From: Liviu Dudau <liviu.dudau@arm.com> To: Rob Herring <robh@kernel.org> Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel.vetter@intel.com>, Sean Paul <seanpaul@chromium.org>, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>, Boris Brezillon <boris.brezillon@free-electrons.com>, Archit Taneja <architt@codeaurora.org>, Jingoo Han <jingoohan1@gmail.com>, Inki Dae <inki.dae@samsung.com>, Joonyoung Shim <jy0922.shim@samsung.com>, Seung-Woo Kim <sw0312.kim@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com>, Kukjin Kim <kgene@kernel.org>, Krzysztof Kozlowski <krzk@kernel.org>, Javier Martinez Canillas <javier@osg.samsung.com>, Stefan Agner <stefan@agner.ch>, Alison Wang <alison.wang@freescale.com>, Xinliang Liu <z.liuxinliang@hisilicon.com>, Rongrong Zou <zourongrong@gmail.com>, Xinwei Kong <kong.kongxinwei@hisilicon.com>, Chen Feng <puck.chen@hisilicon.com>, Philipp Zabel <p.zabel@pengutronix.de>, CK Hu <ck.hu@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, Marek Vasut <marex@denx.de>, Mark Yao <mark.yao@rock-chips.com>, Heiko Stuebner <heiko@sntech.de>, Maxime Ripard <maxime.ripard@free-electrons.com>, Chen-Yu Tsai <wens@csie.org>, Mali DP Maintainers <malidp@foss.arm.com>, Neil Armstrong <narmstrong@baylibre.com>, Carlo Caione <carlo@caione.org>, Kevin Hilman <khilman@baylibre.com>, Rob Clark <robdclark@gmail.com>, Jyri Sarha <jsarha@ti.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Eric Anholt <eric@anholt.net>, Russell King <rmk+kernel@armlinux.org.uk> Subject: Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Date: Mon, 6 Feb 2017 17:23:06 +0000 [thread overview] Message-ID: <20170206172306.GY3140@e110455-lin.cambridge.arm.com> (raw) In-Reply-To: <20170206170949.tmm4m2lm2rybm5dh@rob-hp-laptop> On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote: > On Mon, Feb 06, 2017 at 10:29:33AM +0000, Liviu Dudau wrote: > > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote: > > > Convert drivers to use the new of_graph_get_remote_node() helper > > > instead of parsing the endpoint node and then getting the remote device > > > node. Now drivers can just specify the device node and which > > > port/endpoint and get back the connected remote device node. The details > > > of the graph binding are nicely abstracted into the core OF graph code. > > > > > > This changes some error messages to debug messages (in the graph core). > > > Graph connections are often "no connects" depending on the particular > > > board, so we want to avoid spurious messages. Plus the kernel is not a > > > DT validator. > > > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++------- > > > drivers/gpu/drm/arm/malidp_drv.c | 29 ++--------- > > > drivers/gpu/drm/bridge/adv7511/adv7533.c | 12 +---- > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 15 ++---- > > > drivers/gpu/drm/bridge/ti-tfp410.c | 15 ++---- > > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +----- > > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++--- > > > drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +--------- > > > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 26 ++-------- > > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +---------- > > > drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--- > > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++-------- > > > drivers/gpu/drm/meson/meson_drv.c | 12 ++--- > > > drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++----- > > > drivers/gpu/drm/msm/dsi/dsi_host.c | 3 +- > > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +---------- > > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++---- > > > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 11 +---- > > > drivers/gpu/drm/tilcdc/tilcdc_external.c | 66 +++---------------------- > > > drivers/gpu/drm/vc4/vc4_dpi.c | 15 ++---- > > > 20 files changed, 64 insertions(+), 351 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > > > index e5f4f4a6546d..0f70f5fe9970 100644 > > > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > > > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > > > @@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data) > > > > > > static int hdlcd_probe(struct platform_device *pdev) > > > { > > > - struct device_node *port, *ep; > > > + struct device_node *port; > > > struct component_match *match = NULL; > > > > > > - if (!pdev->dev.of_node) > > > - return -ENODEV; > > > - > > > /* there is only one output port inside each device, find it */ > > > - ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL); > > > - if (!ep) > > > - return -ENODEV; > > > - > > > - if (!of_device_is_available(ep)) { > > > - of_node_put(ep); > > > + port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0); > > > + if (!port) > > > return -ENODEV; > > > - } > > > - > > > - /* add the remote encoder port as component */ > > > - port = of_graph_get_remote_port_parent(ep); > > > - of_node_put(ep); > > > - if (!port || !of_device_is_available(port)) { > > > - of_node_put(port); > > > - return -EAGAIN; > > > > The HDLCD change looks reasonable except for this -EAGAIN business. I'll have to > > test your changes on my setup to see how this affects having the encoder as a module. > > What are you expecting to happen with -EAGAIN? This one was a bit of an > oddball. When both the HDLCD and the TDA998x drivers are compiled as modules, the order in which they are inserted can be somewhat random (due to testing). It is at that time when you want the probe of HDLCD to be retried on the insmod-ing of the tda998x.ko rather than fail entirely. > > This condition would only change if you had an overlay. That's a use > case that needs to be handled in a common way ('cause I don't want to > clean-up every driver doing overlays in their own way latter). Just > having "status" changing at runtime would have all sorts of implications > in the kernel. Hmm, not sure what you mean here with overlays. Are you thinking that the remote port is initially disabled and then re-enabled by an overlay? That is not the only way of_device_is_available() can fail, see above regarding modules. Best regards, Liviu > > > > > > - } > > > > > > drm_of_component_match_add(&pdev->dev, &match, compare_dev, port); > > > of_node_put(port); > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c > > > index 32f746e31379..bfa04be7f5de 100644 > > > --- a/drivers/gpu/drm/arm/malidp_drv.c > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c > > > @@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev) > > > { > > > struct resource *res; > > > struct drm_device *drm; > > > - struct device_node *ep; > > > struct malidp_drm *malidp; > > > struct malidp_hw_device *hwdev; > > > struct platform_device *pdev = to_platform_device(dev); > > > @@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev) > > > goto init_fail; > > > > > > /* Set the CRTC's port so that the encoder component can find it */ > > > - ep = of_graph_get_next_endpoint(dev->of_node, NULL); > > > - if (!ep) { > > > - ret = -EINVAL; > > > - goto port_fail; > > > - } > > > - malidp->crtc.port = of_get_next_parent(ep); > > > + malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0); > > > > > > ret = component_bind_all(dev, drm); > > > if (ret) { > > > @@ -418,9 +412,7 @@ static int malidp_bind(struct device *dev) > > > irq_init_fail: > > > component_unbind_all(dev, drm); > > > bind_fail: > > > - of_node_put(malidp->crtc.port); > > > > Why removing this line? AFAICT this is still needed, according to of_graph_get_port_by_id() > > documentation. > > Yes, you are right. > > Rob -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯
WARNING: multiple messages have this Message-ID (diff)
From: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org> To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>, Daniel Vetter <daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, Archit Taneja <architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Joonyoung Shim <jy0922.shim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Seung-Woo Kim <sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>, Alison Wang <alison.wang-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, Xinliang Liu <z.liuxinliang@hisi> Subject: Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Date: Mon, 6 Feb 2017 17:23:06 +0000 [thread overview] Message-ID: <20170206172306.GY3140@e110455-lin.cambridge.arm.com> (raw) In-Reply-To: <20170206170949.tmm4m2lm2rybm5dh@rob-hp-laptop> On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote: > On Mon, Feb 06, 2017 at 10:29:33AM +0000, Liviu Dudau wrote: > > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote: > > > Convert drivers to use the new of_graph_get_remote_node() helper > > > instead of parsing the endpoint node and then getting the remote device > > > node. Now drivers can just specify the device node and which > > > port/endpoint and get back the connected remote device node. The details > > > of the graph binding are nicely abstracted into the core OF graph code. > > > > > > This changes some error messages to debug messages (in the graph core). > > > Graph connections are often "no connects" depending on the particular > > > board, so we want to avoid spurious messages. Plus the kernel is not a > > > DT validator. > > > > > > Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > > --- > > > drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++------- > > > drivers/gpu/drm/arm/malidp_drv.c | 29 ++--------- > > > drivers/gpu/drm/bridge/adv7511/adv7533.c | 12 +---- > > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 15 ++---- > > > drivers/gpu/drm/bridge/ti-tfp410.c | 15 ++---- > > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +----- > > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++--- > > > drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +--------- > > > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 26 ++-------- > > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +---------- > > > drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++--- > > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++-------- > > > drivers/gpu/drm/meson/meson_drv.c | 12 ++--- > > > drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++----- > > > drivers/gpu/drm/msm/dsi/dsi_host.c | 3 +- > > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +---------- > > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++---- > > > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 11 +---- > > > drivers/gpu/drm/tilcdc/tilcdc_external.c | 66 +++---------------------- > > > drivers/gpu/drm/vc4/vc4_dpi.c | 15 ++---- > > > 20 files changed, 64 insertions(+), 351 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c > > > index e5f4f4a6546d..0f70f5fe9970 100644 > > > --- a/drivers/gpu/drm/arm/hdlcd_drv.c > > > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c > > > @@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data) > > > > > > static int hdlcd_probe(struct platform_device *pdev) > > > { > > > - struct device_node *port, *ep; > > > + struct device_node *port; > > > struct component_match *match = NULL; > > > > > > - if (!pdev->dev.of_node) > > > - return -ENODEV; > > > - > > > /* there is only one output port inside each device, find it */ > > > - ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL); > > > - if (!ep) > > > - return -ENODEV; > > > - > > > - if (!of_device_is_available(ep)) { > > > - of_node_put(ep); > > > + port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0); > > > + if (!port) > > > return -ENODEV; > > > - } > > > - > > > - /* add the remote encoder port as component */ > > > - port = of_graph_get_remote_port_parent(ep); > > > - of_node_put(ep); > > > - if (!port || !of_device_is_available(port)) { > > > - of_node_put(port); > > > - return -EAGAIN; > > > > The HDLCD change looks reasonable except for this -EAGAIN business. I'll have to > > test your changes on my setup to see how this affects having the encoder as a module. > > What are you expecting to happen with -EAGAIN? This one was a bit of an > oddball. When both the HDLCD and the TDA998x drivers are compiled as modules, the order in which they are inserted can be somewhat random (due to testing). It is at that time when you want the probe of HDLCD to be retried on the insmod-ing of the tda998x.ko rather than fail entirely. > > This condition would only change if you had an overlay. That's a use > case that needs to be handled in a common way ('cause I don't want to > clean-up every driver doing overlays in their own way latter). Just > having "status" changing at runtime would have all sorts of implications > in the kernel. Hmm, not sure what you mean here with overlays. Are you thinking that the remote port is initially disabled and then re-enabled by an overlay? That is not the only way of_device_is_available() can fail, see above regarding modules. Best regards, Liviu > > > > > > - } > > > > > > drm_of_component_match_add(&pdev->dev, &match, compare_dev, port); > > > of_node_put(port); > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c > > > index 32f746e31379..bfa04be7f5de 100644 > > > --- a/drivers/gpu/drm/arm/malidp_drv.c > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c > > > @@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev) > > > { > > > struct resource *res; > > > struct drm_device *drm; > > > - struct device_node *ep; > > > struct malidp_drm *malidp; > > > struct malidp_hw_device *hwdev; > > > struct platform_device *pdev = to_platform_device(dev); > > > @@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev) > > > goto init_fail; > > > > > > /* Set the CRTC's port so that the encoder component can find it */ > > > - ep = of_graph_get_next_endpoint(dev->of_node, NULL); > > > - if (!ep) { > > > - ret = -EINVAL; > > > - goto port_fail; > > > - } > > > - malidp->crtc.port = of_get_next_parent(ep); > > > + malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0); > > > > > > ret = component_bind_all(dev, drm); > > > if (ret) { > > > @@ -418,9 +412,7 @@ static int malidp_bind(struct device *dev) > > > irq_init_fail: > > > component_unbind_all(dev, drm); > > > bind_fail: > > > - of_node_put(malidp->crtc.port); > > > > Why removing this line? AFAICT this is still needed, according to of_graph_get_port_by_id() > > documentation. > > Yes, you are right. > > Rob -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-02-06 17:23 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-04 3:36 [PATCH 0/5] DRM OF graph clean-up Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 3:36 ` [PATCH 1/5] of: introduce of_graph_get_remote_node Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 16:10 ` Vladimir Zapolskiy 2017-02-04 16:10 ` Vladimir Zapolskiy 2017-02-06 8:50 ` Daniel Vetter 2017-02-06 8:50 ` Daniel Vetter 2017-02-06 13:41 ` Rob Herring 2017-02-06 13:41 ` Rob Herring 2017-02-06 10:32 ` Philipp Zabel 2017-02-06 10:32 ` Philipp Zabel 2017-02-06 13:54 ` Rob Herring 2017-02-06 13:54 ` Rob Herring 2017-02-06 14:03 ` Philipp Zabel 2017-02-06 14:03 ` Philipp Zabel 2017-02-04 3:36 ` [PATCH 2/5] drm: of: introduce drm_of_find_panel_or_bridge Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-06 10:18 ` Liviu Dudau 2017-02-06 10:18 ` Liviu Dudau 2017-02-06 16:20 ` Rob Herring 2017-02-06 16:20 ` Rob Herring 2017-02-06 10:42 ` Philipp Zabel 2017-02-06 10:42 ` Philipp Zabel 2017-02-06 16:53 ` Rob Herring 2017-02-06 16:53 ` Rob Herring 2017-02-06 17:45 ` Philipp Zabel 2017-02-06 17:45 ` Philipp Zabel 2017-02-10 19:42 ` Frank Rowand 2017-02-10 19:42 ` Frank Rowand 2017-02-04 3:36 ` [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-06 8:31 ` Jyri Sarha 2017-02-06 8:31 ` Jyri Sarha 2017-02-06 10:17 ` Neil Armstrong 2017-02-06 10:17 ` Neil Armstrong 2017-02-06 10:29 ` Liviu Dudau 2017-02-06 10:29 ` Liviu Dudau 2017-02-06 17:09 ` Rob Herring 2017-02-06 17:09 ` Rob Herring 2017-02-06 17:23 ` Liviu Dudau [this message] 2017-02-06 17:23 ` Liviu Dudau 2017-02-06 17:34 ` Russell King - ARM Linux 2017-02-06 17:34 ` Russell King - ARM Linux 2017-02-06 17:55 ` Liviu Dudau 2017-02-06 17:55 ` Liviu Dudau 2017-02-06 18:09 ` Russell King - ARM Linux 2017-02-06 18:09 ` Russell King - ARM Linux 2017-02-06 17:42 ` Rob Herring 2017-02-06 17:42 ` Rob Herring 2017-02-06 10:52 ` Philipp Zabel 2017-02-06 10:52 ` Philipp Zabel 2017-02-06 13:40 ` Rob Herring 2017-02-06 13:40 ` Rob Herring 2017-02-08 11:57 ` Liviu Dudau 2017-02-08 11:57 ` Liviu Dudau 2017-02-08 20:44 ` Eric Anholt 2017-02-08 20:44 ` Eric Anholt 2017-02-04 3:36 ` [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 20:26 ` Fabio Estevam 2017-02-04 20:26 ` Fabio Estevam 2017-02-05 22:25 ` Rob Herring 2017-02-05 22:25 ` Rob Herring 2017-02-06 0:01 ` Fabio Estevam 2017-02-06 0:01 ` Fabio Estevam 2017-02-06 1:22 ` Fabio Estevam 2017-02-06 1:22 ` Fabio Estevam 2017-02-06 10:03 ` Maxime Ripard 2017-02-06 10:03 ` Maxime Ripard 2017-02-06 17:32 ` Rob Herring 2017-02-06 17:32 ` Rob Herring 2017-02-08 7:46 ` Maxime Ripard 2017-02-08 7:46 ` Maxime Ripard 2017-02-06 11:07 ` Philipp Zabel 2017-02-06 11:07 ` Philipp Zabel 2017-02-04 3:36 ` [PATCH 5/5] drm: omap: use common OF graph helpers Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 10:47 ` [PATCH 0/5] DRM OF graph clean-up Russell King - ARM Linux 2017-02-04 10:47 ` Russell King - ARM Linux
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=20170206172306.GY3140@e110455-lin.cambridge.arm.com \ --to=liviu.dudau@arm.com \ --cc=airlied@linux.ie \ --cc=alison.wang@freescale.com \ --cc=architt@codeaurora.org \ --cc=boris.brezillon@free-electrons.com \ --cc=carlo@caione.org \ --cc=ck.hu@mediatek.com \ --cc=daniel.vetter@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=eric@anholt.net \ --cc=frowand.list@gmail.com \ --cc=heiko@sntech.de \ --cc=inki.dae@samsung.com \ --cc=javier@osg.samsung.com \ --cc=jingoohan1@gmail.com \ --cc=jsarha@ti.com \ --cc=jy0922.shim@samsung.com \ --cc=kgene@kernel.org \ --cc=khilman@baylibre.com \ --cc=kong.kongxinwei@hisilicon.com \ --cc=krzk@kernel.org \ --cc=kyungmin.park@samsung.com \ --cc=linux-kernel@vger.kernel.org \ --cc=malidp@foss.arm.com \ --cc=marex@denx.de \ --cc=mark.yao@rock-chips.com \ --cc=matthias.bgg@gmail.com \ --cc=maxime.ripard@free-electrons.com \ --cc=narmstrong@baylibre.com \ --cc=p.zabel@pengutronix.de \ --cc=puck.chen@hisilicon.com \ --cc=rmk+kernel@armlinux.org.uk \ --cc=robdclark@gmail.com \ --cc=robh@kernel.org \ --cc=seanpaul@chromium.org \ --cc=stefan@agner.ch \ --cc=sw0312.kim@samsung.com \ --cc=tomi.valkeinen@ti.com \ --cc=wens@csie.org \ --cc=z.liuxinliang@hisilicon.com \ --cc=zourongrong@gmail.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: linkBe 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.