On Wed, May 30, 2012 at 10:40:30AM -0400, Alan Stern wrote: > On Wed, 30 May 2012, Bjørn Mork wrote: > > > Bjørn Mork <bjorn@xxxxxxx> writes: > > > > > I am not at all sure this is the correct way to fix this, > > > but at least it solves my problem. > > > > Been sleeping on this, and I don't think the fix is entirely correct. > > > > We may have situations where two or more drivers intentionally match the > > same device, assuming the serial driver probe will sort out the correct > > driver. E.g. one driver doing wildcard pid matching for a single vid, > > and another driver matching a single odd device from the same vendor. > > The proposed patch will only allow one of those probes to run and will > > therefore fail if the first called probe fails. > > > > But I don't think we want to move the driver matching after the serial > > driver probing either. That would cause unnecessary probe calls from > > the "wrong" drivers. > > > > So search_serial_device needs to do the match. Does anyone see a > > problem with that? I guess noone here does, unless I express it in code > > :-) So I'll go do that now. > > The new patch looks okay to me. But there's still a problem. > > Greg, as far as I can see, the generic driver is unique in that it uses > _different_ id tables for its USB probing and its serial probing: > > generic_serial_ids is used for USB probing, > > generic_device_ids is used for serial probing. > > So it's still possible that the USB probe may match while the serial > probe is rejected. In the 3.3 kernel such cases were rejected by > generic_probe(), but that routine doesn't exist any more. > > Maybe generic_serial_ids should be removed entirely and replaced with > generic_device_ids? Hm, maybe that would be best. I can't make a patch at the moment, and probably will not be able to for at least a week, but if others are willing to try... :) thanks, greg k-h -- 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
