linux-kernel - Re: [PATCH v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

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]

Date:	Fri, 27 Nov 2015 14:32:26 +0100
From:	Heiko Stübner <heiko@...ech.de>
To:	Yakir Yang <ykk@...k-chips.com>
Cc:	Inki Dae <inki.dae@...sung.com>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Seung-Woo Kim <sw0312.kim@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Jingoo Han <jingoohan1@...il.com>,
	Thierry Reding <treding@...dia.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Yao <mark.yao@...k-chips.com>,
	Russell King <linux@....linux.org.uk>, djkurtz@...omium.org,
	dianders@...omium.org, Sean Paul <seanpaul@...omium.org>,
	Kukjin Kim <kgene@...nel.org>,
	Kumar Gala <galak@...eaurora.org>, emil.l.velikov@...il.com,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Kishon Vijay Abraham I <kishon@...com>,
	Pawel Moll <pawel.moll@....com>, ajaynumb@...il.com,
	robherring2@...il.com, javier@....samsung.com,
	Andy Yan <andy.yan@...k-chips.com>,
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

Am Mittwoch, 28. Oktober 2015, 16:56:01 schrieb Yakir Yang:
> There are some IP limit on rk3288 that only support 4 physical lanes
> of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
> 
> Tested-by: Javier Martinez Canillas <javier@....samsung.com>
> Signed-off-by: Yakir Yang <ykk@...k-chips.com>
> ---

[...]

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> 6307060..563ffb1d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp) return;
>  	}
> 
> -	ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> -					 dp->video_info.link_rate);
> +	ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> +					 dp->video_info.max_link_rate);
>  	if (ret) {
>  		dev_err(dp->dev, "unable to do link train\n");
>  		return;
> @@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct
> analogix_dp_device *dp) struct device_node *dp_node = dp->dev->of_node;
>  	struct video_info *video_info = &dp->video_info;
> 
> -	if (of_property_read_u32(dp_node, "samsung,link-rate",
> -				 &video_info->link_rate)) {
> -		dev_err(dp->dev, "failed to get link-rate\n");
> -		return -EINVAL;
> -	}
> -
> -	if (of_property_read_u32(dp_node, "samsung,lane-count",
> -				 &video_info->lane_count)) {
> -		dev_err(dp->dev, "failed to get lane-count\n");
> -		return -EINVAL;
> +	switch (dp->plat_data && dp->plat_data->dev_type) {

drivers/gpu/drm/bridge/analogix/analogix_dp_core.c: In function ‘analogix_dp_dt_parse_pdata’:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1191:10: warning: switch condition has boolean value [-Wswitch-bool]
  switch (dp->plat_data && dp->plat_data->dev_type) {
          ^

As I think we always will need to distinguish between implementations,
I guess it should be safe to exit with an error, it that implementation-data
is not available, like just doing before the switch a:

if (!dp->plat_data)
	return -EINVAL;


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/