[PATCH net-next v2 00/11] net: pcs: Add support for devices probed in the "usual" manner

Vladimir Oltean vladimir.oltean at nxp.com
Fri Nov 11 02:29:26 AEDT 2022


On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> On 11/9/22 17:41, Vladimir Oltean wrote:
> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> 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?

> 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/

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.


More information about the Linuxppc-dev mailing list