Hi Tom,
On gio, 2018-07-26 at 20:29 -0400, Tom Rini wrote:
> On Thu, Jul 26, 2018 at 10:16:01PM +0200, Goldschmidt Simon wrote:
>
> >
> > + Tom:
> >
> > I don't know via which tree this would go in. I think you took the
> > last env
> > changes directly?
> >
> > v1..v4 are detached threads, I
On Thu, Jul 26, 2018 at 10:16:01PM +0200, Goldschmidt Simon wrote:
> + Tom:
>
> I don't know via which tree this would go in. I think you took the last env
> changes directly?
>
> v1..v4 are detached threads, I can send you links if you need them.
It's on my TODO list to pick up, thanks!
--
T
+ Tom:
I don't know via which tree this would go in. I think you took the last
env changes directly?
v1..v4 are detached threads, I can send you links if you need them.
Thanks,
Simon
On 26.07.2018 16:02, Maxime Ripard wrote:
On Thu, Jul 26, 2018 at 07:16:36AM +0200, Simon Goldschmidt wro
On Thu, Jul 26, 2018 at 07:16:36AM +0200, Simon Goldschmidt wrote:
> Simon, Maxime,
>
> any input on this? Via which tree would this be pushed? Should we CC Tom?
>
> It would be nice if 2018.09 had this bug fixed (endless loop in env_save()
> on error).
This looks good to me but Tom will probabl
Simon, Maxime,
any input on this? Via which tree would this be pushed? Should we CC Tom?
It would be nice if 2018.09 had this bug fixed (endless loop in
env_save() on error).
Thanks,
Simon
On 23.07.2018 10:01, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only ret
When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when
the low-level drv->save() call fails.
The env_save() function sh
6 matches
Mail list logo
