On Fri, Sep 13, 2024 at 06:04:17PM +0100, Conor Dooley wrote: > On Fri, Sep 13, 2024 at 04:15:05PM +0300, Vladimir Oltean wrote: > > If we don't add something along these lines, it is absolutely impossible > > to know, for trees with 3 or more switches, which links represent direct > > connections and which don't. > > > > I've studied existing mainline device trees, and it seems that the rule > > has been respected thus far. I've actually tested such a 3-switch setup > > with the Turris MOX. > > What about out of tree (so in u-boot or the likes)? Are there other > users that we need to care about? > > This doesn't really seem like an ABI change, if this is the established > convention, but feels like a fixes tag and backports to stable etc are > in order to me. Looking at the next patch, it does not appear to change the behaviour of existing drivers, it just adds additional information a driver may choose to use. As Vladimir says, all existing instances already appear to be in this order, but that is just happen stance, because it does not matter. So i would be reluctant to say there is an established convention. The mv88e6xxx driver does not care about the order of the list, and this patch series does not appear to change that. So i'm O.K. with the code changes. > > - Should be a list of phandles to other switch's DSA port. This > > - port is used as the outgoing port towards the phandle ports. The > > - full routing information must be given, not just the one hop > > - routes to neighbouring switches > > + Should be a list of phandles to other switch's DSA port. This port is > > + used as the outgoing port towards the phandle ports. In case of trees > > + with more than 2 switches, the full routing information must be given. > > + The first element of the list must be the directly connected DSA port > > + of the adjacent switch. I would prefer to weaken this, just to avoid future backwards compatibility issues. `must` is too strong, because mv88e6xxx does not care, and there could be DT blobs out there which do not conform to this. Maybe 'For the SJA1105, the first element ...". What i don't want is some future developer reading this, assume it is actually true when it maybe is not, and making use of it in the mv88e6xxx or the core, breaking backwards compatibility. Andrew
