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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/