linux-kernel - Re: [PATCH v3 1/2] drm/bridge: sii902x: Fix mode

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <x7i5miguht47wxliioos7npelzzicnwt7g5pfjqjvdztksgzga@c7djvf3lg3kf>
Date: Fri, 24 May 2024 22:46:52 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Jayesh Choudhary <j-choudhary@...com>
Cc: linux-kernel@...r.kernel.org, andrzej.hajda@...el.com, 
	neil.armstrong@...aro.org, rfoss@...nel.org, Laurent.pinchart@...asonboard.com, 
	sam@...nborg.org, mripard@...nel.org, dri-devel@...ts.freedesktop.org, 
	jonas@...boo.se, jernej.skrabec@...il.com, maarten.lankhorst@...ux.intel.com, 
	tzimmermann@...e.de, airlied@...il.com, daniel@...ll.ch, a-bhatia1@...com
Subject: Re: [PATCH v3 1/2] drm/bridge: sii902x: Fix mode_valid hook

On Fri, May 24, 2024 at 05:54:02PM +0530, Jayesh Choudhary wrote:
> Hello Dmitry,
> 
> On 24/05/24 15:11, Dmitry Baryshkov wrote:
> > On Fri, May 24, 2024 at 03:05:08PM +0530, Jayesh Choudhary wrote:
> > > Currently, mode_valid hook returns all mode as valid and it is
> > > defined only in drm_connector_helper_funcs. With the introduction of
> > > 'DRM_BRIDGE_ATTACH_NO_CONNECTOR', connector is not initialized in
> > > bridge_attach call for cases when the encoder has this flag enabled.
> > > So add the mode_valid hook in drm_bridge_funcs as well with proper
> > > clock checks for maximum and minimum pixel clock supported by the
> > > bridge.
> > > 
> > > Signed-off-by: Jayesh Choudhary <j-choudhary@...com>
> 
> [...]
> 
> > > +
> > >   static enum drm_mode_status sii902x_mode_valid(struct drm_connector *connector,
> > >   					       struct drm_display_mode *mode)
> > >   {
> > > -	/* TODO: check mode */
> > > +	struct sii902x *sii902x = connector_to_sii902x(connector);
> > > +	const struct drm_display_mode *mod = mode;
> > > -	return MODE_OK;
> > > +	return sii902x_validate(sii902x, mod);
> > 
> > There is no need to. The drm_bridge_chain_mode_valid() should take care
> > of calling bridge's mode_valid callback and rejecting the mode if it is
> > not accepted.
> 
> I need some clarity here.
> 
> IIRC, if the bridge does initialize the connector in case
> where the encoder does not attach the bridge with the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR (DBANC) flag (referring to tidss
> encoder before we implemented the DBANC feature), then
> drm_connector_helper_func are called and drm_bridge_funcs
> are NOT called (atleast from what I have seen in detect
> hook for cdns-mhdp-8546 driver which is there in both
> structures).

There are different kinds of bridge_funcs. detect is a part of the
connector-related interface, so it is not called by the drm core. On the
other hand functions like mode_valid, enable/disable, etc. are called
for all bridges.

> I do not have any platform to test non-DBANC encoders.
> And I did not want to break any platform that were still using
> bridge_attach without DBANC flag.
> That is why I kept mode_valid hook in both structures.
> 
> Are you implying that if connector_helper_funcs are not there
> then there will be some sort of fallback to bridge_funcs instead
> of passthrough for mode_valid check? Because that goes against my
> previous observations.

Not quite. See how drm_atomic_heler uses bridge_funcs.

-- 
With best wishes
Dmitry