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: <000201dbca1f$737647d0$5a62d770$@samsung.com>
Date: Wed, 21 May 2025 12:40:32 +0530
From: "Pritam Manohar Sutar" <pritam.sutar@...sung.com>
To: "'Krzysztof Kozlowski'" <krzk@...nel.org>, "'Neil Armstrong'"
	<neil.armstrong@...aro.org>, <vkoul@...nel.org>, <kishon@...nel.org>,
	<robh@...nel.org>, <krzk+dt@...nel.org>, <conor+dt@...nel.org>,
	<alim.akhtar@...sung.com>, <andre.draszik@...aro.org>,
	<peter.griffin@...aro.org>, <kauschluss@...root.org>,
	<m.szyprowski@...sung.com>, <s.nawrocki@...sung.com>
Cc: <linux-phy@...ts.infradead.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-samsung-soc@...r.kernel.org>, <rosa.pila@...sung.com>,
	<dev.tailor@...sung.com>, <faraz.ata@...sung.com>,
	<muhammed.ali@...sung.com>, <selvarasu.g@...sung.com>
Subject: RE: [PATCH v2 2/2] phy: exyons5-usbdrd: support HS phy for
 ExynosAutov920

Hi Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@...nel.org>
> Sent: 20 May 2025 01:13 PM
> To: Neil Armstrong <neil.armstrong@...aro.org>; Pritam Manohar Sutar
> <pritam.sutar@...sung.com>; vkoul@...nel.org; kishon@...nel.org;
> robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org;
> alim.akhtar@...sung.com; andre.draszik@...aro.org; peter.griffin@...aro.org;
> kauschluss@...root.org; m.szyprowski@...sung.com;
> s.nawrocki@...sung.com
> Cc: linux-phy@...ts.infradead.org; devicetree@...r.kernel.org; linux-
> kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-samsung-
> soc@...r.kernel.org; rosa.pila@...sung.com; dev.tailor@...sung.com;
> faraz.ata@...sung.com; muhammed.ali@...sung.com;
> selvarasu.g@...sung.com
> Subject: Re: [PATCH v2 2/2] phy: exyons5-usbdrd: support HS phy for
> ExynosAutov920
> 
> On 20/05/2025 09:39, neil.armstrong@...aro.org wrote:
> >> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> >> b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> >> index 634c4310c660..b440b56c6595 100644
> >> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> >> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> >> @@ -177,6 +177,9 @@
> >>   #define HSPHYPLLTUNE_PLL_P_TUNE			GENMASK(3,
> 0)
> >>
> >>   /* Exynos850: USB DRD PHY registers */
> >> +#define EXYNOSAUTOv920_DRD_CTRL_VER		0x00
> >> +#define CTRL_VER_MAJOR_VERSION			GENMASK(31,
> 24)
> >> +
> >>   #define EXYNOS850_DRD_LINKCTRL			0x04
> >>   #define LINKCTRL_FORCE_RXELECIDLE		BIT(18)
> >>   #define LINKCTRL_FORCE_PHYSTATUS		BIT(17)
> >> @@ -1772,6 +1775,10 @@ static const char * const
> exynos5_regulator_names[] = {
> >>   	"vbus", "vbus-boost",
> >>   };
> >>
> >> +static const char * const exynosautov920_clk_names[] = {
> >> +	"ext_xtal",
> >> +};
> >> +
> >>   static const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy =
> {
> >>   	.phy_cfg		= phy_cfg_exynos5,
> >>   	.phy_ops		= &exynos5_usbdrd_phy_ops,
> >> @@ -1847,6 +1854,81 @@ static const struct exynos5_usbdrd_phy_drvdata
> exynos850_usbdrd_phy = {
> >>   	.n_regulators		= ARRAY_SIZE(exynos5_regulator_names),
> >>   };
> >>
> >> +static void exynosautov920_usbdrd_utmi_init(struct
> >> +exynos5_usbdrd_phy *phy_drd) {
> >> +	u32 version;
> >> +
> >> +	version = readl(phy_drd->reg_phy +
> EXYNOSAUTOv920_DRD_CTRL_VER);
> >> +	dev_info(phy_drd->dev, "usbphy: version:0x%x\n", version);
> >
> > Please do not add mode info to boot log, use dev_dbg instead.
> 
> Just drop entirely, not even worth dbg (see coding style, driver development
> debugging guide). It is fixed per given compatible, isn't it? If not, there is entire
> commit msg to explain unusual things.

This SoC has a single USB 3.1 DRD combo v400 phy and three USB2.0 DRD phy v303
controllers those only support the UTMI+ interface. Currently, supporting only 
v303 phy in this patch-set, and planning v400 phy later (soon). Same may be 
also updated in commit  message. 

If there's any issue in phy init, dbg print is needed to debug which phy caused it. 

> 
> >
> >> +
> >> +	if (FIELD_GET(CTRL_VER_MAJOR_VERSION, version) == 0x3)
> >> +		/* utmi init for exynosautov920 HS phy */
> >> +		exynos850_usbdrd_utmi_init(phy_drd);
> >> +}
> >> +
> >> +static int exynosautov920_usbdrd_phy_init(struct phy *phy) {
> >> +	struct phy_usb_instance *inst = phy_get_drvdata(phy);
> >> +	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
> >> +	int ret = 0;
> >> +
> >> +	ret = clk_bulk_prepare_enable(phy_drd->drv_data->n_clks, phy_drd-
> >clks);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	/* UTMI or PIPE3 specific init */
> >> +	inst->phy_cfg->phy_init(phy_drd);
> >> +
> >> +	clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks,
> >> +phy_drd->clks);
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +static void exynosautov920_v3p1_phy_dis(struct phy *phy) {
> >> +	struct phy_usb_instance *inst = phy_get_drvdata(phy);
> >> +	struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
> >> +	void __iomem *reg_phy = phy_drd->reg_phy;
> >> +	u32 version;
> >> +
> >> +	version = readl(reg_phy + EXYNOSAUTOv920_DRD_CTRL_VER);
> >> +
> >> +	if (FIELD_GET(CTRL_VER_MAJOR_VERSION, version) == 0x3)
> >> +		exynos850_usbdrd_phy_exit(phy);
> >> +}
> >> +
> >> +static int exynosautov920_usbdrd_phy_exit(struct phy *phy) {
> >> +	struct phy_usb_instance *inst = phy_get_drvdata(phy);
> >> +
> >> +	if (inst->phy_cfg->id == EXYNOS5_DRDPHY_UTMI)
> >> +		exynosautov920_v3p1_phy_dis(phy);
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +static const struct phy_ops exynosautov920_usbdrd_phy_ops = {
> >> +	.init		= exynosautov920_usbdrd_phy_init,
> >> +	.exit		= exynosautov920_usbdrd_phy_exit,
> >
> > <snip>
> >
> >> +		.id		= EXYNOS5_DRDPHY_UTMI,
> >> +		.phy_init	= exynosautov920_usbdrd_utmi_init,
> >
> > <snip>
> >
> >> +	}, {
> >> +		.compatible = "samsung,exynosautov920-usb31drd-phy",
> >> +		.data = &exynosautov920_usb31drd_phy
> >
> > All those new ops are only called when matching this compatible, it it
> > really necessary to check the version ? is there
> > "samsung,exynosautov920-usb31drd-phy" PHYs with version different from 3
> in the wild ?
> 
> 
> Yeah, this looks like downstream code. Anyway this would need explanation in
> the commit msg.

Commit msg can be updated as mentioned below 

" This SoC has a single USB 3.1 DRD combo v400 phy that supports 
both UTMI+ (HS) and PIPE3 (SS) and three USB2.0 DRD v303 phy 
controllers those only support the UTMI+ (HS) interface. 
	
Support only HS phy in this commit which is very similar to what
the existing Exynos850 supports.

Support combo phy later (soon) and this is out of scope of this commit.

Add required change in phy driver to support HS phy for this SoC."

> 
> Best regards,
> Krzysztof

Thank you,
Pritam


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ