On Thu, Jul 12, 2018 at 6:41 AM, Peter Rosin <peda@xxxxxxxxxx> wrote: > On 2018-07-11 19:12, Boris Brezillon wrote: >> On Wed, 11 Jul 2018 17:39:56 +0200 Arnd Bergmann <arnd@xxxxxxxx> 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? 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. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html