From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: linux-phy@lists.infradead.org,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Josua Mayer <josua@solid-run.com>,
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, stable@vger.kernel.org
Subject: Re: [PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers
Date: Thu, 13 Nov 2025 18:54:54 +0200 [thread overview]
Message-ID: <20251113165454.2fxy5s3ejuepjgy7@skbuf> (raw)
In-Reply-To: <aRYLeVUSk5G3DYlF@vaman>
Hi Vinod,
Thanks for taking a look at this patch set!
On Thu, Nov 13, 2025 at 10:16:49PM +0530, Vinod Koul wrote:
> > Link: https://lore.kernel.org/lkml/02270f62-9334-400c-b7b9-7e6a44dbbfc9@solid-run.com/
> > 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
> > Cc: stable@vger.kernel.org
>
> You can keep cc lines after s-o-b line after the '---' separator, that
> way it will be skipped when applying while email client will cc folks.
Yes, but keeping the CC list even when the patch is applied was the
intention, especially for stable.
> My main question was cc stable, for a binding additions, that might not
> be helpful as dts may not have these updates, so why port bindings?
There is a faction of people, whose point as a matter of fact I do
understand, is that if you make an update to the device tree, you
shouldn't be required to also update the kernel for things to continue
to work as before.
The purpose of backporting the binding addition to stable is exactly in
order for kernels such as linux-6.12.y to start supporting modified
device trees, such that one day we could roll out such modifications.
The series doesn't depend on that, but the "DT is ABI" statement has
implications in terms of kernel <-> device tree compatibility, if you
consider the fact that they can be delivered to a board through
different channels. For example, you try to ship a bootloader that
provides its own device tree to the kernel to support generic distros
which don't come with device trees prepackaged, and you have to support
2 LTS kernels with that same device tree.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2025-11-13 16:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 9:22 [PATCH v4 phy 00/16] Lynx 28G improvements part 1 Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 01/16] dt-bindings: phy: lynx-28g: permit lane OF PHY providers Vladimir Oltean
2025-11-12 16:20 ` Rob Herring (Arm)
2025-11-13 16:46 ` Vinod Koul
2025-11-13 16:54 ` Vladimir Oltean [this message]
2025-11-10 9:22 ` [PATCH v4 phy 02/16] phy: lynx-28g: refactor lane probing to lynx_28g_probe_lane() Vladimir Oltean
2025-11-13 16:49 ` Vinod Koul
2025-11-13 16:56 ` Vladimir Oltean
2025-11-17 18:57 ` Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 03/16] phy: lynx-28g: support individual lanes as OF PHY providers Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 04/16] phy: lynx-28g: remove LYNX_28G_ prefix from register names Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 05/16] phy: lynx-28g: don't concatenate lynx_28g_lane_rmw() argument "reg" with "val" and "mask" Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 06/16] phy: lynx-28g: use FIELD_GET() and FIELD_PREP() Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 07/16] phy: lynx-28g: convert iowrite32() calls with magic values to macros Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 08/16] phy: lynx-28g: restructure protocol configuration register accesses Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 09/16] phy: lynx-28g: make lynx_28g_set_lane_mode() more systematic Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 10/16] phy: lynx-28g: refactor lane->interface to lane->mode Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 11/16] phy: lynx-28g: distinguish between 10GBASE-R and USXGMII Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 12/16] phy: lynx-28g: configure more equalization params for 1GbE and 10GbE Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 13/16] phy: lynx-28g: use "dev" argument more in lynx_28g_probe() Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 14/16] phy: lynx-28g: improve lynx_28g_probe() sequence Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 15/16] dt-bindings: phy: lynx-28g: add compatible strings per SerDes and instantiation Vladimir Oltean
2025-11-10 10:29 ` Rob Herring (Arm)
2025-11-10 11:58 ` Vladimir Oltean
2025-11-10 9:22 ` [PATCH v4 phy 16/16] phy: lynx-28g: probe on per-SoC and per-instance compatible strings 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=20251113165454.2fxy5s3ejuepjgy7@skbuf \
--to=vladimir.oltean@nxp.com \
--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=robh@kernel.org \
--cc=stable@vger.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