Greg KH <greg@xxxxxxxxx> writes: > On Fri, May 11, 2012 at 11:02:56AM +0200, Bjørn Mork wrote: >> A number of USB drivers are unable to successfully probe a new >> device without some driver specific information in the >> driver_info field. By copying the driver_info from the first >> device in the static device id list, we can enable dynamic >> device IDs for such drivers as well. > > Ah, nice hack :) Thinking more about it, probably too much of a hack. But thanks for looking anyway. >> This will make the first device a generic template for dynamic >> IDs, with no way to specify another template device. > > Is that a real problem? The first entry could be a weird device needing special probing, while other entries are more suitable as generic template devices. I know I did just that in the qmi_wwan driver for example. But if that's a problem, then it can be fixed by rearranging the entries. There are also examples of class drivers where the first entries are blacklist entries, like cdc_ether for example. These won't work any better/worse with this hack (as the blacklist marker is driver_info being 0), but they could in theory have worked if there was some way to select another template device. What's worse is that there are examples of drivers where the first entry results in abnormal probing, like cdc-acm, while driver_info == 0 gives normal probing. Which I believe makes this hack unacceptable. > I like the idea, but I wonder how well this will really work for most > devices. You say it works for the usbnet drivers, what about others? My working theory was that it wouldn't make anything worse, but I was wrong as noted above. It worked for some usbnet drivers, but not all. And it will make at least one driver (cdc-acm) behave very unexpected. I'll think this over again and see if I can come up with something better. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
