Date: Sun, 7 Jan 2024 00:03:34 +0200
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jie Luo <quic_luoj@...cinc.com>, agross@...nel.org, andersson@...nel.org,
 konrad.dybcio@...aro.org, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, robh+dt@...nel.org,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 hkallweit1@...il.com, linux@...linux.org.uk, robert.marko@...tura.hr,
 linux-arm-msm@...r.kernel.org, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 quic_srichara@...cinc.com
Subject: Re: [PATCH v4 0/5] support ipq5332 platform

On 06.01.2024 17:45, Andrew Lunn wrote:
>> I just realized that the UNIPHY block is a MII (probably SGMII) controller.
>> Isn't it? And I expect that it responsible more then just for clock
>> enabling. It should also activate and perform a basic configuration of MII
>> for actual data transmission. If so, then it should placed somewhere under
>> drivers/net/phy or drivers/net/pcs.
> 
> Before we decide that, we need a description of what the UNIPHY
> actually does, what registers it has, etc. Sometimes blocks like this
> get split into a generic PHY, aka drivers/phy/ and a PCS driver. This
> would be true if the UNIPHY is also used for USB SERDES, SATA SERDES
> etc. The SERDES parts go into a generic PHY driver, and the SGMII on
> to of the SERDES is placed is a PCS driver.

As far as I understand, UNIPHY only contains SGMII/PSGMII/whatever and a 
simple clock controller. PCIe & USB phys are implemented in other 
hardware blocks. See the lately merged USB support code for similar 
IPQ5018 SoC. But I can only speak to what I found searching online and 
checking the vendor's qca-ssdk "driver".

https://git.codelinaro.org/clo/qsdk/oss/lklm/qca-ssdk/-/tree/NHSS.QSDK.12.4.5.r3

I hope Luo can clarify with more confidence.

> The problem i have so far is that there is no usable description of
> any of this hardware, and the developers trying to produce drivers for
> this hardware don't actually seem to understand the Linux architecture
> for things like this.
>
>> As far as I understand, we basically agree that clocks configuration can be
>> implemented based on the clock API using a more specialized driver(s) than
>> MDIO. The only obstacle is the PHY chip initialization issue explained
>> below.
>> Thank you for this compact yet detailed summary. Now it much more clear,
>> what this phy chip requires to be initialized.
>>
>> Looks like you need to implement at least two drivers:
>> 1. chip (package) level driver that is responsible for basic "package"
>> initialization;
>> 2. phy driver to handle actual phy capabilities.
> 
> Nope. As i keep saying, please look at the work Christian is
> doing. phylib already has the concept of a PHY package, e.g. look at
> the MSCC driver, and how it uses devm_phy_package_join(). What is
> missing is a DT binding which allows package properties to be
> expressed in DT. And this is what Christian is adding.

Andrew, thank you so much for pointing me to that API and Christian's 
work. I have checked the DT change proposal and it fits this QCA8084 
case perfectly.

Am I right that all one has to do to solve this QCA8084 initialization 
case is wrap phys in a ethernet-phy-package node and use 
devm_phy_package_join() / phy_package_init_once() to do the basic 
initialization? So simple?

I came to put my 2c in and learnt a couple of new tricks. What a nice day :)

--
Sergey

Powered by blists - more mailing lists