linux-kernel - Re: [PATCH v3 5/8] drm: bridge: thc63: Do not report input bus mode through bridge timings

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: <20191107195215.GJ24983@pendragon.ideasonboard.com>
Date:   Thu, 7 Nov 2019 21:52:15 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Fabrizio Castro <fabrizio.castro@...renesas.com>
Cc:     Andrzej Hajda <a.hajda@...sung.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Sean Paul <sean@...rly.run>, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, Simon Horman <horms@...ge.net.au>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        linux-renesas-soc@...r.kernel.org,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>, sam@...nborg.org
Subject: Re: [PATCH v3 5/8] drm: bridge: thc63: Do not report input bus mode
 through bridge timings

Hi Fabrizio,

Thank you for the patch.

On Wed, Aug 28, 2019 at 07:36:39PM +0100, Fabrizio Castro wrote:
> No need to report the input bus mode through bridge timings
> anymore, that's now done through the DT, as specified by the
> dt-bindings.

Doesn't this break backward compatibility with older DT, as mentioned in
the review of 4/8 ?

> Signed-off-by: Fabrizio Castro <fabrizio.castro@...renesas.com>
> 
> ---
> v2->v3:
> * new patch
> ---
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 9 ++++-----
>  include/drm/drm_bridge.h              | 8 --------
>  2 files changed, 4 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c
> index 3d74129b..730f682 100644
> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -34,7 +34,7 @@ struct thc63_dev {
>  	struct drm_bridge bridge;
>  	struct drm_bridge *next;
>  
> -	struct drm_bridge_timings timings;
> +	bool dual_link;
>  };
>  
>  static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> @@ -62,7 +62,7 @@ static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
>  	 * isn't supported by the driver yet, simply derive the limits from the
>  	 * input mode.
>  	 */
> -	if (thc63->timings.dual_link) {
> +	if (thc63->dual_link) {
>  		min_freq = 40000;
>  		max_freq = 150000;
>  	} else {
> @@ -157,13 +157,13 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
>  
>  		if (remote) {
>  			if (of_device_is_available(remote))
> -				thc63->timings.dual_link = true;
> +				thc63->dual_link = true;
>  			of_node_put(remote);
>  		}
>  	}
>  
>  	dev_dbg(thc63->dev, "operating in %s-link mode\n",
> -		thc63->timings.dual_link ? "dual" : "single");
> +		thc63->dual_link ? "dual" : "single");
>  
>  	return 0;
>  }
> @@ -221,7 +221,6 @@ static int thc63_probe(struct platform_device *pdev)
>  	thc63->bridge.driver_private = thc63;
>  	thc63->bridge.of_node = pdev->dev.of_node;
>  	thc63->bridge.funcs = &thc63_bridge_func;
> -	thc63->bridge.timings = &thc63->timings;
>  
>  	drm_bridge_add(&thc63->bridge);
>  
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 7616f65..3228018 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -362,14 +362,6 @@ struct drm_bridge_timings {
>  	 * input signal after the clock edge.
>  	 */
>  	u32 hold_time_ps;
> -	/**
> -	 * @dual_link:
> -	 *
> -	 * True if the bus operates in dual-link mode. The exact meaning is
> -	 * dependent on the bus type. For LVDS buses, this indicates that even-
> -	 * and odd-numbered pixels are received on separate links.
> -	 */
> -	bool dual_link;
>  };
>  
>  /**

-- 
Regards,

Laurent Pinchart