On 20/02/2018 14:33, Andy Shevchenko wrote:
On Mon, Feb 19, 2018 at 7:48 PM, John Garry <john.garry@xxxxxxxxxx> wrote:
From: Zhichang Yuan <yuanzhichang@xxxxxxxxxxxxx>
In commit 41f8bba7f555 ("of/pci: Add pci_register_io_range() and
pci_pio_to_address()"), a new I/O space management was supported. With
that driver, the I/O ranges configured for PCI/PCIe hosts on some
architectures can be mapped to logical PIO, converted easily between
CPU address and the corresponding logicial PIO. Based on this, PCI
I/O devices can be accessed in a memory read/write way through the
unified in/out accessors.
But on some archs/platforms, there are bus hosts which access I/O
peripherals with host-local I/O port addresses rather than memory
addresses after memory-mapped.
To support those devices, a more generic I/O mapping method is introduced
here. Through this patch, both the CPU addresses and the host-local port
can be mapped into the logical PIO space with different logical/fake PIOs.
After this, all the I/O accesses to either PCI MMIO devices or host-local
I/O peripherals can be unified into the existing I/O accessors defined in
asm-generic/io.h and be redirected to the right device-specific hooks
based on the input logical PIO.
Hi Andy,
+#define PIO_INDIRECT 0x01UL /* indirect IO flag */
+#define PIO_CPU_MMIO 0x00UL /* memory mapped io flag */
It looks like bitfield, but from use I don't see it.
IIRC, the orignal intention was that this would be a bit value in a
bitfield.
Perhaps use enum instead?
I'll change to enum to be clear.
+ resource_size_t hwaddr = -1;
+unsigned long
+ return -1;
+ return -1;
+unsigned long
+ return -1;
+type logic_in##bw(unsigned long addr) \
+ type ret = -1; \
All types above are unsigned. I'm not sure it's the best approach to
use -1 implicitly casted to unsigned type.
I would rather use ~0UL or alike.
Yes, I can change these.
Much appreciated,
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
