linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: Johan Hovold <johan@kernel.org>,
	gregkh@linuxfoundation.org, stern@rowland.harvard.edu,
	linux-usb@vger.kernel.org
Subject: Re: Can't we have stricter matching for vendor specific devices?
Date: Tue, 21 Jan 2020 14:24:37 +0100	[thread overview]
Message-ID: <20200121132437.GB8375@localhost> (raw)
In-Reply-To: <1579523791.17973.31.camel@suse.com>

On Mon, Jan 20, 2020 at 01:36:31PM +0100, Oliver Neukum wrote:
> Hi Johan,
> 
> I have looked at your heroic efforts at sanity checking
> and I cannot help myself wondering whether this is a winning
> strategy. Shall we really specify for each device how many
> endpoints it is suposed to have in the probe() method?
> 
> Could we extend the matching by a minimum and maximum number
> of endpoints and masks for permissible endpoint types?
> 
> For class devices this is impossible, but the majority of
> drivers are for vendor specific devices.

I have considered it, but I don't think that encoding this in the device
id table would work. Just take something like the option driver with
about a thousand entries. Encoding what is essentially a driver
requirement would just waste a lot of space.

It's also not clear how to encode the various ways that drivers look up
endpoints, such as by number or by descriptor order, and often in
various combinations (e.g. an endpoint can be optional or the driver can
handle both interrupt and bulk types). For this to work generally, you'd
also need to deal with drivers switching altsettings (e.g. which
altsetting should core verify?).

Any change in this direction would also risk introducing regressions as
we don't have access to the descriptors for devices that have already
been added.

Instead I came to the conclusion that we should treat this just like any
other resource allocation and to provide helpers for drivers to use (I
have some more work in this area coming).

Just like it's a bug to not check the return value from kmalloc() or
platform_get_irq() so should trying to use an endpoint before making
sure it is available be considered a bug even in cases where it doesn't
outright crash the kernel currently. And we should of course always
sanity check external input.

One way of enforcing this would be to eventually require drivers to
initialise URBs using a struct usb_host_endpoint which they would have
lookup up using common helpers. There's even a comment by Alan in
usb_submit_urb() documenting this intention (see 5b653c79c04c ("USB: add
urb->ep")).

Johan

      reply	other threads:[~2020-01-21 13:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 12:36 Can't we have stricter matching for vendor specific devices? Oliver Neukum
2020-01-21 13:24 ` Johan Hovold [this message]

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=20200121132437.GB8375@localhost \
    --to=johan@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=stern@rowland.harvard.edu \
    /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).