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: <yvjb7sd42uhvomsw2svotyxrvdxihsa3qch3lfynpaoap6g3hp@dcqmaw65zsk2>
Date: Tue, 25 Feb 2025 22:57:08 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Ayushi Makhija <quic_amakhija@...cinc.com>
Cc: linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	robdclark@...il.com, sean@...rly.run, marijn.suijten@...ainline.org, 
	andersson@...nel.org, robh@...nel.org, robh+dt@...nel.org, krzk+dt@...nel.org, 
	konradybcio@...nel.org, conor+dt@...nel.org, andrzej.hajda@...el.com, 
	neil.armstrong@...aro.org, rfoss@...nel.org, Laurent.pinchart@...asonboard.com, 
	jonas@...boo.se, jernej.skrabec@...il.com, quic_abhinavk@...cinc.com, 
	quic_rajeevny@...cinc.com, quic_vproddut@...cinc.com, quic_jesszhan@...cinc.com
Subject: Re: [PATCH 10/11] drm/bridge: anx7625: update bridge_ops and sink
 detect logic

On Tue, Feb 25, 2025 at 07:58:24PM +0200, Dmitry Baryshkov wrote:
> On Tue, Feb 25, 2025 at 05:48:23PM +0530, Ayushi Makhija wrote:
> > The anx7625_link_bridge() checks if a device is a not a panel
> > bridge and add DRM_BRIDGE_OP_HPD and DRM_BRIDGE_OP_DETECT to
> > the bridge operations. However, on port 1 of the anx7625
> > bridge, any device added is always treated as a panel
> > bridge, preventing connector_detect function from being
> > called. To resolve this, instead of just checking if it is a
> > panel bridge, we should verify the type of panel bridge
> > whether it is a DisplayPort or eDP panel. If the panel
> > bridge is of the DisplayPort type, we should add
> > DRM_BRIDGE_OP_HPD or DRM_BRIDGE_OP_DETECT to the bridge
> > operations.
> > 
> > In the anx7625_sink_detect(), the device is checked to see
> > if it is a panel bridge, and it always sends a "connected"
> > status to the connector. When adding the DP port on port 1 of the
> > anx7625, it incorrectly treats it as a panel bridge and sends an
> > always "connected" status. Instead of checking the status on the
> > panel bridge, it's better to check the hpd_status for connectors
> > like DisplayPort. This way, it verifies the hpd_status variable
> > before sending the status to the connector.
> > 
> > Signed-off-by: Ayushi Makhija <quic_amakhija@...cinc.com>
> > ---
> >  drivers/gpu/drm/bridge/analogix/anx7625.c | 10 ++++------
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index d2655bf46842..9b6303267924 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -1814,9 +1814,6 @@ static enum drm_connector_status anx7625_sink_detect(struct anx7625_data *ctx)
> >  
> >  	DRM_DEV_DEBUG_DRIVER(dev, "sink detect\n");
> >  
> > -	if (ctx->pdata.panel_bridge)
> > -		return connector_status_connected;
> > -
> >  	return ctx->hpd_status ? connector_status_connected :
> >  				     connector_status_disconnected;
> >  }
> > @@ -2596,9 +2593,10 @@ static int anx7625_link_bridge(struct drm_dp_aux *aux)
> >  	platform->bridge.of_node = dev->of_node;
> >  	if (!anx7625_of_panel_on_aux_bus(dev))
> >  		platform->bridge.ops |= DRM_BRIDGE_OP_EDID;
> > -	if (!platform->pdata.panel_bridge)
> > -		platform->bridge.ops |= DRM_BRIDGE_OP_HPD |
> > -					DRM_BRIDGE_OP_DETECT;
> > +	if (!platform->pdata.panel_bridge ||
> > +	    platform->pdata.panel_bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
> 
> This is incorrect, because there can be other kinds of bridges in the DP
> chain. I think it's better to check for !eDP instead.

Another option comes from the aux-bus bindings. If there is an aux-bus
node, it is an eDP. If there is none, it is most likely DP (well, unless
anybody has been using the bridge with eDP panels defclared using
platform devices rather than the aux-bus.

> 
> > +		platform->bridge.ops |= DRM_BRIDGE_OP_HPD | DRM_BRIDGE_OP_DETECT;
> > +	}
> >  	platform->bridge.type = platform->pdata.panel_bridge ?
> >  				    DRM_MODE_CONNECTOR_eDP :
> >  				    DRM_MODE_CONNECTOR_DisplayPort;
> > -- 
> > 2.34.1
> > 
> 
> -- 
> With best wishes
> Dmitry

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ