microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
WSL2-Linux-Kernel/arch/cris/include/asm/io.h

26 строки
693 B
C
Исходник Обычный вид История

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
#ifndef _ASM_CRIS_IO_H
#define _ASM_CRIS_IO_H
#include <asm/page.h> /* for __va, __pa */
CRIS v32: remove old GPIO and LEDs code Since we now have a gpiolib driver, remove this code: The gpio-etraxfs driver (along with things like gpio-keys-polled for polling support) replaces the GIO driver implementations in mach-a3 and mach-fs. The various generic external chip drivers replace the "virtual gpio" parts. The generic gpio-leds driver replaces the LED handling. Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Jesper Nilsson <jespern@axis.com>
2015-08-03 21:19:24 +03:00
#ifdef CONFIG_ETRAX_ARCH_V10
[CRIS] Move header files from include to arch/cris/include. Change all users of header files to correct path. Remove some unneeded headers for arch-v32. Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
2008-10-21 19:45:58 +04:00
#include <arch/io.h>
CRIS v32: remove old GPIO and LEDs code Since we now have a gpiolib driver, remove this code: The gpio-etraxfs driver (along with things like gpio-keys-polled for polling support) replaces the GIO driver implementations in mach-a3 and mach-fs. The various generic external chip drivers replace the "virtual gpio" parts. The generic gpio-leds driver replaces the LED handling. Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Jesper Nilsson <jespern@axis.com>
2015-08-03 21:19:24 +03:00
#endif
cris: media platform drivers: fix build On cris arch, the functions below aren't defined: drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read': drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write': drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup': drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop': drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] Yet, they're available, as CONFIG_GENERIC_IOMAP is defined. What happens is that asm/io.h was not including asm-generic/iomap.h. Suggested-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-13 03:06:49 +04:00
#include <asm-generic/iomap.h>
[PATCH] CRIS update: pci Patches to make it possible to add PCI support. Signed-off-by: Mikael Starvik <starvik@axis.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 22:44:40 +04:00
#include <linux/kernel.h>
extern void __iomem * __ioremap(unsigned long offset, unsigned long size, unsigned long flags);
extern void __iomem * __ioremap_prot(unsigned long phys_addr, unsigned long size, pgprot_t prot);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
[PATCH] cris: "extern inline" -> "static inline" "extern inline" doesn't make much sense. Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Mikael Starvik <starvik@axis.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 11:58:44 +03:00
static inline void __iomem * ioremap (unsigned long offset, unsigned long size)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
{
return __ioremap(offset, size, 0);
}
[PATCH] CRIS update: pci Patches to make it possible to add PCI support. Signed-off-by: Mikael Starvik <starvik@axis.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-27 22:44:40 +04:00
extern void iounmap(volatile void * __iomem addr);
extern void __iomem * ioremap_nocache(unsigned long offset, unsigned long size);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
cris: use generic io.h fixes the warning: lib/iomap.c: In function ‘ioread8_rep’: ./arch/cris/include/asm/io.h:139:31: warning: statement with no effect [-Wunused-value] #define insb(port,addr,count) (cris_iops ? cris_iops->read_io(port,addr,1,count) : 0) ^ lib/iomap.c:56:3: note: in definition of macro ‘IO_COND’ is_pio; \ ^ lib/iomap.c:197:16: note: in expansion of macro ‘insb’ IO_COND(addr, insb(port,dst,count), mmio_insb(addr, dst, count)); ^ cris_iops was previously set to NULL (no matter if CONFIG_PCI was set or not), but was removed in commit ab28e96fd1cf ("CRIS v32: remove old GPIO and LEDs code"). Before commit ab28e96fd1cf ("CRIS v32: remove old GPIO and LEDs code"), cris_iops could have been set from an external module, since it was exported, but as commit c24bf9b4cc6a ("CRIS: fix I/O macros") noted, the macros using cris_iops have been broken since first included, so they could never have worked. Because of this, instead of readding cris_iops, remove all special handling of cris_iops. By doing so, we can rely on the default implementation of almost all functions previously defined in our arch specific io.h. Signed-off-by: Niklas Cassel <nks@flawful.org> Signed-off-by: Jesper Nilsson <jespern@axis.com>
2016-09-22 17:44:57 +03:00
#include <asm-generic/io.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
#endif