From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Sun, 10 May 2009 20:44:28 +0000 Subject: Re: faking or posing as a specific USB ID? Message-Id: <20090510204428.GA26748@kroah.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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