On Apr 1 10:58, Damien Hedde wrote: > > On 4/1/22 08:29, Klaus Jensen wrote: > > On Mar 31 15:32, Corey Minyard wrote: > > > On Thu, Mar 31, 2022 at 06:57:33PM +0200, Klaus Jensen wrote: > > > > From: Klaus Jensen <k.jen...@samsung.com> > > > > > > > > Hi all, > > > > > > > > This RFC series adds I2C "slave mode" support for the Aspeed I2C > > > > controller as well as the necessary infrastructure in the i2c core to > > > > support this. > > > > > > I've been wondering when this would happen :). I had put some thought > > > into how this would work, but hadn't come up with anything good. > > > > > > The big disadvantage of this is you are adding an interface that is > > > incompatible with the current masters and slaves. So you are using the > > > same I2C bus, but slaves written this way cannot talk to existing > > > masters, and masters written this way cannot talk to existing slave. > > > You could adapt the masters to be able to work either way, and I suppose > > > some slaves that could do it could have both an async send and a normal > > > send. > > > > Would it make sense to introduce a QOM Interface to differentiate > > between the slave/master types? > > > > Probably. > > I expect a normal slave-only I2C device will be compatible with any master > (having or having not this feature) in real life ? >
Yeah, it's just that currently in the i2c core we cannot "suspend" the sending of the ACK. > It would be great if the compatibility between "a I2C slave requiring the > slave-mode from the bus" and the bus could be checked during the device > plug. > Makes sense, I'll see what I can come up with for a v2 :) Thanks!
signature.asc
Description: PGP signature
