From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH 2/11] cell: generalize io-workarounds code
Date: Wed, 02 Apr 2008 22:00:52 +1100 [thread overview]
Message-ID: <1207134052.10388.251.camel@pasglop> (raw)
In-Reply-To: <20080402.195215.-1300526901.kouish@swc.toshiba.co.jp>
On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> Benjamin Herrenschmidt <benh@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.
next prev parent reply other threads:[~2008-04-02 11:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 12:20 [PATCH 2/11] cell: generalize io-workarounds code Ishizaki Kou
2008-03-24 10:41 ` Benjamin Herrenschmidt
2008-03-24 10:44 ` Benjamin Herrenschmidt
2008-03-27 11:02 ` Ishizaki Kou
2008-03-27 21:08 ` Benjamin Herrenschmidt
2008-04-02 10:52 ` Ishizaki Kou
2008-04-02 11:00 ` Benjamin Herrenschmidt [this message]
2008-04-04 6:42 ` Ishizaki Kou
2008-04-04 7:50 ` Benjamin Herrenschmidt
2008-04-09 7:46 ` Ishizaki Kou
2008-04-16 7:18 ` Benjamin Herrenschmidt
2008-04-17 1:48 ` Benjamin Herrenschmidt
2008-04-24 3:07 ` Ishizaki Kou
2008-04-24 3:30 ` Benjamin Herrenschmidt
2008-04-24 3:10 ` Ishizaki Kou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1207134052.10388.251.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=kou.ishizaki@toshiba.co.jp \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.