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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 13 May 2021 14:40:16 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Rob Clark <robdclark@...il.com>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] component: Move host device to end of device lists on
 binding

On Mon, May 10, 2021 at 06:05:21PM +0200, Daniel Vetter wrote:
> Entirely aside, but an s/master/aggregate/ or similar over the entire
> component.c codebase would help a pile in making it easier to understand
> which part does what. Or at least I'm always terribly confused about which
> bind binds what and all that, so maybe an additional review whether we
> have a clear split into aggregate and individual components after that
> initial fix is needed.

I'm not entirely sure what you mean "which bind binds what".

The component helper solves this problem:

We have a master or aggregate device representing a collection of
individual devices. The aggregate and individual devices may be probed
by the device model in any order. The aggregate device is only complete
once all individual and aggregate devices have been successfully probed.

It does this by tracking which devices are present, and only when they
are all present does it call the bind() operation. Conversely, if one
happens to be removed, it calls the unbind() operation. To me, that's
very simple.

When we start talking about PM, the original idea was for the aggregate
device to handle that. However, DRM/OF has pushed to change the model a
bit such that the aggregate device is created as a platform device when
we detect the presence of one of the individual devices.

I suspect what we actually want is something that, when the first
individual device gets notified of a transition to a lower power mode,
we want to place the system formed by all the devices into a low power
mode. Please realise that it may not be appropriate for every
individual device to be affected by that transition until it receives
its own PM call.

> One question I have: Why is the bridge component driver not correctly
> ordered wrt the i2c driver it needs? The idea is that the aggregate driver
> doesn't access any hw itself, but entirely relies on all its components.

As far as I'm aware, bridge was never converted to use any component
stuff, so I'm not sure what you're referring to.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!