On Mon, Jul 20, 2020 at 9:44 AM Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> wrote:Limited test shows most drivers can deal with that. But We'll aware the problem,
It can be very big on LS7A PCH systems.Does this mean that firmware may already have assigned "high" I/O space
Signed-off-by: Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx>
---
* On MIPS I/O ports are memory mapped, so we access them using normal
diff --git a/arch/mips/include/asm/mach-loongson64/spaces.h b/arch/mips/include/asm/mach-loongson64/spaces.h
index 3de0ac9d8829..b99b43854929 100644
--- a/arch/mips/include/asm/mach-loongson64/spaces.h
+++ b/arch/mips/include/asm/mach-loongson64/spaces.h
@@ -11,8 +11,7 @@
#define PCI_IOSIZE SZ_16M
#define MAP_BASE (PCI_IOBASE + PCI_IOSIZE)
-/* Reserved at the start of PCI_IOBASE for legacy drivers */
-#define MMIO_LOWER_RESERVED 0x10000
+#define IO_SPACE_LIMIT 0x00ffffff
numbers for devices? I'm not sure how well device drivers can generally
deal with port numbers that don't fit into a 16-bit integer.
Is it possible to run a 32-bit kernel on these machines? If yes, than
taking up 16MB of virtual addresses may also become a problem.
In practice, one should rarely need more than a few kb worth ofI must blame stupid hardware design here. The LPC Controller (for ISA device) can eat
port numbers, unless you expect to see hundreds of legacy PCI
devices.
Arnd