linux-kernel - Re: [PATCH 4/6] phy: spacemit: introduce PCIe/combo PHY

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250814235757-GYA1008367@gentoo>
Date: Fri, 15 Aug 2025 07:57:57 +0800
From: Yixun Lan <dlan@...too.org>
To: Alex Elder <elder@...cstar.com>
Cc: Inochi Amaoto <inochiama@...il.com>, lpieralisi@...nel.org,
	kwilczynski@...nel.org, mani@...nel.org, robh@...nel.org,
	bhelgaas@...gle.com, krzk+dt@...nel.org, conor+dt@...nel.org,
	vkoul@...nel.org, kishon@...nel.org, paul.walmsley@...ive.com,
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
	p.zabel@...gutronix.de, tglx@...utronix.de, johan+linaro@...nel.org,
	thippeswamy.havalige@....com, namcao@...utronix.de,
	mayank.rana@....qualcomm.com, shradha.t@...sung.com,
	quic_schintav@...cinc.com, fan.ni@...sung.com,
	devicetree@...r.kernel.org, linux-phy@...ts.infradead.org,
	linux-pci@...r.kernel.org, spacemit@...ts.linux.dev,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Junzhong Pan <panjunzhong@...ux.spacemit.com>
Subject: Re: [PATCH 4/6] phy: spacemit: introduce PCIe/combo PHY

Hi Alex,

On 07:15 Thu 14 Aug     , Alex Elder wrote:
> On 8/13/25 6:42 PM, Inochi Amaoto wrote:
> > On Wed, Aug 13, 2025 at 01:46:58PM -0500, Alex Elder wrote:
> >> Introduce a driver that supports three PHYs found on the SpacemiT
> >> K1 SoC.  The first PHY is a combo PHY that can be configured for
> >> use for either USB 3 or PCIe.  The other two PHYs support PCIe
> >> only.
> >>
> >> All three PHYs must be programmed with an 8 bit receiver termination
> >> value, which must be determined dynamically; only the combo PHY is
> >> able to determine this value.  The combo PHY performs a special
> >> calibration step at probe time to discover this, and that value is
> >> used to program each PHY that operates in PCIe mode.  The combo
> >> PHY must therefore be probed--first--if either of the PCIe-only
> >> PHYs will be used.
> >>
> >> During normal operation, the USB or PCIe driver using the PHY must
> >> ensure clocks and resets are set up properly.  However clocks are
> >> enabled and resets are de-asserted temporarily by this driver to
> >> perform the calibration step on the combo PHY.
> >>
> >> Tested-by: Junzhong Pan <panjunzhong@...ux.spacemit.com>
> >> Signed-off-by: Alex Elder <elder@...cstar.com>
> >> ---
> >>   drivers/phy/Kconfig                |  11 +
> >>   drivers/phy/Makefile               |   1 +
> >>   drivers/phy/phy-spacemit-k1-pcie.c | 639 +++++++++++++++++++++++++++++
> >>   3 files changed, 651 insertions(+)
> >>   create mode 100644 drivers/phy/phy-spacemit-k1-pcie.c
> 
> . . .
> 
> >> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> >> index c670a8dac4680..20f0078e543c7 100644
> >> --- a/drivers/phy/Makefile
> >> +++ b/drivers/phy/Makefile
> 
> . . .
> 
> >> +static int k1_pcie_pll_lock(struct k1_pcie_phy *k1_phy, bool pcie)
> >> +{
> >> +	u32 val = pcie ? CFG_FORCE_RCV_RETRY : 0;
> >> +	void __iomem *virt;
> >> +
> >> +	writel(val, k1_phy->regs + PCIE_RC_DONE_STATUS);
> >> +
> >> +	/*
> >> +	 * Wait for indication the PHY PLL is locked.  Lanes for ports
> >> +	 * B and C share a PLL, so it's enough to sample just lane 0.
> >> +	 */
> >> +	virt = k1_phy->regs + PCIE_PU_ADDR_CLK_CFG;	/* Lane 0 */
> >> +
> >> +	return readl_poll_timeout(virt, val, val & PLL_READY,
> >> +				  POLL_DELAY, PLL_TIMEOUT);
> >> +}
> >> +
> > 
> > Can we use standard clk_ops and clk_mux to normalize this process?
> 
> I understand you're suggesting that we represent this as a clock.
> 
> Can you be more specific about how you suggest I do that?
> 
> For example, are you suggesting I create a separate clock driver
> for this one PLL (in each PCIe register space)?
> 
> Or do you mean use clock structures and callbacks within this
> driver to represent this?
> 
> I'm just not sure what you have in mind, and the two options I
> mention seem a lot more complicated than this one function.
> 
> Thanks.
you can take a look at k1's i2c patch that Troy just sent which has similar case

https://lore.kernel.org/all/20250814-k1-i2c-ilcr-v3-1-317723e74bcd@linux.spacemit.com/

> 
> 					-Alex
> 
> > Regards,
> > Inochi
> 

-- 
Yixun Lan (dlan)