On Tue, 29 May 2012, Bjørn Mork wrote: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > On Tue, 29 May 2012, Bjørn Mork wrote: > > > >> We need to make sure that the USB serial driver we found > >> matches the USB driver whose probe we are currently > >> executing. Otherwise we will end up with USB serial > >> devices bound to the correct serila driver but wrong > >> USB driver. > >> > >> This is a real problem for the generic USB serial driver > >> because it matches any device. > > > > Do you have any idea why this hasn't shown up before? It's not at all > > clear why the recent changes to the usb-serial core should cause this > > to start happening. > > No, that is not clear to me either. The probe is not changed, so there > shouldn't be anything preventing this from happening before the new > registration model either. > > But I only noticed it after starting running the new code. I assume it > must have something to do with how the drivers are registered, since > that's the only new part, but I could be entirely wrong. Why would the > old code only run the "correct" probe anyway? Does the new registration > somehow change the probing order? The probing order is determined by the order in which the drivers are registered originally. As far as I can see, that hasn't changed. If you want to find out exactly what drivers get probed for a device, enable CONFIG_DEBUG_DRIVER (or manually change the pr_debug line in drivers/base/dd.c:driver_probe_device() to pr_info). The results will depend on whether or not the usb-serial drivers are built as modules. Maybe the same thing would have happened in 3.3, which didn't have the new registration code. Can you test it? Alan Stern -- 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
