Messages in this thread | | | Subject | Re: [PATCH v14 1/9] LIB: Introduce a generic PIO mapping method | From | John Garry <> | Date | Tue, 20 Feb 2018 15:06:51 +0000 |
| |
On 20/02/2018 14:33, Andy Shevchenko wrote: > On Mon, Feb 19, 2018 at 7:48 PM, John Garry <john.garry@huawei.com> wrote: >> From: Zhichang Yuan <yuanzhichang@hisilicon.com> >> >> 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
| |