On Thu, Mar 15, 2018 at 08:04:55PM +0100, Dominik Brodowski wrote:
> diff --git a/kernel/umh.c b/kernel/umh.c
> index 18e5fa4b0e71..f4b557cadf08 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -135,7 +135,7 @@ static void call_usermodehelper_exec_sync(struct
> subprocess_info *sub_info)
>
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 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 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 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 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 Mon, Mar 12, 2018 at 04:54:51PM -0400, Waiman Long wrote:
> On 03/12/2018 04:46 PM, Luis R. Rodriguez wrote:
> > On Mon, Mar 12, 2018 at 04:15:40PM -0400, Waiman Long wrote:
> >> Checking code is added to check for invalid flags in the ctl_table
> >> and return error
On Mon, Mar 12, 2018 at 04:15:44PM -0400, Waiman Long wrote:
> Add a range clamping test for the msgmni sysctl parameter to verify
No! We don't want to test production values, please add a new test
entry which is similar but does *not* modify system production values!
Luis
On Mon, Mar 12, 2018 at 04:15:43PM -0400, Waiman Long wrote:
> + if (clamped)
> + pr_warn_once("sysctl: \"sem[3]\" was set out of range [%d, %d],
> clamped to %d.\n",
> + 0, IPCMNI, ns->sc_semmni);
Why warn if the kernel already does that? If we can avoid
On Mon, Mar 12, 2018 at 04:15:41PM -0400, Waiman Long wrote:
> Even with clamped sysctl parameters, it is still not that straight
> forward to figure out the exact range of those parameters. One may
> try to write extreme parameter values to see if they get clamped.
> To make it easier, a warning w
On Mon, Mar 12, 2018 at 04:15:40PM -0400, Waiman Long wrote:
> Checking code is added to check for invalid flags in the ctl_table
> and return error if an unknown flag is used.
This should be merged with the first patch otherwise there are atomic
points in time on the commit log history where inva
On Mon, Mar 12, 2018 at 04:15:39PM -0400, Waiman Long wrote:
> When minimum/maximum values are specified for a sysctl parameter in
> the ctl_table structure with proc_dointvec_minmax() handler, update
> to that parameter will fail with error if the given value is outside
> of the required range.
>
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 Sat, Mar 10, 2018 at 02:08:43PM +, Luis R. Rodriguez wrote:
> The alternative to this would be a simple equivalent of
> try_then_request_module()
> for UMH modules: try_umhm_then_request_umh_module() or whatever. So just as I
> argued earlier over UMH limitations, this is no
Also,
Alexei you never answered my questions out aliases with the umh modules.
Long term this important to consider.
Luis
On Sat, Mar 10, 2018 at 11:03 AM, Luis R. Rodriguez wrote:
> On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. wrote:
>> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>>> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
>>> &
On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. wrote:
> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>> On Thu, Mar 08, 2018 at 04:14:11AM +0000, Luis R. Rodriguez wrote:
>> > On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
>
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
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
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
.
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
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
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
.
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
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
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
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
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
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
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(
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
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
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
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
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
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
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
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
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
*Poke*
Luis
On Wed, Nov 29, 2017 at 6:36 PM, Luis R. Rodriguez wrote:
> Debugging ineractions with userspace can often be a bit of pain, specially
> when trying to figure out who is at fault for an issue. Having the kernel
> process aliases when debugging can help us much faster fi
On Fri, Mar 09, 2018 at 06:34:18PM -0800, Alexei Starovoitov wrote:
> On 3/9/18 11:38 AM, Linus Torvalds wrote:
> > On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds
> > wrote:
> > >
> > > How are you going to handle five processes doing the same setup
> > > concurrently?
Let's keep in mind we don
On Thu, Mar 08, 2018 at 03:07:01PM -0800, Alexei Starovoitov wrote:
> On 3/7/18 5:23 PM, Luis R. Rodriguez wrote:
> >
> > request_module() has its own world though too. How often in your proof of
> > concept is request_module() called? How many times do you envision it being
On Thu, Mar 08, 2018 at 04:40:17PM -0500, Waiman Long wrote:
> On 03/08/2018 03:49 PM, Luis R. Rodriguez wrote:
> > On Thu, Mar 08, 2018 at 02:57:09PM -0500, Waiman Long wrote:
> >> On 03/08/2018 01:31 PM, Luis R. Rodriguez wrote:
> >>> On Thu, Mar 01, 2018 at 12:43
On Thu, Mar 08, 2018 at 02:57:09PM -0500, Waiman Long wrote:
> On 03/08/2018 01:31 PM, Luis R. Rodriguez wrote:
> > On Thu, Mar 01, 2018 at 12:43:38PM -0500, Waiman Long wrote:
> >> Even with clamped sysctl parameters, it is still not that straight
> >> forward to fi
On Thu, Mar 08, 2018 at 02:35:32PM -0500, Waiman Long wrote:
> On 03/08/2018 12:57 PM, Luis R. Rodriguez wrote:
> > On Thu, Mar 08, 2018 at 05:51:09PM +0000, Luis R. Rodriguez wrote:
> >> On Thu, Mar 01, 2018 at 01:31:17PM -0800, Andrew Morton wrote:
> >>> On Thu, 1
On Thu, Mar 08, 2018 at 06:23:35PM +, Luis R. Rodriguez wrote:
> On Thu, Mar 01, 2018 at 12:43:34PM -0500, Waiman Long wrote:
> > v2->v3:
> > - Fix kdoc comment errors.
> > - Incorporate comments and suggestions from Luis R. Rodriguez.
> > - Add a patch
On Wed, Mar 07, 2018 at 03:34:24PM -0500, Waiman Long wrote:
>
> % cat msgmni_range
> [0, 32768]
All that sounds promising but I think you are jumping a few
steps ahead of what needs to get done. Let's first sort out the
first series well.
Luis
On Thu, Mar 01, 2018 at 12:43:38PM -0500, Waiman Long wrote:
> Even with clamped sysctl parameters, it is still not that straight
> forward to figure out the exact range of those parameters. One may
> try to write extreme parameter values to see if they get clamped.
> To make it easier, a warning w
On Thu, Mar 01, 2018 at 12:43:34PM -0500, Waiman Long wrote:
> v2->v3:
> - Fix kdoc comment errors.
> - Incorporate comments and suggestions from Luis R. Rodriguez.
> - Add a patch to fix a typo error in fs/proc/proc_sysctl.c.
>
> v1->v2:
> - Add kdoc c
On Thu, Mar 01, 2018 at 12:43:40PM -0500, Waiman Long wrote:
> This patch clamps the semmni value (fourth element of sem_ctls[]
> array) to within the [0, IPCMNI] range and prints a warning message
> once when an out-of-range value is being written.
>
> Signed-off-by: Waiman Long
> ---
> ipc/ipc
On Thu, Mar 01, 2018 at 12:43:39PM -0500, Waiman Long wrote:
> A user can write arbitrary integer values to msgmni and shmmni sysctl
> parameters without getting error, but the actual limit is really
> IPCMNI (32k). This can mislead users as they think they can get a
> value that is not real.
>
>
On Thu, Mar 01, 2018 at 12:43:38PM -0500, Waiman Long wrote:
> Even with clamped sysctl parameters, it is still not that straight
> forward to figure out the exact range of those parameters. One may
> try to write extreme parameter values to see if they get clamped.
> To make it easier, a warning w
On Thu, Mar 08, 2018 at 05:51:09PM +, Luis R. Rodriguez wrote:
> On Thu, Mar 01, 2018 at 01:31:17PM -0800, Andrew Morton wrote:
> > On Thu, 1 Mar 2018 12:43:37 -0500 Waiman Long wrote:
> >
> > > When minimum/maximum values are specified for a sysctl paramete
ec_minmax() and
> proc_douintvec_minmax() are also documented.
>
> Signed-off-by: Waiman Long
Acked-by: Luis R. Rodriguez
Luis
On Thu, Mar 01, 2018 at 12:43:35PM -0500, Waiman Long wrote:
> Signed-off-by: Waiman Long
Acked-by: Luis R. Rodriguez
Luis
On Thu, Mar 01, 2018 at 01:31:17PM -0800, Andrew Morton wrote:
> On Thu, 1 Mar 2018 12:43:37 -0500 Waiman Long wrote:
>
> > When minimum/maximum values are specified for a sysctl parameter in
> > the ctl_table structure with proc_dointvec_minmax() handler, update
> > to that parameter will fail
On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> > On Wed, Mar 07, 2018 at 07:02:05PM +0000, Luis R. Rodriguez wrote:
> > > On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A.
On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> On Wed, Mar 07, 2018 at 07:02:05PM +0000, Luis R. Rodriguez wrote:
> > On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> > > any reason why PAT can't be enabled for ivt
On Wed, Feb 28, 2018 at 08:11:31AM +0100, Greg KH wrote:
> On Tue, Feb 27, 2018 at 09:33:28PM -0800, Kees Cook wrote:
> > On Tue, Feb 27, 2018 at 5:28 PM, Luis R. Rodriguez
> > wrote:
> > > On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote:
> > >> On
On Mon, Mar 05, 2018 at 05:34:57PM -0800, Alexei Starovoitov wrote:
> As the first step in development of bpfilter project [1]
So meta :) The URL refers an lwn article, which in turn refers to this effort's
first RFC. As someone only getting *one* of these patches in emails, It would
be useful if
On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> any reason why PAT can't be enabled for ivtvfb as simply as in the attached
> patch?
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 621b2f613d81..69de110726e8 100644
--- a/drivers/media/pci
On Wed, Feb 28, 2018 at 06:25:16PM -0800, Josh Triplett wrote:
> On Thu, Mar 01, 2018 at 12:38:16AM +0000, Luis R. Rodriguez wrote:
> > On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> > > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> &
On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> On Wed, Feb 28, 2018 at 06:26:03PM +0000, Luis R. Rodriguez wrote:
> > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain an
> > extra 13436 bytes broken down as follows:
>
> A
On Wed, Feb 28, 2018 at 04:49:51PM +0100, Vratislav Bendel wrote:
> The function xfs_buftarg_isolate() used by xfs buffer schrinkers
> to determine whether a buffer should be isolated and disposed
> from LRU list, has inverted logic.
>
> Excerpt from xfs_buftarg_isolate():
> /*
>
On Wed, Feb 28, 2018 at 01:58:53PM -0500, Waiman Long wrote:
> On 02/28/2018 01:43 PM, Luis R. Rodriguez wrote:
> > On Wed, Feb 28, 2018 at 12:53:40PM -0500, Waiman Long wrote:
> >> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote:
> >>> On Tue, Feb 27, 2018 at 03:49
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 12:53:40PM -0500, Waiman Long wrote:
> On 02/27/2018 07:47 PM, Luis R. Rodriguez wrote:
> > On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote:
> >> When minimum/maximum values are specified for a sysctl parameter in
> >> t
On Wed, Feb 28, 2018 at 01:07:23AM -0800, Josh Triplett wrote:
> On Wed, Feb 28, 2018 at 01:32:37AM +0000, Luis R. Rodriguez wrote:
> > On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> > > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez
> > > wrote:
>
On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote:
> > Since we now have knobs to twiddle what used to be set on kernel
> > configurations we can build one base kernel configuration and modify
> > behaviour
On Tue, Feb 27, 2018 at 03:14:53PM -0800, Kees Cook wrote:
> On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote:
> > The firmware fallback code is optional. Split that code out to help
> > distinguish the fallback functionlity from othere core firmware loader
> > featu
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 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: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:41:40PM -0800, Kees Cook wrote:
> On Tue, Feb 27, 2018 at 3:31 PM, Danilo Krummrich
> wrote:
> > proc_sys_link_fill_cache() does not need to check whether we're
> > called for a link - it's already done by scan().
> >
> > Signed-off-by: Danilo Krummrich
>
> Acked-by: K
On Wed, Feb 28, 2018 at 12:31:55AM +0100, Danilo Krummrich wrote:
> proc_sys_link_fill_cache() does not take currently unregistering
> sysctl tables into account, which might result into a page fault in
> sysctl_follow_link() - add a check to fix it.
>
> Signed-off-by: Danilo Krummrich
> ---
> v2
On Tue, Feb 27, 2018 at 03:49:50PM -0500, Waiman Long wrote:
> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
> index 8ad93c2..e4ab272 100644
> --- a/ipc/ipc_sysctl.c
> +++ b/ipc/ipc_sysctl.c
> @@ -41,12 +41,17 @@ static int proc_ipc_dointvec(struct ctl_table *table, int
> write,
> static int p
On Tue, Feb 27, 2018 at 03:49:49PM -0500, Waiman Long wrote:
> Even with clamped sysctl parameters, it is still not that straight
> forward to figure out the exact range of those parameters. One may
> try to write extreme parameter values to see if they get clamped.
> To make it easier, a warning w
On Tue, Feb 27, 2018 at 03:49:48PM -0500, Waiman Long wrote:
> When minimum/maximum values are specified for a sysctl parameter in
> the ctl_table structure with proc_dointvec_minmax() handler,
an
> update
> to that parameter will fail with error if the given value is outside
> of the required ra
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
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
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
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
---
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
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
On Sat, Feb 24, 2018 at 11:45:16AM +0300, Dan Carpenter wrote:
> On Sat, Feb 24, 2018 at 02:59:41AM +0000, Luis R. Rodriguez wrote:
> > On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> > > The main problem is that the parentheses are in the wrong place and the
>
we want to stop
prior to hitting the max, and not rely on the wrap arround at all. So
just cap at num_test_devs + 1, prior to assigning a new device.
Reported-by: Dan Carpenter
Fixes: d9c6a72d6fa2 ("kmod: add test driver to stress test the module loader")
Signed-off-by: Luis R. Rodriguez
On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> The main problem is that the parentheses are in the wrong place and the
> unlikely() call returns either 0 or 1 so it's never less than zero.
Doh, thanks, yes. Seems worth considering a grammar rule for it.
> The other problem is th
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.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader.c | 25
" on a fallback call.
0-day now gives its blessings for both, on linux-next and on Linus' tree.
Questions, feedback, rants all equally welcomed.
Luis
Luis R. Rodriguez (11):
test_firmware: enable custom fallback testing on limited kernel
configs
test_firmware: replace syfs f
old heuristics for now.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/config | 4 +++
tools/testing/selftests/firmware/fw_fallback.sh | 45 -
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/firmware/
.
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
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.
Signed-off-by: Luis R. Rodriguez
---
drivers
Both fw_fallback.sh and fw_filesystem.sh share a common set of
boiler plate setup and tests. We can share these in a common place.
While at it, move both test to use /bin/bash.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 69 ++---
tools
.
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..2d819875348d 100644
--- a
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
/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.
Signed-off-by: Luis R. Rodriguez
---
too
201 - 300 of 2144 matches
Mail list logo
