From: Greg KH <gregkh@linuxfoundation.org>
To: Pin-yen Lin <treapking@chromium.org>
Cc: jerry xzq <jerry.xzq@gmail.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: of: filter disabled device node
Date: Tue, 25 Nov 2025 12:53:30 +0100 [thread overview]
Message-ID: <2025112548-angling-labored-b841@gregkh> (raw)
In-Reply-To: <CAEXTbpeN0Mk+Y-UeV79JzE547UCa_Fhh7T75L+2mhoSq3ark8g@mail.gmail.com>
On Tue, Nov 25, 2025 at 05:44:04PM +0800, Pin-yen Lin wrote:
> > > In our use case, the USB hub and the USB devices (e.g., modem card,
> > > USB camera) are fixed on the board, and describing them allows us to:
> > > (1) Describe the extra resources for the USB devices, like the usages
> > > in drivers/misc/onboard_usb_dev.c. They are mostly USB hubs that
> > > require extra power or reset pin, but there are also USB device
> > > usages.
> >
> > The USB devices should NOT be in DT at all, only for hub controls that
> > you need the extra pin controls please.
>
> I assumed we should describe USB devices because [1] introduced
> bindings for downstream USB ports for on-board hubs. Or should we only
> describe USB connectors but not USB devices?
Describe the USB connectors please, not USB devices. USB devices
already properly describe themselves.
> > > This is the usage from a downstream DTS that hasn't been upstreamed.
> >
> > There's nothing we can do about that. Please work to get it upstream.
> >
> > > The USB hub and devices are defined in a DTSI file, and another DTS
> > > inherits it but wants to disable those USB devices. We expected that
> > > disabling them should be the same as removing them.
> >
> > No, just disable them from userspace properly.
>
> I mean, it is disabled because of some DTS inheritance, and I believe
> we usually disable the nodes instead of removing them. How do we
> disable them from userspace in this case?
You can disable USB devices in userspace through sysfs.
> > > We haven't had a driver for the LTE card on the linux mainline.
> >
> > Why is it not merged upstream? That should be a very simple thing to
> > get accepted.
>
> We would love to, but those work was deprioritized internally.
As you know, we can't do anything about external drivers, so there's
nothing we can do. Please revisit that decision, it's one that is
already costing you time and money :(
> > > But,
> > > it is using M.2 USB interface and requires reset and enable pins, so I
> > > believe we want to describe it as a USB device in DT, and implement
> > > the resource control in onboard_usb_dev.c.
> >
> > No, that is not how USB devices work, they should control themselves.
>
> I see "RTL8188ETV 2.4GHz WiFi" is included in the onboard_usb_hub.c
> driver, and it also seems to be a USB device that requires extra
> resources. Shouldn't we describe them describe them in DT and include
> it in onboard_usb_dev.c if there are hardwares designed like this?
The driver for the USB device itself should handle this, but really, DT
should never be used for this as that goes against what USB is supposed
to be (i.e. your devices are not passing the USB standard by relying on
external DT information.)
thanks,
greg k-h
next prev parent reply other threads:[~2025-11-25 11:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 11:25 [PATCH] USB: of: filter disabled device node Zhengqiao Xia
2025-11-22 11:31 ` Greg KH
2025-11-22 11:32 ` Greg KH
2025-11-22 11:49 ` jerry xzq
2025-11-22 12:32 ` Greg KH
2025-11-22 12:54 ` jerry xzq
2025-11-22 11:32 ` Greg KH
[not found] ` <CAD48c-UjbPK4GewGpVVdEY30fhnhdAGQqrXQ3r0RgHc6suMo7Q@mail.gmail.com>
2025-11-22 12:34 ` Greg KH
2025-11-22 13:15 ` jerry xzq
2025-11-24 14:22 ` Pin-yen Lin
2025-11-24 15:51 ` Greg KH
2025-11-25 9:44 ` Pin-yen Lin
2025-11-25 11:53 ` Greg KH [this message]
2025-11-26 10:02 ` Pin-yen Lin
-- strict thread matches above, loose matches on Subject: below --
2025-11-21 8:09 Zhengqiao Xia
2025-11-21 8:28 ` Greg KH
[not found] ` <CADYyEwQqghzWedZYmZtwk1+R5DxMYg0aMJhVAutrW1w+CTB-7w@mail.gmail.com>
[not found] ` <2025112126-leverage-wrongful-85c4@gregkh>
2025-11-22 11:04 ` Zhengqiao Xia
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=2025112548-angling-labored-b841@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jerry.xzq@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=treapking@chromium.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).