Re: /sys/bus/pci/drivers//new_id

Greg KH
2006-12-04T22:59:22Z

On Wed, Nov 29, 2006 at 09:18:04PM +0000, Russell King wrote:
> Unfortunately, the .../new_id feature does not work with the 8250_pci
> driver.
>
> The reason for this comes down to the way .../new_id is implemented.
> When PCI tries to match a driver to a device, it checks the modules
> static device ID tables _before_ checking the dynamic new_id tables.
>
> When a driver is capable of matching by ID, and falls back to matching
> by class (as 8250_pci does), this makes it absolutely impossible to
> specify a board by ID, and as such the correct driver_data value to
> use with it.
>
> Let's say you have a serial board with vendor 0x1234 and device 0x5678.
> It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
>
> On boot, this card is matched to the 8250_pci driver, which tries to
> probe it because it matched using the class entry. The driver finds
> that it is unable to automatically detect the correct settings to use,
> so it returns -ENODEV.
>
> You know that the information the driver needs is to match this card
> using a device_data value of '7'. So you echo 1234 5678 0 0 0 0 7
> into new_id.
>
> The kernel attempts to re-bind 8250_pci to this device. However,
> because it scans the PCI driver tables, it _again_ matches the class
> entry which has the wrong device_data. It fails.
>
> End of story. You can't support the card without rebuilding the
> kernel (or writing a specific PCI probe module to support it.)
>
> So, can we make new_id override the driver-internal PCI ID tables?
> IOW, like this:

Yes, you are right, I'll add this to my queue.

thanks,

greg k-h