| 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
| ||
|
Message-ID:
<AS8PR04MB8676D33E00DE6B0B961B5EB58C512@AS8PR04MB8676.eurprd04.prod.outlook.com>
Date: Mon, 4 Nov 2024 05:19:07 +0000
From: Hongxing Zhu <hongxing.zhu@....com>
To: Adam Ford <aford173@...il.com>
CC: Frank Li <frank.li@....com>, "vkoul@...nel.org" <vkoul@...nel.org>,
"festevam@...il.com" <festevam@...il.com>, "imx@...ts.linux.dev"
<imx@...ts.linux.dev>, "kernel@...gutronix.de" <kernel@...gutronix.de>,
"kishon@...nel.org" <kishon@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-phy@...ts.infradead.org"
<linux-phy@...ts.infradead.org>, Marcel Ziswiler
<marcel.ziswiler@...adex.com>, "s.hauer@...gutronix.de"
<s.hauer@...gutronix.de>, "shawnguo@...nel.org" <shawnguo@...nel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH v2 1/1] phy: freescale: imx8m-pcie: Do CMN_RST just before
PHY PLL lock check
> -----Original Message-----
> From: Adam Ford <aford173@...il.com>
> Sent: 2024年11月2日 3:53
> To: Hongxing Zhu <hongxing.zhu@....com>
> Cc: Frank Li <frank.li@....com>; vkoul@...nel.org; festevam@...il.com;
> imx@...ts.linux.dev; kernel@...gutronix.de; kishon@...nel.org;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org;
> linux-phy@...ts.infradead.org; Marcel Ziswiler <marcel.ziswiler@...adex.com>;
> s.hauer@...gutronix.de; shawnguo@...nel.org; stable@...r.kernel.org
> Subject: Re: [PATCH v2 1/1] phy: freescale: imx8m-pcie: Do CMN_RST just before
> PHY PLL lock check
>
> On Mon, Oct 21, 2024 at 11:06 PM Hongxing Zhu <hongxing.zhu@....com>
> wrote:
> >
> > > -----Original Message-----
> > > From: Frank Li <frank.li@....com>
> > > Sent: 2024年10月21日 23:53
> > > To: vkoul@...nel.org
> > > Cc: Frank Li <frank.li@....com>; festevam@...il.com; Hongxing Zhu
> > > <hongxing.zhu@....com>; imx@...ts.linux.dev; kernel@...gutronix.de;
> > > kishon@...nel.org; linux-arm-kernel@...ts.infradead.org;
> > > linux-kernel@...r.kernel.org; linux-phy@...ts.infradead.org; Marcel
> > > Ziswiler <marcel.ziswiler@...adex.com>; s.hauer@...gutronix.de;
> > > shawnguo@...nel.org; stable@...r.kernel.org
> > > Subject: [PATCH v2 1/1] phy: freescale: imx8m-pcie: Do CMN_RST just
> > > before PHY PLL lock check
> > >
> > > From: Richard Zhu <hongxing.zhu@....com>
> > >
> > > When enable initcall_debug together with higher debug level below.
> > > CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9
> > > CONFIG_CONSOLE_LOGLEVEL_QUIET=9
> > > CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7
> > >
> > > The initialization of i.MX8MP PCIe PHY might be timeout failed randomly.
> > > To fix this issue, adjust the sequence of the resets refer to the
> > > power up sequence listed below.
> > >
> > > i.MX8MP PCIe PHY power up sequence:
> > > /---------------------------------------------
> > > 1.8v supply ---------/
> > > /---------------------------------------------------
> > > 0.8v supply ---/
> > >
> > > ---\ /--------------------------------------------------
> > > X REFCLK Valid
> > > Reference Clock ---/ \--------------------------------------------------
> > > -------------------------------------------
> > > |
> > > i_init_restn --------------
> > > ------------------------------------
> > > |
> > > i_cmn_rstn ---------------------
> > > -------------------------------
> > > | o_pll_lock_done
> > > --------------------------
> > >
> > > Logs:
> > > imx6q-pcie 33800000.pcie: host bridge /soc@...cie@...00000 ranges:
> > > imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff ->
> > > 0x0000000000
> > > imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff ->
> > > 0x0018000000
> > > probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs
> > > probe of 30e20000.clock-controller returned 0 after 32971 usecs phy
> > > phy-32f00000.pcie-phy.4: phy poweron failed --> -110 probe of
> > > 30e10000.dma-controller returned 0 after 10235 usecs imx6q-pcie
> > > 33800000.pcie: waiting for PHY ready timeout!
> > > dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with
> > > HDCP
> > > (samsung_dw_hdmi_phy2) imx6q-pcie 33800000.pcie: probe with driver
> > > imx6q-pcie failed with error -110
> > >
> > > Fixes: dce9edff16ee ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe
> > > PHY
> > > support")
> > > Cc: stable@...r.kernel.org
> > > Signed-off-by: Richard Zhu <hongxing.zhu@....com>
> > > Signed-off-by: Frank Li <Frank.Li@....com>
> > >
> > > v2 changes:
> > > - Rebase to latest fixes branch of linux-phy git repo.
> > > - Richard's environment have problem and can't sent out patch. So I
> > > help post this fix patch.
>
> Even with this patch, I am still seeing an occasional timeout on 8MP.
> I looked at some logs on a similarly functioning 8MM and I can't get this error to
> appear on Mini that I see on Plus.
>
> The TRM doesn't document the timing of the startup sequence, like this e-mail
> patch did nor does it state how long a reasonable timeout should take. So, I
> started looking through the code and I noticed that the Mini asserts the reset at
> the beginning, then makes all the changes, and de-asserts the resets toward the
> end. Is there any reason we should not assert one or both of the resets on
> 8MP before setting up the reset of the registers like the way Mini does it?
Yes, I had the similar confusions when I try to bring up i.MX8MP PCIe.
i.MX8MP PCIe resets have the different designs but I don't know the reason and
the details. These resets shouldn't be asserted/de-asserted as Mini does during
the initialization.
On i.MX8MP, these resets should be configured one-shot. I used to toggle them
in my own experiments. Unfortunately, the PCIe PHY wouldn't be functional.
Best Regards
Richard Zhu
>
> adam
>
> > > ---
> > Hi Frank:
> > Thanks a lot for your kindly help.
> > Since my server is down, I can't send out this v2 in the past days.
> >
> > Hi Vinod:
> > Sorry for the late reply, and bring you inconvenience.
> >
> > Best Regards
> > Richard Zhu
> >
> > > drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > index 11fcb1867118c..e98361dcdeadf 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c
> > > @@ -141,11 +141,6 @@ static int imx8_pcie_phy_power_on(struct phy
> > > *phy)
> > > IMX8MM_GPR_PCIE_REF_CLK_PLL);
> > > usleep_range(100, 200);
> > >
> > > - /* Do the PHY common block reset */
> > > - regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > - IMX8MM_GPR_PCIE_CMN_RST,
> > > - IMX8MM_GPR_PCIE_CMN_RST);
> > > -
> > > switch (imx8_phy->drvdata->variant) {
> > > case IMX8MP:
> > > reset_control_deassert(imx8_phy->perst);
> > > @@ -156,6 +151,11 @@ static int imx8_pcie_phy_power_on(struct phy
> > > *phy)
> > > break;
> > > }
> > >
> > > + /* Do the PHY common block reset */
> > > + regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14,
> > > + IMX8MM_GPR_PCIE_CMN_RST,
> > > + IMX8MM_GPR_PCIE_CMN_RST);
> > > +
> > > /* Polling to check the phy is ready or not. */
> > > ret = readl_poll_timeout(imx8_phy->base +
> > > IMX8MM_PCIE_PHY_CMN_REG075,
> > > val, val == ANA_PLL_DONE, 10,
> 20000);
> > > --
> > > 2.34.1
> >
> > --
> > linux-phy mailing list
> > linux-phy@...ts.infradead.org
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >
> s.infradead.org%2Fmailman%2Flistinfo%2Flinux-phy&data=05%7C02%7Chongxi
> >
> ng.zhu%40nxp.com%7C666c8968b3094147ed4408dcfaaec631%7C686ea1d3bc
> 2b4c6f
> >
> a92cd99c5c301635%7C0%7C0%7C638660875771545687%7CUnknown%7CTWF
> pbGZsb3d8
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C0
> > %7C%7C%7C&sdata=3Mg4SqcaA%2FlbScveriGBBMOq1YOTt3okydgHmjmdLps
> %3D&reser
> > ved=0
Powered by blists - more mailing lists