Received: by 10.192.165.148 with SMTP id m20csp141936imm; Thu, 3 May 2018 16:43:08 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpXDqr0EOa3JNrdXQgfMgUR+VYp4CFigRMJK3OKRceb0104+lpHwM1VMThGiaVNS5mvIiNe X-Received: by 2002:a63:7945:: with SMTP id u66-v6mr20424741pgc.376.1525390988285; Thu, 03 May 2018 16:43:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525390988; cv=none; d=google.com; s=arc-20160816; b=wsb1wj5vonuqXpz6bK5TaRAz2rtdj/w199tDyMuzs8kcHKzC+rgYH21o1T8L0cN2F3 fgk65KBtyEhJEBHmdVq/Yna9vyME0e9RnKrX5Qb4+1JOZMWicmv9cJEFhgNqWs4CAvGx mv1YSu4+Eteunulfn8/PXTI6HRKCn//rhCkRUvEZaCXe8i/1eeB/aDMM42c/PCLCCYSS rv54qy2KVcIh0q0WuZBbEvTCmCbwu6llfIufB5yaxnPm/kGe6/Hntx3JVLgEKq6DCS9I g1pv94NXRKUFJtrX1kVErQyUxWyEJiRl9GuGgpasvoGZMWheACrIPp7ExxOoFxXg10pR 3Q+w== 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:arc-authentication-results; bh=/o6LFbcG1q7jiH+VHd0/PBT5kQkRRJ+KCC4bk8Owj0w=; b=1F9W7HlPcrtR9vk1q/R59F8Spda4tF29usohsdXZL/79sEbqjioATLmj9wPu1hjtdq gs0y4Lftc2JtL8Fx0Jco18KQX1jfga7lbIKUroEru03HWGUP4eplEUPdTIehijwowJC8 axkm8lBc+EH2R7GANY1jCQWKDukk2hjQoliE7vmN2Akk0zX+QIu1TN0PnvL/WX1/GEym h0zDFEKrPZnG+Lx4tH8uV06wN/lZvbQYybPzmClSHOf5BI0sVfp5iZfcXBcflypbxG9c JJkTU6cCB4A9IGcN8VMLB0QQc1ZtHLGqNUb2zsjQn6Z7OfDMvg2DCeTkVgmdL5S6HbGx gC5g== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g15-v6si12102524pgp.168.2018.05.03.16.42.54; Thu, 03 May 2018 16:43:08 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751308AbeECXmj (ORCPT + 99 others); Thu, 3 May 2018 19:42:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:60197 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbeECXmh (ORCPT ); Thu, 3 May 2018 19:42:37 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 47E31AD44; Thu, 3 May 2018 23:42:36 +0000 (UTC) Date: Thu, 3 May 2018 23:42:35 +0000 From: "Luis R. Rodriguez" To: Andres Rodriguez Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, mcgrof@kernel.org, alexdeucher@gmail.com, christian.koenig@amd.com, kvalo@codeaurora.org, arend.vanspriel@broadcom.com, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, hdegoede@redhat.com, Kees Cook , Mimi Zohar Subject: Re: [PATCH 6/9] firmware: print firmware name on fallback path Message-ID: <20180503234235.GX27853@wotan.suse.de> References: <20180423201205.20533-1-andresx7@gmail.com> <20180423201205.20533-7-andresx7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180423201205.20533-7-andresx7@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 23, 2018 at 04:12:02PM -0400, Andres Rodriguez wrote: > Previously, one could assume the firmware name from the preceding > message: "Direct firmware load for {name} failed with error %d". > > However, with the new firmware_request_nowarn() entrypoint, the message > outlined above will not always be printed. I though the whole point was to not print an error message. What if we want later to disable this error message? This would prove a bit pointless. Let's discuss the exact semantics desired here. Why would only the fallback be desirable here? Andres, Kalle? After we address this I'll address resubmitting this lat patch along with the last one. For now I'll skip it. Luis > Therefore, we add the firmware name to the fallback path spew in order > to associate it with the appropriate request. > > Signed-off-by: Andres Rodriguez > --- > drivers/base/firmware_loader/fallback.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c > index e75928458489..1a47ddc70c31 100644 > --- a/drivers/base/firmware_loader/fallback.c > +++ b/drivers/base/firmware_loader/fallback.c > @@ -669,6 +669,6 @@ int fw_sysfs_fallback(struct firmware *fw, const char *name, > if (!fw_run_sysfs_fallback(opt_flags)) > return ret; > > - dev_warn(device, "Falling back to user helper\n"); > + dev_warn(device, "Falling back to user helper for %s\n", name); > return fw_load_from_user_helper(fw, name, device, opt_flags); > } > -- > 2.14.1 > > -- Do not panic