From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ming Lei <ming.lei@canonical.com>
Cc: linux-kernel@vger.kernel.org, Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH v1 3/4] firmware loader: allow distribution to choose default search paths
Date: Thu, 6 Jun 2013 12:47:50 -0700 [thread overview]
Message-ID: <20130606194750.GA4526@kroah.com> (raw)
In-Reply-To: <1370520110-32293-4-git-send-email-ming.lei@canonical.com>
On Thu, Jun 06, 2013 at 08:01:49PM +0800, Ming Lei wrote:
> For some distributions(e.g. android), firmware images aren't put
> under kernel built-in search paths, so introduce one Kconfig
> option to allow distributions or users to choose its specific default
> search paths, which are always tried before searching from kernel
> built-in paths in direct loading.
>
> Also this patch introduces fw_get_fw_file_from_paths to cover all
> search paths, and fw_get_filesystem_firmware is simpified a bit.
>
> Cc: Takashi Iwai <tiwai@suse.de>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
> ---
> drivers/base/Kconfig | 14 ++++++++++
> drivers/base/firmware_class.c | 61 ++++++++++++++++++++++++++++++++++-------
> 2 files changed, 65 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 07abd9d..2be10e4 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -156,6 +156,20 @@ config FW_LOADER_USER_HELPER
> no longer required unless you have a special firmware file that
> resides in a non-standard path.
>
> +config FW_CUSTOMIZED_PATH
> + string "default firmware search paths for direct loading"
> + help
> + On some distribution(e.g. android), firmware images aren't
> + put under kernel built-in search paths, so provide this option
> + for distributions to choose a distribution specific firmware
> + search path. The option allows to choose more than one path,
> + and paths are seperated with colon like $PATH(e.g. on android,
> + the option might look as "/etc/firmware:/vendor/firmware").
> + Each path should be a absolute path, and relative path will be
> + ignored.
> +
> + If you are unsure about this, don't choose here.
> +
> config DEBUG_DRIVER
> bool "Driver Core verbose debug messages"
> depends on DEBUG_KERNEL
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 6ede229..051db83 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -265,8 +265,13 @@ static void fw_free_buf(struct firmware_buf *buf)
>
> /* direct firmware loading support */
> static char fw_path_para[256];
> +
> +/* search runtime paths first, then static pre-defined paths */
> static const char * const fw_path[] = {
> fw_path_para,
> +#ifdef CONFIG_FW_CUSTOMIZED_PATH
> + CONFIG_FW_CUSTOMIZED_PATH,
> +#endif
> "/lib/firmware/updates/" UTS_RELEASE,
> "/lib/firmware/updates",
> "/lib/firmware/" UTS_RELEASE,
> @@ -314,6 +319,50 @@ static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf
> return true;
> }
>
> +static bool fw_get_file_firmware(const char *path,
> + struct firmware_buf *buf)
> +{
> + struct file *file;
> + bool success;
> +
> + file = filp_open(path, O_RDONLY, 0);
> + if (IS_ERR(file))
> + return false;
> + success = fw_read_file_contents(file, buf);
> + fput(file);
> +
> + return success;
> +}
> +
> +/* The path in @paths is seperated by ';' */
No it isn't.
> +static bool fw_get_file_fw_from_paths(const char *paths, char *path,
> + struct firmware_buf *buf)
> +{
> + int len, start, end = -1;
> + char *pos;
> +
> + do {
> + start = end + 1;
> + pos = strchr(&paths[start], ':');
As you have an array of paths now, why are you doing the ':' check
still? Don't do that, just allow the person building the kernel to add
one path to the loader, that should be all that we need, right?
thanks,
greg k-h
next prev parent reply other threads:[~2013-06-06 19:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 12:01 [PATCH v1 0/4] firmware loader: cleanup and introduce search paths option Ming Lei
2013-06-06 12:01 ` [PATCH v1 1/4] firmware loader: don't export cache_firmware and uncache_firmware Ming Lei
2013-06-06 12:01 ` [PATCH v1 2/4] firmware loader: simplify holding module for request_firmware Ming Lei
2014-01-07 7:56 ` Dmitry Torokhov
2014-01-07 14:53 ` Ming Lei
2014-01-07 17:23 ` Dmitry Torokhov
2013-06-06 12:01 ` [PATCH v1 3/4] firmware loader: allow distribution to choose default search paths Ming Lei
2013-06-06 19:47 ` Greg Kroah-Hartman [this message]
2013-06-07 1:24 ` Ming Lei
2013-06-07 4:20 ` Greg Kroah-Hartman
2013-06-07 15:01 ` Ming Lei
2013-06-06 12:01 ` [RFC PATCH v1 4/4] firmware loader: don't allow to request firmware via relative path Ming Lei
2013-06-06 19:48 ` Greg Kroah-Hartman
2013-06-07 1:30 ` Ming Lei
2013-06-07 4:21 ` Greg Kroah-Hartman
2013-06-07 6:04 ` Takashi Iwai
2013-06-07 14:54 ` Ming Lei
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=20130606194750.GA4526@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=tiwai@suse.de \
/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