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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.