linux-kernel - Re: [PATCH] component: Move host device to end of device lists on binding

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: <CAE-0n50WBz6rpbuxw-2=XNi=1fmaf=mYrcWdV88E-0KioKHZDg@mail.gmail.com>
Date:   Tue, 11 May 2021 10:00:43 -0700
From:   Stephen Boyd <swboyd@...omium.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Russell King <rmk+kernel@....linux.org.uk>,
        Rob Clark <robdclark@...il.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] component: Move host device to end of device lists on binding

Quoting Rafael J. Wysocki (2021-05-11 03:52:06)
> On Mon, May 10, 2021 at 9:08 PM Stephen Boyd <swboyd@...omium.org> wrote:
>
> [cut]
>
> >
> > >
> > > > I will try it, but then I wonder about things like system wide
> > > > suspend/resume too. The drm encoder chain would need to reimplement the
> > > > logic for system wide suspend/resume so that any PM ops attached to the
> > > > msm device run in the correct order. Right now the bridge PM ops will
> > > > run, the i2c bus PM ops will run, and then the msm PM ops will run.
> > > > After this change, the msm PM ops will run, the bridge PM ops will run,
> > > > and then the i2c bus PM ops will run. It feels like that could be a
> > > > problem if we're suspending the DSI encoder while the bridge is still
> > > > active.
> > >
> > > Yup suspend/resume has the exact same problem as shutdown.
> >
> > I think suspend/resume has the exact opposite problem. At least I think
> > the correct order is to suspend the bridge, then the encoder, i.e. DSI,
> > like is happening today. It looks like drm_atomic_helper_shutdown()
> > operates from the top down when we want bottom up? I admit I have no
> > idea what is supposed to happen here.
>
> Why would the system-wide suspend ordering be different from the
> shutdown ordering?

I don't really know. I'm mostly noting that today the order of suspend
is to suspend the bridge device first and then the aggregate device. If
the suspend of the aggregate device is traversing the devices like
drm_atomic_helper_shutdown() then it would operate on the bridge device
after it has been suspended, like is happening during shutdown. But it
looks like that isn't happening. At least for the msm driver we're
suspending the aggregate device after the bridge, and there are some
weird usages of prepare and complete in there (see msm_pm_prepare() and
msm_pm_complete) which makes me think that it's all working around this
component code.

The prepare phase is going to suspend the display pipeline, and then the
bridge device will run its suspend hooks, and then the aggregate driver
will run its suspend hooks. If we had a proper device for the aggregate
device instead of the bind/unbind component hooks we could clean this
up.