summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-ixp4xx/include/mach/io.h
Commit message (Collapse)AuthorAgeFilesLines
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ARM: ixp4xx: fix ioport_unmap definitionArnd Bergmann2017-07-271-2/+9
| | | | | | | | | | | | | | | | | An empty macro definition can cause unexpected behavior, in case of the ixp4xx ioport_unmap, we get two warnings: drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] ioport_unmap(card->iobase); drivers/vfio/pci/vfio_pci_rdwr.c: In function 'vfio_pci_vga_rw': drivers/vfio/pci/vfio_pci_rdwr.c:230:15: error: the omitted middle operand in ?: will always be 'true', suggest explicit middle operand [-Werror=parentheses] is_ioport ? ioport_unmap(iomem) : iounmap(iomem); This uses an inline function to define the macro in a safer way. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
* ARM: ixp4xx: use normal prototype for {read,write}s{b,w,l}Arnd Bergmann2017-07-271-6/+17
| | | | | | | | | | | | | | | | | ixp4xx defines the arguments to its __indirect_writesb() and other functions as pointers to fixed-size data. This is not necessarily wrong, and it works most of the time, but it causes warnings in at least one driver: drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv': drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types] SMC_PULL_DATA(lp, data, packet_len - 4); All other definitions of the same functions pass void pointers, so doing the same here avoids the warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
* ARM: ixp4xx: fix read{b,w,l} return typesArnd Bergmann2015-12-011-6/+6
| | | | | | | | | | | | | | | | | | | | On ixp4xx, the readl() function returns an 'unsigned long' output when indirect I/O is used. This is unlike any other platform, and it causes lots of harmless compiler warnings, such as: drivers/ata/libahci.c: In function 'ahci_show_host_version': drivers/ata/libahci.c:254:22: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=] drivers/block/mtip32xx/mtip32xx.c: In function 'mtip_hw_read_registers': drivers/block/mtip32xx/mtip32xx.c:2602:31: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=] drivers/block/cciss.c: In function 'print_cfg_table': drivers/block/cciss.c:3845:25: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=] This changes all six of the ixp4xx specific I/O read functions to return the same types that we have in the normal asm/io.h, to avoid the warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl>
* ARM: ixp4xx: fix {in,out}s{bwl} data typesArnd Bergmann2015-02-181-6/+13
| | | | | | | | | | | | | | | | | | | | | | | Most platforms use void pointer arguments in these functions, but ixp4xx does not, which triggers lots of warnings in device drivers like: net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr': net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1); ^ In file included from include/asm/io.h:214:0, from /git/arm-soc/include/linux/io.h:22, from /git/arm-soc/include/linux/pci.h:31, from net/ethernet/8390/ne2k-pci.c:48: mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *' static inline void insw(u32 io_addr, u16 *vaddr, u32 count) Fixing the drivers seems hopeless, so this changes the ixp4xx code to do the same as the others to avoid the warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl> Cc: Imre Kaloz <kaloz@openwrt.org>
* ARM: ixp4xx: Properly override I/O accessorsThierry Reding2014-11-101-0/+12
| | | | | | | | In order to override accessors properly they must be #define'd so that subsequent generic headers (the one for ARM and finally the architecture independent one) can properly detect it. Signed-off-by: Thierry Reding <treding@nvidia.com>
* ARM: ixp4xx: Fix build with IXP4XX_INDIRECT_PCIArnd Bergmann2014-11-101-4/+12
| | | | | | | | | Provide *_relaxed() accessors and make sure to pass the volatile void __iomem * to accessors rather than the value cast to a u32. This allows ixp4xx to build with IXP4XX_INDIRECT_PCI enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
* ARM: ixp4xx: avoid use of PCIBIOS_MIN_MEM in io.hArnd Bergmann2014-03-211-1/+2
| | | | | | | | | | | | | | | | | | | When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive header file dependency between mach/io.h and asm/pci.h, resulting in a build failure: mach-ixp4xx/include/mach/io.h: In function 'is_pci_memory': mach-ixp4xx/include/mach/io.h:53:18: error: 'PCIBIOS_MIN_MEM' undeclared (first use in this function) return (addr >= PCIBIOS_MIN_MEM) && (addr <= 0x4FFFFFFF); ^ mach-ixp4xx/include/mach/io.h:53:18: note: each undeclared identifier is reported only once for each function it appears in We can work around this by referencing the pcibios_min_mem variable directly through an extern declaration, rather than using the macro. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl>
* ARM: kill off __mem_pciRob Herring2012-03-061-5/+1
| | | | | | | | | | | | | | | | | __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
* ARM: ixp4xx: use runtime ioremap hookRob Herring2012-03-061-18/+0
| | | | | | | | | Convert ixp4xx platforms to use run-time ioremap hook instead of the compile time hook. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl>
* ARM: io: remove IO_SPACE_LIMIT from platforms with ISA/PCI and 64K windowRussell King2011-08-171-2/+0
| | | | | | | | | | Remove IO_SPACE_LIMIT definitions from platforms which have a well defined ISA or PCI, and has a 64K window. EBSA110 - well defined set of ISA devices. Footbridge, Integrator, IXP4xx, VT8500 - PCI platforms. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: io: make iounmap() a simple macroRussell King2010-12-081-2/+2
| | | | | | | | | | Defining iounmap() with arguments prevents it from being used as a function pointer, causing platforms to work around this. Instead, define it to be a simple macro. Do the same for __arch_io(re|un)map too. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* IXP4xx: Fix sparse warnings in I/O primitives.Krzysztof Hałasa2010-05-271-3/+3
| | | | Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Extend PCI MMIO indirect address space to 1 GB.Krzysztof Hałasa2009-12-051-12/+10
| | | | | | | | | IXP4xx CPUs can indirectly access the whole 4 GB PCI MMIO address space (using the non-prefetch registers). Previously the available space depended on the CPU variant, since one of the IXP43x platforms needed more than the usual 128 MB. 1 GB should be enough for everyone, and if not, we can trivially increase it. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Fix compilation failure with CONFIG_IXP4XX_INDIRECT_PCI.Krzysztof Hałasa2009-12-051-8/+15
| | | | | | | | Instead of including the heavy linux/mm.h for VMALLOC_START, test the addresses against PCI MIN and MAX addresses. Indirect PCI uses 1:1 mapping for MMIO space making this change possible. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Drop "__ixp4xx_" prefix from in/out/ioread/iowrite functions for ↵Krzysztof Hałasa2009-12-051-95/+55
| | | | | | clarity. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Rename indirect MMIO primitives from __ixp4xx_* to __indirect_*.Krzysztof Hałasa2009-12-051-57/+50
| | | | Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* ARM: fix insl() and outsl() endianness on IXP4xx architecture.Krzysztof Hałasa2009-12-051-3/+4
| | | | | | The repetitive in/out functions must preserve order, not value. Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changesMikael Pettersson2009-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2.6.31-rc kernels don't boot on my ixp4xx box (ds101), because the libata driver doesn't find the PCI IDE controller any more. 2.6.30 was fine. I traced this to a PCI update (1f82de10d6b1d845155363c895c552e61b36b51a) in 2.6.30-git19. Diffing the kernel boot logs from 2.6.30-git18 and 2.6.30-git19 illustrates the breakage: > --- dmesg-2.6.30-git18 2009-08-04 01:45:22.000000000 +0200 > +++ dmesg-2.6.30-git19 2009-08-04 01:45:46.000000000 +0200 > @@ -26,6 +26,13 @@ > pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot > pci 0000:00:02.2: PME# disabled > PCI: bus0: Fast back to back transfers disabled > +pci 0000:00:01.0: BAR 0: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 1: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 2: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 3: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:01.0: BAR 4: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:02.0: BAR 4: can't allocate I/O resource [0x10000-0xffff] > +pci 0000:00:02.1: BAR 4: can't allocate I/O resource [0x10000-0xffff] > bio: create slab <bio-0> at 0 > SCSI subsystem initialized > NET: Registered protocol family 2 > @@ -44,11 +51,7 @@ > console [ttyS0] enabled > serial8250.0: ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale > Driver 'sd' needs updating - please use bus_type methods > -PCI: enabling device 0000:00:01.0 (0140 -> 0141) > -scsi0 : pata_artop > -scsi1 : pata_artop > -ata1: PATA max UDMA/100 cmd 0x1050 ctl 0x1060 bmdma 0x1040 irq 28 > -ata2: PATA max UDMA/100 cmd 0x1058 ctl 0x1064 bmdma 0x1048 irq 28 > +pata_artop 0000:00:01.0: no available native port > Using configured DiskOnChip probe address 0x50000000 > DiskOnChip found at 0x50000000 > NAND device: Manufacturer ID: 0x98, Chip ID: 0x73 (Toshiba NAND 16MiB 3,3V 8-bit) The specific change in 1f82de10d6b1d845155363c895c552e61b36b51a responsible for this failure turned out to be the following: > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, > res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN; > if (type == pci_bar_io) { > l &= PCI_BASE_ADDRESS_IO_MASK; > - mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff; > + mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT; > } else { > l &= PCI_BASE_ADDRESS_MEM_MASK; > mask = (u32)PCI_BASE_ADDRESS_MEM_MASK; Every arch except arm's ixp4xx defines IO_SPACE_LIMIT as an all-bits-one bitmask, typically -1UL but sometimes only a 16-bit 0x0000ffff. But ixp4xx defines it as 0xffff0000, which is now causing the PCI failures. Russell King noted that ixp4xx has 64KB PCI IO space, so IO_SPACE_LIMIT should be 0x0000ffff. This patch makes that change, which fixes the PCI failures on my ixp4xx box. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
* [ARM] Add a common typesafe __io implementationRussell King2008-11-301-1/+1
| | | | | | | | As Al did for Versatile in 2ad4f86b60b649fd7428265c08d73a3bd360c81b, add a typesafe __io implementation for platforms to use. Convert platforms to use this new simple typesafe implementation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] ixp4xx: clean up includesRussell King2008-11-281-2/+0
| | | | | | | mach/io.h doesn't need linux/mm.h. mach/dma.h doesn't need linux/device.h, asm/page.h or mach/hardware.h Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King2008-08-071-0/+569
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-09 21:40:09 +0000