On Tue, Jan 20, 2015 at 12:14:31PM +0100, Paul Osmialowski wrote:
> On Mon, 19 Jan 2015, Mark Brown wrote:
> >OK, so that's what should go in the changelog (along with an explanation
> >of why this preparation is required at all) - but I still don't see the
> >async bit of this I'm afraid.
> I
On Tue, Jan 20, 2015 at 12:14:31PM +0100, Paul Osmialowski wrote:
On Mon, 19 Jan 2015, Mark Brown wrote:
OK, so that's what should go in the changelog (along with an explanation
of why this preparation is required at all) - but I still don't see the
async bit of this I'm afraid.
I don't
On Mon, 19 Jan 2015, Mark Brown wrote:
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
What I'm saying is that I want to understand this change from a point of
view that isn't tied to I2C - at the regmap level what is this doing,
On Mon, 19 Jan 2015, Mark Brown wrote:
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
What I'm saying is that I want to understand this change from a point of
view that isn't tied to I2C - at the regmap level what is this doing,
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote:
> On Fri, 16 Jan 2015, Mark Brown wrote:
> >What I'm saying is that I want to understand this change from a point of
> >view that isn't tied to I2C - at the regmap level what is this doing,
> From the regmap point of view, it
On Fri, 16 Jan 2015, Mark Brown wrote:
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
I don't know what this means, sorry. I'm also very worried about the
fact that this is being discussed purely in terms of I2C - why would
this
On Fri, 16 Jan 2015, Mark Brown wrote:
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
I don't know what this means, sorry. I'm also very worried about the
fact that this is being discussed purely in terms of I2C - why would
this
On Mon, Jan 19, 2015 at 10:31:22AM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
What I'm saying is that I want to understand this change from a point of
view that isn't tied to I2C - at the regmap level what is this doing,
From the regmap point of view, it allows its
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
> On Fri, 16 Jan 2015, Mark Brown wrote:
> >I don't know what this means, sorry. I'm also very worried about the
> >fact that this is being discussed purely in terms of I2C - why would
> >this not affect other buses?
> I tried to
On Fri, 16 Jan 2015, Mark Brown wrote:
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
> This uses the enhancement of i2c API in order to address following problem
> caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
explanations, explain in words what the problem
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
-> #1 (prepare_lock){+.+.+.}:
[2.730502][] __lock_acquire+0x3c0/0x8a4
[2.735970][] lock_acquire+0x6c/0x8c
[2.741090][] mutex_lock_nested+0x68/0x464
[
On Fri, 16 Jan 2015, Mark Brown wrote:
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
On Fri, 16 Jan 2015, Mark Brown wrote:
I don't know what this means, sorry. I'm also very worried about the
fact that this is being discussed purely in terms of I2C - why would
this not affect other buses?
I tried to open
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
- #1 (prepare_lock){+.+.+.}:
[2.730502][c0061e50] __lock_acquire+0x3c0/0x8a4
[2.735970][c0062868] lock_acquire+0x6c/0x8c
[2.741090][c04a2724]
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
explanations, explain in words what the problem
16 matches
Mail list logo
