Re: [PATCH v4] PCI: add kernel parameter to override devid<->driver mapping.

[Bjorn Helgaas]

Hi Marcel,

I'm not quite clear on what the objective is here, so I apologize for
some questions that probably seem silly.

On Mon, Oct 20, 2014 at 8:04 AM, Marcel Apfelbaum <marcel.a@xxxxxxxxxx> wrote:
> Scanning a lot of devices during boot requires a lot of time.

I think what takes a lot of time is the .probe() method for some
drivers, right?  I first thought you meant that it took a long time
for the PCI core to enumerate a lot of devices, but you're not
changing anything there.

If the intent is to reduce boot time, I don't think this is a general
solution.  Drivers should be able to schedule asynchronous things in
their .probe() methods if necessary.

> On other scenarios there is a need to bind a driver to a specific slot.

A short example here would be good.  Are you talking about something
like binding a NIC driver to one device while leaving others unbound
for use by guests?

> Binding devices to pci-stub driver does not work,
> as it will not differentiate between devices of the
> same type.

I assume you mean booting with "pci-stub.ids=$VENDOR:$DEVICE" will
make pci-stub bind to *all* matching devices, and you only want it to
bind to some.  Maybe pci-stub could be extended to pay attention to
PCI bus addresses in addition to vendor/device IDs.

> Using some start scripts is error prone.
>
> The solution leverages driver_override functionality introduced by
>
>         commit: 782a985d7af26db39e86070d28f987cad21313c0
>         Author: Alex Williamson <alex.williamson@xxxxxxxxxx>
>         Date:   Tue May 20 08:53:21 2014 -0600
>
>         PCI: Introduce new device binding path using pci_dev.driver_override
>
> In order to bind PCI slots to specific drivers use:
>         pci=driver[xxxx:xx:xx.x]=foo,driver[xxxx:xx:xx.x]=bar,...

If/when you address Alex's comments about other bus types, can you
also update the changelog to use the canonical commit reference
format, i.e., 782a985d7af2 ("PCI: Introduce new device binding path
using pci_dev.driver_override") in this case?

PCI bus numbers are mutable, e.g., they can change with hotplug or
other configuration changes.  But I don't have any better suggestion,
so I guess all we can do is be aware of this.

Speaking of hotplug, this is only a boot-time kernel parameter, with
no opportunity to use this, e.g., to add slot/driver pairs, after
boot.  Do you not need that because of Alex's driver_override thing?
How can we integrate this all together into a coherent whole?  I'm a
little confused as to how this would all be documented in a form
usable by end-users.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/