From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Chaoyi Chen" <chaoyi.chen@rock-chips.com>,
"Chaoyi Chen" <kernel@airkyi.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>,
"Peter Chen" <hzpeterchen@gmail.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Sandy Huang" <hjc@rock-chips.com>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Yubing Zhang" <yubing.zhang@rock-chips.com>,
"Frank Wang" <frank.wang@rock-chips.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>,
"Amit Sunil Dhamne" <amitsd@google.com>,
"Dragan Simic" <dsimic@manjaro.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Diederik de Haas" <didi.debian@cknow.org>,
"Peter Robinson" <pbrobinson@gmail.com>
Cc: <linux-usb@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-phy@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-rockchip@lists.infradead.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v9 08/10] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
Date: Wed, 19 Nov 2025 20:49:42 +0100 [thread overview]
Message-ID: <DECXKE9A67HG.35AR5UZKKQ8A1@bootlin.com> (raw)
In-Reply-To: <2ebace6f-d3c4-4516-b6cb-4951de06b6c8@rock-chips.com>
Hello Chaoyi,
On Mon Nov 17, 2025 at 2:33 AM CET, Chaoyi Chen wrote:
...
>>>> + /* One endpoint may correspond to one next bridge. */
>>>> + for_each_of_graph_port_endpoint(port, dp_ep) {
>>>> + struct device_node *next_bridge_node __free(device_node) =
>>>> + of_graph_get_remote_port_parent(dp_ep);
>>>> +
>>>> + bridge = of_drm_find_bridge(next_bridge_node);
>>>> + if (!bridge) {
>>>> + ret = -EPROBE_DEFER;
>>>> + goto out;
>>>> + }
>>>> +
>>>> + dp->next_bridge_valid = true;
>>>> + dp->next_bridge_list[count].bridge = bridge;
>>> You are storing a reference to a drm_bridge, so have to increment the
>>> refcount:
>>>
>>> dp->next_bridge_list[count].bridge = drm_bridge_get(bridge);
>>> ^^^^^^^^^^^^^^
>>>
>>> FYI there is a plan to replace of_drm_find_bridge() with a function that
>>> increases the bridge refcount before returning the bridge, but it's not
>>> there yet. When that will happen, the explicit drm_bridge_get() won't be
>>> needed anymore and this code can be updated accordingly.
>
> Out of curiosity, I checked the callers of of_drm_find_bridge(), and it
> seems that the vast majority of them do not pay attention to the increase
> or decrease of reference counts.
They do not call drm_bridge_put() to decrease the refcount, and that's
"correct" because of_drm_find_bridge() does not increase it. This was
totally correct in the past because DRM bridge refcounting did not exist.
Refcounting has been added to support hot-pluggable bridges. If you want
more info, this presentation I gave at ELCE 2025 is a good summary, with
links to relevant patches:
* Video (start at 19:30): https://www.youtube.com/watch?v=msmBQBSyZZ4
* Slides (start at slide 27):
https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
> Does this mean that even if we add reference counting in
> of_drm_find_bridge(), we still need to modify the corresponding functions
> of their callers and decrease the reference count at the appropriate
> time?
Exactly. I have explored that approach but it turned out being not
reasonably doable due to the large number of (direct + indirect) callers of
of_drm_find_bridge() as well as the trickiness of those involvingthe
panel_bridge. So Maxime proposed a different approach [0]: deprecate
of_drm_find_bridge() and replace it with a function that increments the
refcount, then let the various callers move to the new function over time.
Earlier today I sent a series doing that, and converting lots of users
[1]. If/when that approach will be accepted, you can update your driver to
use the new drm_of_fund_bridge() and take care of putting the reference
when appropriate. But you don't need to do anything until then.
[0] https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
[1] https://lore.kernel.org/lkml/20251119-drm-bridge-alloc-getput-drm_of_find_bridge-v1-0-0db98a7fe474@bootlin.com/
> Thank you.
You're welcome. I hope it was a clear explanation.
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: "Chaoyi Chen" <chaoyi.chen@rock-chips.com>,
"Chaoyi Chen" <kernel@airkyi.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>,
"Peter Chen" <hzpeterchen@gmail.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Sandy Huang" <hjc@rock-chips.com>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Yubing Zhang" <yubing.zhang@rock-chips.com>,
"Frank Wang" <frank.wang@rock-chips.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>,
"Amit Sunil Dhamne" <amitsd@google.com>,
"Dragan Simic" <dsimic@manjaro.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Diederik de Haas" <didi.debian@cknow.org>,
"Peter Robinson" <pbrobinson@gmail.com>
Cc: <linux-usb@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-phy@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-rockchip@lists.infradead.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v9 08/10] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
Date: Wed, 19 Nov 2025 20:49:42 +0100 [thread overview]
Message-ID: <DECXKE9A67HG.35AR5UZKKQ8A1@bootlin.com> (raw)
In-Reply-To: <2ebace6f-d3c4-4516-b6cb-4951de06b6c8@rock-chips.com>
Hello Chaoyi,
On Mon Nov 17, 2025 at 2:33 AM CET, Chaoyi Chen wrote:
...
>>>> + /* One endpoint may correspond to one next bridge. */
>>>> + for_each_of_graph_port_endpoint(port, dp_ep) {
>>>> + struct device_node *next_bridge_node __free(device_node) =
>>>> + of_graph_get_remote_port_parent(dp_ep);
>>>> +
>>>> + bridge = of_drm_find_bridge(next_bridge_node);
>>>> + if (!bridge) {
>>>> + ret = -EPROBE_DEFER;
>>>> + goto out;
>>>> + }
>>>> +
>>>> + dp->next_bridge_valid = true;
>>>> + dp->next_bridge_list[count].bridge = bridge;
>>> You are storing a reference to a drm_bridge, so have to increment the
>>> refcount:
>>>
>>> dp->next_bridge_list[count].bridge = drm_bridge_get(bridge);
>>> ^^^^^^^^^^^^^^
>>>
>>> FYI there is a plan to replace of_drm_find_bridge() with a function that
>>> increases the bridge refcount before returning the bridge, but it's not
>>> there yet. When that will happen, the explicit drm_bridge_get() won't be
>>> needed anymore and this code can be updated accordingly.
>
> Out of curiosity, I checked the callers of of_drm_find_bridge(), and it
> seems that the vast majority of them do not pay attention to the increase
> or decrease of reference counts.
They do not call drm_bridge_put() to decrease the refcount, and that's
"correct" because of_drm_find_bridge() does not increase it. This was
totally correct in the past because DRM bridge refcounting did not exist.
Refcounting has been added to support hot-pluggable bridges. If you want
more info, this presentation I gave at ELCE 2025 is a good summary, with
links to relevant patches:
* Video (start at 19:30): https://www.youtube.com/watch?v=msmBQBSyZZ4
* Slides (start at slide 27):
https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
> Does this mean that even if we add reference counting in
> of_drm_find_bridge(), we still need to modify the corresponding functions
> of their callers and decrease the reference count at the appropriate
> time?
Exactly. I have explored that approach but it turned out being not
reasonably doable due to the large number of (direct + indirect) callers of
of_drm_find_bridge() as well as the trickiness of those involvingthe
panel_bridge. So Maxime proposed a different approach [0]: deprecate
of_drm_find_bridge() and replace it with a function that increments the
refcount, then let the various callers move to the new function over time.
Earlier today I sent a series doing that, and converting lots of users
[1]. If/when that approach will be accepted, you can update your driver to
use the new drm_of_fund_bridge() and take care of putting the reference
when appropriate. But you don't need to do anything until then.
[0] https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
[1] https://lore.kernel.org/lkml/20251119-drm-bridge-alloc-getput-drm_of_find_bridge-v1-0-0db98a7fe474@bootlin.com/
> Thank you.
You're welcome. I hope it was a clear explanation.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: "Luca Ceresoli" <luca.ceresoli@bootlin.com>
To: "Chaoyi Chen" <chaoyi.chen@rock-chips.com>,
"Chaoyi Chen" <kernel@airkyi.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@oss.qualcomm.com>,
"Peter Chen" <hzpeterchen@gmail.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Sandy Huang" <hjc@rock-chips.com>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Yubing Zhang" <yubing.zhang@rock-chips.com>,
"Frank Wang" <frank.wang@rock-chips.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>,
"Amit Sunil Dhamne" <amitsd@google.com>,
"Dragan Simic" <dsimic@manjaro.org>,
"Johan Jonker" <jbx6244@gmail.com>,
"Diederik de Haas" <didi.debian@cknow.org>,
"Peter Robinson" <pbrobinson@gmail.com>
Cc: <linux-usb@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-phy@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-rockchip@lists.infradead.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v9 08/10] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
Date: Wed, 19 Nov 2025 20:49:42 +0100 [thread overview]
Message-ID: <DECXKE9A67HG.35AR5UZKKQ8A1@bootlin.com> (raw)
In-Reply-To: <2ebace6f-d3c4-4516-b6cb-4951de06b6c8@rock-chips.com>
Hello Chaoyi,
On Mon Nov 17, 2025 at 2:33 AM CET, Chaoyi Chen wrote:
...
>>>> + /* One endpoint may correspond to one next bridge. */
>>>> + for_each_of_graph_port_endpoint(port, dp_ep) {
>>>> + struct device_node *next_bridge_node __free(device_node) =
>>>> + of_graph_get_remote_port_parent(dp_ep);
>>>> +
>>>> + bridge = of_drm_find_bridge(next_bridge_node);
>>>> + if (!bridge) {
>>>> + ret = -EPROBE_DEFER;
>>>> + goto out;
>>>> + }
>>>> +
>>>> + dp->next_bridge_valid = true;
>>>> + dp->next_bridge_list[count].bridge = bridge;
>>> You are storing a reference to a drm_bridge, so have to increment the
>>> refcount:
>>>
>>> dp->next_bridge_list[count].bridge = drm_bridge_get(bridge);
>>> ^^^^^^^^^^^^^^
>>>
>>> FYI there is a plan to replace of_drm_find_bridge() with a function that
>>> increases the bridge refcount before returning the bridge, but it's not
>>> there yet. When that will happen, the explicit drm_bridge_get() won't be
>>> needed anymore and this code can be updated accordingly.
>
> Out of curiosity, I checked the callers of of_drm_find_bridge(), and it
> seems that the vast majority of them do not pay attention to the increase
> or decrease of reference counts.
They do not call drm_bridge_put() to decrease the refcount, and that's
"correct" because of_drm_find_bridge() does not increase it. This was
totally correct in the past because DRM bridge refcounting did not exist.
Refcounting has been added to support hot-pluggable bridges. If you want
more info, this presentation I gave at ELCE 2025 is a good summary, with
links to relevant patches:
* Video (start at 19:30): https://www.youtube.com/watch?v=msmBQBSyZZ4
* Slides (start at slide 27):
https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf
> Does this mean that even if we add reference counting in
> of_drm_find_bridge(), we still need to modify the corresponding functions
> of their callers and decrease the reference count at the appropriate
> time?
Exactly. I have explored that approach but it turned out being not
reasonably doable due to the large number of (direct + indirect) callers of
of_drm_find_bridge() as well as the trickiness of those involvingthe
panel_bridge. So Maxime proposed a different approach [0]: deprecate
of_drm_find_bridge() and replace it with a function that increments the
refcount, then let the various callers move to the new function over time.
Earlier today I sent a series doing that, and converting lots of users
[1]. If/when that approach will be accepted, you can update your driver to
use the new drm_of_fund_bridge() and take care of putting the reference
when appropriate. But you don't need to do anything until then.
[0] https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
[1] https://lore.kernel.org/lkml/20251119-drm-bridge-alloc-getput-drm_of_find_bridge-v1-0-0db98a7fe474@bootlin.com/
> Thank you.
You're welcome. I hope it was a clear explanation.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-11-19 19:50 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-11 10:50 [PATCH v9 00/10] Add Type-C DP support for RK3399 EVB IND board Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 01/10] usb: typec: Add notifier functions Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-17 8:33 ` Heikki Krogerus
2025-11-17 8:33 ` Heikki Krogerus
2025-11-17 8:33 ` Heikki Krogerus
2025-11-17 8:41 ` Chaoyi Chen
2025-11-17 8:41 ` Chaoyi Chen
2025-11-17 8:41 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 02/10] usb: typec: Export all typec device types Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 03/10] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-17 8:40 ` Heikki Krogerus
2025-11-17 8:40 ` Heikki Krogerus
2025-11-17 8:40 ` Heikki Krogerus
2025-11-17 8:47 ` Chaoyi Chen
2025-11-17 8:47 ` Chaoyi Chen
2025-11-17 8:47 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 04/10] dt-bindings: phy: rockchip: rk3399-typec-phy: Support mode-switch Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 11:09 ` Krzysztof Kozlowski
2025-11-11 11:09 ` Krzysztof Kozlowski
2025-11-11 11:09 ` Krzysztof Kozlowski
2025-11-12 2:50 ` Chaoyi Chen
2025-11-12 2:50 ` Chaoyi Chen
2025-11-12 2:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 05/10] phy: rockchip: phy-rockchip-typec: Add typec_mux/typec_switch support Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 06/10] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-18 9:08 ` Neil Armstrong
2025-11-18 9:08 ` Neil Armstrong
2025-11-18 9:08 ` Neil Armstrong
2025-11-18 9:37 ` Chaoyi Chen
2025-11-18 9:37 ` Chaoyi Chen
2025-11-18 9:37 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 07/10] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 08/10] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 15:14 ` Luca Ceresoli
2025-11-11 15:14 ` Luca Ceresoli
2025-11-11 15:14 ` Luca Ceresoli
2025-11-12 1:37 ` Chaoyi Chen
2025-11-12 1:37 ` Chaoyi Chen
2025-11-12 1:37 ` Chaoyi Chen
2025-11-17 1:33 ` Chaoyi Chen
2025-11-17 1:33 ` Chaoyi Chen
2025-11-17 1:33 ` Chaoyi Chen
2025-11-19 19:49 ` Luca Ceresoli [this message]
2025-11-19 19:49 ` Luca Ceresoli
2025-11-19 19:49 ` Luca Ceresoli
2025-11-11 10:50 ` [PATCH v9 09/10] arm64: dts: rockchip: Add missing dp_out port for RK3399 CDN-DP Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` [PATCH v9 10/10] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
2025-11-11 10:50 ` Chaoyi Chen
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=DECXKE9A67HG.35AR5UZKKQ8A1@bootlin.com \
--to=luca.ceresoli@bootlin.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=amitsd@google.com \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=chaoyi.chen@rock-chips.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsimic@manjaro.org \
--cc=frank.wang@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=hzpeterchen@gmail.com \
--cc=jbx6244@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@airkyi.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=pbrobinson@gmail.com \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=vkoul@kernel.org \
--cc=yubing.zhang@rock-chips.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.