Re: [PATCH v9 5/5] docs: i2c: i2c-topology: add section about bus speed

[Marcus Folkesson]

Hi Peter!

On Sat, May 30, 2026 at 08:54:51AM +0200, Peter Rosin wrote:
> Hi all,
> 
> First off, sorry for being so incredibly slow in getting to this
> series.

No worries!


[...]
> > > +Consider the following example: ::
> > > +
> > > +                          .----------. 100kHz .--------.
> > > +        .--------. 400kHz |   mux-   |--------| dev D1 |
> > > +        |  root  |--+-----|  locked  |        '--------'
> > > +        '--------'  |     |  mux M1  |--. 400kHz .--------.
> > > +                    |     '----------'  '--------| dev D2 |
> > > +                    |  .--------.                '--------'
> > > +                    '--| dev D3 |
> > > +                       '--------'
> > > +
> > > +If the idle state of M1 is:
> > > +
> > > +- All channels disconnected: No problem, D1 and D2 are not affected by communication
> > > +  to D3.
> > > +- Last selected channel: Problem if D1 was the last selected channel. High speed
> > > +  communication to D3 will be "leaked" to D1.
> > > +- Predefined channel: Problem if the predefined channel D1. Set predefined channel
> > > +  to D2 as D2 may handle 400kHz.
> > 
> > ... unlike here. We have MUX_IDLE_AS_IS and MUX_IDLE_DISCONNECT defined
> > already. And I'd think we should only allow bus speed switching for
> > MUX_IDLE_DISCONNECT to avoid out-of-spec scenarios. Opinions?
> 
> It is probably not unwise to disallow MUX_IDLE_AS_IS in this context,
> at least until someone actually needs it. Which does not seem all that
> likely?

I agree, I had this in my first iteration [1][2], but only as a warning
though. 

Maybe I should reintroduce `idle_state` again and only allow
MUX_IDLE_DISCONNECT?


[1] https://lists.infradead.org/pipermail/linux-arm-kernel/2025-September/1064986.html
[2] https://lists.infradead.org/pipermail/linux-arm-kernel/2025-September/1064987.html

> 
> However, it seems like it should be fairly OK to allow a predefined
> idle channel, as long as that channel is not lowering the bus speed
> compared to the parent. But maybe supporting that can also wait for
> an actual user?
> 
> > > +Supported controllers
> > > +-----------------------
> > > +
> > > +Not all I2C controllers support setting the bus speed dynamically.
> > > +At the time of writing, the following controllers have support:
> > > +
> > > +============================   =============================================
> > > +i2c-davinci                    Supports dynamic bus speed
> > > +============================   =============================================
> > 
> > This paragaph is easy to get outdated. We can document that only
> > controller drivers with the callback function implemented will work.
> > People then can find out if that applies for their driver...
> 
> There are other such hard-to-maintain lists elsewhere in the text.
> Not saying that this makes neither those nor this list a good idea,
> but it is an explanation for adding one more.
> 
> Cheers,
> Peter


Best regards,
Marcus Folkesson