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]
Date:   Thu, 30 Mar 2023 10:31:16 -0500
From:   Rob Herring <robh@...nel.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 1/4] dt-bindings: usb: gpio-sbu-mux: Add OnSemi
 NB7VPQ904M mux

On Tue, Mar 21, 2023 at 11:12:28PM +0100, Konrad Dybcio wrote:
> The OnSemi NB7VPQ904M Type-C DP altmode redriver provides SBU signals
> that can be used in with the gpio-sbu-mux driver. Document it.
> 
> Note that the -mux suffix is there to indicate that the gpio-sbu-mux
> driver interacts with the mux part of this otherwise quite sophisticated
> chip, leaving the "onnn,nb7vpq904m" compatible free for when a proper
> driver taking care of all of the chip's capabilities is introduced.

You should define a proper and complete binding. If you want to bind the 
gpio-sbu-mux driver to it now until you have a proper driver then that's 
fine. When you have such a driver, then you drop the compatible from the 
gpio-sbu-mux driver.

Note that having the fallback "gpio-sbu-mux" is somewhat problematic 
because the kernel has no mechanism to ensure you bind the most specific 
driver. For that to happen, it would have to support (automatically) 
unbinding one driver and binding to the more specific driver since one 
driver could be built-in and the other a module.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ