Re: [PATCH] firmware: add a function to load optional firmware v2

On Tue, Mar 13, 2018 at 03:39:23PM +0200, Kalle Valo wrote: > "Luis R. Rodriguez" <mcg...@kernel.org> 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: > >> > >

Re: [PATCH] firmware: add a function to load optional firmware v2

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

Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits

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

Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits

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

Re: [PATCH v4 6/6] test_sysctl: Add range clamping test

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

Re: [PATCH v4 6/6] test_sysctl: Add range clamping test

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

Re: [PATCH v4 5/6] ipc: Clamp semmni to the real IPCMNI limit

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

Re: [PATCH v4 5/6] ipc: Clamp semmni to the real IPCMNI limit

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

Re: [PATCH v4 3/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v4 3/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits

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

Re: [PATCH v4 2/6] proc/sysctl: Check for invalid flags bits

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

Re: [PATCH v4 1/6] sysctl: Add flags to support min/max range clamping

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. >

Re: [PATCH v4 1/6] sysctl: Add flags to support min/max range clamping

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. >

Re: [PATCH] firmware: add a function to load optional firmware v2

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

Re: [PATCH] firmware: add a function to load optional firmware v2

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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. Luis

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. Luis

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sat, Mar 10, 2018 at 11:03 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. <n...@ou.edu> wrote: >> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote: >>> On Thu, Mar 08, 2018 at 04:14:11AM

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

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: >>> &

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. <n...@ou.edu> 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 Thu, Mar 08, 2018 at 04:06:01AM +,

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

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: >

Re: [PATCH] firmware: add a function to load optional firmware v2

On Sat, Mar 10, 2018 at 6:35 AM, Luis R. Rodriguez <mcg...@kernel.org> 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 tho

Re: [PATCH] firmware: add a function to load optional firmware v2

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

Re: [PATCH] firmware: add a function to load optional firmware v2

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

Re: [PATCH] firmware: add a function to load optional firmware v2

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

[PATCH v3 03/20] test_firmware: replace syfs fallback check with kconfig_has helper

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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- tools/testing/selfte

[PATCH v3 03/20] test_firmware: replace syfs fallback check with kconfig_has helper

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

[PATCH v3 02/20] test_firmware: enable custom fallback testing on limited kernel configs

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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- tools/testing/selftests/firmware/config | 4 t

[PATCH v3 02/20] test_firmware: enable custom fallback testing on limited kernel configs

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/fw_fallback.sh | 6

[PATCH v3 04/20] firmware: enable to split firmware_class into separate target files

. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- 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/

[PATCH v3 04/20] firmware: enable to split firmware_class into separate target files

. 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

[PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config

, and that is 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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> ---

[PATCH v3 01/20] test_firmware: add simple firmware firmware test library

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 <mcg...@kernel.org> --- tools/testing/selftests/firmware/fw_fallback.sh | 7 ++-- tools/t

[PATCH v3 07/20] firmware: move loading timeout under struct firmware_fallback_config

, and that is 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

[PATCH v3 01/20] test_firmware: add simple firmware firmware test library

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/selftests/firmware

[PATCH v3 06/20] firmware: use helpers for setting up a temporary cache timeout

. Acked-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/base/firmware_loader.c | 49 ++ 1 file changed, 30 insertions(+), 19 deletions(-) diff --git a/drivers/base/firmware_loader.c b/

[PATCH v3 06/20] firmware: use helpers for setting up a temporary cache timeout

. 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

[PATCH v3 08/20] firmware: split firmware fallback functionality into its own file

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 <mcg...@kernel.org> --- drivers/base/Makefile

[PATCH v3 08/20] firmware: split firmware fallback functionality into its own file

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

[PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodrigue

Re: [RFC 0/1] Loading optional firmware

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

Re: [RFC 0/1] Loading optional firmware

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

[PATCH v3 05/20] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

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

[PATCH v3 10/20] firmware: enable run time change of forcing fallback loader

to 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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/base/firmware_loader/fallback.c | 1 + drivers/base/fir

[PATCH v3 10/20] firmware: enable run time change of forcing fallback loader

to 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

[PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time

org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/base/firmware_loader/fallback.c | 5 + drivers/base/firmware_loader/fallback.h | 4 drivers/base/firmware_loader/fallback_table.c | 9 + 3 files changed, 18 insertions(+) diff --git a/

[PATCH v3 11/20] firmware: enable to force disable the fallback mechanism at run time

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

[PATCH v3 14/20] rename: _request_firmware_load() fw_load_sysfs_fallback()

This reflects much clearer what is being done. While at it, kdoc'ify it. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +- drivers/base/firmware_loader/fallback.c | 13 ++--- 2 files chang

[PATCH v3 14/20] rename: _request_firmware_load() fw_load_sysfs_fallback()

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(+), 4

[PATCH v3 17/20] test_firmware: modify custom fallback tests to use unique files

with the 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. Rodriguez

[PATCH v3 15/20] firmware: fix checking for return values for fw_add_devm_name()

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: Luis R. Rodr

[PATCH v3 17/20] test_firmware: modify custom fallback tests to use unique files

with the 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. Rodriguez

[PATCH v3 15/20] firmware: fix checking for return values for fw_add_devm_name()

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: Luis R.

[PATCH v3 16/20] firmware: add helper to check to see if fw cache is setup

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 <mcg...@kernel.org> --- drivers/base/firmware_loader/main.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/driver

[PATCH v3 16/20] firmware: add helper to check to see if fw cache is setup

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

[PATCH v3 12/20] test_firmware: expand on library with shared helpers

This expands our library with as many things we could find which both scripts we use share. Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- tools/testing/selftests/firmware/fw_fallback.sh | 31 +++--- tools/testing/selftests/firmware/fw_filesystem.s

[PATCH v3 12/20] test_firmware: expand on library with shared helpers

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

[PATCH v3 18/20] firmware: ensure the firmware cache is not used on incompatible calls

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 <mcg...@kernel.org> --- drivers/base/firmware_loader/main.c | 14 ++ 1 file c

[PATCH v3 18/20] firmware: ensure the firmware cache is not used on incompatible calls

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

[PATCH v3 13/20] test_firmware: test three firmware kernel configs using a proc knob

ed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- tools/testing/selftests/firmware/Makefile| 2 +- tools/testing/selftests/firmware/fw_lib.sh | 51 + tools/testing/selftests/firmware/fw_run_tests.sh | 70 3 files changed, 122 insertions(+)

[PATCH v3 13/20] test_firmware: test three firmware kernel configs using a proc knob

(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-by: Luis R. Rodriguez

[PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

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 <mcg...@kernel.org> --- .../driver-api/firmware/request_firmwa

[PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

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

[PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot

back this fixes his woes with both suspend and hibernation. Reported-by: Cantabile <cantabile.d...@gmail.com> Tested-by: Cantabile <cantabile.d...@gmail.com> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- drivers/net/wireless/mediatek/mt7601u/mcu.c | 2 +- 1 file ch

[PATCH v3 20/20] mt7601u: use request_firmware_cache() to address cache on reboot

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

[PATCH v3 09/20] firmware: move firmware loader into its own directory

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 <keesc...@chromium.org> Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> ---

[PATCH v3 09/20] firmware: move firmware loader into its own directory

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

[PATCH v3 00/20] firmware: development for v4.17

rmware-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: enable to split firmware_class into s

[PATCH v3 00/20] firmware: development for v4.17

rmware-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: enable to split firmware_class into s

Re: [PATCH 0/3] module: process aliasing when debugging

*Poke* Luis On Wed, Nov 29, 2017 at 6:36 PM, Luis R. Rodriguez <mcg...@kernel.org> 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 c

Re: [PATCH 0/3] module: process aliasing when debugging

*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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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 > > >

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 3/6] sysctl: Add flags to support min/max range clamping

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

Re: [PATCH v3 3/6] sysctl: Add flags to support min/max range clamping

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

Re: [PATCH v3 0/6] ipc: Clamp *mni to the real IPCMNI limit

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

Re: [PATCH v3 0/6] ipc: Clamp *mni to the real IPCMNI limit

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

Re: [PATCH 0/5] sysctl: Enable easy addition of range showing sysctl parameters

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

Re: [PATCH 0/5] sysctl: Enable easy addition of range showing sysctl parameters

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 0/6] ipc: Clamp *mni to the real IPCMNI limit

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

Re: [PATCH v3 0/6] ipc: Clamp *mni to the real IPCMNI limit

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

Re: [PATCH v3 6/6] ipc: Clamp semmni to the real IPCMNI limit

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

Re: [PATCH v3 6/6] ipc: Clamp semmni to the real IPCMNI limit

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 > --- >

Re: [PATCH v3 5/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

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. > >

Re: [PATCH v3 5/6] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

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. > >

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 4/6] sysctl: Warn when a clamped sysctl parameter is set out of range

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

Re: [PATCH v3 3/6] sysctl: Add flags to support min/max range clamping

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 <long...@redhat.com> wrote: > > > > > When minimum/maximum values are sp

Re: [PATCH v3 3/6] sysctl: Add flags to support min/max range clamping

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

<    1   2   3   4   5   6   7   8   9   10   >