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: <CAEXTbpcdS-Bc8T82Osay1EWjTRxj4-mk66CByzcW3Sgiro1AWA@mail.gmail.com>
Date: Wed, 26 Nov 2025 18:02:15 +0800
From: Pin-yen Lin <treapking@...omium.org>
To: Greg KH <gregkh@...uxfoundation.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

Hi Greg,

On Tue, Nov 25, 2025 at 7:53 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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.

Okay. But in our case, we can reproduce the crash even if we only
describe the on-board USB hub and the USB connectors and set the
status as "disabled".
>
> > > > 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.

I think you misunderstood our use case. We have device A that has an
on-board USB hub, so we describe it in the DTS. Then, another device B
is similar to device A but does not have the USB hub. So, we inherit
device A's DTS and disable the hub nodes, and we observed a NULL
pointer dereference after boot.
>
> > > > 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.)

Maybe those devices violated the USB standard, but we do see WWAN
cards that use M.2 socket 2 and work on USB with additional reset
pins.

Though this is off-topic because we can reproduce even without
describing the WWAN card in our devicetree.
>
> thanks,
>
> greg k-h

Regards,
Pin-yen