linux-kernel - Re: [PATCH] serial: core: Fix checks for tx runtime PM state

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]

Date:   Mon, 16 Oct 2023 17:18:25 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>, Dhruva Gole <d-gole@...com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        John Ogness <john.ogness@...utronix.de>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        Maximilian Luz <luzmaximilian@...il.com>
Subject: Re: [PATCH] serial: core: Fix checks for tx runtime PM state

On Sat, Oct 07, 2023 at 08:45:41AM +0300, Tony Lindgren wrote:
> * Johan Hovold <johan@...nel.org> [231006 15:37]:
> > On Fri, Oct 06, 2023 at 11:37:12AM +0300, Tony Lindgren wrote:

> > > Care to clarify a bit which parts are unclear? The hierarchy of port
> > > devices, making serial core manage runtime PM in a generic way, or
> > > flushing tx?
> > 
> > I still don't know why you added these two new abstractions (controller
> > and port), and that isn't really explained by the commit message either.
> 
> We want serial core to do runtime PM in a generic way and have the usage
> count propagate to the parent serial port hardware device. This way we
> don't need to care much if the numerous serial port drivers implement
> runtime PM or not. Well, except for now we need to check the parent state
> for this fix :)

That sounds like a lot of complexity to avoid checking if (the single
instance of) pm_runtime_get() returns -EACCESS.
 
> We also want serial core to know the serial port to serial port hardware
> mapping as we already have multiport devices. The serial core controller
> is there to group the serial ports for each serial port hardware device.
> We at least now have an option to support devices with multiple controllers
> and ports in case we ever happen to see such things.

Hypothetical multiple serial controllers should be modelled as separate
controllers, but yeah, perhaps we want to describe the ports.
 
> > And if these are indeed needed, then why isn't the serdev controller now
> > a child of the "port" device, for example?
> 
> Yes I agree we should now move serdev controller to be a child of the
> serial core port device. Then this $subject patch can be reverted.
> 
> Moving serdev controller should also help serdev to deal with multiport
> devices I think?

It wouldn't help currently I think, since we already resume the
controller and don't manage ports individually, but if we now have port
devices then it probably should be moved.

Johan