linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Bastien Nocera <hadess@hadess.net>
Cc: linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>
Subject: Re: [PATCH 4/5] USB: Select better matching USB drivers when available
Date: Wed, 9 Oct 2019 13:28:10 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1910091324300.1603-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <7b3877fa575212e06b12136c4646e8a220f65cdb.camel@hadess.net>

On Wed, 9 Oct 2019, Bastien Nocera wrote:

> On Wed, 2019-10-09 at 10:43 -0400, Alan Stern wrote:
> > On Wed, 9 Oct 2019, Bastien Nocera wrote:
> > 
> > > Now that USB device drivers can reuse code from the generic USB
> > device
> > > driver, we need to make sure that they get selected rather than the
> > > generic driver. Add an id_table and match vfunc to the
> > usb_device_driver
> > > struct, which will get used to select a better matching driver at
> > > ->probe time.
> > > 
> > > This is a similar mechanism to that used in the HID drivers, with
> > the
> > > generic driver being selected unless there's a better matching one
> > found
> > > in the registered drivers (see hid_generic_match() in
> > > drivers/hid/hid-generic.c).
> > > 
> > > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > > ---
> > >  drivers/usb/core/driver.c  | 15 +++++++++++++--
> > >  drivers/usb/core/generic.c | 29 +++++++++++++++++++++++++++++
> > >  include/linux/usb.h        |  2 ++
> > >  3 files changed, 44 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> > > index 50f92da8afcf..27ce63ed902d 100644
> > > --- a/drivers/usb/core/driver.c
> > > +++ b/drivers/usb/core/driver.c
> > > @@ -819,13 +819,24 @@ static int usb_device_match(struct device
> > *dev, struct device_driver *drv)
> > >  {
> > >       /* devices and interfaces are handled separately */
> > >       if (is_usb_device(dev)) {
> > > +             struct usb_device *udev;
> > > +             struct usb_device_driver *udrv;
> > >  
> > >               /* interface drivers never match devices */
> > >               if (!is_usb_device_driver(drv))
> > >                       return 0;
> > >  
> > > -             /* TODO: Add real matching code */
> > > -             return 1;
> > > +             udev = to_usb_device(dev);
> > > +             udrv = to_usb_device_driver(drv);
> > > +
> > > +             if (udrv->id_table &&
> > > +                 usb_device_match_id(udev, udrv->id_table) !=
> > NULL) {
> > > +                     return 1;
> > > +             }
> > > +
> > > +             if (udrv->match)
> > > +                     return udrv->match(udev);
> > > +             return 0;
> > 
> > What happens if the subclass driver's probe routine returns an
> > error?  
> > Don't you still want the device to be bound to the generic driver?
> 
> I don't know whether that's what you'd want to do. But if we did,
> that'd only be for devices which have "generic_init" set.
> 
> We'd need to remember the result of the ->probe() call at the end of
> usb_probe_device() (as modified in patch 2), and only call the generic
> driver (not the specific device driver)'s functions in later usage.
> 
> Is that what you would expect?

No, that's not quite it.

Here's what should happen when the subclass driver is being probed:
First, call the generic_probe routine, and return immediately if that
fails.  Then call the subclass driver's probe routine.  If that gets an
error, fail the probe call but tell the device core that the device is
now bound to the generic driver, not to the subclass driver.

Alan Stern


  reply	other threads:[~2019-10-09 17:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 13:43 [PATCH 0/5] Add Apple MFi fastcharge USB device driver Bastien Nocera
2019-10-09 13:43 ` [PATCH 1/5] USB: Export generic USB device driver functions Bastien Nocera
2019-10-09 13:43 ` [PATCH 2/5] USB: Make it possible to "subclass" usb_device_driver Bastien Nocera
2019-10-09 14:34   ` Alan Stern
2019-10-09 14:41     ` Alan Stern
2019-10-10  8:10     ` Bastien Nocera
2019-10-10  9:58   ` kbuild test robot
2019-10-09 13:43 ` [PATCH 3/5] USB: Implement usb_device_match_id() Bastien Nocera
2019-10-09 14:36   ` Alan Stern
2019-10-09 15:40     ` Bastien Nocera
2019-10-09 17:29       ` Alan Stern
2019-10-09 13:43 ` [PATCH 4/5] USB: Select better matching USB drivers when available Bastien Nocera
2019-10-09 14:43   ` Alan Stern
2019-10-09 15:35     ` Bastien Nocera
2019-10-09 17:28       ` Alan Stern [this message]
2019-10-09 18:24         ` Bastien Nocera
2019-10-09 18:45           ` Alan Stern
2019-10-10  8:26             ` Bastien Nocera
2019-10-10 14:19               ` Alan Stern
2019-10-10 10:33   ` kbuild test robot
2019-10-09 13:43 ` [PATCH 5/5] USB: Add driver to control USB fast charge for iOS devices Bastien Nocera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1910091324300.1603-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hadess@hadess.net \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).