Hey guys,
I stumbled over this one again and want to make sure we have a
conclusion here.
> The way I understand it, the problem this intends to fix is not the
> state the device ends up in, but that it needs to be powered while
> registers are read or written.
I agree.
> It seems to me that th
Sorry for the delay...
> On April 13, 2018 at 7:27 PM Geert Uytterhoeven wrote:
>
> On Fri, Apr 13, 2018 at 7:00 PM, Ulrich Hecht
> wrote:
> > These patches make sure that the device is up while the suspend/resume code
> > is executed. Up-port from the BSP, tested not to break stuff.
> >
> > Hi
On Fri, Apr 13, 2018 at 07:27:59PM +0200, Geert Uytterhoeven wrote:
> Hi Ulrich,
>
> On Fri, Apr 13, 2018 at 7:00 PM, Ulrich Hecht
> wrote:
> > These patches make sure that the device is up while the suspend/resume code
> > is executed. Up-port from the BSP, tested not to break stuff.
> >
> > Hie
> > These patches make sure that the device is up while the suspend/resume code
> > is executed. Up-port from the BSP, tested not to break stuff.
> >
> > Hien Dang (2):
> > serial: sh-sci: Use pm_runtime_get_sync()/put() on suspend
> > serial: sh-sci: Use pm_runtime_get_sync()/put() on resume
Hi Ulrich,
On Fri, Apr 13, 2018 at 7:00 PM, Ulrich Hecht
wrote:
> These patches make sure that the device is up while the suspend/resume code
> is executed. Up-port from the BSP, tested not to break stuff.
>
> Hien Dang (2):
> serial: sh-sci: Use pm_runtime_get_sync()/put() on suspend
> seria
