From: Vladimir Oltean <olteanv@gmail.com>
To: Christian Marangi <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Rob Herring <robh@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Daniel Golle <daniel@makrotopia.org>,
Qingfang Deng <dqfext@gmail.com>,
SkyLake Huang <SkyLake.Huang@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
David Epping <david.epping@missinglinkelectronics.com>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
Harini Katakam <harini.katakam@amd.com>,
Simon Horman <horms@kernel.org>,
Robert Marko <robert.marko@sartura.hr>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [net-next RFC PATCH 03/14] dt-bindings: net: document ethernet PHY package nodes
Date: Fri, 24 Nov 2023 18:59:23 +0200 [thread overview]
Message-ID: <20231124165923.p2iozsrnwlogjzua@skbuf> (raw)
In-Reply-To: <655e4939.5d0a0220.d9a9e.0491@mx.google.com>
On Wed, Nov 22, 2023 at 07:32:22PM +0100, Christian Marangi wrote:
> Sooooo.... Sorry if I insist but I would really love to have something
> ""stable"" to move this further. (the changes are easy enough so it's
> really a matter of finding a good DT structure)
>
> Maybe a good idea would be summarize the concern and see what solution
> was proposed:
Sorry, I didn't follow the entire discussion. I hope I'm not too far off
with my understanding of your problems.
I think you are hitting some of the same points I have hit with DSA.
The PHY package could be considered an SoC with lots of peripherals on
it, for which you'd want separate drivers. Just like a DSA switch would.
I don't think it's exactly phylib's place to deal with that, just like
it's not DSA's place to deal with complex SoCs, just with the switching
IP (like the Ethernet PHY IP for phylib).
https://lore.kernel.org/lkml/20221222134844.lbzyx5hz7z5n763n@skbuf/
Why does the ethernet-phy-package DT binding attempt to be so grand and
generic? I would expect the 180 degree opposite. Make it have a _single_
compatible of "qcom,qca807x" (but don't use an "x" wildcard, do specify
the full package name).
Make it have a "reg" property which is the base MDIO address of the package.
Write an mdio_device driver that probes on that. The PHY core already
knows that if a child on the MDIO bus has a compatible string of the
normal form (not like "ethernet-phy-id004d.d0b2"), then it's looking at
an mdio_device.
Make the OF node of the package have an "mdio" child with its own
compatible string, which represents the place where PHYs are. The driver
for the "mdio" child has a very simple implementation of the mii_bus
ops, which just calls into the device parent (it can assume a certain
parent implementation and private data structures).
Lateral to the "mdio" child node of the "qcom,qca807x" package node, you
could put any other device tree properties that you want.
Make the mdio_device driver for "qcom,qca807x" use shared code if you
want - but keep the device tree structure hardware-specific. Look at the
compatible strings that e.g. the drivers/mfd/simple-mfd-i2c.c driver
probes on. You could always change the driver implementation for a
certain compatible string, but you'll be stuck with the ultra-generic
compatible = "ethernet-phy-package", which has the problems that you
mention.
>
> Concern list:
> 1. ethernet-phy-package MUST be placed in mdio node (not in ethernet,
> the example was wrong anyway) and MUST have an addr
>
> Current example doesn't have an addr. I would prefer this way but
> no problem in changing this.
>
> Solution:
> - Add reg to the ethernet-phy-package node with the base address of
> the PHY package (base address = the first PHY address of the
> package)
Correct, what I'm saying is compatible with this.
>
> We will have a PHY node with the same address of the PHY package
> node. Each PHY node in the PHY package node will have reg set to
> the REAL address in the mdio bus.
If the real PHY IPs are children of the package rather than on the same
level with it, I don't think this will be a problem. I wonder if some
address translation could be done with the "ranges" device tree property.
I've never seen this with MDIO though.
> 4. Not finding a correct place to put PHY package info.
>
> I'm still convinced the mdio node is the correct place.
> - PHY package are PHY in bundle so they are actual PHY
> - We already have in the mdio node special handling (every DSA switch
> use custom compatible and PHY ID is not used to probe them
> normally)
> - Node this way won't be treated as PHY as they won't match the PHY
> node name pattern and also won't have the compatible pattern for
> PHY.
>
> Solution:
> - ethernet-phy-package node is OK given a reg is defined.
I agree that it should sit under the MDIO node. I disagree with the idea
of a standardized binding for PHY packages.
next prev parent reply other threads:[~2023-11-24 16:59 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 13:50 [net-next RFC PATCH 00/14] net: phy: Support DT PHY package Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 01/14] net: phy: extend PHY package API to support multiple global address Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 02/14] dt-bindings: net: move PHY modes to common PHY mode types definition Christian Marangi
2023-11-20 15:14 ` Rob Herring
2023-11-20 17:30 ` Rob Herring
2023-11-20 13:50 ` [net-next RFC PATCH 03/14] dt-bindings: net: document ethernet PHY package nodes Christian Marangi
2023-11-20 17:41 ` Rob Herring
2023-11-20 16:39 ` Christian Marangi
2023-11-20 20:44 ` Andrew Lunn
2023-11-20 18:09 ` Christian Marangi
2023-11-20 21:25 ` Andrew Lunn
2023-11-20 18:45 ` Christian Marangi
2023-11-21 14:42 ` Rob Herring
2023-11-21 14:45 ` Andrew Lunn
2023-11-22 18:32 ` Christian Marangi
2023-11-23 3:30 ` Andrew Lunn
2023-11-23 10:38 ` Christian Marangi
2023-11-23 14:27 ` Andrew Lunn
2023-11-23 14:35 ` Russell King (Oracle)
2023-11-23 14:57 ` Andrew Lunn
2023-11-23 19:33 ` Christian Marangi
2023-11-24 11:49 ` Jie Luo
2023-11-24 12:02 ` Russell King (Oracle)
2023-11-24 14:44 ` Andrew Lunn
2023-11-24 15:16 ` Russell King (Oracle)
2023-11-24 16:59 ` Robert Marko
2023-11-23 15:07 ` Andrew Lunn
2023-11-23 19:36 ` Christian Marangi
2023-11-24 16:59 ` Vladimir Oltean [this message]
2023-11-24 16:25 ` Christian Marangi
2023-11-24 18:27 ` Vladimir Oltean
2023-11-24 18:35 ` Andrew Lunn
2023-11-24 19:40 ` Vladimir Oltean
2023-11-20 13:50 ` [net-next RFC PATCH 04/14] net: phy: add initial support for PHY package in DT Christian Marangi
2023-11-22 10:41 ` Simon Horman
2023-11-22 10:52 ` Simon Horman
2023-11-22 18:15 ` Christian Marangi
2023-11-22 21:14 ` Simon Horman
2023-11-20 13:50 ` [net-next RFC PATCH 05/14] net: phy: add support for named global PHY in DT PHY package Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 06/14] net: phy: add support for shared priv data size for PHY package in DT Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 07/14] net: phy: add support for driver specific PHY package probe/config Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 08/14] net: phy: add support for PHY package interface mode Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 09/14] net: phy: move mmd_phy_indirect to generic header Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 10/14] net: phy: add support for PHY package MMD read/write Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 11/14] dt-bindings: net: add QCA807x PHY defines Christian Marangi
2023-11-23 3:01 ` Andrew Lunn
2023-11-20 13:50 ` [net-next RFC PATCH 12/14] dt-bindings: net: Document Qcom QCA807x PHY package Christian Marangi
2023-11-23 2:15 ` Andrew Lunn
2023-11-23 11:20 ` Robert Marko
2023-11-23 9:41 ` Russell King (Oracle)
2023-11-20 13:50 ` [net-next RFC PATCH 13/14] net: phy: add Qualcom QCA807x driver Christian Marangi
2023-11-23 2:55 ` Andrew Lunn
2023-11-20 13:50 ` [net-next RFC PATCH 14/14] net: phy: qca807x: Add support for configurable LED Christian Marangi
2023-11-20 15:11 ` [net-next RFC PATCH 00/14] net: phy: Support DT PHY package Maxime Chevallier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231124165923.p2iozsrnwlogjzua@skbuf \
--to=olteanv@gmail.com \
--cc=SkyLake.Huang@mediatek.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ansuelsmth@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=conor+dt@kernel.org \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=david.epping@missinglinkelectronics.com \
--cc=devicetree@vger.kernel.org \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=harini.katakam@amd.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robert.marko@sartura.hr \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox