From: Michal Pecio <michal.pecio@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: yicongsrfy@163.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, oliver@neukum.org, pabeni@redhat.com
Subject: Re: [PATCH net v5 2/3] net: usb: ax88179_178a: add USB device driver for config selection
Date: Fri, 17 Oct 2025 19:15:11 +0200 [thread overview]
Message-ID: <20251017191511.6dd841e9.michal.pecio@gmail.com> (raw)
In-Reply-To: <db3db4c6-d019-49d0-92ad-96427341589c@rowland.harvard.edu>
On Fri, 17 Oct 2025 09:10:22 -0400, Alan Stern wrote:
> On Fri, Oct 17, 2025 at 10:42:29AM +0800, yicongsrfy@163.com wrote:
> > > > + /* The vendor mode is not always config #1, so to find it out. */
> > > > + c = udev->config;
> > > > + num_configs = udev->descriptor.bNumConfigurations;
> > > > + for (i = 0; i < num_configs; (i++, c++)) {
> > > > + struct usb_interface_descriptor *desc = NULL;
> > > > +
> > > > + if (!c->desc.bNumInterfaces)
> > > > + continue;
> > > > + desc = &c->intf_cache[0]->altsetting->desc;
> > > > + if (desc->bInterfaceClass == USB_CLASS_VENDOR_SPEC)
> > > > + break;
> > > > + }
> > > > +
> > > > + if (i == num_configs)
> > > > + return -ENODEV;
> > > > +
> > > > + return c->desc.bConfigurationValue;
> > > > +}
> > >
> > > I wonder how many copies of this code would justify making it some
> > > sort of library in usbnet or usbcore?
> >
> > Yes, there are many similar code instances in the USB subsystem.
> > However, I'm primarily focused on the networking subsystem,
> > so my abstraction work here might not be thorough enough.
> > Hopefully, an experienced USB developer may can optimize this issue.
>
> Would it help to have a USB quirks flag that tells the core to prefer
> configurations with a USB_CLASS_VENDOR_SPEC interface class when we
> choose the device's configuration? Or something similar to that (I'm
> not sure exactly what you are looking for)?
Either that or just patch usb_choose_configuration() to prefer vendor
config *if* an interface driver is available. But not 100% sure if that
couldn't backfire, so maybe only if the driver asked for it, indeed.
I was looking into making a PoC of that (I have r8152 with two configs)
but there is a snag: r8152-cfgselector bails out if a vendor-specific
check indicates the chip isn't a supported HW revision.
So to to fully replicate r8152-cfgselector, core would neet to get new
"pre_probe" callback in the interface driver. It gets complicated.
A less complicated improvement could be moving the common part of all
cfgselectors into usbnet. Not sure if it's worth it yet for only two?
Regards,
Michal
next prev parent reply other threads:[~2025-10-17 17:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 7:53 [PATCH net v5 0/3] ax88179 driver optimization yicongsrfy
2025-10-11 7:53 ` [PATCH net v5 1/3] net: usb: support quirks in cdc_ncm yicongsrfy
2025-10-11 7:53 ` [PATCH net v5 2/3] net: usb: ax88179_178a: add USB device driver for config selection yicongsrfy
2025-10-13 9:07 ` Michal Pecio
2025-10-17 2:42 ` yicongsrfy
2025-10-17 13:10 ` Alan Stern
2025-10-17 17:15 ` Michal Pecio [this message]
2025-10-18 2:27 ` Alan Stern
2025-10-18 15:21 ` Michal Pecio
2025-10-18 15:36 ` Alan Stern
2025-10-18 15:56 ` Michal Pecio
2025-10-20 15:56 ` Alan Stern
2025-10-20 16:23 ` Michal Pecio
2025-10-20 16:59 ` Alan Stern
2025-10-21 9:13 ` Oliver Neukum
2025-10-21 16:33 ` Alan Stern
2025-10-22 7:58 ` Oliver Neukum
2025-10-22 14:28 ` Alan Stern
2025-10-21 2:29 ` Yi Cong
2025-10-21 2:59 ` Alan Stern
2025-10-21 6:26 ` Yi Cong
2025-10-21 16:26 ` Alan Stern
2025-10-20 9:59 ` Oliver Neukum
2025-10-20 10:48 ` Greg KH
2025-10-20 15:59 ` Michal Pecio
2025-10-21 9:02 ` Oliver Neukum
2025-10-20 10:27 ` Oliver Neukum
2025-10-11 7:53 ` [PATCH net v5 3/3] Revert "net: usb: ax88179_178a: Bind only to vendor-specific interface" yicongsrfy
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=20251017191511.6dd841e9.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=pabeni@redhat.com \
--cc=stern@rowland.harvard.edu \
--cc=yicongsrfy@163.com \
/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).