On Sun, May 10, 2009 at 11:25:42PM +0300, Jani Monoses wrote: > Hello, > > the lkml is probably a better list for this question but there may be a > udev answer to it. > > The problem I am trying to find the most elegant solution for is the > following: given a certain driver that supports USB device AAAA:BBBB try > to see if it works with new device CCCC:DDDD without rebuilding (or > hexediting :) the module by somehow asking it to treat the new device as > if it were AAAA:BBBB. Just use the "new_id" files in sysfs and the bind and unbind files there to do the binding after writing the new id to the driver. That is what those files are there for. > This may not be possible with the current kernel, as drivers only look > for devices hardcoded in their .initdata sections. While some can be > told via a new_id sysfs attribute to add a new ID dynamically to their > supported list, webcams and probably other families of devices would > need to specify extra parameters (ex: bridge and img sensor tuple) > besides the ID. If a driver needs more than the id, then no, the new_id stuff will not work, sorry. > Does udev have some way of faking insertion events or altering an event > coming from the kernel and sending it back that way? A rule that says in > effect, rename USB ID AAAA:BBBB to CCCC:DDDD ? No, that will not work, use bind/unbind/new_id from userspace through sysfs. > If not, the the ID matching code in the kernel is the one I think could > be told via a syfs atribute similar to new_id. Yes, use that :) hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
