Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Date:   Tue, 12 Dec 2023 16:15:24 +0200
From:   Heikki Krogerus <heikki.krogerus@linux.intel.com>
To:     Javier Carrasco <javier.carrasco@wolfvision.net>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] usb: typec: tipd: add function to request firmware
Message-ID: <ZXhq/IJp9KVCkQYb@kuha.fi.intel.com>
References: <20231207-tps6598x_update-v1-0-dc21b5301d91@wolfvision.net>
 <20231207-tps6598x_update-v1-2-dc21b5301d91@wolfvision.net>
 <ZXMudF++A9/y4TNk@kuha.fi.intel.com>
 <196acb44-fb0d-45b6-a9c3-b5a289a41917@wolfvision.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <196acb44-fb0d-45b6-a9c3-b5a289a41917@wolfvision.net>
Precedence: bulk

Hi,

On Fri, Dec 08, 2023 at 07:58:52PM +0100, Javier Carrasco wrote:
> Hi Heikki,
> 
> On 08.12.23 15:55, Heikki Krogerus wrote:
> 
> >> +	ret = request_firmware(fw, firmware_name, tps->dev);
> >> +	if (ret) {
> >> +		dev_err(tps->dev, "failed to retrieve \"%s\"\n", firmware_name);
> >> +		/* probe deferring in case the file system is not ready */
> >> +		return (ret == -ENOENT) ? -EPROBE_DEFER : ret;
> > 
> > It's more likely that the firmware really isn't available, and it will
> > never be available in this case. I think there is only one place in
> > kernel where failing request_firmware() can lead to deferred probe
> > (drivers/tee/optee/smc_abi.c) and there the code can actually see the
> > system state - that's actually the condition.
> > 
> > So just return dev_err_probe() here:
> > 
> > 	ret = request_firmware(fw, firmware_name, tps->dev);
> > 	if (ret)
> >                 return dev_err_probe(tps->dev, ret, "failed to retrieve \"%s\"", firmware_name);
> > 
> Thank you for your feedback.
> 
> This solution arose from a real use case: in the system I am using to
> test the tps65987d, the filesystem is not ready when the probe function
> is called. If I just return on -ENOENT, the device will never get the
> update.

Just like all the other devices that require firmware. This driver is
no different from the others, and it is also not the only one that
needs the firmware only in special cases. Just make the firmware part
of your ramdisk, or build the driver as a module.

Are these firmwares available linux-firmware (or are the going to be)?
https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git

thanks,

-- 
heikki