On 03/15/2016 04:09 PM, Peter Rosin wrote:
The series will be posted again for review. This is just a heads up.
v5 compared to v4:
- Rebase on top of v4.5-rc7.
- A new patch making me maintainer of i2c muxes (also sent separately).
- A new file Documentation/i2c/i2c-topology that describes vari
Hi!
On 2016-03-03 23:27, Peter Rosin wrote:
> From: Peter Rosin
>
> Hi!
>
> I have a pair of boards with this i2c topology:
>
>GPIO ---| -- BAT1
> | v /
>I2C -+--B---+ MUX
> | \
>
I wrote:
> I wrote:
>> Concerns:
>> - The locking is perhaps too complex?
>
> Ok, to highlight the benefits of this series, I expect that patches such as
> [1] and the one inlined below can follow up to clean up ad-hoc i2c locking
> in drivers. Putting this locking in one place instead of having i
I wrote:
> Concerns:
> - The locking is perhaps too complex?
Ok, to highlight the benefits of this series, I expect that patches such as
[1] and the one inlined below can follow up to clean up ad-hoc i2c locking
in drivers. Putting this locking in one place instead of having it spread
out in rando
From: Peter Rosin
Hi!
I have a pair of boards with this i2c topology:
GPIO ---| -- BAT1
| v /
I2C -+--B---+ MUX
| \
EEPROM -- BAT2
(B denotes the bound
5 matches
Mail list logo
