Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3144086pxb; Tue, 12 Oct 2021 23:04:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZYk/6k7pA+S1fwhNDHv5Z7okbf2bGPMKjtjslCIRZ3TWc5Bij86YJQwFQxLDFMqhWYUhR X-Received: by 2002:a05:6a00:230e:b0:44c:4f2d:9b00 with SMTP id h14-20020a056a00230e00b0044c4f2d9b00mr35591063pfh.24.1634105079716; Tue, 12 Oct 2021 23:04:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634105079; cv=none; d=google.com; s=arc-20160816; b=pdLKrrvfV2408Z69tyF+YTylKTOW/C1Mx50M3XSBsuKXaU6zBh0KeTNT5byoGS8Utd fKu1bO8OvKN5rCuYmE7JFlvFScUcdwSr/vj3PlVonyqSW9xyUAmafjj8Bjw4Wb7b4Us3 sSklwYE9oYRGKPfGHBg0Fj3+OHbG8iHwkqgz/mUSO16505u7eKN+niqWz/zdUOEs/FMT YbxP1cLsBOey23K2tU5emrkFf98Jx0FhDcvG/2ZXlakjNi3ByMKepiYc6N4CqSTwTjfo HuesbyjXmkg4ouO+xpzEMsXTjNnoIu+N2Na3qF30WI4J6E36tmS6lGmVnkeg9VA5bmDu Suqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rUEN95niWQqYL2gRu+u8I/SZBx+amo90JLng1i0FIVc=; b=HGzB8IzF6nQg4OAg7YLJs2qyiTBNaVlKFK6opDfRRJpJyCX3iSlDmNvEd87g3h5XvR /VgSBJJOeHmnLEI4qYfa3HQ9JmffrOxjbbLp6ddJ3k5zuOiXYTTYnxVnQTUvvf2YaSDK 2VIg4iUqZyMbv4zHfv6mEv+05r73/37kOrT9Q9YDuWDYBg/TsC7LZy7uTHKXaT+c13lS ppcQAOjYq3xlKibCzsH1i0iot2Rop1cVy8FFJRPPnsKrjxfTRnwlof8tI2p6aWNTISWy N4uaEo0DS8XBFXeMS8wooCxko82Jaka+41P1Odht8xFmuYeUTQLI6f91gwHT1j4W40tI YvRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r2si6540455pjr.143.2021.10.12.23.04.24; Tue, 12 Oct 2021 23:04:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237828AbhJMGFC (ORCPT + 99 others); Wed, 13 Oct 2021 02:05:02 -0400 Received: from honk.sigxcpu.org ([24.134.29.49]:50634 "EHLO honk.sigxcpu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbhJMGFB (ORCPT ); Wed, 13 Oct 2021 02:05:01 -0400 Received: from localhost (localhost [127.0.0.1]) by honk.sigxcpu.org (Postfix) with ESMTP id A9626FB03; Wed, 13 Oct 2021 08:02:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at honk.sigxcpu.org Received: from honk.sigxcpu.org ([127.0.0.1]) by localhost (honk.sigxcpu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66EE4GbhLCIQ; Wed, 13 Oct 2021 08:02:55 +0200 (CEST) Date: Wed, 13 Oct 2021 08:02:54 +0200 From: Guido =?iso-8859-1?Q?G=FCnther?= To: Laurent Pinchart Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Jyri Sarha , Tomi Valkeinen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm/bridge: Ignore -EPROBE_DEFER when bridge attach fails Message-ID: References: <00493cc61d1443dab1c131c46c5890f95f6f9b25.1634068657.git.agx@sigxcpu.org> 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-kernel@vger.kernel.org Hi, On Tue, Oct 12, 2021 at 10:47:14PM +0200, Guido G?nther wrote: > Hi Laurent, > On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote: > > Hi Guido, > > > > Thank you for the patch. > > > > On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido G?nther wrote: > > > Otherwise logs are filled with > > > > > > [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@30800000/mipi-dsi@30a0 0000 to encoder None-34: -517 > > > > > > when the bridge isn't ready yet. > > > > > > Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge attach fails") > > > Signed-off-by: Guido G?nther > > > --- > > > drivers/gpu/drm/drm_bridge.c | 11 ++++++----- > > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > > > index a8ed66751c2d..f0508e85ae98 100644 > > > --- a/drivers/gpu/drm/drm_bridge.c > > > +++ b/drivers/gpu/drm/drm_bridge.c > > > @@ -227,14 +227,15 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, > > > bridge->encoder = NULL; > > > list_del(&bridge->chain_node); > > > > > > + if (ret != -EPROBE_DEFER) { > > > #ifdef CONFIG_OF > > > - DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n", > > > - bridge->of_node, encoder->name, ret); > > > + DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n", > > > + bridge->of_node, encoder->name, ret); > > > #else > > > - DRM_ERROR("failed to attach bridge to encoder %s: %d\n", > > > - encoder->name, ret); > > > + DRM_ERROR("failed to attach bridge to encoder %s: %d\n", > > > + encoder->name, ret); > > > #endif > > > - > > > + } > > > > This looks fine as such, but I'm concerned about the direction it's > > taking. Ideally, probe deferral should happen at probe time, way before > > the bridge is attached. Doing otherwise is a step in the wrong direction > > in my opinion, and something we'll end up regretting when we'll feel the > > pain it inflicts. > > The particular case I'm seeing this is the nwl driver probe deferrals if > the panel bridge isn't ready (which needs a bunch of components > (dsi, panel, backlight wrapped led, ...) and it probes fine later on so I > wonder where you see the actual error cause? That downstream of the > bridge isn't ready or that the display controller is already attaching > the bridge? I should add that mxsfb does a `dev_err_probe()` already when checking the return value of `drm_bridge_attach()` so the error printed is triggered by the additional check added in the above function while the code path already ignored -EPROBE_DEFER before. This looks sensible to me since upper layers can't known when all the downstream bridges are done probing or am I missing something? Cheers, -- Guido > > Cheers, > -- Guido > > > > > > return ret; > > > } > > > EXPORT_SYMBOL(drm_bridge_attach); > > > > -- > > Regards, > > > > Laurent Pinchart > >