Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2169692yba; Thu, 25 Apr 2019 11:46:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqxozwB61gTX2+a6qqWJBuzyWKbu+5+FWZ6vNZCqW58TFrb4jePTytEPjvHn935c8Mn0owaL X-Received: by 2002:aa7:8392:: with SMTP id u18mr43202397pfm.217.1556218002168; Thu, 25 Apr 2019 11:46:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556218002; cv=none; d=google.com; s=arc-20160816; b=RSA1ZGXmKga7SEvnfAUs92X7NeeAMyuE3kH+fkmZiXj1i58yyYdj3Ynl3eJoMjP3kE ZkU7iNALiVsfXj0FH2jWDPtYGy3zaxRfOzmUxjn25Qz1vssLFc+aYoNx/1o2OWfC32rT 0iiSSvhFWnshJhU1J3uw75ST8waTXQkTdFSIlKWew281GWKqF4RTIr/llO7pyPZoz3l1 TL4JtB9YnTIP6qvirKCBO4yKVeuna0shChh6sOvcth5o+DCyxGaQr+V12xbRrb1DM1il Fe3Zi/EBaVertbveoRjwEd/qVvcvX3t6/PIC2yJUyIDkS3IzHOhJtrkO9Z3WC+5vGZ5g 2Gvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=IrBUdIrVIOUCScFtCp7bAmVR0nUwTmO4GV6VmSS/774=; b=RyeetWr52Gm90e7AJF/V3etOm7OYW59BqObnkb7Tk21n5//dXYthiJd6joyap/rphG oU0Imvymv4C2l+vwzDhUHl5e3SyXmUCmMNHJ1k9gqTfE9deEtD0NmWZ1liNJpDtwR84E 9Ca+lB+BgwJ/BHuAPyMEwMMCLJ9AYOzLbEGLC7vUcH1bZ2ek8SGr4/XHa5ygzCDwSXFL pWj54Zvg3aq4lVhfyS7qxuUdz+nosI0cKzasEf8fxsN3cgDVnQl5AZRYrOZTqtRYg9Et 2FO39B5zSw5d31tNaJ2Yj/xs3joDxbZEFPAttiB4tOzcNoxEXEkAb2Ny9r/xg/6+4crJ X7GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pgzroVIN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1si24530799pld.280.2019.04.25.11.46.27; Thu, 25 Apr 2019 11:46:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pgzroVIN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729885AbfDYR73 (ORCPT + 99 others); Thu, 25 Apr 2019 13:59:29 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:38406 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726199AbfDYR73 (ORCPT ); Thu, 25 Apr 2019 13:59:29 -0400 Received: from pendragon.ideasonboard.com (net-37-182-44-227.cust.vodafonedsl.it [37.182.44.227]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 081ED5F; Thu, 25 Apr 2019 19:59:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1556215166; bh=hMFo5LJYIOc8aE3CjuyJzgdqYSZukamjRh8Gh+GQLTs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pgzroVINvUiav+qSFs90cB9UWPLN0i0yHXrfq45IUZkgFXdOIJ1fktOj7Ex1NvLrR sWHszVmyxVFl9D7kkoO2fOgmfa7yMp1ckg6lbfahKs8zpHvIVV0MmDSOjuY0SRyO+z ZixZc1lAwaeVJbPLi45MSaPJliN00KSPMZlEoRio= Date: Thu, 25 Apr 2019 20:59:15 +0300 From: Laurent Pinchart To: Matt Redfearn Cc: Andrzej Hajda , Philippe Cornu , "dri-devel@lists.freedesktop.org" , Matthew Redfearn , Nickey Yang , Heiko Stuebner , Archit Taneja , "linux-kernel@vger.kernel.org" , David Airlie , Daniel Vetter Subject: Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable Message-ID: <20190425175915.GB12024@pendragon.ideasonboard.com> References: <20190424142148.25927-1-matt.redfearn@thinci.com> <3da4c0a3-a77b-5128-63f7-9c8d6b012c68@samsung.com> <95c36782-7eaf-2224-bb52-cff0a53d98d8@thinci.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <95c36782-7eaf-2224-bb52-cff0a53d98d8@thinci.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Matt, On Thu, Apr 25, 2019 at 12:39:27PM +0000, Matt Redfearn wrote: > On 25/04/2019 13:13, Andrzej Hajda wrote: > > On 24.04.2019 16:22, Matt Redfearn wrote: > >> The DRM documentation states that post_disable is an optional callback. > >> As such an implementing device may not populate it. To avoid panicing > >> the kernel by calling a NULL function pointer, we should NULL check it > >> before blindy calling it. > >> > >> Signed-off-by: Matt Redfearn > > > >> --- > >> > >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> index 38e88071363..0ee440216b8 100644 > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct drm_bridge *bridge) > >> * This needs to be fixed in the drm_bridge framework and the API > >> * needs to be updated to manage our own call chains... > >> */ > >> - dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge); > >> + if (dsi->panel_bridge->funcs->post_disable) > >> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge); > >> > > > > Why not drm_bridge_post_disable ? > > Ah - that seems like a nicer fix! Do you think the comment above > describing why this function pointer is called directly can be removed > as well if we go this route? It shouldn't be necessary to call ->post_disable manually here as the bridge core handles it internally. This is a hack to work around a problem, and should be fixed properly. > If someone calls drm_bridge_post_disable() on the Synposys DSI > drm_bridge it will go on to call post_disable on all other bridges in > the chain, in addition to us calling them here. Is it an issue to call > it multiple times? It depends on the panel implementation, but in general it's not a good idea. It may happen to work, but could break at any time in the future. > >> if (dsi->slave) { > >> dw_mipi_dsi_disable(dsi->slave); -- Regards, Laurent Pinchart