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
