Re: [PATCH net-next 5/9] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, Dec 01, 2025 at 09:41:21AM +0100, Krzysztof Kozlowski wrote:
> On 01/12/2025 09:37, Vinod Koul wrote:
> > On 24-11-25, 20:01, Jakub Kicinski wrote:
> >> On Sat, 22 Nov 2025 21:33:37 +0200 Vladimir Oltean wrote:
> >>> Add helpers in the generic PHY folder which can be used using 'select
> >>> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
> >>> enable GENERIC_PHY.
> >>>
> >>> These helpers need to deal with the slight messiness of the fact that
> >>> the polarity properties are arrays per protocol, and with the fact that
> >>> there is no default value mandated by the standard properties, all
> >>> default values depend on driver and protocol (PHY_POL_NORMAL may be a
> >>> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
> >>> PCIe).
> >>>
> >>> Push the supported mask of polarities to these helpers, to simplify
> >>> drivers such that they don't need to validate what's in the device tree
> >>> (or other firmware description).
> >>>
> >>> The proposed maintainership model is joint custody between netdev and
> >>> linux-phy, because of the fact that these properties can be applied to
> >>> Ethernet PCS blocks just as well as Generic PHY devices. I've added as
> >>> maintainers those from "ETHERNET PHY LIBRARY", "NETWORKING DRIVERS" and
> >>> "GENERIC PHY FRAMEWORK".
> >>
> >> I dunno.. ain't no such thing as "joint custody" maintainership.
> >> We have to pick one tree. Given the set of Ms here, I suspect 
> >> the best course of action may be to bubble this up to its own tree.
> >> Ask Konstantin for a tree in k.org, then you can "co-post" the patches
> >> for review + PR link in the cover letter (e.g. how Tony from Intel
> >> submits their patches). This way not networking and PHY can pull
> >> the shared changes with stable commit IDs.
> > 
> > How much is the volume of the changes that we are talking about, we can
> > always ack and pull into each other trees..?
> 
> That's just one C file, isn't it? Having dedicated tree for one file
> feels like huge overhead.

I have to admit, no matter how we define what pertains to this presumed
new git tree, the fact is that the volume of patches will be quite low.

Since the API provider always sits in drivers/phy/ in every case that I
can think about, technically all situations can be resolved by linux-phy
providing these stable PR branches to netdev. In turn, to netdev it
makes no difference whether the branches are coming from linux-phy or a
third git tree. Whereas to linux-phy, things would even maybe a bit
simpler, due to already having the patches vs needing to pull them from
the 3rd tree.

From my perspective, if I'm perfectly honest, the idea was attractive
because of the phenomenal difference in turnaround times between netdev
and linux-phy review&merge processes (very fast in netdev, very slow and
patchy in linux-phy). If there's a set like this, where all API consumers
are in netdev for now but the API itself is in linux-phy, you'd have to
introduce 1000 NOP cycles just to wait for the PR branch.

In that sense, having more people into the mix would help just because
there's more people (i.e. fewer points of failure), even though overall
there's more overhead.

IDK, these are my 2 cents, I can resubmit this set in 2 weeks with the
maintainership of the PHY common properties exclusive to linux-phy.