lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Sep 2021 10:29:37 +0300
From:   Tony Lindgren <>
To:     Andy Shevchenko <>
Cc:     Greg Kroah-Hartman <>,
        Andy Shevchenko <>,
        Jiri Slaby <>,
        Johan Hovold <>,
        Vignesh Raghavendra <>,
        "open list:SERIAL DRIVERS" <>,
        Linux OMAP Mailing List <>,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH 2/4] serial: 8250: Implement wakeup for TX and use it for

* Andy Shevchenko <> [210930 07:18]:
> On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren <> wrote:
> >
> > We can use the wakeup() and uart_start_pending_tx() calls to wake up an
> > idle serial port and send out the pending TX buffer on runtime PM resume.
> > This allows us to remove the depedency to pm_runtime_irq_safe() for
> dependency
> > 8250_omap driver in the following patches.
> >
> > We manage the port runtime_suspended flag in the serial port driver as
> > only the driver knows when the hardware is runtime PM suspended. Note that
> > The current flag for rpm_tx_active cannot be used as it is TX specific
> > for 8250_port.
> >
> > We already have serial8250_start_tx() call serial8250_rpm_get_tx(), and
> > serial8250_stop_tx() call serial8250_rpm_put_tx() to take care of the
> > runtime PM usage count for TX. To have the serial port driver call
> > uart_start_pending_tx() on runtime resume, we must now use just
> > pm_runtime_get() for serial8250_start_tx() instead of the sync version.
> >
> > With these changes we must now also flip 8250_omap driver over to call
> > uart_start_pending_tx(). That's currently the only user of UART_CAP_RPM.
> Do I understand the flow correctly:
>  1) if we suspended, we request resume
>  2) until resume is not fulfilled we return error code to user space
> to try again
> ?

Correct. I think the only thing we can currently do is return -EAGAIN
when the serial port registers are not accessible.

> In this case we have no register access to the powered off device and
> ACPI, for example, may have a chance to resume the device in a
> non-atomic way. Is this the correct interpretation?

Yes that's correct. That works as long as the serial port device driver
implements PM runtime resume function, and then at the end of it calls



Powered by blists - more mailing lists