Re: [PATCH v4 0/5] support ipq5332 platform

[Jie Luo <quic_luoj@quicinc.com>]

On 1/6/2024 11:45 PM, 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.

UNIPHY is located in PPE, which controls the interface mode for
connecting with external PHY, the hardware register(4 bytes) of UNIPHY
is accessed by local bus(ioremap).

> 
> 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.

Hi Andrew,
the UNIPHY is the hardware part of PPE(packet process engine) in IPQ
platform, which can't be used for USB, SATA serdes, the UNIPHY of
PPE is dedicated for connecting with external PHY CHIP.

> 
> 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.

Sorry for missing this description of UNIPHY, since the UNIPHY block is
the part of PPE, PPE driver will be posted as the independent driver for
review, so i did not give the description of UNIPHY.

The IPQ PPE includes MAC and UNIPHY integrated, the connection with
external PHY is as below.
MAC ---- UNIPHY(PCS) ---- (PCS)external PHY.

The UNIPHY here is the Ethernet dedicated SERDES for connecting with
external PHY.

> 
>> 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

Thanks Andrew, the driver of qca8084 will be updated based on the
concept of PHY package.