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]
Message-ID:
 <TYCPR01MB113322F56AC7B122218F2D90286402@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Date: Fri, 18 Oct 2024 07:43:12 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Liu Ying <victor.liu@....com>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>
CC: "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de"
	<s.hauer@...gutronix.de>, "kernel@...gutronix.de" <kernel@...gutronix.de>,
	"festevam@...il.com" <festevam@...il.com>, "andrzej.hajda@...el.com"
	<andrzej.hajda@...el.com>, "neil.armstrong@...aro.org"
	<neil.armstrong@...aro.org>, "rfoss@...nel.org" <rfoss@...nel.org>,
	laurent.pinchart <laurent.pinchart@...asonboard.com>, "jonas@...boo.se"
	<jonas@...boo.se>, "jernej.skrabec@...il.com" <jernej.skrabec@...il.com>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"simona@...ll.ch" <simona@...ll.ch>, "marex@...x.de" <marex@...x.de>,
	"stefan@...er.ch" <stefan@...er.ch>, "dmitry.baryshkov@...aro.org"
	<dmitry.baryshkov@...aro.org>
Subject: RE: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector

Hi Liu Ying,

> -----Original Message-----
> From: Liu Ying <victor.liu@....com>
> Sent: Friday, October 18, 2024 8:38 AM
> To: Biju Das <biju.das.jz@...renesas.com>; devicetree@...r.kernel.org; imx@...ts.linux.dev; linux-arm-
> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; dri-devel@...ts.freedesktop.org
> Cc: robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org; shawnguo@...nel.org;
> s.hauer@...gutronix.de; kernel@...gutronix.de; festevam@...il.com; andrzej.hajda@...el.com;
> neil.armstrong@...aro.org; rfoss@...nel.org; laurent.pinchart <laurent.pinchart@...asonboard.com>;
> jonas@...boo.se; jernej.skrabec@...il.com; maarten.lankhorst@...ux.intel.com; mripard@...nel.org;
> tzimmermann@...e.de; airlied@...il.com; simona@...ll.ch; marex@...x.de; stefan@...er.ch;
> dmitry.baryshkov@...aro.org
> Subject: Re: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
> 
> On 10/18/2024, Biju Das wrote:
> > Hi Liu Ying,
> 
> Hi Biju,
> 
> >
> > Thanks for the patch.
> 
> Thanks for your review.
> 
> >
> >> -----Original Message-----
> >> From: linux-arm-kernel <linux-arm-kernel-bounces@...ts.infradead.org>
> >> On Behalf Of Liu Ying
> >> Sent: Friday, October 18, 2024 7:48 AM
> >> Subject: [PATCH 5/5] drm: lcdif: Use drm_bridge_connector
> >>
> >> Initialize a connector by calling drm_bridge_connector_init() for
> >> each encoder so that down stream bridge drivers don't need to create connectors any more.
> >>
> >> Signed-off-by: Liu Ying <victor.liu@....com>
> >> ---
> >>  drivers/gpu/drm/mxsfb/Kconfig     |  1 +
> >>  drivers/gpu/drm/mxsfb/lcdif_drv.c | 17 ++++++++++++++++-
> >>  2 files changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mxsfb/Kconfig
> >> b/drivers/gpu/drm/mxsfb/Kconfig index
> >> 264e74f45554..06c95e556380 100644
> >> --- a/drivers/gpu/drm/mxsfb/Kconfig
> >> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> >> @@ -27,6 +27,7 @@ config DRM_IMX_LCDIF
> >>  	depends on DRM && OF
> >>  	depends on COMMON_CLK
> >>  	depends on ARCH_MXC || COMPILE_TEST
> >> +	select DRM_BRIDGE_CONNECTOR
> >>  	select DRM_CLIENT_SELECTION
> >>  	select DRM_MXS
> >>  	select DRM_KMS_HELPER
> >> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> index 58ccad9c425d..d4521da6675e 100644
> >> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> >> @@ -16,7 +16,9 @@
> >>
> >>  #include <drm/drm_atomic_helper.h>
> >>  #include <drm/drm_bridge.h>
> >> +#include <drm/drm_bridge_connector.h>
> >>  #include <drm/drm_client_setup.h>
> >> +#include <drm/drm_connector.h>
> >>  #include <drm/drm_drv.h>
> >>  #include <drm/drm_encoder.h>
> >>  #include <drm/drm_fbdev_dma.h>
> >> @@ -56,6 +58,7 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> >>  		struct device_node *remote;
> >>  		struct of_endpoint of_ep;
> >>  		struct drm_encoder *encoder;
> >> +		struct drm_connector *connector;
> >>
> >>  		remote = of_graph_get_remote_port_parent(ep);
> >>  		if (!of_device_is_available(remote)) { @@ -97,13 +100,25 @@ static
> >> int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> >>  			return ret;
> >>  		}
> >>
> >> -		ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> >> +		ret = drm_bridge_attach(encoder, bridge, NULL,
> >> +					DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >>  		if (ret) {
> >>  			of_node_put(ep);
> >>  			return dev_err_probe(dev, ret,
> >>  					     "Failed to attach bridge for endpoint%u\n",
> >>  					     of_ep.id);
> >>  		}
> >> +
> >> +		connector = drm_bridge_connector_init(lcdif->drm, encoder);
> >> +		if (IS_ERR(connector)) {
> >> +			ret = PTR_ERR(connector);
> >> +			dev_err(dev, "Failed to initialize bridge connector: %d\n",
> >> +				ret);
> >> +			of_node_put(ep);
> >> +			return ret;
> >
> > Maybe same error path style like above??
> > 		of_node_put(ep);
> > 		return dev_err_probe(dev, PTR_ERR(connector),"Failed to initialize
> > bridge connector");
> 
> I thought about that and decided not to use dev_err_probe() because I don't think
> drm_bridge_connector_init() may return -EPROBE_DEFER, no?

Yes, you are correct.

Reviewed-by: Biju Das <biju.das.jz@...renesas.com>

Cheers,
Biju

> 
> >
> > Cheers,
> > Biju
> >
> >> +		}
> >> +
> >> +		drm_connector_attach_encoder(connector, encoder);
> >>  	}
> >>
> >>  	return 0;
> >> --
> >> 2.34.1
> >>
> >
> 
> --
> Regards,
> Liu Ying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ