linux-kernel - Re: [PATCH v5 4/4] phy: qcom: edp: Add Glymur platform support

Open Source and information security mailing list archives

Message-ID: <mao4pyywje5x526ggasodx2hpmrgrw3yhq7a4v2lxtj2m3p6ii@6mtei6u7jbuc>
Date: Wed, 10 Dec 2025 19:51:22 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Abel Vesa <abel.vesa@....qualcomm.com>
Cc: Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Dmitry Baryshkov <lumag@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [PATCH v5 4/4] phy: qcom: edp: Add Glymur platform support

On Wed, Dec 10, 2025 at 01:26:38PM +0200, Abel Vesa wrote:
> On 25-12-08 16:16:31, Abel Vesa wrote:
> > On 25-12-05 22:26:35, Dmitry Baryshkov wrote:
> > > On Fri, Dec 05, 2025 at 04:23:23PM +0200, Abel Vesa wrote:
> > > > From: Abel Vesa <abel.vesa@...aro.org>
> > > > 
> > > > The Qualcomm Glymur platform has the new v8 version
> > > > of the eDP/DP PHY. So rework the driver to support this
> > > > new version and add the platform specific configuration data.
> > > > 
> > > > Signed-off-by: Abel Vesa <abel.vesa@...aro.org>
> > > > Signed-off-by: Abel Vesa <abel.vesa@....qualcomm.com>
> > > > ---
> > > >  drivers/phy/qualcomm/phy-qcom-edp.c | 230 +++++++++++++++++++++++++++++++++++-
> > > >  1 file changed, 224 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > index f98fe83de42e..052b7782b3d4 100644
> > > > --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > @@ -26,6 +26,8 @@
> > > >  #include "phy-qcom-qmp-qserdes-com-v4.h"
> > > >  #include "phy-qcom-qmp-qserdes-com-v6.h"
> > > >  
> > > > +#include "phy-qcom-qmp-qserdes-dp-com-v8.h"
> > > > +
> > > >  /* EDP_PHY registers */
> > > >  #define DP_PHY_CFG                              0x0010
> > > >  #define DP_PHY_CFG_1                            0x0014
> > > > @@ -76,6 +78,7 @@ struct phy_ver_ops {
> > > >  	int (*com_power_on)(const struct qcom_edp *edp);
> > > >  	int (*com_resetsm_cntrl)(const struct qcom_edp *edp);
> > > >  	int (*com_bias_en_clkbuflr)(const struct qcom_edp *edp);
> > > > +	int (*com_clk_fwd_cfg)(const struct qcom_edp *edp);
> > > >  	int (*com_configure_pll)(const struct qcom_edp *edp);
> > > >  	int (*com_configure_ssc)(const struct qcom_edp *edp);
> > > >  };
> > > > @@ -83,6 +86,8 @@ struct phy_ver_ops {
> > > >  struct qcom_edp_phy_cfg {
> > > >  	bool is_edp;
> > > >  	const u8 *aux_cfg;
> > > > +	int aux_cfg_size;
> > > 
> > > Can we always write DP_AUX_CFG_SIZE values?
> > > 
> > 
> > Sure, I could check what are the values for the rest of the regs for platforms
> > with v4 and v5.
> > 
> 
> So, after checking the docs, it seems we could write the reset values for the
> v4 and v5 as they always are the same between all platforms: 0x03, 0x02, 0x02, 0x00.
> At least on the platforms I was able to check.
> 
> Should we risk it and add these extra values to the array even though they are
> the reset values, just to make the driver more clean by having single sized arrays
> for AUX_CFGx between all platforms ?

as far as I can see, yet, please. I don't see a risk in it.

> 
> -- 
> linux-phy mailing list
> linux-phy@...ts.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy

-- 
With best wishes
Dmitry

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