linux-kernel - Re: [PATCH] phy: qcom-qusb2: Re add "qcom,sdm845-qusb2-phy" compat string

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: <CALAqxLXfd+7Wc79_XWRv8cKLFu+MpM1w9e3byx9z5bXSdTemLg@mail.gmail.com>
Date:   Thu, 2 Apr 2020 16:08:21 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Manu Gautam <mgautam@...eaurora.org>,
        Sandeep Maheswaram <sanm@...eaurora.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH] phy: qcom-qusb2: Re add "qcom,sdm845-qusb2-phy" compat string

On Thu, Apr 2, 2020 at 3:56 PM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Thu, Apr 2, 2020 at 3:37 PM John Stultz <john.stultz@...aro.org> wrote:
> >
> > In commit 8fe75cd4cddf ("phy: qcom-qusb2: Add generic QUSB2 V2
> > PHY support"), the change was made to add "qcom,qusb2-v2-phy"
> > as a generic compat string. However the change also removed
> > the "qcom,sdm845-qusb2-phy" compat string, which is documented
> > in the binding and already in use.
> >
> > This patch re-adds the "qcom,sdm845-qusb2-phy" compat string
> > which allows the driver to continue to work with existing dts
> > entries such as found on the db845c.
> >
> > Cc: Andy Gross <agross@...nel.org>
> > Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> > Cc: Rob Herring <robh+dt@...nel.org>
> > Cc: Mark Rutland <mark.rutland@....com>
> > Cc: Doug Anderson <dianders@...omium.org>
> > Cc: Manu Gautam <mgautam@...eaurora.org>
> > Cc: Sandeep Maheswaram <sanm@...eaurora.org>
> > Cc: Matthias Kaehlcke <mka@...omium.org>
> > Cc: Stephen Boyd <swboyd@...omium.org>
> > Cc: Kishon Vijay Abraham I <kishon@...com>
> > Cc: linux-arm-msm@...r.kernel.org
> > Cc: devicetree@...r.kernel.org
> > Fixes: 8fe75cd4cddf ("phy: qcom-qusb2: Add generic QUSB2 V2 PHY support")
> > Reported-by: YongQin Liu <yongqin.liu@...aro.org>
> > Signed-off-by: John Stultz <john.stultz@...aro.org>
> > ---
> >  drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
> >  1 file changed, 3 insertions(+)
>
> Do you have an out-of-tree dts file?  If not, I'd prefer that the fix
> was for this patch to land instead:
>
> https://lore.kernel.org/r/1583747589-17267-9-git-send-email-sanm@codeaurora.org

No, no out of tree dts.  The usage is already in tree:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sdm845.dtsi#n2389


> While we can land your patch if someone needs it for supporting an
> out-of-tree dts, it gives people supporting future SoCs the idea that
> they need to add themselves to this table too.  That's now discouraged
> unless there's a specific quirk that needs to be handled just for this
> SoC.

My understanding with dts bindings is that they are effectively an
ABI. While maybe it makes sense to deprecate the
"qcom,sdm845-qusb2-phy" string in the Documentation to avoid new
users, I'd think we'd want to keep the support in the driver as we
aren't supposed to have tight coupling between the DTB and kernel (at
least for official bindings).

Granted, I've not gotten much experience with boards that were fully
upstream and thus didn't have an eternally evolving dts file that had
to be kept in sync with the kernel, so in practice either solution
does work for me, but in theory it seems like we should at least
pretend these things are stable. :)

thanks
-john