On Wed, Feb 15, 2017 at 11:29:47PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Thu, Feb 16, 2017 at 08:26:35AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> >
> > a) just remove the print and use instead request_module_nowait() (this is
> > more in alignment of what your code actually does today; or
> >
> > b) fix the request_module() use so that the error print matches the
> > exp
On Tue, Feb 21, 2017 at 10:47:53AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> > >
> > > a) just remove the print and use instead request_module_nowait() (this is
> > > more in alignment of what you
On Tue, Feb 21, 2017 at 09:17:15PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> > On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> > > >
> > > > a) just remove the print and use inst
rt is actually the more common path. The other path,
from the async callback is rathe rare (1/8 or so times for me) --
it happens when the the opmode driver's init routine completed
prior to the driver's async callback opmode start call.
Signed-off-by: Luis R. Rodriguez
---
drivers/net
will return immediately
without failure.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
b/drivers/net/wireless/intel/iwlwif
This lets us offload and share all the final opmode related work
necessary for either an opmode driver or new device. This has the most
impact for opmode drivers as this now offloads opmode start for each
device onto the workqueue.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel
The firmware async callback and the opmode registration share
some functionality -- to start the drv's opmode. Move this work
into a helper which is shared. This should help us share fixes
should these diverging code paths change.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/
) + 5.1916s (initrd) + 10.8968s
(userspace) = 18.7036s
After these patches:
Startup finished in 2.5468s (kernel) + 4.9536s (initrd) + 10.798s
(userspace) = 18.2994s
Luis R. Rodriguez (2):
iwlwifi: share opmode start work code
iwlwifi: convert final opmode work into a workqueue
drivers/net
effort to load suffices and keeps the driver cleaner.
There no change to the first patch. The second patch just embraces
request_module_nowait() instead of implementing a verifier for a sync
call. The remaining patches from the last series will be sent separately.
Luis R. Rodriguez (2):
iwlwifi: fix
On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote:
> On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> > Luis: would you ack this patch now I followed your guidance?
>
> It's up to Luis now :)
I'm reviewing now!
Luis
On Fri, Mar 17, 2017 at 06:29:36PM +0100, Luis R. Rodriguez wrote:
> On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote:
> > On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> > > Luis: would you ack this patch now I followed your guidance?
> >
On Tue, Apr 11, 2017 at 10:53:57AM +0200, Hans de Goede wrote:
> Hi,
>
> On 10-04-17 23:50, Arend Van Spriel wrote:
> > On 8-4-2017 11:53, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 07-04-17 23:43, Arend Van Spriel wrote:
> > > >
> > > >
> > > > On 6-4-2017 14:14, Hans de Goede wrote:
> > >
On Fri, Apr 07, 2017 at 11:43:04PM +0200, Arend Van Spriel wrote:
> On 6-4-2017 14:14, Hans de Goede wrote:
> > Luis, do you think it would be a good idea to add
> > .optional_postfix member to driver_data_req_params
> > for this? I believe other sdio based wifi devices
> > may want to do the same,
On Wed, May 03, 2017 at 09:02:20PM +0200, Arend Van Spriel wrote:
> On 3-1-2017 18:59, Luis R. Rodriguez wrote:
> > On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote:
> >>
> >> Right question is "should we solve it without user-space help"?
> &g
On Fri, May 12, 2017 at 11:02:26PM +0200, Arend Van Spriel wrote:
> try again.. replacing email address from Michał
> On 12-5-2017 22:55, Arend Van Spriel wrote:
> > Let me explain the idea to refresh your memory (and mine). It started
> > when we were working on adding driver support for OpenWrt i
On Tue, May 16, 2017 at 10:41:08AM +0200, Arend Van Spriel wrote:
> On 16-5-2017 1:13, Luis R. Rodriguez wrote:
> > On Fri, May 12, 2017 at 11:02:26PM +0200, Arend Van Spriel wrote:
> >> try again.. replacing email address from Michał
> >> On 12-5-2017 22:55, Arend Van
On Mon, Feb 19, 2018 at 05:01:27PM +0200, cantabile wrote:
> On 19/02/18 07:55, Jakub Kicinski wrote:
> > On Sat, 17 Feb 2018 13:23:29 +0200, cantabile wrote:
> > > > Thanks for the info. Would it be cleaner to EXPORT fw_add_devm_name()
> > > > and just call that in case driver sees FW is already
On Tue, Feb 27, 2018 at 02:25:55PM +0200, cantabile wrote:
> On 27/02/18 04:28, Jakub Kicinski wrote:
> > On Sun, 25 Feb 2018 17:54:25 +0000, Luis R. Rodriguez wrote:
>
> > > I want to understand the case where the firmware is *not* available on
> > > resume?
> &
On Tue, Feb 27, 2018 at 10:22:53AM -0800, Jakub Kicinski wrote:
> On Tue, 27 Feb 2018 16:54:51 +0000, Luis R. Rodriguez wrote:
> > OK, this just confirms that firmware is not needed on reboot sometimes,
> > but it does not explain *why*. What driver and code lines are involved
>
git/mcgrof/linux.git/log/?h=20180227-firmware-cache
Luis R. Rodriguez (7):
rename: _request_firmware_load() fw_load_sysfs_fallback()
firmware: fix checking for return values for fw_add_devm_name()
firmware: make fw_add_devm_name() return 0 if cache present
firmware: add helper to check to see if f
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index 65a8004418ea..b90456a4b4d7 100644
--- a/drivers/net
the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 14
Currently fw_add_devm_name() returns 1 if the firmware cache
was already set. This makes it complicated for us to check for
correctness. It is actually non-fatal if the firmware cache
is already setup, so just return 0, and simplify the checkers.
Signed-off-by: Luis R. Rodriguez
---
drivers
later.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 5f3d44d0bfe0..99c540164074 100644
--- a/drivers/base/firmware_loader.c
+++ b/drivers/base
name into devres list")
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 21dd31ef08ae..48932581c70c 100644
---
Add a helper to check if the firmware cache is already setup for a device.
This will be used later.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers
This reflects much clearer what is being done.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +-
drivers/base/firmware_fallback.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation
On Tue, Feb 27, 2018 at 03:29:53PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote:
> > fw_add_devm_name() adds device's name onto the devres for the
> > device so that prior to suspend we cache the firmware onto memory,
> > so that
On Tue, Feb 27, 2018 at 03:31:11PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote:
> > Currently fw_add_devm_name() returns 1 if the firmware cache
> > was already set. This makes it complicated for us to check for
> > correctness. It is
On Tue, Feb 27, 2018 at 03:28:21PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 3:20 PM, Luis R. Rodriguez wrote:
> > This reflects much clearer what is being done.
> >
> > Signed-off-by: Luis R. Rodriguez
> > ---
> > Documentation/driver-api/fir
On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote:
> On 28/02/18 01:20, Luis R. Rodriguez wrote:
> > Cantabile, please give these patches a spin and let me know if it fixes
> > your reported issue. They depend on other pending patches I have in line
> > waiting to be
On Wed, Feb 28, 2018 at 08:02:59PM +0200, cantabile wrote:
> On 27/02/18 22:42, Luis R. Rodriguez wrote:
> > I'd be curious if someone who can trigger the situation can test what
> > happens if you use:
> >
> > diff --git a/drivers/net/wireless/mediatek/mt7601u/m
On Wed, Feb 28, 2018 at 08:18:33PM +0100, Arend van Spriel wrote:
> On 2/28/2018 7:48 PM, Luis R. Rodriguez wrote:
> > On Wed, Feb 28, 2018 at 08:02:59PM +0200, cantabile wrote:
> > > On 27/02/18 22:42, Luis R. Rodriguez wrote:
> > > > I'd be curious if someon
On Wed, Feb 28, 2018 at 11:18:59PM +0200, cantabile wrote:
> On 28/02/18 20:48, Luis R. Rodriguez wrote:
> > On Wed, Feb 28, 2018 at 08:02:59PM +0200, cantabile wrote:
> > > On 27/02/18 22:42, Luis R. Rodriguez wrote:
> > OK so we know that the optimization is optional, not
On Thu, Mar 01, 2018 at 04:05:29PM +0200, cantabile wrote:
> On 01/03/18 02:28, Luis R. Rodriguez wrote:
> > On Wed, Feb 28, 2018 at 11:18:59PM +0200, cantabile wrote:
> >
> > > Feb 28 22:46:19 home kernel: mt7601u 2-3:1.0: Firmware Version: 0.1.00
> > > Build:
On Thu, Mar 01, 2018 at 10:11:01PM +0200, cantabile wrote:
> On 01/03/18 19:29, Luis R. Rodriguez wrote:
> >
> > Correct?
> >
>
> The above log is from "20180227-firmware-cache" kernel plus your suggested
> change that makes it always upload the firmware
This expands our library with as many things we could find which
both scripts we use share.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 31 +++---
tools/testing/selftests/firmware/fw_filesystem.sh | 41 +++---
tools/testing
back this fixes his woes with both suspend and
hibernation.
Reported-by: Cantabile
Tested-by: Cantabile
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c
the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 14
later.
One of the reasons we want to enforce this is the firmware cache is
used for helping with suspend/resume, and if incompatible calls use it
they can stall suspend.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/main.c | 14 ++
1 file changed, 14 insertions
/proc/config.gz
(CONFIG_IKCONFIG_PROC) or haven't enabled CONFIG_FW_LOADER_USER_HELPER
we cannot run these dynamic tests, so just run both scripts just
as we used to before making blunt assumptions about your setup
and requirements exactly as we did before.
Acked-by: Kees Cook
Signed-off-b
turn make resume fail.
This is all theoretical, no known issues have been reported.
This small issue has been present way since the addition of the
devres firmware cache names on v3.7.
Fixes: f531f05ae9437 ("firmware loader: store firmware name into devres list")
Signed-off-by: Lu
same file.
We'll soon become strict about this on the firmware interface to reject
such calls later, so correct the test scripts to avoid such uses as well.
We address this on the tests scripts by simply using unique names when
testing the custom fallback interface.
Signed-off-by: Luis R. Rodr
Add a helper to check if the firmware cache is already setup for a device.
This will be used later.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/main.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b
You currently need four different kernel builds to test the firmware
API fully. By adding a proc knob to force disable the fallback mechanism
completely we are able to reduce the amount of kernels you need built
to test the firmware API down to two.
Acked-by: Kees Cook
Signed-off-by: Luis R
inspect if
CONFIG_FW_LOADER_USER_HELPER_FALLBACK was enabled at build time by checking
the proc value at boot time.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 1 +
drivers/base/firmware_loader/fallback.h | 4 +++-
drivers/base
This will make it much easier to manage as we manage to
keep trimming componnents down into their own files to more
easily manage and maintain this codebase.
Suggested-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS | 2
This reflects much clearer what is being done.
While at it, kdoc'ify it.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +-
drivers/base/firmware_loader/fallback.c | 13 ++---
2 files changed, 11 insertions(
On Fri, Mar 9, 2018 at 2:12 PM, Andres Rodriguez wrote:
> Hi Everyone,
>
> Wanted to inquire your opinions about the following matter.
>
> We are experiencing some end user confusion regarding the following messages
> being printed to dmesg:
>
> [0.571324] amdgpu :01:00.0: Direct firmware
enable firmware loading is so that we can later enable the kernel
after subsequent patches to tweak this configuration, even if the
firmware loader is modular.
This introduces no functional changes.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/Makefile | 4 +-
drivers/base
All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool,
initailized at build time. Define it as such. This simplifies the
logic even further, removing now all explicit #ifdefs around the code.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c
.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 49 ++
1 file changed, 30 insertions(+), 19 deletions(-)
diff --git a/drivers/base/firmware_loader.c b/drivers/base/firmware_loader.c
index 59dba794ce1a
used as an unsigned
long. There a few cases however where it makes sense to get or
set the timeout as an int, the helpers annotate these use cases
have been properly vetted for.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 46
.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/Makefile| 1 +
drivers/base/{firmware_class.c => firmware_loader.c} | 0
2 files changed, 1 insertion(+)
rename drivers/base/{firmware_class.c => firmware_loader.c} (100%)
diff --git a/drivers/base/Makefile b/d
We'll expland on this later, for now just add basic module checker.
While at it, move this all to use /bin/bash as we'll have much more
flexibility with it.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 7 ++--
tools/testing/selftest
Now that we have a kconfig checker just use that instead of relying
on testing a sysfs directory being present, since our requirements
are spelled out.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 5 +
1 file changed, 1
old heuristics for now.
We stuff the new kconfig_has() helper into our shared library as we'll
later expando on its use elsewhere.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/config | 4
tools/testing/selftests/firmware
mcgrof/linux.git/log/?h=20180307-firmware-dev-for-v4.17
Luis R. Rodriguez (20):
test_firmware: add simple firmware firmware test library
test_firmware: enable custom fallback testing on limited kernel
configs
test_firmware: replace syfs fallback check with kconfig_has helper
firmware: en
First, thanks for your patch!
On Fri, Mar 9, 2018 at 3:09 PM, Andres Rodriguez wrote:
> Currently the firmware loader only exposes one silent path for querying
> optional firmware, and that is request_firmware_direct(). This function
> also disables the usermodehelper fallback which might not alw
On Sat, Mar 10, 2018 at 6:35 AM, Luis R. Rodriguez wrote:
> You also I take it have users in
> mind? I'd like to see at least one user of the API or this fixing a
> reported issue. Ie, if users have reported this as issues incorrectly,
> referring to those incorrect posts as is
On Mon, Mar 12, 2018 at 12:10:47AM +0100, Arend van Spriel wrote:
> On 3/11/2018 5:05 PM, Andres Rodriguez wrote:
> > > Your patch series then should also have the driver callers who you
> > > want to modify to use this new API. Collect from the 802.11 folks the
> > > other drivers which I think th
On Tue, Mar 13, 2018 at 03:39:23PM +0200, Kalle Valo wrote:
> "Luis R. Rodriguez" writes:
>
> > On Mon, Mar 12, 2018 at 12:10:47AM +0100, Arend van Spriel wrote:
> >> On 3/11/2018 5:05 PM, Andres Rodriguez wrote:
> >> > > Your patch series th
On Tue, Mar 13, 2018 at 03:16:34PM +0200, Kalle Valo wrote:
> "Luis R. Rodriguez" writes:
>
> >> +/**
> >> + * request_firmware_optional: - request for an optional fw module
> >> + * @firmware_p: pointer to firmware image
> >> + * @name: name
On Sat, Mar 10, 2018 at 09:16:36AM -0800, Kees Cook wrote:
> On Sat, Mar 10, 2018 at 6:14 AM, Luis R. Rodriguez wrote:
> > Greg,
> >
> > Here's a respin of what I have queued up for v4.17 for the firmware API. It
> > combines the cleanup I've been worki
On Wed, Mar 14, 2018 at 11:56 AM, Greg KH wrote:
> On Sat, Mar 10, 2018 at 06:14:48AM -0800, Luis R. Rodriguez wrote:
>> The timeout is a fallback construct, so we can just stuff the
>> timeout configuration under struct firmware_fallback_config.
>
> Why? What does it matter
On Wed, Mar 14, 2018 at 11:53 AM, Greg KH wrote:
> On Sat, Mar 10, 2018 at 06:14:46AM -0800, Luis R. Rodriguez wrote:
>> All CONFIG_FW_LOADER_USER_HELPER_FALLBACK really is, is just a bool,
>> initailized at build time. Define it as such. This simplifies the
>> logic even
On Wed, Mar 14, 2018 at 12:00 PM, Greg KH wrote:
> On Sat, Mar 10, 2018 at 06:14:52AM -0800, Luis R. Rodriguez wrote:
>> You currently need four different kernel builds to test the firmware
>> API fully. By adding a proc knob to force disable the fallback mechanism
>> comp
On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote:
> On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote:
> > +EXPORT_SYMBOL_GPL(request_firmware_cache);
>
> I know you are just following the existing naming scheme, but please
> let's not continue the
On Tue, Mar 20, 2018 at 06:38:01PM +0100, Greg KH wrote:
> On Tue, Mar 20, 2018 at 05:34:09PM +0000, Luis R. Rodriguez wrote:
> > On Tue, Mar 20, 2018 at 09:30:55AM +0100, Greg KH wrote:
> > > On Sat, Mar 10, 2018 at 06:15:00AM -0800, Luis R. Rodriguez wrote:
> >
On Tue, Mar 20, 2018 at 02:54:44PM -0400, Konstantin Ryabitsev wrote:
> On 03/20/18 14:24, Luis R. Rodriguez wrote:
> > *Iff* this seems sensible, this would only mean kernel.org would have to
> > start
> > accepting git notes long term, for those who optionally want to p
back this fixes his woes with both suspend and
hibernation.
Reported-by: Cantabile
Tested-by: Cantabile
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c
the firmware on a reboot and then suspend
they can miss looking for the firmware on resume. To help with this we
need a way to cache the firmware when such an optimization has taken
place.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 14
When the sysctl knob is used ignore the fallback mechanism we pr_info_once()
to ensure its noted the knob was used. The print incorrectly states its a
debugfs knob, its a sysctl knob, so correct this typo.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 2 +-
1
start addressing
the firmware API rename for the rest of the callers. That will take some
time as I'm running quite a bit of tests on those changes and I am going
to wait for 0-day to give me its blesssings.
Question, feedback, and specially rants are greatly appreciated.
Luis
Luis R. Ro
On Mon, Apr 23, 2018 at 04:11:57PM -0400, Andres Rodriguez wrote:
> Including:
> - Fixup outdated kernel-doc paths
> - Slightly too short title underline
> - Some typos
>
> Signed-off-by: Andres Rodriguez
This already got merged.
On Mon, Apr 23, 2018 at 04:11:58PM -0400, Andres Rodriguez wrote:
> This should let us associate enum kdoc to these values.
>
> v2: use BIT() macro
No need to keep the changelog of series here, best to put them below as
I note.
>
> Signed-off-by: Andres Rodriguez
> ---
Here is good to add chan
On Mon, Apr 23, 2018 at 04:11:59PM -0400, Andres Rodriguez wrote:
> Some basic definitions for the FW_OPT_* values
>
> v2: Documentation corrections from Luis.
Likewise.
> Signed-off-by: Andres Rodriguez
> ---
> drivers/base/firmware_loader/firmware.h | 20
> 1 file change
On Mon, Apr 23, 2018 at 04:12:00PM -0400, Andres Rodriguez wrote:
> The kernel-doc spec dictates a function name ends in ().
>
> Signed-off-by: Andres Rodriguez
> Acked-by: Randy Dunlap
0-day never got back to me about my full sweep API rename so I think your
changes are best to go in first, I'
On Mon, Apr 23, 2018 at 04:12:01PM -0400, Andres Rodriguez wrote:
> Currently the firmware loader only exposes one silent path for querying
> optional firmware, and that is firmware_request_direct(). This function
> also disables the fallback path, which might not always be the
> desired behaviour.
On Mon, Apr 23, 2018 at 04:12:02PM -0400, Andres Rodriguez wrote:
> Previously, one could assume the firmware name from the preceding
> message: "Direct firmware load for {name} failed with error %d".
>
> However, with the new firmware_request_nowarn() entrypoint, the message
> outlined above will
On Mon, Apr 23, 2018 at 04:12:03PM -0400, Andres Rodriguez wrote:
> Use the correct prefix for symbols exported by firmware_loader(). This
> is done since firmware_sysfs_fallback() is now exposed through
> kernel-doc.
>
> Signed-off-by: Andres Rodriguez
> ---
> drivers/base/firmware_loader/fallb
On Mon, Apr 23, 2018 at 04:12:01PM -0400, Andres Rodriguez wrote:
> diff --git a/include/linux/firmware.h b/include/linux/firmware.h
> index db8351a42405..a34e16f77f20 100644
> --- a/include/linux/firmware.h
> +++ b/include/linux/firmware.h
> @@ -42,6 +42,8 @@ struct builtin_fw {
> #if defined(CON
On Mon, Jun 27, 2016 at 01:38:43AM +0200, Martin Blumenstingl wrote:
> On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter
> wrote:
> > I've added lede-dev and Luis since this is relevant for them.
> > Maybe between the sysloadfw.sh and owl-loader, there's another
> > solution we overlooked so fa
On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> + Luis
>
> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > (cc: firmware and brcmfmac maintainers)
> >
> > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 07/21/2016 04:05 AM, Stanislaw Gruszka
On Fri, Jul 22, 2016 at 12:26:00PM +0200, Stanislaw Gruszka wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> > + Luis
> >
> > On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > > (cc: firmware and brcmfmac maintainers)
> > >
> > > On Thu, Jul 21, 2016 at 06:23:11AM -0400
On Fri, Jul 22, 2016 at 08:51:36AM -0400, Prarit Bhargava wrote:
> On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
> >> Another option to solve to problem would be stop requesting not
> >> available publicly firmware. However, I assume some drivers would
> >> like to preserve that option.
> >
> >
On Thu, Jul 28, 2016 at 09:23:35PM +0200, Arend van Spriel wrote:
> On 23-07-16 00:05, Luis R. Rodriguez wrote:
> > The firmware API is a mess and I've been trying to correct that
> > with a more flexible API.
<-- snip -->
> > Extensions to the fw API are IMHO be
On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> + Luis (again) ;-)
>
> On 29-07-16 08:13, Daniel Wagner wrote:
> > On 07/28/2016 09:01 PM, Bjorn Andersson wrote:
> >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:
> >>
> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Danie
On Mon, Aug 01, 2016 at 02:26:04PM +0200, Daniel Wagner wrote:
> On 07/31/2016 09:23 AM, Dmitry Torokhov wrote:
> >On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez"
> >wrote:
> >>On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> >
On Sun, Jul 31, 2016 at 12:23:09AM -0700, Dmitry Torokhov wrote:
> On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez"
> wrote:
> >On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> >> + Luis (again) ;-)
> >>
> >> On 29-07-16 08
On Mon, Aug 01, 2016 at 10:19:51AM -0700, Bjorn Andersson wrote:
> On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote:
>
> > On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> > > + Luis (again) ;-)
> > >
> > > On 29-07-16 08:13, Daniel
On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
> >The sysdata API's main goal rather is to provide a flexible API first,
> >compartamentalizing the usermode helper was secondary. But now it seems
> >I may just also add devm support too to help simplify code further.
>
> I missed th
On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
> >>>The sysdata API's main goal rather is to provide a flexible API first,
> >&g
On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote:
> "Luis R. Rodriguez" writes:
>
> > I was considering this as a future extension to the firmware API
> > through the new extensible firmware API, the sysdata API.
>
> I think Linus mentioned thi
On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote:
> On 02-08-16 16:16, Luis R. Rodriguez wrote:
> > On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote:
> >> "Luis R. Rodriguez" writes:
> >>
> >>> I was consideri
On Wed, Aug 03, 2016 at 01:43:31PM +0200, Arend van Spriel wrote:
> On 03-08-16 09:42, Dmitry Torokhov wrote:
> > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez
> > wrote:
> >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
> >>> On 08
On Wed, Aug 03, 2016 at 12:42:14AM -0700, Dmitry Torokhov wrote:
> On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote:
> > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote:
> >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote:
> >> >On Tue, Au
1 - 100 of 320 matches
Mail list logo
