I'll defer to Jeff's judgement here. If the device is broken such that
it does not know to return the correct class, then we need to be able to
have a "quirk" table in the userspace tools to handle the list of
devices that are broken in that way.
For config items, we don't want to modify them in any way, we just want
to pass-through the data direct from the device. Look at the sysfs and
proc files for pci config spaces. They are returning binary data stored
in the device directly. We do not want to have to start modifying that
data directly just to handle messed up devices like this.
So this should be handled by yast or other userspace programs properly,
That is done purely due to the way that Microsoft wrote their operating
system. The only way to write a userspace USB driver on windows is to
have it claim to be a HID device. Then the kernel driver correctly
grabs it, and allows userspace programs to take over control of it.
That is why we have such a huge blacklist of HID devices in our kernel,
and so does Apple. All because Windows can not easily handle something
we have been doing for over 7 years now.
And yes, you can now write userspace drivers for all USB devices on
Windows now, but you still have to get your userspace-driver signed, and
the interface is so horrible it's not even funny, so companies are still
avoiding it and using the old "make it claim to be a hid device" hack
for new devices.
So the HID table examples really have nothing to do with the broken
network device, as the HID devices are purposfully created that way.
For this network device, someone just messed up at the manufacturer :)
thanks,
greg k-h
-
