Re: i2c: slave support framework improvements

[Kachalov Anton <mouse@mayc.ru>]

Hello,

just want to remind my usage scenario where I have control board connected via i2c-mux switch to a number of Node. Control board and Nodes implements IPMB proto: each device acts as Slave (receive requests) and Master (send answers). Logically, there is one Master and many Slaves. Only Control board may switch i2c channel and talk to Nodes. CB's slave is constant (usually 0x20). To achieve this in our setup we instantiate a number of i2c-clients (dummy) and slaves with the same address. E.g. 0x11 for client write (Node) and 0x20 for slave read (ourselves, to receive answers from nodes).

Therefore, we should treat i2c-switch as one-way gate with multi-master.

Thanks.

16.08.2016, 16:33, "Peter Rosin" <peda@axentia.se>:
> On 2016-08-16 14:12, Wolfram Sang wrote:
>>  Hi Peter,
>>
>>>  If you really have a separate device on the bus with the same address
>>>  that you want to add slave support for, then there really is a conflict,
>>>  and the kernel knows it.
>>
>>  We still have a disagreement about "the kernel knows it". The kernel
>>  knows it only in one case, i.e. when you are able to describe all
>>  devices on the bus.
>>
>>  What about this compromise: We keep the current scheme, but print a
>>  warning when the kernel notices a slave device has the same address
>>  which is already claimed by a client driver. This will let most users
>>  know about the conflict but it will not hurt the debugging-via-loopback
>>  case, since people know what they are doing and will happily ignore it.
>>
>>  If you can agree to that, I'll cook up a patch later this week.
>
> Hmm, maybe add a "slave loopback quirk" to adapters that allows this,
> and forbid it if the quirk isn't present?
>
> (or use whatever flag is appropriate, if quirks do not fit)
>
> And/or require some kind of loopback flag when adding a client driver
> that is supported via loopback to a slave driver.
>
> Note, I do not feel strongly about this at all, I'm mainly trying to
> understand what's going on. Now I do understand, and do not desperately
> seek changes. It just looked fishy, that's all...
>
> Cheers,
> Peter