Message ID | 20181010192709.19302-2-marek.vasut+renesas@gmail.com |
---|---|
State | Accepted |
Delegated to: | Tom Rini |
Headers | show |
Series | [U-Boot,1/4] pci: Support parsing PCI controller DT subnodes | expand |
Hi Marek, On Thu, Oct 11, 2018 at 3:28 AM Marek Vasut <marek.vasut@gmail.com> wrote: > > Reword the documentation to make it clear the compatible string is now > optional, yet still matching on it takes precedence over PCI IDs and > PCI classes. > > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> > Cc: Simon Glass <sjg@chromium.org> > Cc: Tom Rini <trini@konsulko.com> > --- > doc/driver-model/pci-info.txt | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> I think I provided my RB tag to previous version, and if there is no changes, I would appreciate it the RB tag was added in the new version to save some time. > diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt > index e1701d1fbc..14364c5c75 100644 > --- a/doc/driver-model/pci-info.txt > +++ b/doc/driver-model/pci-info.txt > @@ -34,11 +34,15 @@ under that bus. > Note that this is all done on a lazy basis, as needed, so until something is > touched on PCI (eg: a call to pci_find_devices()) it will not be probed. > > -PCI devices can appear in the flattened device tree. If they do this serves to > -specify the driver to use for the device. In this case they will be bound at > -first. Each PCI device node must have a compatible string list as well as a > -<reg> property, as defined by the IEEE Std 1275-1994 PCI bus binding document > -v2.1. Note we must describe PCI devices with the same bus hierarchy as the > +PCI devices can appear in the flattened device tree. If they do, their node > +often contains extra information which cannot be derived from the PCI IDs or > +PCI class of the device. Each PCI device node must have a <reg> property, as > +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible > +string list is optional and generally not needed, since PCI is discoverable > +bus, albeit there are justified exceptions. If the compatible string is > +present, matching on it takes precedence over PCI IDs and PCI classes. > + > +Note we must describe PCI devices with the same bus hierarchy as the > hardware, otherwise driver model cannot detect the correct parent/children > relationship during PCI bus enumeration thus PCI devices won't be bound to > their drivers accordingly. A working example like below: > -- Regards, Bin
On Wed, Oct 10, 2018 at 09:27:07PM +0200, Marek Vasut wrote: > Reword the documentation to make it clear the compatible string is now > optional, yet still matching on it takes precedence over PCI IDs and > PCI classes. > > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> > Cc: Simon Glass <sjg@chromium.org> > Cc: Tom Rini <trini@konsulko.com> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Applied to u-boot/master, thanks!
diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt index e1701d1fbc..14364c5c75 100644 --- a/doc/driver-model/pci-info.txt +++ b/doc/driver-model/pci-info.txt @@ -34,11 +34,15 @@ under that bus. Note that this is all done on a lazy basis, as needed, so until something is touched on PCI (eg: a call to pci_find_devices()) it will not be probed. -PCI devices can appear in the flattened device tree. If they do this serves to -specify the driver to use for the device. In this case they will be bound at -first. Each PCI device node must have a compatible string list as well as a -<reg> property, as defined by the IEEE Std 1275-1994 PCI bus binding document -v2.1. Note we must describe PCI devices with the same bus hierarchy as the +PCI devices can appear in the flattened device tree. If they do, their node +often contains extra information which cannot be derived from the PCI IDs or +PCI class of the device. Each PCI device node must have a <reg> property, as +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible +string list is optional and generally not needed, since PCI is discoverable +bus, albeit there are justified exceptions. If the compatible string is +present, matching on it takes precedence over PCI IDs and PCI classes. + +Note we must describe PCI devices with the same bus hierarchy as the hardware, otherwise driver model cannot detect the correct parent/children relationship during PCI bus enumeration thus PCI devices won't be bound to their drivers accordingly. A working example like below:
Reword the documentation to make it clear the compatible string is now optional, yet still matching on it takes precedence over PCI IDs and PCI classes. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> --- doc/driver-model/pci-info.txt | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)