linux-kernel - Re: [PATCH] arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY compatible

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:   Mon, 16 Oct 2023 20:28:10 -0700
From:   Bjorn Andersson <quic_bjorande@...cinc.com>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC:     Johan Hovold <johan@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: qcom: sc8280xp-x13s: Use the correct DP PHY
 compatible

On Mon, Oct 16, 2023 at 12:10:18PM +0300, Dmitry Baryshkov wrote:
> On Mon, 16 Oct 2023 at 12:01, Johan Hovold <johan@...nel.org> wrote:
> >
> > On Mon, Oct 16, 2023 at 11:51:33AM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 29 Sept 2023 at 19:03, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
> > > >
> > > > The DP PHY needs different settings when an eDP display is used.
> > > > Make sure these apply on the X13s.
> > >
> > > Could you please clarify, is it the same PHY type, just being
> > > repurposed for eDP or is it a different PHY type?
> >
> > Same PHY, just different settings AFAIK.
> >
> > > If the former is the case (and the same PHY can be used for both DP
> > > and eDP), it should carry the same compatible string and use software
> > > mechanisms (e.g. phy_set_mode_ext()) to be programmed for the correct
> > > operation mode.
> >
> > Possibly, but that's not how the current binding and implementation
> > works:
> >
> >         6993c079cd58 ("dt-bindings: phy: qcom-edp: Add SC8280XP PHY compatibles")
> >         2300d1cb24b3 ("phy: qcom: edp: Introduce support for DisplayPort")
> >         3b7267dec445 ("phy: qcom: edp: Add SC8280XP eDP and DP PHYs")
> >
> >         https://lore.kernel.org/lkml/20220810040745.3582985-1-bjorn.andersson@linaro.org/
> >
> > And you'd still need to infer the mode from DT somehow.
> 
> If it is the same hardware block, it seems incorrect to have two
> different compat entries. For example, for PCIe RC vs PCIe EP we
> specify the PHY mode from the host controller driver.
> I'd say, we need to fix the bindings for both DP/eDP controller and
> the PHY.  See the `phy-mode` DT property for example.
> 

It is one hardware block, supporting both eDP and DP, so I like your
suggestion of having a single compatible instead and using some other
means of defining the configuration. I just wasn't able to find a
better way to do so back when I wrote the binding/driver...

Regards,
Bjorn