From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Louis Chauvet" <louis.chauvet@bootlin.com>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jonathan Corbet" <corbet@lwn.net>,
"Alexey Brodkin" <abrodkin@synopsys.com>,
"Phong LE" <ple@baylibre.com>, "Liu Ying" <victor.liu@nxp.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"Adrien Grassein" <adrien.grassein@gmail.com>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
"Tomi Valkeinen" <tomi.valkeinen+renesas@ideasonboard.com>,
"Kieran Bingham" <kieran.bingham+renesas@ideasonboard.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Anitha Chrisanthus" <anitha.chrisanthus@intel.com>,
"Edmund Dea" <edmund.j.dea@intel.com>,
"Inki Dae" <inki.dae@samsung.com>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>
Cc: "Hui Pu" <Hui.Pu@gehealthcare.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <imx@lists.linux.dev>,
<linux-arm-kernel@lists.infradead.org>,
<linux-renesas-soc@vger.kernel.org>,
<linux-amlogic@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge
Date: Wed, 19 Nov 2025 16:05:05 +0100 [thread overview]
Message-ID: <DECRIHBXOEXY.WX45FITGF5DA@bootlin.com> (raw)
In-Reply-To: <0858117f-9397-4045-9b7d-490ad24926cb@bootlin.com>
Hi Louis,
On Wed Nov 19, 2025 at 3:33 PM CET, Louis Chauvet wrote:
>
>
> On 11/19/25 13:05, Luca Ceresoli wrote:
>> Several drivers (about 20) follow the same pattern:
>>
>> 1. get a pointer to a bridge (typically the next bridge in the chain) by
>> calling of_drm_find_bridge()
>> 2. store the returned pointer in the private driver data, keep it until
>> driver .remove
>> 3. dereference the pointer at attach time and possibly at other times
>>
>> of_drm_find_bridge() is now deprecated because it does not increment the
>> refcount and should be replaced with drm_of_find_bridge() +
>> drm_bridge_put().
>>
>> However some of those drivers have a complex code flow and adding a
>> drm_bridge_put() call in all the appropriate locations is error-prone,
>> leads to ugly and more complex code, and can lead to errors over time with
>> code flow changes.
>>
>> To handle all those drivers in a straightforward way, add a devm variant of
>> drm_of_find_bridge() that adds a devm action to invoke drm_bridge_put()
>> when the said driver is removed. This allows all those drivers to put the
>> reference automatically and safely with a one line change:
>>
>> - priv->next_bridge = of_drm_find_bridge(remote_np);
>> + priv->next_bridge = devm_drm_of_find_bridge(dev, remote_np);
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>> drivers/gpu/drm/drm_bridge.c | 30 ++++++++++++++++++++++++++++++
>> include/drm/drm_bridge.h | 5 +++++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 09ad825f9cb8..c7baafbe5695 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -1446,6 +1446,36 @@ struct drm_bridge *drm_of_find_bridge(struct device_node *np)
>> }
>> EXPORT_SYMBOL(drm_of_find_bridge);
>>
>> +/**
>> + * devm_drm_of_find_bridge - find the bridge corresponding to the device
>> + * node in the global bridge list and add a devm
>> + * action to put it
>> + *
>> + * @dev: device requesting the bridge
>> + * @np: device node
>> + *
>> + * On success the returned bridge refcount is incremented, and a devm
>> + * action is added to call drm_bridge_put() when @dev is removed. So the
>> + * caller does not have to put the returned bridge explicitly.
>> + *
>> + * RETURNS:
>> + * drm_bridge control struct on success, NULL on failure
>
> I am not sure for the "NULL on failure", you return ERR_PTR(err), which
> is probably not NULL but an error code.
Indeed.
Apologies for the mess in this series: it was adapted from an old one using
a different approach, so I had to adapt lots of details, and missed a few
along the way. :(
About the value to return, maybe it's better to use the same semantics as
drm_of_find_bridge(), i.e. NULL on error. I don't think a caller would have
anything clever to do with an error return value other tan bailing out. And
the only error path for devm_add_action_or_reset() is on a small
allocation, so it basically cannot happen.
>> +struct drm_bridge *devm_drm_of_find_bridge(struct device *dev, struct device_node *np)
>> +{
>> + struct drm_bridge *bridge = drm_of_find_bridge(np);
>> +
>> + if (bridge) {
>> + int err = devm_add_action_or_reset(dev, drm_bridge_put_void, bridge);
>> +
>> + if (err)
>> + return ERR_PTR(err);
>> + }
So this would become:
if (bridge) {
if (devm_add_action_or_reset(dev, drm_bridge_put_void, bridge))
return NULL;
}
>> +
>> + return bridge;
>> +}
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Louis Chauvet" <louis.chauvet@bootlin.com>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jonathan Corbet" <corbet@lwn.net>,
"Alexey Brodkin" <abrodkin@synopsys.com>,
"Phong LE" <ple@baylibre.com>, "Liu Ying" <victor.liu@nxp.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"Adrien Grassein" <adrien.grassein@gmail.com>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
"Tomi Valkeinen" <tomi.valkeinen+renesas@ideasonboard.com>,
"Kieran Bingham" <kieran.bingham+renesas@ideasonboard.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Kevin Hilman" <khilman@baylibre.com>,
"Jerome Brunet" <jbrunet@baylibre.com>,
"Martin Blumenstingl" <martin.blumenstingl@googlemail.com>,
"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Anitha Chrisanthus" <anitha.chrisanthus@intel.com>,
"Edmund Dea" <edmund.j.dea@intel.com>,
"Inki Dae" <inki.dae@samsung.com>,
"Seung-Woo Kim" <sw0312.kim@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>
Cc: "Hui Pu" <Hui.Pu@gehealthcare.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <imx@lists.linux.dev>,
<linux-arm-kernel@lists.infradead.org>,
<linux-renesas-soc@vger.kernel.org>,
<linux-amlogic@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge
Date: Wed, 19 Nov 2025 16:05:05 +0100 [thread overview]
Message-ID: <DECRIHBXOEXY.WX45FITGF5DA@bootlin.com> (raw)
In-Reply-To: <0858117f-9397-4045-9b7d-490ad24926cb@bootlin.com>
Hi Louis,
On Wed Nov 19, 2025 at 3:33 PM CET, Louis Chauvet wrote:
>
>
> On 11/19/25 13:05, Luca Ceresoli wrote:
>> Several drivers (about 20) follow the same pattern:
>>
>> 1. get a pointer to a bridge (typically the next bridge in the chain) by
>> calling of_drm_find_bridge()
>> 2. store the returned pointer in the private driver data, keep it until
>> driver .remove
>> 3. dereference the pointer at attach time and possibly at other times
>>
>> of_drm_find_bridge() is now deprecated because it does not increment the
>> refcount and should be replaced with drm_of_find_bridge() +
>> drm_bridge_put().
>>
>> However some of those drivers have a complex code flow and adding a
>> drm_bridge_put() call in all the appropriate locations is error-prone,
>> leads to ugly and more complex code, and can lead to errors over time with
>> code flow changes.
>>
>> To handle all those drivers in a straightforward way, add a devm variant of
>> drm_of_find_bridge() that adds a devm action to invoke drm_bridge_put()
>> when the said driver is removed. This allows all those drivers to put the
>> reference automatically and safely with a one line change:
>>
>> - priv->next_bridge = of_drm_find_bridge(remote_np);
>> + priv->next_bridge = devm_drm_of_find_bridge(dev, remote_np);
>>
>> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>> ---
>> drivers/gpu/drm/drm_bridge.c | 30 ++++++++++++++++++++++++++++++
>> include/drm/drm_bridge.h | 5 +++++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 09ad825f9cb8..c7baafbe5695 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -1446,6 +1446,36 @@ struct drm_bridge *drm_of_find_bridge(struct device_node *np)
>> }
>> EXPORT_SYMBOL(drm_of_find_bridge);
>>
>> +/**
>> + * devm_drm_of_find_bridge - find the bridge corresponding to the device
>> + * node in the global bridge list and add a devm
>> + * action to put it
>> + *
>> + * @dev: device requesting the bridge
>> + * @np: device node
>> + *
>> + * On success the returned bridge refcount is incremented, and a devm
>> + * action is added to call drm_bridge_put() when @dev is removed. So the
>> + * caller does not have to put the returned bridge explicitly.
>> + *
>> + * RETURNS:
>> + * drm_bridge control struct on success, NULL on failure
>
> I am not sure for the "NULL on failure", you return ERR_PTR(err), which
> is probably not NULL but an error code.
Indeed.
Apologies for the mess in this series: it was adapted from an old one using
a different approach, so I had to adapt lots of details, and missed a few
along the way. :(
About the value to return, maybe it's better to use the same semantics as
drm_of_find_bridge(), i.e. NULL on error. I don't think a caller would have
anything clever to do with an error return value other tan bailing out. And
the only error path for devm_add_action_or_reset() is on a small
allocation, so it basically cannot happen.
>> +struct drm_bridge *devm_drm_of_find_bridge(struct device *dev, struct device_node *np)
>> +{
>> + struct drm_bridge *bridge = drm_of_find_bridge(np);
>> +
>> + if (bridge) {
>> + int err = devm_add_action_or_reset(dev, drm_bridge_put_void, bridge);
>> +
>> + if (err)
>> + return ERR_PTR(err);
>> + }
So this would become:
if (bridge) {
if (devm_add_action_or_reset(dev, drm_bridge_put_void, bridge))
return NULL;
}
>> +
>> + return bridge;
>> +}
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2025-11-19 15:05 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 13:05 [PATCH 00/26] drm/bridge: add drm_of_find_bridge(), deprecate of_drm_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 01/26] drm/bridge: add drm_of_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 14:22 ` Louis Chauvet
2025-11-19 14:22 ` Louis Chauvet
2025-11-19 14:29 ` Luca Ceresoli
2025-11-19 14:29 ` Luca Ceresoli
2025-11-24 10:15 ` Maxime Ripard
2025-11-24 10:15 ` Maxime Ripard
2025-11-24 16:03 ` Luca Ceresoli
2025-11-24 16:03 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 02/26] drm/bridge: deprecate of_drm_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 14:28 ` Louis Chauvet
2025-11-19 14:28 ` Louis Chauvet
2025-11-19 15:13 ` Luca Ceresoli
2025-11-19 15:13 ` Luca Ceresoli
2025-11-24 10:18 ` Maxime Ripard
2025-11-24 10:18 ` Maxime Ripard
2025-11-24 16:23 ` Luca Ceresoli
2025-11-24 16:23 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 03/26] drm/todo: add entry about converting to drm_of_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-24 10:21 ` Maxime Ripard
2025-11-24 10:21 ` Maxime Ripard
2025-11-19 13:05 ` [PATCH 04/26] drm/bridge: make of_drm_find_bridge() a wrapper of drm_of_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-24 10:22 ` Maxime Ripard
2025-11-24 10:22 ` Maxime Ripard
2025-11-24 16:44 ` Luca Ceresoli
2025-11-24 16:44 ` Luca Ceresoli
2025-12-01 16:34 ` Maxime Ripard
2025-12-01 16:34 ` Maxime Ripard
2025-12-11 17:48 ` Luca Ceresoli
2025-12-11 17:48 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 05/26] drm/arcpgu: convert to drm_of_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 14:33 ` Louis Chauvet
2025-11-19 14:33 ` Louis Chauvet
2025-11-19 15:05 ` Luca Ceresoli [this message]
2025-11-19 15:05 ` Luca Ceresoli
2025-11-24 10:39 ` Maxime Ripard
2025-11-24 10:39 ` Maxime Ripard
2025-11-24 16:25 ` Luca Ceresoli
2025-11-24 16:25 ` Luca Ceresoli
2025-12-01 16:51 ` Maxime Ripard
2025-12-01 16:51 ` Maxime Ripard
2025-12-11 17:47 ` Luca Ceresoli
2025-12-11 17:47 ` Luca Ceresoli
2025-12-12 11:10 ` Luca Ceresoli
2025-12-12 11:10 ` Luca Ceresoli
2025-12-15 10:35 ` Maxime Ripard
2025-12-15 10:35 ` Maxime Ripard
2025-12-15 14:11 ` Luca Ceresoli
2025-12-15 14:11 ` Luca Ceresoli
2025-12-16 13:49 ` Maxime Ripard
2025-12-16 13:49 ` Maxime Ripard
2025-12-16 16:36 ` Luca Ceresoli
2025-12-16 16:36 ` Luca Ceresoli
2025-12-15 9:41 ` Maxime Ripard
2025-12-15 9:41 ` Maxime Ripard
2025-12-15 9:52 ` Laurent Pinchart
2025-12-15 9:52 ` Laurent Pinchart
2025-11-19 13:05 ` [PATCH 07/26] drm/bridge: ite-it66121: use devm_drm_of_find_bridge() to put the next bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 14:36 ` Louis Chauvet
2025-11-19 14:36 ` Louis Chauvet
2025-11-19 13:05 ` [PATCH 08/26] drm/bridge: imx8qxp-pixel-combiner: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 09/26] drm/bridge: simple-bridge: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 10/26] drm/bridge: tpd12s015: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 11/26] drm/bridge: thc63lvd1024: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 12/26] drm/bridge: imx8qxp-pxl2dpi: use devm_drm_of_find_bridge() to put the next and companion bridges Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 13/26] drm/bridge: lt8912b: use devm_drm_of_find_bridge() to put the hdmi bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 14/26] drm/bridge: tfp410: use devm_drm_of_find_bridge() to put the next bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 15/26] drm/bridge: imx8qxp-ldb: use devm_drm_of_find_bridge() to put the companion bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 16/26] drm/rcar-du: lvds: use devm_drm_of_find_bridge() to put the next bridge Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 17/26] drm/meson: encoder_*: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 18/26] drm/bridge: sii902x: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 19/26] drm/mediatek: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 20/26] drm/kmb: dsi: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 21/26] drm/imx/ipuv3: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 22/26] drm/exynos: hdmi: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 23/26] drm/bridge: dw-hdmi: " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 24/26] drm/bridge: imx8qxp-pixel-link: simplify logic to find " Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 25/26] drm/bridge: imx8qxp-pixel-link: simplify freeing of the remote device_node Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
2025-11-19 13:05 ` [PATCH 26/26] drm/bridge: imx8qxp-pixel-link: convert to drm_of_find_bridge() Luca Ceresoli
2025-11-19 13:05 ` Luca Ceresoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DECRIHBXOEXY.WX45FITGF5DA@bootlin.com \
--to=luca.ceresoli@bootlin.com \
--cc=Hui.Pu@gehealthcare.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=abrodkin@synopsys.com \
--cc=adrien.grassein@gmail.com \
--cc=airlied@gmail.com \
--cc=alim.akhtar@samsung.com \
--cc=andrzej.hajda@intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=anitha.chrisanthus@intel.com \
--cc=chunkuang.hu@kernel.org \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=edmund.j.dea@intel.com \
--cc=festevam@gmail.com \
--cc=geert+renesas@glider.be \
--cc=imx@lists.linux.dev \
--cc=inki.dae@samsung.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@pengutronix.de \
--cc=khilman@baylibre.com \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=magnus.damm@gmail.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=ple@baylibre.com \
--cc=rfoss@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=simona@ffwll.ch \
--cc=sw0312.kim@samsung.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tomi.valkeinen+renesas@ideasonboard.com \
--cc=tzimmermann@suse.de \
--cc=victor.liu@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.