linux-kernel - Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

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: <ed9879ef42a70d2609f60f73834cabb7e3df9e2f.camel@linux.intel.com>
Date:   Wed, 16 May 2018 16:10:15 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH v1 0/3] console, serial8250: Disable PM and DMA ops

On Wed, 2018-05-16 at 12:47 +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-16 13:17:36 [+0300], Andy Shevchenko wrote:
> > > The output is usually short so there
> > > shouldn't be much benefit from using it.
> > > I remember Tony wanted runtime-pm on the kernel console, too. And
> > > he
> > > told me explicit how to test it so that it works. Once the UART
> > > goes
> > > into PM (down), the whole IP block can go into power save mode.
> > > The
> > > board can be woken up by sending a character via the UART. The
> > > first few
> > > (incoming / read) characters are lost until the IP block is up
> > > again the
> > > frequency stable. This is known / expected.
> > 
> > Don't consider world the OMAP only. The things more complicated if
> > we
> > go out of it. Which I tried to explain in the commit message of
> > patch
> > 2.
> 
> I am not saying the world is OMAP only. I just tried to explain how
> any
> why it got there and its purpose. I haven't NACKed it. I would believe
> that with that information and Tony not defending his use case or
> possible change it somehow so it is not standing in your way, Greg
> would
> have enough information to go your way.

Yes, I got it.

> But since I am on it. You have to enable runtime-PM for the UART. So
> what is the problem if you simply don't enable it for the UART which
> used as the kernel console?

How do I know at the ->probe() time that device in question is going to
be kernel console? Maybe I missed simple way of it.

> From reading the description of #2, my understanding is that you are
> afraid that enabling the UART (bringing it from power-down mode) might
> take too long because it requires (or might require) an ACPI function
> call. This brings me again to: why bother and enable it in the first
> place? Because this might not work from NMI context.

> From looking at #2. You remove put/get in console_write()

...which must be removed in any case...

>  and avoid
> runtime PM by pm_runtime_get_noresume() and need the extra hook on
> console exit. I wasn't aware that you can remove the console at
> runtime
> (and assumed you have to stick to what said in console= at bootime).

> Because if that is the case, you could simply strip UART_CAP_RPM and
> then there is no more runtime-PM for you. Or is it too simple and I
> miss something here?

See above question. IIRC it's either too early or too late to decide on
per port basis.

> 
> > > In order to achieve the same thing you would have to disable the
> > > kernel
> > > console on that UART. I leave this to Tony.
> > 
> > Precisely the point of the series.

Besides above this would be needed _at least_ for several 8250 glue
drivers, so, I decide to go once for all.

> 
> Sebastian

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy