From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
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>,
Vladimir Oltean <olteanv@gmail.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: Mon, 20 Nov 2023 19:09:10 +0100 [thread overview]
Message-ID: <655bc8d6.050a0220.d22f2.315f@mx.google.com> (raw)
In-Reply-To: <c21ff90d-6e05-4afc-b39c-2c71d8976826@lunn.ch>
On Mon, Nov 20, 2023 at 09:44:58PM +0100, Andrew Lunn wrote:
> On Mon, Nov 20, 2023 at 02:50:30PM +0100, Christian Marangi wrote:
> > Document ethernet PHY package nodes used to describe PHY shipped in
> > bundle of 4-5 PHY. These particular PHY require specific PHY in the
> > package for global onfiguration of the PHY package.
> >
> > Example are PHY package that have some regs only in one PHY of the
> > package and will affect every other PHY in the package, for example
> > related to PHY interface mode calibration or global PHY mode selection.
>
> I think you are being overly narrow here. The 'global' registers could
> be spread over multiple addresses. Particularly for a C22 PHY. I
> suppose they could even be in a N+1 address space, where there is no
> PHY at all.
>
> Where the global registers are is specific to a PHY package
> vendor/model. The PHY driver should know this. All the PHY driver
> needs to know is some sort of base offset. PHY0 in this package is
> using address X. It can then use relative addressing from this base to
> access the global registers for this package.
Yes that would also work but adds extra fragile code in PHY driver.
An idea might be define PHY package node with a reg that is the base
addr... and if we really want every PHY in the PHY package node is an
offset of the base addr.
>
> > It's also possible to specify the property phy-mode to specify that the
> > PHY package sets a global PHY interface mode and every PHY of the
> > package requires to have the same PHY interface mode.
>
> I don't think it is what simple. See the QCA8084 for example. 3 of the
> 4 PHYs must use QXGMII. The fourth PHY can also use QXGMII but it can
> be multiplexed to a different PMA and use 1000BaseX, SGMII or
> 2500BaseX.
Yes that is totally a problem but I think it can only be handled with
some validation in the PHY driver... I assume probe_once would validate
the modes?
>
> I do think we need somewhere to put package properties. But i don't
> think phy-mode is such a property. At the moment, i don't have a good
> example of a package property.
>
And this is the main problem with this thing... Find a good way to
define them that everyone is OK with.
Another idea might be introduce to each PHY a property that point to the
PHY package node (phandle) with all the info... But where to place
that??? Outside mdio node? That would be confusing... This is why I like
this subnode way.
I know it deviates a bit from the normal way of defining small node in
the mdio node one for each PHY.
> > +examples:
> > + - |
> > + ethernet {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet-phy-package {
> > + compatible = "ethernet-phy-package";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> You have the PHYs within the Ethernet node. This is allowed by DT, for
> historic reasons. However, i don't remember the last time a patch was
> submitted that actually used this method. Now a days, PHYs are on an
> MDIO bus, and they are children of that bus in the DT representation.
> However you represent the package needs to work with MDIO busses.
>
Using the ethernet node was an oversight and actually this is defined as
a subnode in the mdio node.
A real DT that use this is (ipq807x):
&mdio {
status = "okay";
pinctrl-0 = <&mdio_pins>;
pinctrl-names = "default";
reset-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
ethernet-phy-package {
compatible = "ethernet-phy-package";
phy-mode = "psgmii";
global-phys = <&qca8075_4>, <&qca8075_psgmii>;
global-phy-names = "combo", "analog_psgmii";
qca8075_0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
qca8075_1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
qca8075_2: ethernet-phy@2 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <2>;
};
qca8075_3: ethernet-phy@3 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <3>;
};
qca8075_4: ethernet-phy@4 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <4>;
};
qca8075_psgmii: ethernet-phy@5 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <5>;
};
};
qca8081: ethernet-phy@28 {
compatible = "ethernet-phy-id004d.d101";
reg = <28>;
reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
};
aqr113c: ethernet-phy@8 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <8>;
reset-gpios = <&tlmm 63 GPIO_ACTIVE_LOW>;
};
};
--
Ansuel
WARNING: multiple messages have this Message-ID (diff)
From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
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>,
Vladimir Oltean <olteanv@gmail.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: Mon, 20 Nov 2023 19:09:10 +0100 [thread overview]
Message-ID: <655bc8d6.050a0220.d22f2.315f@mx.google.com> (raw)
In-Reply-To: <c21ff90d-6e05-4afc-b39c-2c71d8976826@lunn.ch>
On Mon, Nov 20, 2023 at 09:44:58PM +0100, Andrew Lunn wrote:
> On Mon, Nov 20, 2023 at 02:50:30PM +0100, Christian Marangi wrote:
> > Document ethernet PHY package nodes used to describe PHY shipped in
> > bundle of 4-5 PHY. These particular PHY require specific PHY in the
> > package for global onfiguration of the PHY package.
> >
> > Example are PHY package that have some regs only in one PHY of the
> > package and will affect every other PHY in the package, for example
> > related to PHY interface mode calibration or global PHY mode selection.
>
> I think you are being overly narrow here. The 'global' registers could
> be spread over multiple addresses. Particularly for a C22 PHY. I
> suppose they could even be in a N+1 address space, where there is no
> PHY at all.
>
> Where the global registers are is specific to a PHY package
> vendor/model. The PHY driver should know this. All the PHY driver
> needs to know is some sort of base offset. PHY0 in this package is
> using address X. It can then use relative addressing from this base to
> access the global registers for this package.
Yes that would also work but adds extra fragile code in PHY driver.
An idea might be define PHY package node with a reg that is the base
addr... and if we really want every PHY in the PHY package node is an
offset of the base addr.
>
> > It's also possible to specify the property phy-mode to specify that the
> > PHY package sets a global PHY interface mode and every PHY of the
> > package requires to have the same PHY interface mode.
>
> I don't think it is what simple. See the QCA8084 for example. 3 of the
> 4 PHYs must use QXGMII. The fourth PHY can also use QXGMII but it can
> be multiplexed to a different PMA and use 1000BaseX, SGMII or
> 2500BaseX.
Yes that is totally a problem but I think it can only be handled with
some validation in the PHY driver... I assume probe_once would validate
the modes?
>
> I do think we need somewhere to put package properties. But i don't
> think phy-mode is such a property. At the moment, i don't have a good
> example of a package property.
>
And this is the main problem with this thing... Find a good way to
define them that everyone is OK with.
Another idea might be introduce to each PHY a property that point to the
PHY package node (phandle) with all the info... But where to place
that??? Outside mdio node? That would be confusing... This is why I like
this subnode way.
I know it deviates a bit from the normal way of defining small node in
the mdio node one for each PHY.
> > +examples:
> > + - |
> > + ethernet {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet-phy-package {
> > + compatible = "ethernet-phy-package";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> You have the PHYs within the Ethernet node. This is allowed by DT, for
> historic reasons. However, i don't remember the last time a patch was
> submitted that actually used this method. Now a days, PHYs are on an
> MDIO bus, and they are children of that bus in the DT representation.
> However you represent the package needs to work with MDIO busses.
>
Using the ethernet node was an oversight and actually this is defined as
a subnode in the mdio node.
A real DT that use this is (ipq807x):
&mdio {
status = "okay";
pinctrl-0 = <&mdio_pins>;
pinctrl-names = "default";
reset-gpios = <&tlmm 37 GPIO_ACTIVE_LOW>;
ethernet-phy-package {
compatible = "ethernet-phy-package";
phy-mode = "psgmii";
global-phys = <&qca8075_4>, <&qca8075_psgmii>;
global-phy-names = "combo", "analog_psgmii";
qca8075_0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
qca8075_1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
qca8075_2: ethernet-phy@2 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <2>;
};
qca8075_3: ethernet-phy@3 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <3>;
};
qca8075_4: ethernet-phy@4 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <4>;
};
qca8075_psgmii: ethernet-phy@5 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <5>;
};
};
qca8081: ethernet-phy@28 {
compatible = "ethernet-phy-id004d.d101";
reg = <28>;
reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
};
aqr113c: ethernet-phy@8 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <8>;
reset-gpios = <&tlmm 63 GPIO_ACTIVE_LOW>;
};
};
--
Ansuel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-20 21:00 UTC|newest]
Thread overview: 113+ 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 ` 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 ` 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 13:50 ` Christian Marangi
2023-11-20 15:14 ` Rob Herring
2023-11-20 15:14 ` Rob Herring
2023-11-20 17:30 ` 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 13:50 ` Christian Marangi
2023-11-20 17:41 ` Rob Herring
2023-11-20 17:41 ` Rob Herring
2023-11-20 16:39 ` Christian Marangi
2023-11-20 16:39 ` Christian Marangi
2023-11-20 20:44 ` Andrew Lunn
2023-11-20 20:44 ` Andrew Lunn
2023-11-20 18:09 ` Christian Marangi [this message]
2023-11-20 18:09 ` Christian Marangi
2023-11-20 21:25 ` Andrew Lunn
2023-11-20 21:25 ` Andrew Lunn
2023-11-20 18:45 ` Christian Marangi
2023-11-20 18:45 ` Christian Marangi
2023-11-21 14:42 ` Rob Herring
2023-11-21 14:42 ` Rob Herring
2023-11-21 14:45 ` Andrew Lunn
2023-11-21 14:45 ` Andrew Lunn
2023-11-22 18:32 ` Christian Marangi
2023-11-22 18:32 ` Christian Marangi
2023-11-23 3:30 ` Andrew Lunn
2023-11-23 3:30 ` Andrew Lunn
2023-11-23 10:38 ` Christian Marangi
2023-11-23 10:38 ` Christian Marangi
2023-11-23 14:27 ` Andrew Lunn
2023-11-23 14:27 ` Andrew Lunn
2023-11-23 14:35 ` Russell King (Oracle)
2023-11-23 14:35 ` Russell King (Oracle)
2023-11-23 14:57 ` Andrew Lunn
2023-11-23 14:57 ` Andrew Lunn
2023-11-23 19:33 ` Christian Marangi
2023-11-23 19:33 ` Christian Marangi
2023-11-24 11:49 ` Jie Luo
2023-11-24 11:49 ` Jie Luo
2023-11-24 12:02 ` Russell King (Oracle)
2023-11-24 12:02 ` Russell King (Oracle)
2023-11-24 14:44 ` Andrew Lunn
2023-11-24 14:44 ` Andrew Lunn
2023-11-24 15:16 ` Russell King (Oracle)
2023-11-24 15:16 ` Russell King (Oracle)
2023-11-24 16:59 ` Robert Marko
2023-11-24 16:59 ` Robert Marko
2023-11-23 15:07 ` Andrew Lunn
2023-11-23 15:07 ` Andrew Lunn
2023-11-23 19:36 ` Christian Marangi
2023-11-23 19:36 ` Christian Marangi
2023-11-24 16:59 ` Vladimir Oltean
2023-11-24 16:59 ` Vladimir Oltean
2023-11-24 16:25 ` Christian Marangi
2023-11-24 16:25 ` Christian Marangi
2023-11-24 18:27 ` Vladimir Oltean
2023-11-24 18:27 ` Vladimir Oltean
2023-11-24 18:35 ` Andrew Lunn
2023-11-24 18:35 ` Andrew Lunn
2023-11-24 19:40 ` Vladimir Oltean
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-20 13:50 ` Christian Marangi
2023-11-22 10:41 ` Simon Horman
2023-11-22 10:41 ` Simon Horman
2023-11-22 10:52 ` Simon Horman
2023-11-22 10:52 ` Simon Horman
2023-11-22 18:15 ` Christian Marangi
2023-11-22 18:15 ` Christian Marangi
2023-11-22 21:14 ` Simon Horman
2023-11-22 21:14 ` Simon Horman
2023-11-22 12:40 ` kernel test robot
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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Christian Marangi
2023-11-20 13:50 ` [net-next RFC PATCH 11/14] dt-bindings: net: add QCA807x PHY defines Christian Marangi
2023-11-20 13:50 ` Christian Marangi
2023-11-23 3:01 ` Andrew Lunn
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-20 13:50 ` Christian Marangi
2023-11-23 2:15 ` Andrew Lunn
2023-11-23 2:15 ` Andrew Lunn
2023-11-23 11:20 ` Robert Marko
2023-11-23 11:20 ` Robert Marko
2023-11-23 9:41 ` Russell King (Oracle)
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-20 13:50 ` Christian Marangi
2023-11-21 13:37 ` kernel test robot
2023-11-22 14:48 ` kernel test robot
2023-11-22 15:45 ` kernel test robot
2023-11-23 2:55 ` Andrew Lunn
2023-11-23 2:55 ` Andrew Lunn
2023-11-24 11:46 ` kernel test robot
2023-11-20 13:50 ` [net-next RFC PATCH 14/14] net: phy: qca807x: Add support for configurable LED Christian Marangi
2023-11-20 13:50 ` Christian Marangi
2023-11-20 15:11 ` [net-next RFC PATCH 00/14] net: phy: Support DT PHY package Maxime Chevallier
2023-11-20 15:11 ` 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=655bc8d6.050a0220.d22f2.315f@mx.google.com \
--to=ansuelsmth@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=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=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.