[PATCH 2/11] cell: generalize io-workarounds code

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Apr 2 22:00:52 EST 2008


On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> > > As you said, if read/write/in/out functions take device parameter,
> > > taking I/O function pointers into the dev_archdata structure should be
> > > the best solution. But they don't take device parameter, and they must
> > > search I/O function pointers with address parameter. I think it's
> > > better they search pointers from bus bridges, because access mothod
> > > for a device on its parent bus bridge, not device itself.
> > 
> > What I meant is that if the pointers are in dev_archdata, we can
> > populate with a different set of pointers for PCI vs. PCI-E.
> 
> I'm afraid I misunderstood your opinion.
> 
> My concern is how to find a device by address when I/O function
> pointers are in dev_archdata.
> 
> You must select the appropriate device with an address, because all
> I/O functions, read/write/in/out don't have device parameter. If the
> address is in MMIO space, you can set 'token' to the address to select
> the device. But in IO space, you can't set 'token' to the I/O port
> address. Thefore you must scan all devices to select the device.
> 
> Do you have any better solution?

No, you are right. The EEH code has a way to go back to the device but
it has significant overhead. Let's stick to your current approach.

Cheers,
Ben.





More information about the Linuxppc-dev mailing list