Re: [PATCH v14 1/9] LIB: Introduce a generic PIO mapping method

[John Garry]

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