Re: [PATCH v6 00/24] i2c mux cleanup and locking update

> can obviously take forever. At the same time, many of the patches are kind > of mechanical, and feels rather safe. I agree about the mechanical stuff, thus my suggestion. We do what we can about testing and reviewing. And once it reaches linux-next (hopefully next week latest), test coverage

Re: [PATCH v6 00/24] i2c mux cleanup and locking update

Hi! On 2016-04-11 14:39, Wolfram Sang wrote: Hi Peter, To summarize the series, there's some i2c-mux infrastructure cleanup work first (I think that part stands by itself as desireable regardless), the locking changes are in 16/24 and after with the real meat in 18/24. There is some

Re: [PATCH v6 00/24] i2c mux cleanup and locking update

Hi Peter, > To summarize the series, there's some i2c-mux infrastructure cleanup work > first (I think that part stands by itself as desireable regardless), the > locking changes are in 16/24 and after with the real meat in 18/24. There > is some documentation added in 19/24 while 20/24 and after

[PATCH v6 00/24] i2c mux cleanup and locking update

From: Peter Rosin Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B