Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Luck, Tony" <tony.luck@intel.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        "hdegoede@redhat.com" <hdegoede@redhat.com>,
        "markgross@kernel.org" <markgross@kernel.org>
CC:     "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "andriy.shevchenko@linux.intel.com" 
        <andriy.shevchenko@linux.intel.com>,
        "Joseph, Jithu" <jithu.joseph@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>
Subject: RE: [PATCH v5 04/10] platform/x86/intel/ifs: Read IFS firmware image
Thread-Topic: [PATCH v5 04/10] platform/x86/intel/ifs: Read IFS firmware image
Thread-Index: AQHYWxYW3hJGAbUOoU6LIs4KNS99IK0PBS8A///rt6A=
Date:   Wed, 4 May 2022 16:49:07 +0000
Message-ID: <f36faedeb6144ba491d1fda27e6bfaaa@intel.com>
References: <20220422200219.2843823-1-tony.luck@intel.com>
 <20220428153849.295779-1-tony.luck@intel.com>
 <20220428153849.295779-5-tony.luck@intel.com> <87wnf1k2gv.ffs@tglx>
In-Reply-To: <87wnf1k2gv.ffs@tglx>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.6.401.20
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

>> +	ret =3D request_firmware_direct(&fw, scan_path, dev);
>> +	if (ret) {
>> +		dev_err(dev, "ifs file %s load failed\n", scan_path);
>> +		return;
>
> Why is this not returning an error to the caller?

There are three call sequences that lead here:

1) CONFIG_INTEL_IFS=3Dy
    At boot this is pretty much guaranteed to fail (unless some crazy perso=
n includes the
   scan file in the initramfs). In this case there isn't a useful caller to=
 return the code to.
   In this case the driver init routine must ignore any error to make sure =
the sysfs reload
   file is present to load the scan file once the file system is available.

2) CONFIG_INTEL_IFS=3Dm module load time
    Same code path as built-in ... so must ignore a failed load here too (u=
nless there is a
    way to distinguish the built-in vs. module execution environment).

3) echo 1 > reload
    Hmmm. Some older revision did return an error ... but I seem to have fa=
ctored it out
   during cleanups. Limited to standard -E???? error codes. The reload_stor=
e() function
   can just check whether the load succeeded by looking at ifsd->loaded ins=
tead of a
   return value from ifs_load_firmware()

So, I will fix case 3. But probably by checking ifsd->loaded rather than by=
 adding a return
code to this function.

-Tony