> > > For i2c, it could look something like this:
> > >
> > > connector {
> > > i2c {
> > > i2c-parent = <&i2c1>;
> > >
> > > eeprom@50 {...};
> > > };
> > > };
I definitely understand the usefulness of such an additional level of
indirection in the most general case, to decouple the add-on side of the
I2C bus from the base board side of it, thus allowing multiple different
base board models and even helping with having multiple connectors
(multiple add-ons at the same time) on the same main board.
But I also see drawbacks.
The first one is added complexity.
The second is that this representation seems to suggest that the 'i2c'
node above is another bus w.r.t. '&i2c1', somewhat similarly to what
happens with child busses of an i2c mux being a different node from the
parent bus. But in this case they are really the same bus on the same
electrical lines (when the add-on is connected).
So I think both representations have pros and cons.
Back to the specific product I'm working on: there is only one base
board model, and also only one connector per main board, and this is by
the very nature of the product, i.e. it would not make sense to have
two connectors on the same board.
So in the specific case of this product, do you think it would be OK to
keep the representation I proposed initially?
> > > Do you load the first overlay and then from it decide which
> > > specific overlay to apply?
> >
> > Exactly.
> >
> > The first overlay (the example you quoted above) describes enough to
> > reach the model ID in the EEPROM, and this is identical for all add-on
> > models. The second add-on is model-specific, there is one for each
> > model, and the model ID allows to know which one to load.
>
> So you don't really need an overlay for this unless the EEPROM model
> changes or the model-id offset changes.
The EEPROM model is the same on all add-on models, or at least it's
fully compatible. Otherwise finding out the model ID would become very
annoying.
However the EEPROM is on the add-on, so describing it in the main DT
would be wrong. Not only conceptually, as hardware not present should
not be in the live DT, but also practically, as when the add-on is
removed and then a possibly different add-on is connected we need the
EEPROM driver to probe again, in order to do any initialization that
might be needed in the EEPROM driver probe function.
So I see no option but adding the EEPROM in an overlay. But it cannot
be the "full" overlay because before accessing the EEPROM we don't know
which model is loaded.
Do you have in mind a better approach that I just didn't think about?
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
