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]

Message-ID: <20231007054541.GL34982@atomide.com>
Date:   Sat, 7 Oct 2023 08:45:41 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Johan Hovold <johan@...nel.org>
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

* Johan Hovold <johan@...nel.org> [231006 15:37]:
> On Fri, Oct 06, 2023 at 11:37:12AM +0300, Tony Lindgren wrote:
> > OK so let's just use:
> > 
> > The serdev controller runtime PM state is not currently propagated
> > to the serial core controller port device. The runtime PM usage count
> > only propagates to the parent device.
> 
> That sounds better.

OK

> > > I'm still not sure why it was implemented this way, or if it is even
> > > correct, but this seems to be the state of things.
> > 
> > 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 :)

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.

> 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?

In the long run serial port specific functions could live there too.

> There are just a lot of questions and I worry that there are more
> problems lurking, but unfortunately I still don't have time to review
> this.

Well incremental steps should be easier to do now.

Regards,

Tony