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
Date: Fri, 8 Dec 2023 16:55:48 +0200 [thread overview]
Message-ID: <ZXMudF++A9/y4TNk@kuha.fi.intel.com> (raw)
In-Reply-To: <20231207-tps6598x_update-v1-2-dc21b5301d91@wolfvision.net>
Hi Javier,
On Thu, Dec 07, 2023 at 12:51:07PM +0100, Javier Carrasco wrote:
> The firmware request process is device agnostic and can be used for
> other parts.
>
> A probe deferring mechanism has been added in order to account for cases
> where the file system where the firmware resides is still not available
> when the probe function is triggered and no firmware is found.
>
> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
> ---
> drivers/usb/typec/tipd/core.c | 36 +++++++++++++++++++++++++++---------
> 1 file changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
> index f0c4cd571a37..165a1391dc72 100644
> --- a/drivers/usb/typec/tipd/core.c
> +++ b/drivers/usb/typec/tipd/core.c
> @@ -873,6 +873,31 @@ tps6598x_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode)
> return 0;
> }
>
> +static int tps_request_firmware(struct tps6598x *tps, const struct firmware **fw)
> +{
> + const char *firmware_name;
> + int ret;
> +
> + ret = device_property_read_string(tps->dev, "firmware-name",
> + &firmware_name);
> + if (ret)
> + return ret;
> +
> + 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);
> + }
> +
> + if ((*fw)->size == 0) {
> + release_firmware(*fw);
> + ret = -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> static int
> tps25750_write_firmware(struct tps6598x *tps,
> u8 bpms_addr, const u8 *data, size_t len)
> @@ -961,16 +986,9 @@ static int tps25750_start_patch_burst_mode(struct tps6598x *tps)
> if (ret)
> return ret;
>
> - ret = request_firmware(&fw, firmware_name, tps->dev);
> - if (ret) {
> - dev_err(tps->dev, "failed to retrieve \"%s\"\n", firmware_name);
> + ret = tps_request_firmware(tps, &fw);
> + if (ret)
> return ret;
> - }
> -
> - if (fw->size == 0) {
> - ret = -EINVAL;
> - goto release_fw;
> - }
>
> ret = of_property_match_string(np, "reg-names", "patch-address");
> if (ret < 0) {
>
> --
> 2.39.2
thanks,
--
heikki
next prev parent reply other threads:[~2023-12-08 14:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 11:51 [PATCH 0/4] usb: typec: tipd: add patch update support for tps6598x Javier Carrasco
2023-12-07 11:51 ` [PATCH 1/4] usb: typec: tipd: add init and reset functions to tipd_data Javier Carrasco
2023-12-07 11:51 ` [PATCH 2/4] usb: typec: tipd: add function to request firmware Javier Carrasco
2023-12-08 14:55 ` Heikki Krogerus [this message]
2023-12-08 18:58 ` Javier Carrasco
2023-12-12 14:15 ` Heikki Krogerus
2023-12-12 14:41 ` Javier Carrasco
2023-12-13 15:15 ` Heikki Krogerus
2023-12-13 15:32 ` Javier Carrasco
2023-12-07 11:51 ` [PATCH 3/4] usb: typec: tipd: declare in_data in as const in exec_cmd functions Javier Carrasco
2023-12-07 11:51 ` [PATCH 4/4] usb: typec: tipd: add patch update support for tps6598x Javier Carrasco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZXMudF++A9/y4TNk@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=javier.carrasco@wolfvision.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox