Re: [PATCH 1/2] usbcore/driver: Fix specific driver selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2020-09-17 at 12:59 +0300, M. Vefa Bicakci wrote:
> This commit resolves two minor bugs in the selection/discovery of
> more
> specific USB device drivers for devices that are currently bound to
> generic USB device drivers.
> 
> The first bug is related to the way a candidate USB device driver is
> compared against the generic USB device driver. The code in
> is_dev_usb_generic_driver() used to unconditionally use
> to_usb_device_driver() on each device driver, without verifying that
> the device driver in question is a USB device driver (as opposed to a
> USB interface driver).

You could also return early if is_usb_device() fails in
__usb_bus_reprobe_drivers(). Each of the interface and the device
itself is a separate "struct device", and "non-interface" devices won't
have interface devices assigned to them.


> The second bug is related to the logic that determines whether a
> device
> currently bound to a generic USB device driver should be re-probed by
> a
> more specific USB device driver or not. The code in
> __usb_bus_reprobe_drivers() used to have the following lines:
> 
>   if (usb_device_match_id(udev, new_udriver->id_table) == NULL &&
>       (!new_udriver->match || new_udriver->match(udev) != 0))
>  		return 0;
> 
>   ret = device_reprobe(dev);
> 
> As the reader will notice, the code checks whether the USB device in
> consideration matches the identifier table (id_table) of a specific
> USB device_driver (new_udriver), followed by a similar check, but
> this
> time with the USB device driver's match function. However, the match
> function's return value is not checked correctly. When match()
> returns
> zero, it means that the specific USB device driver is *not*
> applicable
> to the USB device in question, but the code then goes on to reprobe
> the
> device with the new USB device driver under consideration. All this
> to
> say, the logic is inverted.

Could you split that change as the first commit in your patchset?

I'll test your patches locally once you've respun them. Thanks for
working on this.

Cheers




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux