linux-kernel - Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+-kcDoFjp7a9ESa78Ar-ObLapXfuzn-WFNT-8rro_bJQ@mail.gmail.com>
Date:   Mon, 5 Oct 2020 14:36:45 -0500
From:   Rob Herring <robh@...nel.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        Doug Anderson <dianders@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Frank Rowand <frowand.list@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux USB List <linux-usb@...r.kernel.org>,
        Bastien Nocera <hadess@...ess.net>,
        Stephen Boyd <swboyd@...omium.org>,
        Ravi Chandra Sadineni <ravisadineni@...omium.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Peter Chen <peter.chen@....com>
Subject: Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard
 USB hubs

On Mon, Oct 5, 2020 at 2:18 PM Matthias Kaehlcke <mka@...omium.org> wrote:
>
> On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote:
> > On Mon, Oct 05, 2020 at 09:06:55AM -0700, Matthias Kaehlcke wrote:
> > > On Sat, Oct 03, 2020 at 08:41:42AM -0400, Alan Stern wrote:
> > > > The decision to enable the power regulator at system startup would be
> > > > kernel policy, not a part of the DT description.  But there ought to be
> > > > a standard way of recognizing which resource requirements of this sort
> > > > should be handled at startup.  Then there could be a special module (in
> > > > the driver model core? -- that doesn't really seem appropriate) which
> > > > would search through the whole DT database for resources of this kind
> > > > and enable them.
> > >
> > > This might work for some cases that only have a single resource or multiple
> > > resources but no timing/sequencing requirements. For the more complex cases
> > > it would probably end up in something similar to the pwrseq series
> > > (https://lore.kernel.org/patchwork/project/lkml/list/?series=314989&state=%2A&archive=both),
> > > which was nack-ed by Rafael, Rob also expressed he didn't want to go
> > > down that road.
> > >
> > > It seems to me that initialization of the resources needs to be done by
> > > the/a driver for the device, which knows about the sequencing requirements.
> > > Potentially this could be done in a pre-probe function that you brought up
> > > earlier.
> >
> > One of the important points of my suggestion was that the resource init
> > should be done _outside_ of the device's driver, precisely because the
> > driver module might not even be loaded until the resources are set up
> > and the device is discovered.
> >
> > The conclusion is that we need to have code that is aware of some
> > detailed needs of a specific device but is not part of the device's
> > driver.  I'm not sure what the best way to implement this would be.
>
> Wouldn't it be possible to load the module when the DT specifies that
> the device exists? For USB the kernel would need the VID/PID to identify
> the module, these could be extracted from the compatible string.

You don't even have to do that. Just add the MODULE_DEVICE_TABLE with
the compatible strings and module loading will just work once you walk
the USB bus in DT. Though probably you'd still need the VID/PID to
create the device.

Rob