From: "Rob Herring (Arm)" <robh@kernel.org>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Josua Mayer <josua@solid-run.com>,
linux-kernel@vger.kernel.org, Vinod Koul <vkoul@kernel.org>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
devicetree@vger.kernel.org,
Kishon Vijay Abraham I <kishon@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-phy@lists.infradead.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>
Subject: Re: [PATCH v2 phy 12/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation
Date: Tue, 23 Sep 2025 15:37:31 -0500 [thread overview]
Message-ID: <175865985168.25580.11987486707034552652.robh@kernel.org> (raw)
In-Reply-To: <20250923194445.454442-13-vladimir.oltean@nxp.com>
On Tue, 23 Sep 2025 22:44:41 +0300, Vladimir Oltean wrote:
> Going by the generic "fsl,lynx-28g" compatible string and expecting all
> SerDes instantiations on all SoCs to use it was a mistake.
>
> They all share the same register map, sure, but the number of protocol
> converters and lanes which are instantiated differs in a way that isn't
> detectable by the programming interface.
>
> Using a separate compatible string per SerDes instantiation is
> sufficient for any device driver to distinguish these features and/or
> any instance-specific quirk. It also reflects how the SoC reference
> manual provides different tables with protocol combinations for each
> SerDes. NXP clearly documents these as not identical, and refers to them
> as such (SerDes 1, 2, etc).
>
> The other sufficient approach would be to list in the device tree all
> protocols supported by each lane. That was attempted in this unmerged
> patch set for the older Lynx 10G family:
> https://lore.kernel.org/linux-phy/20230413160607.4128315-3-sean.anderson@seco.com/
>
> but IMO that approach is more drawn-out and more prone to errors,
> whereas this one is more succinct and obviously correct.
>
> Since this compatible string change breaks forward compatibility of old
> kernels with new device trees (which is OK with the known users), this
> is a good time to fulfill another user request, which is that individual
> SerDes lanes should have had their own OF nodes, so that we can
> customize electrical parameters:
> https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
>
> This request requires #phy-cells = <0>, and because "fsl,lynx-28g"
> requires #phy-cells = <1>, we obviously cannot have both at the same
> time.
>
> Change the expected name of the top-level node to "serdes", and update
> the example too.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2:
> - drop the usage of "fsl,lynx-28g" as a fallback compatible
> - mark "fsl,lynx-28g" as deprecated
> - implement Josua's request for per-lane OF nodes for the new compatible
> strings
>
> .../devicetree/bindings/phy/fsl,lynx-28g.yaml | 146 +++++++++++++++++-
> 1 file changed, 140 insertions(+), 6 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml:42:18: [error] string value is redundantly quoted with any quotes (quoted-strings)
./Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml:46:18: [error] string value is redundantly quoted with any quotes (quoted-strings)
./Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml:49:18: [error] string value is redundantly quoted with any quotes (quoted-strings)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250923194445.454442-13-vladimir.oltean@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
next prev parent reply other threads:[~2025-09-23 20:37 UTC|newest]
Thread overview: 27+ 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 ` [PATCH v2 phy 01/16] phy: lynx-28g: remove LYNX_28G_ prefix from register names 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 ` [PATCH v2 phy 03/16] phy: lynx-28g: use FIELD_GET() and FIELD_PREP() 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 ` [PATCH v2 phy 05/16] phy: lynx-28g: restructure protocol configuration register accesses 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 ` [PATCH v2 phy 07/16] phy: lynx-28g: refactor lane->interface to lane->mode 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 ` [PATCH v2 phy 09/16] phy: lynx-28g: configure more equalization params for 1GbE and 10GbE 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 ` [PATCH v2 phy 11/16] phy: lynx-28g: improve lynx_28g_probe() sequence 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 20:37 ` Rob Herring (Arm) [this message]
2025-09-23 20:57 ` Vladimir Oltean
2025-09-24 13:54 ` Rob Herring
2025-09-24 15:45 ` Vladimir Oltean
2025-09-24 15:56 ` Josua Mayer
2025-09-25 8:03 ` Vladimir Oltean
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 ` [PATCH v2 phy 14/16] phy: lynx-28g: add support for 25GBASER 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-24 10:09 ` Josua Mayer
2025-09-24 13:06 ` Vladimir Oltean
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
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=175865985168.25580.11987486707034552652.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox