linux-kernel - Re: [PATCH 2/4] serial: 8250: Implement wakeup for TX and use it for 8250

lists.openwall.net		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]

Message-ID: <YVVnYfEOw/78ZyI8@atomide.com>
Date:   Thu, 30 Sep 2021 10:29:37 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Johan Hovold <johan@...nel.org>,
        Vignesh Raghavendra <vigneshr@...com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] serial: 8250: Implement wakeup for TX and use it for
 8250_omap

* Andy Shevchenko <andy.shevchenko@...il.com> [210930 07:18]:
> On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren <tony@...mide.com> 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
uart_start_pending_tx().

Regards,

Tony