| 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
| ||
|
Message-ID: <20250522-amphibian-shiny-chachalaca-cf05ba@houat>
Date: Thu, 22 May 2025 16:57:30 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>, Jagan Teki <jagan@...rulasolutions.com>,
Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
Douglas Anderson <dianders@...omium.org>, Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Krzysztof Kozlowski <krzk@...nel.org>, Liu Ying <victor.liu@....com>,
Anusha Srivatsa <asrivats@...hat.com>, Paul Kocialkowski <paulk@...-base.io>,
Dmitry Baryshkov <lumag@...nel.org>, Hui Pu <Hui.Pu@...ealthcare.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>, dri-devel@...ts.freedesktop.org, asahi@...ts.linux.dev,
linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
linux-amlogic@...ts.infradead.org, linux-renesas-soc@...r.kernel.org,
platform-driver-x86@...r.kernel.org, linux-samsung-soc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
freedreno@...ts.freedesktop.org, linux-stm32@...md-mailman.stormreply.com,
Louis Chauvet <louis.chauvet@...tlin.com>, Alim Akhtar <alim.akhtar@...sung.com>,
Inki Dae <inki.dae@...sung.com>, Kyungmin Park <kyungmin.park@...sung.com>,
Seung-Woo Kim <sw0312.kim@...sung.com>, Manikandan Muralidharan <manikandan.m@...rochip.com>,
Adam Ford <aford173@...il.com>, Adrien Grassein <adrien.grassein@...il.com>,
Aleksandr Mishin <amishin@...rgos.ru>, Andy Yan <andy.yan@...k-chips.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Benson Leung <bleung@...omium.org>,
Biju Das <biju.das.jz@...renesas.com>, Christoph Fritz <chf.fritz@...glemail.com>,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>, Detlev Casanova <detlev.casanova@...labora.com>,
Dharma Balasubiramani <dharma.b@...rochip.com>, Guenter Roeck <groeck@...omium.org>,
Heiko Stuebner <heiko@...ech.de>, Jani Nikula <jani.nikula@...el.com>, Janne Grunau <j@...nau.net>,
Jerome Brunet <jbrunet@...libre.com>, Jesse Van Gavere <jesseevg@...il.com>,
Kevin Hilman <khilman@...libre.com>, Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>, Matthias Brugger <matthias.bgg@...il.com>,
Philipp Zabel <p.zabel@...gutronix.de>, Phong LE <ple@...libre.com>,
Sasha Finkelstein <fnkl.kernel@...il.com>, Sugar Zhang <sugar.zhang@...k-chips.com>,
Sui Jingfeng <sui.jingfeng@...ux.dev>, Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>,
Vitalii Mordan <mordan@...ras.ru>, "Rob Herring (Arm)" <robh@...nel.org>,
Hsin-Te Yuan <yuanhsinte@...omium.org>, Pin-yen Lin <treapking@...omium.org>,
Xin Ji <xji@...logixsemi.com>, Aradhya Bhatia <a-bhatia1@...com>,
Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Ian Ray <ian.ray@...ealthcare.com>,
Martyn Welch <martyn.welch@...labora.co.uk>, Peter Senna Tschudin <peter.senna@...il.com>,
Helge Deller <deller@....de>, Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>, Philippe Cornu <philippe.cornu@...s.st.com>,
Raphael Gallais-Pou <raphael.gallais-pou@...s.st.com>, Yannick Fertre <yannick.fertre@...s.st.com>,
Alain Volmat <alain.volmat@...s.st.com>, Raphael Gallais-Pou <rgallaispou@...il.com>,
Michal Simek <michal.simek@....com>, Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 00/22] drm: convert all bridges to
devm_drm_bridge_alloc()
On Wed, May 21, 2025 at 04:22:16PM +0200, Luca Ceresoli wrote:
> Hello Maxime, Shawn, Liu, all,
>
> On Fri, 09 May 2025 15:53:26 +0200
> Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
>
> > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a DRM
> > bridge, and the only one supported from now on. It is the first milestone
> > towards removal of bridges from a still existing DRM pipeline without
> > use-after-free.
>
> I applied on drm-misc-next patches 3-17,20-21 as they match all the
> criteria:
> - At least a Acked-by (or R-by maintainers)
> - patch is for drm-misc
>
> Being my very first commits to drm-misc, I tried to be careful, and
> double checked all the patches with Louis (thanks!).
>
> Here are the pending questions and plan for the remaining patches.
>
> > Revert "drm/exynos: mic: convert to devm_drm_bridge_alloc() API"
>
> This reverts the commit applied my mistake:
> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/91c5c7b5bb2dd09b43b025bce6d790d3c79f4518
>
> Neither the original patch nor the revert has been reviewed/acked.
>
> As the commit was a mistake, I'm applying the revert by the end of this
> week (i.e. on Friday) unless there are better instructions.
Given the lack of answers, and that it looks correct to me, just leave
it there. We can always revert later on if things turned out to be
broken.
> > drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API
>
> This patch affects multiple drivers. Running get_maintainers.pl
> points at Shawn Guo's repository. After reviewing the MAINTAINERS file,
> this looks like due to the 'N:' line in:
>
> ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> M: Shawn Guo <shawnguo@...nel.org>
> M: Sascha Hauer <s.hauer@...gutronix.de>
> R: Pengutronix Kernel Team <kernel@...gutronix.de>
> ...
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
> N: imx
> ...
>
> (https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/MAINTAINERS?ref_type=heads#L2511-2528)
>
> Here 'imx' matches the 'drivers/gpu/drm/bridge/imx/imx-legacy-bridge.c'
> file that is touched by the patch. That regexp appears overly generic to me.
I agree, or at least, we shouldn't wait for Shawn or Sasha...
> Shawn, can it be fixed by making it less generic?
>
> If not, can we at least add a band-aid 'X:' entry for
> drivers/gpu/drm/bridge/imx?
>
> I think the other matching entry is the one to consider:
>
> DRM DRIVERS FOR FREESCALE IMX BRIDGE
> M: Liu Ying <victor.liu@....com>
> L: dri-devel@...ts.freedesktop.org
> S: Maintained
> F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
> F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
> F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
> F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
> F: drivers/gpu/drm/bridge/imx/
>
> (https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/MAINTAINERS?ref_type=heads#L7940-7948)
... As long as Ying is fine with it, because it does look like they are
the actual maintainer.
> However it does not list any trees. I _guess_ drm-misc applies here as
> a fallback as well as common sense.
>
> Liu, should this entry have a 'T:' line for drm/misc?
>
> > drm/bridge: imx8qxp-pixel-combiner: convert to devm_drm_bridge_alloc() API
>
> Not acked/reviewed, some discussion happened. I am resending it in v4,
> possibly with updates based on the discussion.
>
> But it has the same issue discussed above, with get_maintiners.pl
> pointing at Shawn Guo's tree, so in the future I'm assuming this goes
> to drm-misc unless there are news about that.
>
> > drm/bridge: tc358767: convert to devm_drm_bridge_alloc() API
>
> No feedback, resending in v4.
>
> > drm/todo: add entry to remove devm_drm_put_bridge()
>
> This involves documentation maintained on another tree. Where should it
> be applied? There are two matching entries in MAINTAINERS:
>
> * DRM DRIVERS -> the drm tree
> * DRM DRIVERS AND MISC GPU PATCHES -> the drm-misc tree
>
> To me it looks like the second is obviously the closest match as we are
> dealing with DRM bridges, so I'm applying this as well on Friday unless
> there are better instructions.
Yes, they should be applied to drm-misc.
That being said, putting a two days timeout on *any* email is really
over-the-top. I doubt you reply to any of your mail in such a short
timeframe. We have rules for a reason, I'd expect you to follow them, no
matter how frustrating the lack of answers can be.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists