From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EC87C433FE for ; Sat, 16 Oct 2021 08:58:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 79C8860FF2 for ; Sat, 16 Oct 2021 08:58:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239855AbhJPJAc (ORCPT ); Sat, 16 Oct 2021 05:00:32 -0400 Received: from msg-1.mailo.com ([213.182.54.11]:46332 "EHLO msg-1.mailo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236048AbhJPJAb (ORCPT ); Sat, 16 Oct 2021 05:00:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=net-c.es; s=mailo; t=1634374693; bh=9IL8gtMx9v+2OPAAge0RErzrh08ys/P7bdTcb4UTPyc=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; b=MoYnQZ5L6Ax0/fqJMIwGZCAaXd+RW/7hsqN7Ru2uyoWj8IQKyGyQt87jaZGxhKhF+ RctnOXYKQjlXfB+3BNI9Dje/aQ7GoBOvzDDIAWxFg8zcvim3fw5K1HxLeVx6jfxIbN RIizUInJ4bkCf1hQdJdE2jWovuRx5ozpyfFHXVEs= Received: by b-2.in.mailobj.net [192.168.90.12] with ESMTP via ip-206.mailobj.net [213.182.55.206] Sat, 16 Oct 2021 10:58:13 +0200 (CEST) X-EA-Auth: A5rfGmpIBDyFxLfMHpfhudehUSSxmDiQm2TxkL/eXbGqty570ZAWa8gGp3kSB+GyiaCfMVhAZa4NwN7QqTApIj+sGlxqqx7d Date: Sat, 16 Oct 2021 10:58:10 +0200 From: Claudio Suarez To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, intel-gfx@lists.freedesktop.org, David Airlie , Daniel Vetter , Laurent Pinchart , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Pan Xinhui , Emma Anholt , Maxime Ripard , Thierry Reding , Patrik Jakobsson , Jingoo Han , Rob Clark , Sean Paul , linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, Chen-Yu Tsai , Sandy Huang , heiko@sntech.de, Neil Armstrong , Robert Foss , Ben Skeggs , nouveau@lists.freedesktop.org Subject: Re: [Freedreno] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info Message-ID: References: <20211015113713.630119-1-cssk@net-c.es> <20211015113713.630119-2-cssk@net-c.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Sat, Oct 16, 2021 at 10:25:03AM +0200, Claudio Suarez wrote: > On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote: > > On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote: > > > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote: > > > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote: > > > > > According to the documentation, drm_add_edid_modes > > > > > "... Also fills out the &drm_display_info structure and ELD in @connector > > > > > with any information which can be derived from the edid." > > > > > > > > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a > > > > > value or may be null. When it is not null, connector->display_info and > > > > > connector->eld are updated according to the edid. When edid=NULL, only > > > > > connector->eld is reset. Reset connector->display_info to be consistent > > > > > and accurate. > > > > > > > > > > Signed-off-by: Claudio Suarez > > > > > --- > > > > > drivers/gpu/drm/drm_edid.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > > > > index 6325877c5fd6..6cbe09b2357c 100644 > > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > > > > > > > > if (edid == NULL) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > return 0; > > > > > } > > > > > if (!drm_edid_is_valid(edid)) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > > > > Looks easier if you pull both of those out from these branches and > > > > just call them unconditionally at the start. > > > > > > After looking at the full code, I am not sure. This is the code: > > > ================== > > > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > { > > > int num_modes = 0; > > > u32 quirks; > > > > > > if (edid == NULL) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > return 0; > > > } > > > if (!drm_edid_is_valid(edid)) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > drm_warn(connector->dev, "%s: EDID invalid.\n", > > > connector->name); > > > return 0; > > > } > > > > > > drm_edid_to_eld(connector, edid); > > > > > > quirks = drm_add_display_info(connector, edid); > > > etc... > > > ================= > > > > > > If we move those out of these branches and edid != NULL, we are executing an > > > unnecessary clear_eld(connector) and an unnecessary drm_reset_display_info(connector) > > > because the fields will be set in the next drm_edid_to_eld(connector, edid) and > > > drm_add_display_info(connector, edid) > > > > > > Do we want this ? > > > > Seems fine by me. And maybe we could nuke the second > > drm_reset_display_info() from deeper inside drm_add_display_info()? > > Not sure if drm_add_display_info() still has to be able to operate > > standalone or not. > > > > Hmm. Another option is to just move all these NULL/invalid edid > > checks into drm_edid_to_eld() and drm_add_display_info(). > > I was thinking about this. We can use a boolean variable: > =============== > bool edid_is_invalid; > > edid_is_invalid = !drm_edid_is_valid(edid); > > if (edid == NULL || edid_is_invalid) { > clear_eld(connector); > drm_reset_display_info(connector); > if (edid_is_invalid) > drm_warn(connector->dev, "%s: EDID invalid.\n", > connector->name); > return 0; > } > > drm_edid_to_eld(connector, edid); > ... > =============== > Internally, drm_edid_is_valid() handles NULL pointers properly. > It is a quite elegant solution with a small change in the original > design, and it improves this part in the way you pointed out. I'll send a patch with this idea and we can talk about the new code. Thanks! Best regards, Claudio Suarez. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EB5FC433F5 for ; Sat, 16 Oct 2021 08:58:27 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 052DA611AF for ; Sat, 16 Oct 2021 08:58:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 052DA611AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=net-c.es Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 953AE6E423; Sat, 16 Oct 2021 08:58:23 +0000 (UTC) Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by gabe.freedesktop.org (Postfix) with ESMTPS id 844206E41B; Sat, 16 Oct 2021 08:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=net-c.es; s=mailo; t=1634374693; bh=9IL8gtMx9v+2OPAAge0RErzrh08ys/P7bdTcb4UTPyc=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; b=MoYnQZ5L6Ax0/fqJMIwGZCAaXd+RW/7hsqN7Ru2uyoWj8IQKyGyQt87jaZGxhKhF+ RctnOXYKQjlXfB+3BNI9Dje/aQ7GoBOvzDDIAWxFg8zcvim3fw5K1HxLeVx6jfxIbN RIizUInJ4bkCf1hQdJdE2jWovuRx5ozpyfFHXVEs= Received: by b-2.in.mailobj.net [192.168.90.12] with ESMTP via ip-206.mailobj.net [213.182.55.206] Sat, 16 Oct 2021 10:58:13 +0200 (CEST) X-EA-Auth: A5rfGmpIBDyFxLfMHpfhudehUSSxmDiQm2TxkL/eXbGqty570ZAWa8gGp3kSB+GyiaCfMVhAZa4NwN7QqTApIj+sGlxqqx7d Date: Sat, 16 Oct 2021 10:58:10 +0200 From: Claudio Suarez To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, intel-gfx@lists.freedesktop.org, David Airlie , Daniel Vetter , Laurent Pinchart , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Pan Xinhui , Emma Anholt , Maxime Ripard , Thierry Reding , Patrik Jakobsson , Jingoo Han , Rob Clark , Sean Paul , linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, Chen-Yu Tsai , Sandy Huang , heiko@sntech.de, Neil Armstrong , Robert Foss , Ben Skeggs , nouveau@lists.freedesktop.org Message-ID: References: <20211015113713.630119-1-cssk@net-c.es> <20211015113713.630119-2-cssk@net-c.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Nouveau] [Freedreno] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Sat, Oct 16, 2021 at 10:25:03AM +0200, Claudio Suarez wrote: > On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote: > > On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote: > > > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote: > > > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote: > > > > > According to the documentation, drm_add_edid_modes > > > > > "... Also fills out the &drm_display_info structure and ELD in @connector > > > > > with any information which can be derived from the edid." > > > > > > > > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a > > > > > value or may be null. When it is not null, connector->display_info and > > > > > connector->eld are updated according to the edid. When edid=NULL, only > > > > > connector->eld is reset. Reset connector->display_info to be consistent > > > > > and accurate. > > > > > > > > > > Signed-off-by: Claudio Suarez > > > > > --- > > > > > drivers/gpu/drm/drm_edid.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > > > > index 6325877c5fd6..6cbe09b2357c 100644 > > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > > > > > > > > if (edid == NULL) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > return 0; > > > > > } > > > > > if (!drm_edid_is_valid(edid)) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > > > > Looks easier if you pull both of those out from these branches and > > > > just call them unconditionally at the start. > > > > > > After looking at the full code, I am not sure. This is the code: > > > ================== > > > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > { > > > int num_modes = 0; > > > u32 quirks; > > > > > > if (edid == NULL) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > return 0; > > > } > > > if (!drm_edid_is_valid(edid)) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > drm_warn(connector->dev, "%s: EDID invalid.\n", > > > connector->name); > > > return 0; > > > } > > > > > > drm_edid_to_eld(connector, edid); > > > > > > quirks = drm_add_display_info(connector, edid); > > > etc... > > > ================= > > > > > > If we move those out of these branches and edid != NULL, we are executing an > > > unnecessary clear_eld(connector) and an unnecessary drm_reset_display_info(connector) > > > because the fields will be set in the next drm_edid_to_eld(connector, edid) and > > > drm_add_display_info(connector, edid) > > > > > > Do we want this ? > > > > Seems fine by me. And maybe we could nuke the second > > drm_reset_display_info() from deeper inside drm_add_display_info()? > > Not sure if drm_add_display_info() still has to be able to operate > > standalone or not. > > > > Hmm. Another option is to just move all these NULL/invalid edid > > checks into drm_edid_to_eld() and drm_add_display_info(). > > I was thinking about this. We can use a boolean variable: > =============== > bool edid_is_invalid; > > edid_is_invalid = !drm_edid_is_valid(edid); > > if (edid == NULL || edid_is_invalid) { > clear_eld(connector); > drm_reset_display_info(connector); > if (edid_is_invalid) > drm_warn(connector->dev, "%s: EDID invalid.\n", > connector->name); > return 0; > } > > drm_edid_to_eld(connector, edid); > ... > =============== > Internally, drm_edid_is_valid() handles NULL pointers properly. > It is a quite elegant solution with a small change in the original > design, and it improves this part in the way you pointed out. I'll send a patch with this idea and we can talk about the new code. Thanks! Best regards, Claudio Suarez. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DD71C433F5 for ; Sat, 16 Oct 2021 08:58:33 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EDA5C611AF for ; Sat, 16 Oct 2021 08:58:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EDA5C611AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=net-c.es Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6B9D66E42A; Sat, 16 Oct 2021 08:58:24 +0000 (UTC) Received: from msg-1.mailo.com (msg-1.mailo.com [213.182.54.11]) by gabe.freedesktop.org (Postfix) with ESMTPS id 844206E41B; Sat, 16 Oct 2021 08:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=net-c.es; s=mailo; t=1634374693; bh=9IL8gtMx9v+2OPAAge0RErzrh08ys/P7bdTcb4UTPyc=; h=X-EA-Auth:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; b=MoYnQZ5L6Ax0/fqJMIwGZCAaXd+RW/7hsqN7Ru2uyoWj8IQKyGyQt87jaZGxhKhF+ RctnOXYKQjlXfB+3BNI9Dje/aQ7GoBOvzDDIAWxFg8zcvim3fw5K1HxLeVx6jfxIbN RIizUInJ4bkCf1hQdJdE2jWovuRx5ozpyfFHXVEs= Received: by b-2.in.mailobj.net [192.168.90.12] with ESMTP via ip-206.mailobj.net [213.182.55.206] Sat, 16 Oct 2021 10:58:13 +0200 (CEST) X-EA-Auth: A5rfGmpIBDyFxLfMHpfhudehUSSxmDiQm2TxkL/eXbGqty570ZAWa8gGp3kSB+GyiaCfMVhAZa4NwN7QqTApIj+sGlxqqx7d Date: Sat, 16 Oct 2021 10:58:10 +0200 From: Claudio Suarez To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, linux-tegra@vger.kernel.org, intel-gfx@lists.freedesktop.org, David Airlie , Daniel Vetter , Laurent Pinchart , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , Pan Xinhui , Emma Anholt , Maxime Ripard , Thierry Reding , Patrik Jakobsson , Jingoo Han , Rob Clark , Sean Paul , linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, Chen-Yu Tsai , Sandy Huang , heiko@sntech.de, Neil Armstrong , Robert Foss , Ben Skeggs , nouveau@lists.freedesktop.org Message-ID: References: <20211015113713.630119-1-cssk@net-c.es> <20211015113713.630119-2-cssk@net-c.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Intel-gfx] [Freedreno] [PATCH 01/15] gpu/drm: make drm_add_edid_modes() consistent when updating connector->display_info X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Sat, Oct 16, 2021 at 10:25:03AM +0200, Claudio Suarez wrote: > On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote: > > On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote: > > > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote: > > > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote: > > > > > According to the documentation, drm_add_edid_modes > > > > > "... Also fills out the &drm_display_info structure and ELD in @connector > > > > > with any information which can be derived from the edid." > > > > > > > > > > drm_add_edid_modes accepts a struct edid *edid parameter which may have a > > > > > value or may be null. When it is not null, connector->display_info and > > > > > connector->eld are updated according to the edid. When edid=NULL, only > > > > > connector->eld is reset. Reset connector->display_info to be consistent > > > > > and accurate. > > > > > > > > > > Signed-off-by: Claudio Suarez > > > > > --- > > > > > drivers/gpu/drm/drm_edid.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > > > > index 6325877c5fd6..6cbe09b2357c 100644 > > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > > @@ -5358,10 +5358,12 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > > > > > > > > if (edid == NULL) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > return 0; > > > > > } > > > > > if (!drm_edid_is_valid(edid)) { > > > > > clear_eld(connector); > > > > > + drm_reset_display_info(connector); > > > > > > > > Looks easier if you pull both of those out from these branches and > > > > just call them unconditionally at the start. > > > > > > After looking at the full code, I am not sure. This is the code: > > > ================== > > > int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) > > > { > > > int num_modes = 0; > > > u32 quirks; > > > > > > if (edid == NULL) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > return 0; > > > } > > > if (!drm_edid_is_valid(edid)) { > > > clear_eld(connector); > > > drm_reset_display_info(connector); <--- added by me > > > drm_warn(connector->dev, "%s: EDID invalid.\n", > > > connector->name); > > > return 0; > > > } > > > > > > drm_edid_to_eld(connector, edid); > > > > > > quirks = drm_add_display_info(connector, edid); > > > etc... > > > ================= > > > > > > If we move those out of these branches and edid != NULL, we are executing an > > > unnecessary clear_eld(connector) and an unnecessary drm_reset_display_info(connector) > > > because the fields will be set in the next drm_edid_to_eld(connector, edid) and > > > drm_add_display_info(connector, edid) > > > > > > Do we want this ? > > > > Seems fine by me. And maybe we could nuke the second > > drm_reset_display_info() from deeper inside drm_add_display_info()? > > Not sure if drm_add_display_info() still has to be able to operate > > standalone or not. > > > > Hmm. Another option is to just move all these NULL/invalid edid > > checks into drm_edid_to_eld() and drm_add_display_info(). > > I was thinking about this. We can use a boolean variable: > =============== > bool edid_is_invalid; > > edid_is_invalid = !drm_edid_is_valid(edid); > > if (edid == NULL || edid_is_invalid) { > clear_eld(connector); > drm_reset_display_info(connector); > if (edid_is_invalid) > drm_warn(connector->dev, "%s: EDID invalid.\n", > connector->name); > return 0; > } > > drm_edid_to_eld(connector, edid); > ... > =============== > Internally, drm_edid_is_valid() handles NULL pointers properly. > It is a quite elegant solution with a small change in the original > design, and it improves this part in the way you pointed out. I'll send a patch with this idea and we can talk about the new code. Thanks! Best regards, Claudio Suarez.