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@xxxxxxxxxx/ 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.