> My offer is going to be this, I'll look after any unforeseen future problems
> caused by this rework, and I can be the i2c-mux maintainer. But if being
Yay, thanks a lot!
> the i2c-mux maintainer turns out to be a huge time-sink, there is no way I
> can stay on in the long run. But I guess tha
On 2016-03-05 19:29, Wolfram Sang wrote:
>
>> Perhaps it's one to let sit into at least the next cycle (and get some
>> testing
>> on those media devices if we can) but, whilst it is fiddly the gains seen in
>> individual drivers (like the example Peter put in response to the V4 series)
>> make i
> Perhaps it's one to let sit into at least the next cycle (and get some testing
> on those media devices if we can) but, whilst it is fiddly the gains seen in
> individual drivers (like the example Peter put in response to the V4 series)
> make it look worthwhile to me. Also, whilst the invensen
On 02/03/16 17:29, Wolfram Sang wrote:
> On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote:
>> From: Peter Rosin
>>
>> Hi!
>>
>> [doing a v3 even if there is no "big picture" feedback yet, but
>> previous versions has bugs that make them harder to test than
>> needed, and testing is ve
Wolfram Sang wrote:
> On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote:
> >
> > Hi!
> >
> > [doing a v3 even if there is no "big picture" feedback yet, but
> > previous versions has bugs that make them harder to test than
> > needed, and testing is very much desired]
> >
> > I have
On Fri, Jan 08, 2016 at 04:04:48PM +0100, Peter Rosin wrote:
> From: Peter Rosin
>
> Hi!
>
> [doing a v3 even if there is no "big picture" feedback yet, but
> previous versions has bugs that make them harder to test than
> needed, and testing is very much desired]
>
> I have a pair of boards