From: Rob Herring <robh@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: linux-phy@lists.infradead.org,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Josua Mayer <josua@solid-run.com>,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation
Date: Thu, 25 Sep 2025 08:05:10 -0500 [thread overview]
Message-ID: <20250925130510.GA451343-robh@kernel.org> (raw)
In-Reply-To: <20250924154534.cyyfi2aez46iu2sw@skbuf>
On Wed, Sep 24, 2025 at 06:45:34PM +0300, Vladimir Oltean wrote:
> Hi Rob,
>
> On Wed, Sep 24, 2025 at 08:54:29AM -0500, Rob Herring wrote:
> > > +description: |
> >
> > Don't need '|' if no formatting to preserve.
>
> Thanks, will drop.
>
> > > + "#address-cells":
> > > + const: 1
> > > + description: "Address cells for child lane nodes"
> >
> > You don't need generic descriptions of common properties.
>
> Ok, I'll also drop the description from #size-cells but keep it in
> #phy-cells (less obvious).
>
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > + description: "Size cells for child lane nodes"
> > > +
> > > "#phy-cells":
> > > + description: "Number of cells in PHY specifier (legacy binding only)"
> > > const: 1
> > >
> > > @@ -32,9 +124,51 @@ examples:
> > > soc {
> > > #address-cells = <2>;
> > > #size-cells = <2>;
> > > - serdes_1: phy@1ea0000 {
> > > - compatible = "fsl,lynx-28g";
> > > +
> > > + serdes_1: serdes@1ea0000 {
> > > + compatible = "fsl,lx2160a-serdes1";
> > > reg = <0x0 0x1ea0000 0x0 0x1e30>;
> > > - #phy-cells = <1>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + phy@0 {
> > > + reg = <0>;
> > > + #phy-cells = <0>;
> > > + };
> >
> > There's really no difference between having child nodes 0-7 and 8 phy
> > providers vs. putting 0-7 into a phy cell arg and 1 phy provider.
> >
> > The only difference I see is it is more straight-forward to determine
> > what lanes are present in the phy driver if the driver needs to know
> > that. But you can also just read all 'phys' properties in the DT with a
> > &serdes_1 phandle and determine that. Is that efficient? No, but you
> > have to do that exactly once and probably has no measurable impact.
> >
> > With that, then can't you simply just add a more specific compatible:
> >
> > compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
> >
> > Then you maintain some compatibility.
> >
> > Rob
>
> With the patches that have been presented to you thus far -- yes, this
> is the correct conclusion, there is not much of a difference. But this
> is not all.
That's all I can base my conclusion on if you don't tell me more...
> If I want in the future to apply the properties from
> Documentation/devicetree/bindings/phy/transmit-amplitude.yaml to just
> one of the lanes, how would I do that with just 1 phy provider? It's not
> so clear. Compared to 8 phy providers, each with its OF node => much
> easier to structure and to understand.
That's unfortunate that binding wasn't designed to support more than
1 instance. You could do:
lane@0 {
reg = <0>;
tx-p2p-microvolt = <123>;
};
lane@1 {
reg = <1>;
tx-p2p-microvolt = <123>;
};
Yeah, that's about what you had, but it avoids changing the cell size.
That should be a bit simpler to implement in the driver and to add to
existing DTs as a fixup (because you don't have to change 'phys' entries
everywhere).
Another option is go to cell size of 2 and stick the voltage in a cell.
That approach doesn't work well if you have a 3rd, 4th, etc. cell to add
later for more properties.
Your overlaying the old and new bindings approach works too. That
approach is fine with me.
Rob
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: linux-phy@lists.infradead.org,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Josua Mayer <josua@solid-run.com>,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation
Date: Thu, 25 Sep 2025 08:05:10 -0500 [thread overview]
Message-ID: <20250925130510.GA451343-robh@kernel.org> (raw)
In-Reply-To: <20250924154534.cyyfi2aez46iu2sw@skbuf>
On Wed, Sep 24, 2025 at 06:45:34PM +0300, Vladimir Oltean wrote:
> Hi Rob,
>
> On Wed, Sep 24, 2025 at 08:54:29AM -0500, Rob Herring wrote:
> > > +description: |
> >
> > Don't need '|' if no formatting to preserve.
>
> Thanks, will drop.
>
> > > + "#address-cells":
> > > + const: 1
> > > + description: "Address cells for child lane nodes"
> >
> > You don't need generic descriptions of common properties.
>
> Ok, I'll also drop the description from #size-cells but keep it in
> #phy-cells (less obvious).
>
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > + description: "Size cells for child lane nodes"
> > > +
> > > "#phy-cells":
> > > + description: "Number of cells in PHY specifier (legacy binding only)"
> > > const: 1
> > >
> > > @@ -32,9 +124,51 @@ examples:
> > > soc {
> > > #address-cells = <2>;
> > > #size-cells = <2>;
> > > - serdes_1: phy@1ea0000 {
> > > - compatible = "fsl,lynx-28g";
> > > +
> > > + serdes_1: serdes@1ea0000 {
> > > + compatible = "fsl,lx2160a-serdes1";
> > > reg = <0x0 0x1ea0000 0x0 0x1e30>;
> > > - #phy-cells = <1>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + phy@0 {
> > > + reg = <0>;
> > > + #phy-cells = <0>;
> > > + };
> >
> > There's really no difference between having child nodes 0-7 and 8 phy
> > providers vs. putting 0-7 into a phy cell arg and 1 phy provider.
> >
> > The only difference I see is it is more straight-forward to determine
> > what lanes are present in the phy driver if the driver needs to know
> > that. But you can also just read all 'phys' properties in the DT with a
> > &serdes_1 phandle and determine that. Is that efficient? No, but you
> > have to do that exactly once and probably has no measurable impact.
> >
> > With that, then can't you simply just add a more specific compatible:
> >
> > compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
> >
> > Then you maintain some compatibility.
> >
> > Rob
>
> With the patches that have been presented to you thus far -- yes, this
> is the correct conclusion, there is not much of a difference. But this
> is not all.
That's all I can base my conclusion on if you don't tell me more...
> If I want in the future to apply the properties from
> Documentation/devicetree/bindings/phy/transmit-amplitude.yaml to just
> one of the lanes, how would I do that with just 1 phy provider? It's not
> so clear. Compared to 8 phy providers, each with its OF node => much
> easier to structure and to understand.
That's unfortunate that binding wasn't designed to support more than
1 instance. You could do:
lane@0 {
reg = <0>;
tx-p2p-microvolt = <123>;
};
lane@1 {
reg = <1>;
tx-p2p-microvolt = <123>;
};
Yeah, that's about what you had, but it avoids changing the cell size.
That should be a bit simpler to implement in the driver and to add to
existing DTs as a fixup (because you don't have to change 'phys' entries
everywhere).
Another option is go to cell size of 2 and stick the voltage in a cell.
That approach doesn't work well if you have a 3rd, 4th, etc. cell to add
later for more properties.
Your overlaying the old and new bindings approach works too. That
approach is fine with me.
Rob
next prev parent reply other threads:[~2025-09-25 13:05 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 19:44 [PATCH v2 phy 00/16] Lynx 28G improvements part 1 Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 01/16] phy: lynx-28g: remove LYNX_28G_ prefix from register names Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 02/16] phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg" with "val" and "mask" Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 03/16] phy: lynx-28g: use FIELD_GET() and FIELD_PREP() Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 04/16] phy: lynx-28g: convert iowrite32() calls with magic values to macros Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 05/16] phy: lynx-28g: restructure protocol configuration register accesses Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 06/16] phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 07/16] phy: lynx-28g: refactor lane->interface to lane->mode Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 08/16] phy: lynx-28g: distinguish between 10GBASE-R and USXGMII Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 09/16] phy: lynx-28g: configure more equalization params for 1GbE and 10GbE Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 10/16] phy: lynx-28g: use "dev" argument more in lynx_28g_probe() Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 11/16] phy: lynx-28g: improve lynx_28g_probe() sequence Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 20:37 ` Rob Herring (Arm)
2025-09-23 20:37 ` Rob Herring (Arm)
2025-09-23 20:57 ` Vladimir Oltean
2025-09-23 20:57 ` Vladimir Oltean
2025-09-24 13:54 ` Rob Herring
2025-09-24 13:54 ` Rob Herring
2025-09-24 15:45 ` Vladimir Oltean
2025-09-24 15:45 ` Vladimir Oltean
2025-09-24 15:56 ` Josua Mayer
2025-09-24 15:56 ` Josua Mayer
2025-09-25 8:03 ` Vladimir Oltean
2025-09-25 8:03 ` Vladimir Oltean
2025-09-25 13:05 ` Rob Herring [this message]
2025-09-25 13:05 ` Rob Herring
2025-09-23 19:44 ` [PATCH v2 phy 13/16] phy: lynx-28g: probe on per-SoC and per-instance compatible strings Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 14/16] phy: lynx-28g: add support for 25GBASER Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-23 19:44 ` [PATCH v2 phy 15/16] phy: lynx-28g: truly power the lanes up or down Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
2025-09-24 10:09 ` Josua Mayer
2025-09-24 10:09 ` Josua Mayer
2025-09-24 13:06 ` Vladimir Oltean
2025-09-24 13:06 ` Vladimir Oltean
2025-09-24 15:57 ` Josua Mayer
2025-09-24 15:57 ` Josua Mayer
2025-09-23 19:44 ` [PATCH v2 phy 16/16] phy: lynx-28g: implement phy_exit() operation Vladimir Oltean
2025-09-23 19:44 ` Vladimir Oltean
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=20250925130510.GA451343-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ioana.ciornei@nxp.com \
--cc=josua@solid-run.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=vkoul@kernel.org \
--cc=vladimir.oltean@nxp.com \
/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.