All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Kalle Valo <kvalo@codeaurora.org>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Andres Rodriguez <andresx7@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] firmware: add a function to load optional firmware v2
Date: Wed, 14 Mar 2018 09:24:09 +0100	[thread overview]
Message-ID: <5AA8DC29.2000806@broadcom.com> (raw)
In-Reply-To: <87fu53apod.fsf@kamboji.qca.qualcomm.com>

On 3/13/2018 5:46 PM, Kalle Valo wrote:
> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>
>> On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote:
>>> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>>>
>>>>> +/**
>>>>> + * request_firmware_optional: - request for an optional fw module
>>>>> + * @firmware_p: pointer to firmware image
>>>>> + * @name: name of firmware file
>>>>> + * @device: device for which firmware is being loaded
>>>>> + *
>>>>> + * This function is similar in behaviour to request_firmware(), except
>>>>> + * it doesn't produce warning messages when the file is not found.
>>>>> + **/
>>>>> +int
>>>>> +request_firmware_optional(const struct firmware **firmware_p, const char *name,
>>>>> +                         struct device *device)
>>>>> +{
>>>>> +       int ret;
>>>>> +
>>>>> +       /* Need to pin this module until return */
>>>>> +       __module_get(THIS_MODULE);
>>>>> +               ret = _request_firmware(firmware_p, name, device, NULL, 0,
>>>>> +                               FW_OPT_UEVENT | FW_OPT_NO_WARN );
>>>>> +       module_put(THIS_MODULE);
>>>>> +       return ret;
>>>>> +}
>>>>> +EXPORT_SYMBOL(request_firmware_optional);
>>>>
>>>> New exported symbols for the firmware API should be EXPORT_SYMBOL_GPL().
>>>
>>> To me the word optional feels weird to me. For example, in ath10k I
>>> suspect we would be only calling request_firmware_optional() with all
>>> firmware and not request_firmware() at all.
>>>
>>> How about request_firmware_nowarn()? That would even match the
>>> documentation above.
>>
>> _nowarn() works with me. Do you at least want the return value to give
>> an error value if no file was found? This way the driver can decide
>> when to issue an error if it wants to.
>
> Yes, it would be very good to return the error value to ath10k. That way
> we can give a proper error message to the user if we can't find a
> suitable firmware image.

I fully agree with the _nowarn() and returning an error. However, the 
firmware_p parameter (btw. do we really want the _p postfix?) is an 
output parameter which will be null in case of an error so do you really 
need a specific error code for the proper error message.

Regards,
Arend

  reply	other threads:[~2018-03-14  8:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-09 22:12 [RFC 0/1] Loading optional firmware Andres Rodriguez
2018-03-09 22:12 ` [PATCH 1/1] firmware: add a function to load " Andres Rodriguez
2018-03-09 23:09   ` [PATCH] firmware: add a function to load optional firmware v2 Andres Rodriguez
2018-03-10 14:35     ` Luis R. Rodriguez
2018-03-10 14:40       ` Luis R. Rodriguez
2018-03-11 16:05         ` Andres Rodriguez
2018-03-11 23:10           ` Arend van Spriel
2018-03-12 19:27             ` Luis R. Rodriguez
2018-03-13 13:39               ` Kalle Valo
2018-03-13 16:25                 ` Andres Rodriguez
2018-03-13 16:38                 ` Luis R. Rodriguez
2018-03-20  2:21                   ` Andres Rodriguez
2018-03-13 13:35             ` Kalle Valo
2018-03-13 13:16       ` Kalle Valo
2018-03-13 16:40         ` Luis R. Rodriguez
2018-03-13 16:42           ` Andres Rodriguez
2018-03-13 16:46           ` Kalle Valo
2018-03-14  8:24             ` Arend van Spriel [this message]
2018-03-14  8:48               ` Kalle Valo
2018-03-11 23:18     ` Arend van Spriel
2018-03-10 14:18 ` [RFC 0/1] Loading optional firmware Luis R. Rodriguez

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=5AA8DC29.2000806@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=andresx7@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@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.