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

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: <895eadd7-1631-4b6b-8db4-d371f2e52611@lunn.ch>
Date: Sat, 6 Jan 2024 16:45:08 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
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

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

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