qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v8 07/11] pci: introduce a parser for pci device


From: Gleb Natapov
Subject: [Qemu-devel] Re: [PATCH v8 07/11] pci: introduce a parser for pci device path
Date: Mon, 15 Nov 2010 11:03:48 +0200

On Mon, Nov 15, 2010 at 05:57:40PM +0900, Isaku Yamahata wrote:
> On Mon, Nov 15, 2010 at 10:06:13AM +0200, Michael S. Tsirkin wrote:
> > On Mon, Nov 15, 2010 at 04:30:43PM +0900, Isaku Yamahata wrote:
> > > introduce a function to parse pci device path of
> > > the format, [Domain:]Slot.Function:Slot.Function....:Slot.Function.
> > > 
> > > Signed-off-by: Isaku Yamahata <address@hidden>
> > 
> > Hmm.
> > How about we use openfirmware path like what Gleb's patch does,
> > with a fallback to bus:dev.fn for when it's unambiguous?
> 
> Okay, let me check my understanding of the format.
> 
> The openfirmware path in pci case looks like
> /pci@<ioport>/<device name>@<slot>,<func>/.../<device name>@<slot>,<func>
> 
> "pci@<ioport>" corresponds to pci domain. So <mmio address> should be
> also supported in addition to <ioport>.
> 
Correct.

> Maybe we'd like "<device name>@" to be optional.
> So the parser would accept something like
> /{<ioport>, <mmio addr>}/<slot>,<func>/.../<slot>,<func>
My patch series has pci_dev_fw_name() function that fills in <device name>
for you, so no reason to make it optional. If you still want to make it
optional @ should stay, so it should be /@ioport/@slot.func/

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]