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: <YU3kPHg2qLr//HEF@hovoldconsulting.com>
Date:   Fri, 24 Sep 2021 16:44:12 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-serial@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] serial: 8250: Implement prep_tx for power management

On Thu, Sep 23, 2021 at 06:05:36PM +0300, Tony Lindgren wrote:
> * Johan Hovold <johan@...nel.org> [210923 12:50]:
> > On Tue, Sep 21, 2021 at 01:33:44PM +0300, Tony Lindgren wrote:
> > > +static int serial8250_prep_tx(struct uart_port *port)
> > > +{
> > > +	struct uart_8250_port *up = up_to_u8250p(port);
> > > +	struct device *dev = up->port.dev;
> > > +	int err;
> > > +
> > > +	if (!(up->capabilities & UART_CAP_RPM))
> > > +		return 0;
> > > +
> > > +	if (!pm_runtime_suspended(dev)) {
> > > +		pm_runtime_mark_last_busy(dev);
> > > +		return 0;
> > > +	}
> > > +
> > > +	err = pm_request_resume(dev);
> > > +	if (err < 0) {
> > > +		dev_warn(dev, "prep_tx wakeup failed: %d\n", err);
> > > +		return err;
> > > +	}
> > 
> > How is this supposed to work without a runtime PM usage-counter
> > increment? What's to prevent the port from suspending again while it's
> > transmitting?
> 
> Hmm yeah we should at pm_runtime_get() and pm_runtime_put() to write()
> unless serial8250_rpm_get() and serial8250_rpm_put() are doing it.

If you do the put after just buffering the data it doesn't really solve
anything.

> Or pair prep with finish and deal with the usage count there.

Problem is where to call it from. How do you tell the device is done
transmitting? And how should we deal with flow control? Etc.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ