linux-kernel - Re: [PATCH] USB: of: filter disabled device node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025112548-angling-labored-b841@gregkh>
Date: Tue, 25 Nov 2025 12:53:30 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Pin-yen Lin <treapking@...omium.org>
Cc: jerry xzq <jerry.xzq@...il.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: of: filter disabled device node

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