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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 63840C433EF for ; Fri, 21 Jan 2022 13:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=R4EQP/4ZW3bUtnl+ouRiPz5FrzteHkJBcguT+ICu4DU=; b=hQuuNFeWFuZJH/ RLuzDockTxClW/4L/XvWDlCnSDF7riOJIBirQlkIkxEKFbnsFXTWl1h2NnC53nqZR36mNYNyZ1WMH AOKqAWgslejA5RJYWZfRTlsrfSdHANAWctHkNtb11aqzAXj9AZpwuw/pBdXRGR3kOWhUdgDvULx2D IZCDwxfdBYJAXAU5iYE0iBBE0l90PHeHPgLMZKPe+fVXTIwoW+r2AibIcmXwYVEfgytp2GEo7BM0y yBqO/A4MEdQGiT4sWTjcf7zKNyt2iLlk2X7l44Fn38p7nY1Ed5XwzB0KuabQ1qvf8aszlz3DyH936 2MeLAcE0qQrWFnr7GS3g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAtue-00F8dH-Aj; Fri, 21 Jan 2022 13:25:10 +0000 Received: from mx1.tq-group.com ([93.104.207.81]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAtuV-00F8Zh-LD for linux-arm-kernel@lists.infradead.org; Fri, 21 Jan 2022 13:25:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1642771499; x=1674307499; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=b1ZjZfJWEv5qfjNd/5rN2kL2/2EdJgPINvco89nSHpA=; b=HPigm0xm3YvmD+XI8civ3XsRHjIBcRC15I0FZjHL5XGX6QBgI3INX8ti 603KN5/u3uzzsov7TP7rcY0dvRZg4+RuyPJbrpKbl37TCw+VcEaCFXM3v s7mfQor9AVFNswCkVtpdJ8Kr5Wu2SzXt4NHdiKJ9Yr3dT6pXtiS9VItr/ mqx6mIN8NvlKlSfbE/KgcJ+vSrg0mp0xO+9YKmO0NUJgybRuV6Dj0RXz9 DI8ZahXLGtbR6Cn1Z/edeYp0Ou2IYju5naUK/59OvQV0Wcf3EAIkaTbjD RQgaY2Q0yYkrulclOLDIYTVTWoQduxZ6t3gvUG+g/xNp66Pu3+v92NvtE A==; X-IronPort-AV: E=Sophos;i="5.88,304,1635199200"; d="scan'208";a="21641031" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 21 Jan 2022 14:24:57 +0100 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Fri, 21 Jan 2022 14:24:57 +0100 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Fri, 21 Jan 2022 14:24:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1642771497; x=1674307497; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=b1ZjZfJWEv5qfjNd/5rN2kL2/2EdJgPINvco89nSHpA=; b=pcfLDM/dNDghkg4x3qfQWqErVCbjMJkiAsCJiUBgWzNb5HpVOPloYp+H Xoep8bRbeeEMyl3/ZX0Swu2IWmkPnymSP/tggLFITwoAL64g+D5IaID5Z RD9g7vUmbhYZTCzqVLGMuit+dJxyUddNWJsOcwDQrnfYF+GW/ZSAPQLPX VnV/ACml6MMJXkobn6Mr8gu0GbHC8yNeHNntpRs/bQwxP4WUnQx3q6UZC l0k2NgZSrEd5bFLGzgCLK31NNCwMbLfpef6H1RnKnA29yidkP0Uhcba64 eEHxqdnC56SmUiX/aCd3nmQulDpOxHJydFjf2k2idSJH0qMVQDeegllc4 g==; X-IronPort-AV: E=Sophos;i="5.88,304,1635199200"; d="scan'208";a="21641030" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 21 Jan 2022 14:24:57 +0100 Received: from steina-w.localnet (unknown [10.123.49.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vtuxmail01.tq-net.de (Postfix) with ESMTPSA id 6D2AF280065; Fri, 21 Jan 2022 14:24:57 +0100 (CET) From: Alexander Stein To: Stefan Agner , David Airlie , Daniel Vetter , Shawn Guo , Sascha Hauer , Fabio Estevam , Laurent Pinchart , Marek Vasut Cc: linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org Subject: Re: (EXT) Re: [PATCH 1/1] drm: mxsfb: Fix NULL pointer dereference Date: Fri, 21 Jan 2022 14:24:57 +0100 Message-ID: <2361278.ElGaqSPkdT@steina-w> Organization: TQ-Systems GmbH In-Reply-To: <4d3654b5-9a87-1c02-f2d9-d0974e628c20@denx.de> References: <20220121131238.507567-1-alexander.stein@ew.tq-group.com> <4d3654b5-9a87-1c02-f2d9-d0974e628c20@denx.de> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220121_052500_103565_FE8040BD X-CRM114-Status: GOOD ( 26.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut: > On 1/21/22 14:12, Alexander Stein wrote: > > Do not deference the NULL pointer if the bridge does not return a > > bridge state. Assume a fixed format instead. > > > > Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest > > bridge if present") Signed-off-by: Alexander Stein > > > > --- > > This can happen if a "ti,sn75lvds83", "lvds-encoder" bridge is attached > > to it. atomic_get_input_bus_fmts is only implemented for the > > lvds-decoder case. > > > > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 0655582ae8ed..4cfb6c001679 > > 100644 > > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c > > @@ -361,7 +361,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc > > *crtc,> > > bridge_state = > > > > drm_atomic_get_new_bridge_state(state, > > > > mxsfb->bridge); > > > > - bus_format = bridge_state->input_bus_cfg.format; > > + if (!bridge_state) > > + bus_format = MEDIA_BUS_FMT_FIXED; > > + else > > + bus_format = bridge_state- >input_bus_cfg.format; > > + > > > > if (bus_format == MEDIA_BUS_FMT_FIXED) { > > > > dev_warn_once(drm->dev, > > > > "Bridge does not provide bus format, assuming > > MEDIA_BUS_FMT_RGB888_1X24. \n" > > Shouldn't this be fixed on the bridge driver side instead ? > > Which bridge driver do you use ? It's drivers/gpu/drm/bridge/lvds-codec.c. I thought naming the compatibles would suffice. I consider a patch for the bridge driver as a separate issue, hence the warning from mxsfb. Although I'm unsure how/what to implement. Similar to the encode case where the bus format is specified in DT? Anyway, mxsfb should not never dereference the NULL pointer which drm_atomic_get_new_bridge_state is allowed to return. Best regards, Alexander _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel