* Maciej Purski [180307 14:38]:
>
> On 03/07/2018 03:10 PM, Mark Brown wrote:
> > On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> >
> > > I'm trying to figure out what is so special about these boards. The only
> > > strange thing, that I haven't noticed at first, is that all re
On Tue, Mar 06, 2018 at 07:10:01PM -0300, Fabio Estevam wrote:
> Yesterday I spent a few hours trying to understand this locking issue,
> but didn't get any success on this task.
Right, so I'm thinking that if it's taking this much effort to think
about the problem we should just drop the patch s
On 03/07/2018 03:10 PM, Mark Brown wrote:
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
I'm trying to figure out what is so special about these boards. The only
strange thing, that I haven't noticed at first, is that all regulators share
a common supply - dummy regulator. It i
On Wed, Mar 07, 2018 at 01:57:12PM +0100, Maciej Purski wrote:
> I'm trying to figure out what is so special about these boards. The only
> strange thing, that I haven't noticed at first, is that all regulators share
> a common supply - dummy regulator. It is defined in anatop_regulator.c.
No, th
Hi all,
sorry it took me so long to answer.
On 03/06/2018 05:30 PM, Mark Brown wrote:
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
Looks like with next-20180305 there's a regulator regression
where mmc0 won't show any ca
On Tue, Mar 6, 2018 at 6:33 PM, Mark Brown wrote:
> No, unfortunately, apart from the generic kernel ones (like lockdep).
> I'll try to have a poke at adding some tomorrow, though I'm also
> considering just dropping the series for now.
Ok, lockdep is already enabled by default in the defconfig
On Tue, Mar 06, 2018 at 05:06:48PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> > Yeah, that's what I expected. What we really need to figure out I think
> > is what exactly is taking the lock that we end up colliding with, I
> > don't seem to be able to repr
Hi Mark,
On Tue, Mar 6, 2018 at 4:12 PM, Mark Brown wrote:
> Yeah, that's what I expected. What we really need to figure out I think
> is what exactly is taking the lock that we end up colliding with, I
> don't seem to be able to reproduce so I'm having to just go on staring
> at the code here.
On Tue, Mar 06, 2018 at 01:56:42PM -0300, Fabio Estevam wrote:
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> > - for (i = 0; rdev; rdev = rdev_get_supply(rdev), i++)
> > + for (i = 1000; rdev; rdev = rdev_get_supply(rdev), i++)
> > mutex_lock_nested(&rdev->mute
* Fabio Estevam [180306 16:57]:
> Hi Mark,
>
> On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
>
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index e685f8b94acf..2c5b20a97f51 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -159,7
Hi Mark,
On Tue, Mar 6, 2018 at 1:30 PM, Mark Brown wrote:
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index e685f8b94acf..2c5b20a97f51 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -159,7 +159,7 @@ static void regulator_lock_supply(struct
On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote:
> On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> > Looks like with next-20180305 there's a regulator regression
> > where mmc0 won't show any cards or produces errors:
> > mmcblk0: error -110 requesting status
> > mmc1: new h
Hi Tony,
On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote:
> Hi Mark and Maciej,
>
> Looks like with next-20180305 there's a regulator regression
> where mmc0 won't show any cards or produces errors:
>
> mmcblk0: error -110 requesting status
> mmc1: new high speed SDIO card at address 0001
> m
13 matches
Mail list logo
