linux-kernel - Re: [PATCH v2 00/34] component: Make into an aggregate bus

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:   Thu, 7 Oct 2021 16:46:22 -0400
From:   Stephen Boyd <swboyd@...omium.org>
To:     Andrzej Hajda <andrzej.hajda@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
        Arnd Bergmann <arnd@...db.de>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Christian Gmeiner <christian.gmeiner@...il.com>,
        Chun-Kuang Hu <chunkuang.hu@...nel.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Emma Anholt <emma@...olt.net>,
        Heiko Stübner <heiko@...ech.de>,
        Inki Dae <inki.dae@...sung.com>,
        James Qian Wang <james.qian.wang@....com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Joerg Roedel <joro@...tes.org>,
        John Stultz <john.stultz@...aro.org>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Jyri Sarha <jyri.sarha@....fi>,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        linux-fbdev@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-pm@...r.kernel.org, Liviu Dudau <liviu.dudau@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Mark Brown <broonie@...nel.org>,
        Maxime Ripard <mripard@...nel.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Rob Clark <robdclark@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Russell King <linux+etnaviv@...linux.org.uk>,
        Russell King <rmk+kernel@....linux.org.uk>,
        Sandy Huang <hjc@...k-chips.com>,
        Saravana Kannan <saravanak@...gle.com>,
        Sebastian Reichel <sre@...nel.org>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        Takashi Iwai <tiwai@...e.com>,
        Tian Tao <tiantao6@...ilicon.com>,
        Tomas Winkler <tomas.winkler@...el.com>,
        Tomi Valkeinen <tomba@...nel.org>,
        Will Deacon <will@...nel.org>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Yong Wu <yong.wu@...iatek.com>
Subject: Re: [PATCH v2 00/34] component: Make into an aggregate bus

Quoting Andrzej Hajda (2021-10-07 03:16:27)
> Hi Stephen,
>
> On 06.10.2021 21:37, Stephen Boyd wrote:
> > This series is from discussion we had on reordering the device lists for
> > drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
> > the aggregate device onto and then we probe the aggregate device once
> > all the components are probed and call component_add(). The probe/remove
> > hooks are where the bind/unbind calls go, and then a shutdown hook is
> > added that can be used to shutdown the drm display pipeline at the right
> > time.
> >
> > This works for me on my sc7180 board. I no longer get a warning from i2c
> > at shutdown that we're trying to make an i2c transaction after the i2c
> > bus has been shutdown. There's more work to do on the msm drm driver to
> > extract component device resources like clks, regulators, etc. out of
> > the component bind function into the driver probe but I wanted to move
> > everything over now in other component drivers before tackling that
> > problem.
>
>
> As I understand you have DSI host with i2c-controlled DSI bridge. And
> there is an issue that bridge is shutdown before msmdrm. Your solution
> is to 'adjust' device order on pm list.
> I had similar issue and solved it locally by adding notification from
> DSI bridge to DSI host that is has to be removed: mipi_dsi_detach, this
> notification escalates in DSI host to component_del and this allow to
> react properly.
>
> Advantages:
> - it is local (only involves DSI host and DSI device),
> - it does not depend on PM internals,
> - it can be used in other scenarios as well - unbinding DSI device driver
>
> Disadvantage:
> - It is DSI specific (but this is your case), I have advertised some
> time ago more general approach [1][2].
>
> [1]: https://static.sched.com/hosted_files/osseu18/0f/deferred_problem.pdf
> [2]: https://lwn.net/Articles/625454/
>

I think these are all points for or against using the component code in
general? Maybe you can send patches that you think can solve the problem
I'm experiencing and we can review them on the list.