On 11/10/22 10:29, Vladimir Oltean wrote:

On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:

quoted

On 11/9/22 17:41, Vladimir Oltean wrote:

quoted

On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:

quoted

Several (later) patches in this series cannot be applied until a stable
release has occured containing the dts updates.

New kernels must remain compatible with old device trees.

Well, this binding is not present in older device trees, so it needs to
be added before these patches can be applied. It also could be possible
to manually bind the driver using e.g. a helper function (like what is
done with lynx_pcs_create_on_bus). Of course this would be tricky,
because we would need to unbind any generic phy driver attached, but
avoid unbinding an existing Lynx PCS driver.

If you know the value of the MII_PHYSID1 and MII_PHYSID2 registers for
these PCS devices, would it be possible to probe them in a generic way
as MDIO devices, if they lack a compatible string?

PCS devices are not PHYs, and they do not necessarily conform to the
standard PHY registers. Some PCS devices aren't even on MDIO busses (and
are instead memory-mapped). To implement this, I think we would need to be
very careful. There's also the issue where PCS devices might not be
accessable before their mode is selected by the MAC or SerDes.

quoted

As I understand it, kernels must be compatible with device trees from a
few kernels before and after. There is not a permanent guarantee of
backwards compatibility (like userspace has) because otherwise we would
never be able to make internal changes (such as what is done in this
series). I have suggested deferring these patches until after an LTS
release as suggested by Rob last time [1].

--Sean

[1] https://lore.kernel.org/netdev/20220718194444.GA3377770-robh@kernel.org/ (local)

Internal changes limit themselves to what doesn't break compatibility
with device trees in circulation. DT bindings are ABI. Compared to the
lifetime of DPAA2 SoCs (and especially DPAA1), 1 LTS release is nothing,
sorry. The kernel has to continue probing them as Lynx PCS devices even
in lack of a compatible string.

I believe the idea here is to allow some leeway when updating so that
the kernel and device tree don't have to always be in sync. However, we
don't have to support a situation where the kernel is constantly updated
but the device tree is never updated. As long as a reasonable effort is
made to update (or *not* update) both the kernel and device tree, there
is no problem.

--Sean