faking or posing as a specific USB ID?

faking or posing as a specific USB ID?

[Jani Monoses]

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.

In particular, quickly trying out a new webcam by asking/duping various 
v4l webcam drivers to see it as another ID they already handle well, and
when one is found only then modifying the sources to add it to the list 
of supported devices. There are quite a few devices that have the same 
chip combinations inside and this method would allow easier testing for 
less technical people, and would also save time for those who can build 
kernels.

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.

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 ?

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.

thanks for any comments or pointers you may have

Jani

Re: faking or posing as a specific USB ID?

[Greg KH]

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