Hello Tomi, Matti, Wolfram, On Thu, 3 Nov 2022 14:32:02 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote: > On 03/11/2022 14:13, Vaittinen, Matti wrote: > > On 11/3/22 13:50, Tomi Valkeinen wrote: > >> Hi Rob, > >> > >> On 02/11/2022 19:26, Rob Herring wrote: > >>> On Tue, Nov 01, 2022 at 03:20:27PM +0200, Tomi Valkeinen wrote: > >>>> + > >>>> + i2c-alias-pool: > >>> > >>> Something common or could be? If not, then needs a vendor prefix. > >> > >> I'll have to think about this. It is related to the i2c-atr, so I think > >> it might be a common thing. > > > > I'd say this should be common. Where the i2c-atr properties should live > > is another question though. If the I2C-atr stays as a genericly usable > > component - then these bindings should be in a file that can be > > referenced by other I2C-atr users (like the UB960 here). > > Yep. All the links, link, serializer and alias nodes/properties are new > things here, and I guess these could be used by other deser-ser systems. > That said, I don't have any experience with other systems. The i2c-alias-pool was discussed during the RFC,v2 review [1] and it was agreed that it should be generic. The same principle should apply to the other ATR properties. That said, at some point it was also decided that the alias pool should just be ditched in favor of an automatic selection of an unused address by the i2c core [2] [3]. Maybe that idea has changed, definitely some i2c core things needed to be omdified for it to happen, but overall I'm still convinced automatic assignment without a pool was a good idea. > >>>> + > >>>> + i2c-alias: > >>> > >>> Vendor prefix. > >>> > >>>> + description: | > >>>> + The i2c address used for the serializer. Transactions > >>>> to this > >>>> + address on the i2c bus where the deserializer resides are > >>>> + forwarded to the serializer. > >>>> + > >>>> + rx-mode: > >>> > >>> Vendor prefix. And so on... > > >> Yes, I totally missed these. > > > > > > I think the i2c-alias might need to be common as well? > > Perhaps... > > I was also thinking that the serializer addresses could be taken from > the i2c-alias-pool. But maybe that's not a good idea, as the > serializer-access and remote-peripheral-access are a bit different (e.g. > no ATR when accessing the serializer). > > And I was thinking that, at least here, the alias addresses can be > "anything", so they could be reserved dynamically at runtime, without > any predefined aliases. But that might be a bit confusing to the user. I think the serialized alias selection is in an intermediate situation between the deser and the remove chips. For the deser there is a physical address, nothing strange. For the remote chips, lots of things could happen, including having several chips. The serializer is in known quantity (one per connector) and the fact that it is "on the remote bus" is also somewhat false as it does create the remote bus itself. Thus for me it would make sense to keep the current structure (which is quite simple) but mine in not a strong position. [1] https://lore.kernel.org/lkml/CAL_JsqKDkixeDJJVxbzWebD6nqMHyk6QqDGSKrQho0THjLdmKQ@xxxxxxxxxxxxxx/ [2] https://lore.kernel.org/lkml/20190903093455.GD1020@kunai/ [3] https://lucaceresoli.net/plumbers-i2c-bof/ -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
