From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Josua Mayer <josua@solid-run.com>
Cc: Conor Dooley <conor@kernel.org>,
"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH phy 13/14] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation
Date: Fri, 5 Sep 2025 18:29:50 +0300 [thread overview]
Message-ID: <20250905152950.dvt2jqpgfjuzyh4o@skbuf> (raw)
In-Reply-To: <27f64133-729b-448c-96ce-771716485786@solid-run.com>
On Fri, Sep 05, 2025 at 02:44:33PM +0000, Josua Mayer wrote:
> >> Do you have a specific format in mind?
> > I have a prototype implementation based on v5.15 using properties as below
> > (I am not sure this is the best format though, DT maintainers may have opinions):
> >
> > serdes_1_lane_g: phy@6 {
> > reg = <6>;
> > #phy-cells = <0>;
> > fsl,eq-names = "10gbase-r", "25gbase-r";
> > fsl,eq-type = "3-tap", "3-tap";
> > fsl,eq-preq-sign = "positive", "positive";
> > fsl,eq-preq-rate = "1.33", "1.33";
> > fsl,eq-post1q-sign = "negative", "negative";
> > fsl,eq-post1q-rate = "1.26", "1.26";
> > fsl,eq-amp-red = "1.000", "1.000";
> > fsl,eq-adaptive = <32>, <32>;
> > };
> >
> > I imagine a parameters sub-node per protocol may be more readable.
> >
> > The best description would be generic enough to cover pci and sata, too.
> >
> > Perhaps:
> >
> > serdes_1_lane_g: phy@6 {
> > reg = <6>;
> > #phy-cells = <0>;
> > fsl,eq-params = <&serdes_1_lane_g_eq_10g>, <&serdes_1_lane_g_eq_sata>;
>
> fsl,lane-modes = "xfi", "sata";
>
> ^^ Would be mroe elegant, as it can at the same time explain which modes
> a specific lane supports generally.
>
> Then eq-params is an optional list with specific parameters, some of
> which can be shared between different modes (40g/10g)
>
> > serdes_1_lane_g_eq_10g: eq-params-0 {
> > /* compare downstream enum lynx_28g_lane_mode */
> > fsl,lane-protocol = "xfi";
> > fsl,eq-type = "3-tap";
> > fsl,eq-preq-sign = "positive";
> > fsl,eq-preq-rate = "1.33";
> > fsl,eq-post1q-sign = "negative";
> > fsl,eq-post1q-rate = "1.26";
> > fsl,eq-amp-red = "1.000";
> > fsl,eq-adaptive = <32>;
> > };
> >
> > serdes_1_lane_g_eq_sata: eq-1 {
> > /* compare downstream enum lynx_28g_lane_mode */
> > /* example parameters, do not use for sata */
> > fsl,lane-mode = "pci";
> > fsl,eq-type = "3-tap";
> > fsl,eq-preq-sign = "positive";
> > fsl,eq-preq-rate = "1.33";
> > fsl,eq-post1q-sign = "negative";
> > fsl,eq-post1q-rate = "1.26";
> > fsl,eq-amp-red = "1.000";
> > fsl,eq-adaptive = <32>;
> > };
> > };
Why stop the eq-params reuse at "per lane"? Why not make these global
nodes, like SFP cages? It's imaginable your pre-emphasis settings might
be the same across the board, for both SerDes #1 and #2 lanes.
Also, let's take what is upstream now as a starting point. Currently the
driver has #phy-cells = <1> (i.e. the "phys" phandle is to the SerDes,
not to individual lanes). Wouldn't we want to keep it that way, and make
the SerDes lane sub-nodes optional, only in case they have phandles to
custom pre-emphasis settings? If they don't, use the driver default
pre-emphasis.
> >> In the circumstance you describe, isn't your fix just "code after return"?
> >> How would have lynx_28g_set_mode(PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_2500BASEX)
> >> gotten past the lynx_28g_supports_interface() test without being rejected?
> > v6.6.6.52-2.2.0 release, .set_mode:
> >
> > lynx_28g_set_mode->lynx_28g_set_link_mode->lynx_28g_set_lane_mode->lynx_28g_pll_get
> >
> > does not check lynx_28g_supports_interface.
> >
> >> The driver would have needed to suffer some pretty serious modifications
> >> to allow this to happen, and I'm not happy with the fact that it's changed
> >> to handle incorrect downstream changes, without at least a complete
> >> description.
> > Point of my submitted patch was merely to guard an unchecked pointer,
> > generating appropriate error with enough explanation for non-maintainers.
> >
> > I debated using BUG_ON instead of warn.
Sorry for maybe being obtuse. You're saying you added code in mainline
to check for a condition that exists only in downstream lf-6.6.52-2.2.0?
Why?
next prev parent reply other threads:[~2025-09-05 15:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 15:43 [PATCH phy 00/14] Lynx 28G improvements part 1 Vladimir Oltean
2025-09-04 15:44 ` [PATCH phy 13/14] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation Vladimir Oltean
2025-09-04 19:22 ` Conor Dooley
2025-09-05 10:49 ` Vladimir Oltean
2025-09-05 11:10 ` Josua Mayer
2025-09-05 11:37 ` Vladimir Oltean
2025-09-05 14:23 ` Josua Mayer
2025-09-05 14:44 ` Josua Mayer
2025-09-05 15:29 ` Vladimir Oltean [this message]
2025-09-05 15:50 ` Josua Mayer
2025-09-09 11:37 ` Vladimir Oltean
2025-09-05 18:58 ` Conor Dooley
2025-09-05 8:29 ` Krzysztof Kozlowski
2025-09-05 11:02 ` Vladimir Oltean
2025-09-05 15:41 ` Vladimir Oltean
2025-09-05 19:02 ` Conor Dooley
2025-09-08 9:37 ` Vladimir Oltean
2025-09-08 14:02 ` Josua Mayer
2025-09-08 15:37 ` Vladimir Oltean
2025-09-08 16:04 ` Josua Mayer
2025-09-09 11:35 ` Vladimir Oltean
2025-09-09 18:35 ` Conor Dooley
2025-09-09 18:58 ` Vladimir Oltean
2025-09-16 17:07 ` Vladimir Oltean
2025-09-17 10:47 ` Josua Mayer
2025-09-08 18:39 ` Conor Dooley
2025-09-04 15:44 ` [PATCH phy 14/14] phy: lynx-28g: probe on per-SoC and per-instance compatible strings Vladimir Oltean
2025-09-05 10:41 ` Ioana Ciornei
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=20250905152950.dvt2jqpgfjuzyh4o@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=conor+dt@kernel.org \
--cc=conor@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=robh@kernel.org \
--cc=vkoul@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