Re: [RFC] PCI: clean up the dynamic pci id logic

[Greg KH <greg@kroah.com>]

On Fri, Jul 01, 2005 at 03:52:32PM -0400, Adam Belay wrote:
> I was wondering why we need dynamic id support in the driver core.  Is there
> an issue where the bind/unbind mechanism requires this feature?  I was hoping
> bind/unbind would replace it.

No, bind/unbind (well bind, unbind doesn't care) only will work if the
driver's probe function can accept the device.  Without dynamic ids,
it's not possible to have a driver bind to a device that it does not
know about.

I want to put the sysfs file, and a common callback in the driver core,
to make it easier for busses to support dynamic ids.  That's why I am
suggesting we add it there.  But I'll play with implementing it and see
if it's really worth it or not.

Either way, this patch fixes up the pci code to make the dynamic ids for
it, much more readable and smaller.

> I understand that there are PCI drivers that use .driver_data and read from
> their ID table (e.g. pci_serial), but we don't really want the user modifying
> these IDs because they're often attached to some device specific tables.

True, if you look at the current pci dynamic id stuff, we don't set the
driver_data field at all.  Some USB drivers use this field too.

> It was my understanding that the *probe function should be responsible for
> accepting any device, and then gracefully fail if it knows it will be unable
> to support it.  For some drivers this could include failing if it's missing
> from the ID table.

For this to happen, we would have to rewrite all drivers :(  Right now
they assume that the MODULE_TABLE must have matched, in order for the
probe() call to be called.  

Remember, probe() of most busses pass in a valid id structure too...

> If the driver developer requires the driver to match to an unknown
> pool of devices, then the *probe function could be made more advanced.

If the bus/driver core supports dynamic ids, then the individual drivers
don't have to be changed at all :)

thanks,

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