On 2018-07-12 10:08, Arnd Bergmann wrote:

On Thu, Jul 12, 2018 at 6:41 AM, Peter Rosin [off-list ref] wrote:

quoted

On 2018-07-11 19:12, Boris Brezillon wrote:

quoted

On Wed, 11 Jul 2018 17:39:56 +0200 Arnd Bergmann [off-list ref] wrote:

That's exactly the sort of discussion I wanted to trigger. Maybe we
shouldn't care and expose this use case as if it was X different I3C
buses (with all devices present on the bus being exposed X times to the
system).

For I2C, this multiple masters for one bus case was retrofitted in
the i2c-demux-pinctrl driver. It's a huge kludge with a number of
undesirable quirks. I don't know if the circumstances for adding
this I2C driver also applies for I3C, but it might be an argument
in favor of the proposed extra bus object...

From reading the documentation and git history on that driver,
it seems to be used only for static configuration, i.e. you use
one driver or the other, but don't flip between them at runtime,
right?

There is a sysfs file that can be used to change master at runtime
(current_master). This causes all client drivers to be reprobed,
which may not be the best thing to do for every client out there...

I'm guessing that even with i3c we may have to support something
like that, as a likely scenario might be that the i3c controller is
multiplexed with a traditional i2c controller and/or gpios, but you
would not be able to perform the i3c standard secondary master
transition with the latter two because they are (by definition) not
i3c compatible.

i2c-demux-pinctrl should probably not be used as template for something
else, but it is a good argument for some other design IMHO...

Cheers,
Peter