Re: [PATCH v3] i2c: Add support for NXP PCA984x family.

[Adrian Fiergolski <Adrian.Fiergolski@cern.ch>]

On 13.12.2017 at 10:39, Peter Rosin wrote:
> On 2017-12-13 09:47, Adrian Fiergolski wrote:
>> On 12.12.2017 at 20:03, Peter Rosin wrote:
>>> [Adding Wolfram]
>>>
>>> On 2017-12-12 18:14, Adrian Fiergolski wrote:
>>>> On 12.12.2017 at 16:25, Peter Rosin wrote:
>>>>> On 2017-12-12 13:06, Adrian Fiergolski wrote:
>>>>>> In a normal run scenario, I don't need it. I can imagine it may be a
>>>>>> problem, if the module
>>>>>> is suddenly unloaded and loaded: the mux remains set to some not default
>>>>>> bus and
>>>>>> the module is not aware of it. However, I agree then the bus could be
>>>>>> reset somewhere
>>>>>> at higher level.
>>>>> Think about what happens if you have more than one chip on some i2c bus
>>>>> that uses this reset mechanism. First you instantiate one of the drivers
>>>>> and both chips are reset. Then you carry on with careful configuration
>>>>> of that first chip. Then you instantiate the driver for the other chip
>>>>> and all you careful configuration of the first chip is lost as it is
>>>>> reset a second time. So, you just can't reset everything on the bus in
>>>>> any random driver, that has to be done on some other level.
>>>> That's all true. However, we are discussing an I2C mux/switch which is a
>>>> root
>>>> of an I2C sub-tree. It is initialized first, so the SOFTWARE_RESET command
>>>> would reset only mux/switch and all its nodes. The command would be followed
>>>> by the configuration of all its nodes, which anyway can't be performed
>>>> earlier.
>>> Have a look at Documentation/i2c/i2c-topology and think again.
>> And... ?
> If you have a topology like this (use a fixed-width font):
>
>           .-- deviceA
>           |
> i2c-root--+          deviceB
>           |         /
>           '--pca984x
>                     \
>                      deviceC
>
> and linux for some reason starts with instantiating the driver for deviceA,
> and after that instantiates the pca984x driver, then you obviously have a
> problem if deviceA reacts to a general call to reset done by the probe in
> the pca984x driver.
>
> Or if you have this:
>
>                             deviceA
>                            /
>                     pca984x
>                    /       \
> i2c-root----pca984x         deviceB
>                    \
>                     deviceC
>
> then the driver for the first level pca984x device is instantiated first,
> but the general call to reset when the second level pca984x device is
> instantiated will trash the already configured first level pca984x
> device.
>
You are right. I checked addressing in this RESET call again. For some
reasons,
I was sure that this GENERAL_CALL is performed on the I2C buses mastered by
the pca984x device. Of course, this call is performed on its slave
interface. It
couldn't be different.

Thanks,
Adrian