Re: [PATCH] mm/zsmalloc: strength reduce zspage_size calculation

Hi Joey, On Mon, Feb 26, 2018 at 02:21:26AM -1000, Joey Pabalinas wrote: > Replace the repeated multiplication in the main loop > body calculation of zspage_size with an equivalent > (and cheaper) addition operation. > > Signed-off-by: Joey Pabalinas > > 1 file

Re: [PATCH] mm/zsmalloc: strength reduce zspage_size calculation

Hi Joey, On Mon, Feb 26, 2018 at 02:21:26AM -1000, Joey Pabalinas wrote: > Replace the repeated multiplication in the main loop > body calculation of zspage_size with an equivalent > (and cheaper) addition operation. > > Signed-off-by: Joey Pabalinas > > 1 file changed, 2 insertions(+), 2

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On 28/02/2018 00:23, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >>> >>> On 27/02/2018 06:01, Andy Lutomirski wrote: > On Feb 26, 2018, at 8:17 PM,

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On 28/02/2018 00:23, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >>> >>> On 27/02/2018 06:01, Andy Lutomirski wrote: > On Feb 26, 2018, at 8:17 PM, Andy Lutomirski wrote: > >>

[PATCH 0/2] drivers: soc: xilinx: Add support for ZynqMP power domain driver

The zynqmp power domain driver communicates the usage requirements for logical power domains / devices to the platform FW. FW is responsible for choosing appropriate power states, taking Linux' usage information into account. This patchset has dependency on below drivers: Firmware Driver:

[PATCH 0/2] drivers: soc: xilinx: Add support for ZynqMP power domain driver

The zynqmp power domain driver communicates the usage requirements for logical power domains / devices to the platform FW. FW is responsible for choosing appropriate power states, taking Linux' usage information into account. This patchset has dependency on below drivers: Firmware Driver:

[PATCH 1/2] dt-bindings: power: Add ZynqMP power domain bindings

Add documentation to describe ZynqMP power domain bindings. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- .../devicetree/bindings/power/zynqmp-genpd.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644

[PATCH 1/2] dt-bindings: power: Add ZynqMP power domain bindings

Add documentation to describe ZynqMP power domain bindings. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- .../devicetree/bindings/power/zynqmp-genpd.txt | 46 ++ 1 file changed, 46 insertions(+) create mode 100644

[PATCH 2/2] drivers: soc: xilinx: Add ZynqMP power domain driver

The zynqmp-genpd driver communicates the usage requirements for logical power domains / devices to the platform FW. FW is responsible for choosing appropriate power states, taking Linux' usage information into account. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja

[PATCH 2/2] drivers: soc: xilinx: Add ZynqMP power domain driver

The zynqmp-genpd driver communicates the usage requirements for logical power domains / devices to the platform FW. FW is responsible for choosing appropriate power states, taking Linux' usage information into account. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja ---

Regression in IPMI on 4.15.6

Hi, Fedora got a bug report of a crash in IPMI on 4.15.6 https://bugzilla.redhat.com/show_bug.cgi?id=1549316 Unfortunately, it's only a screenshot but it's fairly clear. It looks like a panic in the error handling path in platform_device_unregister. Any ideas? Thanks, Laura

Regression in IPMI on 4.15.6

Hi, Fedora got a bug report of a crash in IPMI on 4.15.6 https://bugzilla.redhat.com/show_bug.cgi?id=1549316 Unfortunately, it's only a screenshot but it's fairly clear. It looks like a panic in the error handling path in platform_device_unregister. Any ideas? Thanks, Laura

Re: [PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

Hi Sai, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc3 next-20180227] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

Hi Sai, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc3 next-20180227] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

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

Re: [PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

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: Kees Cook > --- > v2: removed 'err' as it's only used for

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Wed, Feb 28, 2018 at 12:23 AM, Robert Abel wrote: > On 27 Feb 2018 23:09, Miguel Ojeda wrote:> @@ -469,24 +543,11 @@ static > inline int handle_lcd_special_code(struct charlcd *lcd) >> } >> case 'x': /* gotoxy : LxXXX[yYYY]; */ >> case 'y': /*

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Wed, Feb 28, 2018 at 12:23 AM, Robert Abel wrote: > On 27 Feb 2018 23:09, Miguel Ojeda wrote:> @@ -469,24 +543,11 @@ static > inline int handle_lcd_special_code(struct charlcd *lcd) >> } >> case 'x': /* gotoxy : LxXXX[yYYY]; */ >> case 'y': /* gotoxy :

Re: [PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On Tue, Feb 27, 2018 at 3:31 PM, 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:

Re: [PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On Tue, Feb 27, 2018 at 3:31 PM, 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 Acked-by: Kees

[PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

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: removed empty line between between

[PATCH v2 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

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: removed empty line between between sysctl_head_grab and IS_ERR ---

[PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

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 --- v2: removed 'err' as it's only used for sysctl_follow_link() --- fs/proc/proc_sysctl.c | 9 +++-- 1 file

[PATCH v2 2/2] fs/sysctl: remove redundant link check in proc_sys_link_fill_cache()

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 --- v2: removed 'err' as it's only used for sysctl_follow_link() --- fs/proc/proc_sysctl.c | 9 +++-- 1 file changed, 3 insertions(+), 6

Re: [RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

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 actually non-fatal if the firmware cache > is already setup, so just

Re: [RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

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 actually non-fatal if the firmware cache > is already setup, so just return 0, and

Re: [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

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 resume the firmware is reliably available. We never > were checking for

Re: [RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

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 resume the firmware is reliably available. We never > were checking for success for this call

Re: [PATCH] mm:swap: do not check readahead flag with THP anon

On Wed, Feb 28, 2018 at 08:26:11AM +0900, Minchan Kim wrote: > Huang reported PG_readahead flag marked PF_NO_COMPOUND so that > we cannot use the flag for THP page. So, we need to check first > whether page is THP or not before using TestClearPageReadahead > in lookup_swap_cache. > > This patch

Re: [PATCH] mm:swap: do not check readahead flag with THP anon

On Wed, Feb 28, 2018 at 08:26:11AM +0900, Minchan Kim wrote: > Huang reported PG_readahead flag marked PF_NO_COMPOUND so that > we cannot use the flag for THP page. So, we need to check first > whether page is THP or not before using TestClearPageReadahead > in lookup_swap_cache. > > This patch

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

Hi Willy, On 27 Feb 2018 06:19, Willy Tarreau wrote: > Well actually I don't see a problem there at all. The principle is simply > to accept any sequence assigning x or y or both. If you write x4y2x6, it > simply means that you changed your mind regarding x and that the last > value (6) is the

Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands

Hi Willy, On 27 Feb 2018 06:19, Willy Tarreau wrote: > Well actually I don't see a problem there at all. The principle is simply > to accept any sequence assigning x or y or both. If you write x4y2x6, it > simply means that you changed your mind regarding x and that the last > value (6) is the

Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

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/firmware/fallback-mechanisms.rst | 2 +- > drivers/base/firmware_fallback.c

Re: [RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

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/firmware/fallback-mechanisms.rst | 2 +- > drivers/base/firmware_fallback.c | 4 ++-- > 2

[PATCH] mm:swap: do not check readahead flag with THP anon

Huang reported PG_readahead flag marked PF_NO_COMPOUND so that we cannot use the flag for THP page. So, we need to check first whether page is THP or not before using TestClearPageReadahead in lookup_swap_cache. This patch fixes it. Furthermore, swap_[cluster|vma]_readahead cannot mark

[PATCH] mm:swap: do not check readahead flag with THP anon

Huang reported PG_readahead flag marked PF_NO_COMPOUND so that we cannot use the flag for THP page. So, we need to check first whether page is THP or not before using TestClearPageReadahead in lookup_swap_cache. This patch fixes it. Furthermore, swap_[cluster|vma]_readahead cannot mark

[RFT 0/7] firmware: enable caching of firmware for reboot optimization

and let me know if it fixes your reported issue. They depend on other pending patches I have in line waiting to be merged so the easiest I thing I think is for you to test my 20180227-firmware-cache branch [0], based on Linus' tree. To get that tree, cd into your Linus git tree and do: git remote

[RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

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

[PATCH 2/2] drivers: soc: xilinx: Add ZynqMP PM driver

Add ZynqMP PM driver. PM driver provides power management support for ZynqMP. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- drivers/soc/Makefile| 1 + drivers/soc/xilinx/Kconfig | 2 +

[PATCH 1/2] dt-bindings: soc: Add ZynqMP PM bindings

Add documentation to describe Xilinx ZynqMP power management bindings. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- .../bindings/soc/xilinx/xlnx,zynqmp-power.txt | 28 ++ 1 file changed, 28 insertions(+) create mode

[RFT 0/7] firmware: enable caching of firmware for reboot optimization

and let me know if it fixes your reported issue. They depend on other pending patches I have in line waiting to be merged so the easiest I thing I think is for you to test my 20180227-firmware-cache branch [0], based on Linus' tree. To get that tree, cd into your Linus git tree and do: git remote

[RFT 1/7] rename: _request_firmware_load() fw_load_sysfs_fallback()

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

[PATCH 2/2] drivers: soc: xilinx: Add ZynqMP PM driver

Add ZynqMP PM driver. PM driver provides power management support for ZynqMP. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- drivers/soc/Makefile| 1 + drivers/soc/xilinx/Kconfig | 2 + drivers/soc/xilinx/Makefile | 2 +

[PATCH 1/2] dt-bindings: soc: Add ZynqMP PM bindings

Add documentation to describe Xilinx ZynqMP power management bindings. Signed-off-by: Jolly Shah Signed-off-by: Rajan Vaja --- .../bindings/soc/xilinx/xlnx,zynqmp-power.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644

[PATCH 0/2] drivers: soc: xilinx: Add support for ZynqMP PM driver

Add ZynqMP PM driver. PM driver provides power management support for ZynqMP. This patchset has dependency on below drivers: Firmware Driver: https://patchwork.kernel.org/patch/10230773/ IPI Mailbox Driver: https://patchwork.kernel.org/patch/10145799/ Jolly Shah (2): dt-bindings: soc: Add

[PATCH 0/2] drivers: soc: xilinx: Add support for ZynqMP PM driver

Add ZynqMP PM driver. PM driver provides power management support for ZynqMP. This patchset has dependency on below drivers: Firmware Driver: https://patchwork.kernel.org/patch/10230773/ IPI Mailbox Driver: https://patchwork.kernel.org/patch/10145799/ Jolly Shah (2): dt-bindings: soc: Add

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >> >> On 27/02/2018 06:01, Andy Lutomirski wrote: >>> >>> On Feb 26, 2018, at 8:17 PM, Andy Lutomirski wrote:

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün wrote: >> >> On 27/02/2018 06:01, Andy Lutomirski wrote: >>> >>> On Feb 26, 2018, at 8:17 PM, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün

Re: [PATCH] test_kmod: fix limit check on number of test devices created

On Fri, Feb 23, 2018 at 7:00 PM, Luis R. Rodriguez wrote: > As reported by Dan the parentheses is in the wrong place, and since > unlikely() call returns either 0 or 1 it's never less than zero. > The second issue is that signed integer overflows like "INT_MAX + 1" are >

Re: [PATCH 12/12] i2c: qup: reorganization of driver code to remove polling for qup v2

On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Following are the major issues in current driver code 1. The current driver simply assumes the transfer completion whenever its gets any non-error interrupts and then simply do the polling of available/free bytes in FIFO. 2. The block mode is

Re: [PATCH] test_kmod: fix limit check on number of test devices created

On Fri, Feb 23, 2018 at 7:00 PM, Luis R. Rodriguez wrote: > As reported by Dan the parentheses is in the wrong place, and since > unlikely() call returns either 0 or 1 it's never less than zero. > The second issue is that signed integer overflows like "INT_MAX + 1" are > undefined behavior. > >

Re: [PATCH 12/12] i2c: qup: reorganization of driver code to remove polling for qup v2

On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Following are the major issues in current driver code 1. The current driver simply assumes the transfer completion whenever its gets any non-error interrupts and then simply do the polling of available/free bytes in FIFO. 2. The block mode is

[RFT 4/7] 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.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git

[RFT 4/7] 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.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/base/firmware_loader.c

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On 27 Feb 2018 23:09, Miguel Ojeda wrote:> @@ -469,24 +543,11 @@ static inline int handle_lcd_special_code(struct charlcd *lcd) > } > case 'x': /* gotoxy : LxXXX[yYYY]; */ > case 'y': /* gotoxy : LyYYY[xXXX]; */ > - if (!strchr(esc, ';')) > -

Re: [PATCH RFC v3] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On 27 Feb 2018 23:09, Miguel Ojeda wrote:> @@ -469,24 +543,11 @@ static inline int handle_lcd_special_code(struct charlcd *lcd) > } > case 'x': /* gotoxy : LxXXX[yYYY]; */ > case 'y': /* gotoxy : LyYYY[xXXX]; */ > - if (!strchr(esc, ';')) > -

Re: [PATCH v2 09/11] firmware: enable to force disable the fallback mechanism at run time

On Fri, Feb 23, 2018 at 6:46 PM, 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 > completely we are able to reduce the amount of kernels you need built >

Re: [PATCH v2 09/11] firmware: enable to force disable the fallback mechanism at run time

On Fri, Feb 23, 2018 at 6:46 PM, 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 > completely we are able to reduce the amount of kernels you need built > to test the

[RFT 5/7] firmware: ensure the firmware cache is not used on incompatible calls

request_firmware_into_buf() explicitly disables the firmware cache, meanwhile the firmware cache cannot be used when request_firmware_nowait() is used without the uevent. Enforce a sanity check for this to avoid future issues undocumented behaviours should misuses of the firmware cache happen

[RFT 5/7] firmware: ensure the firmware cache is not used on incompatible calls

request_firmware_into_buf() explicitly disables the firmware cache, meanwhile the firmware cache cannot be used when request_firmware_nowait() is used without the uevent. Enforce a sanity check for this to avoid future issues undocumented behaviours should misuses of the firmware cache happen

Re: [PATCH v2 08/11] firmware: enable run time change of forcing fallback loader

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > Currently one requires to test four kernel configurations to test the > firmware API completely: > > 0) > CONFIG_FW_LOADER=y > > 1) > o CONFIG_FW_LOADER=y > o CONFIG_FW_LOADER_USER_HELPER=y > > 2) > o

Re: [PATCH v2 08/11] firmware: enable run time change of forcing fallback loader

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > Currently one requires to test four kernel configurations to test the > firmware API completely: > > 0) > CONFIG_FW_LOADER=y > > 1) > o CONFIG_FW_LOADER=y > o CONFIG_FW_LOADER_USER_HELPER=y > > 2) > o CONFIG_FW_LOADER=y > o

[RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

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 resume the firmware is reliably available. We never were checking for success for this call though, meaning in some really rare cases we my have never setup

[RFT 2/7] firmware: fix checking for return values for fw_add_devm_name()

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 resume the firmware is reliably available. We never were checking for success for this call though, meaning in some really rare cases we my have never setup

[RFT 6/7] firmware: add request_firmware_cache() to help with cache on reboot

Some devices have an optimization in place to enable the firmware to be retaineed during a system reboot, so after reboot the device can skip requesting and loading the firmware. This can save up to 1s in load time. The mt7601u 802.11 device happens to be such a device. When these devices retain

[RFT 6/7] firmware: add request_firmware_cache() to help with cache on reboot

Some devices have an optimization in place to enable the firmware to be retaineed during a system reboot, so after reboot the device can skip requesting and loading the firmware. This can save up to 1s in load time. The mt7601u 802.11 device happens to be such a device. When these devices retain

[RFT 7/7] mt7601u: use request_firmware_cache() to address cache on reboot

request_firmware_cache() will ensure the firmware is available on resume from suspend if on reboot the device retains the firmware. This optimization is in place given otherwise on reboot we have to reload the firmware, the opmization saves us about max 1s, minimum 10ms. Reported-by: Cantabile

[RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

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

[RFT 3/7] firmware: make fw_add_devm_name() return 0 if cache present

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

[RFT 7/7] mt7601u: use request_firmware_cache() to address cache on reboot

request_firmware_cache() will ensure the firmware is available on resume from suspend if on reboot the device retains the firmware. This optimization is in place given otherwise on reboot we have to reload the firmware, the opmization saves us about max 1s, minimum 10ms. Reported-by: Cantabile

Re: [PATCH v2 06/11] firmware: move loading timeout under struct firmware_fallback_config

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > The timeout is a fallback construct, so we can just stuff the > timeout configuration under struct firmware_fallback_config. > > While at it, add a few helpers which vets the use of getting or > setting the timeout as

Re: [PATCH v2 06/11] firmware: move loading timeout under struct firmware_fallback_config

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > The timeout is a fallback construct, so we can just stuff the > timeout configuration under struct firmware_fallback_config. > > While at it, add a few helpers which vets the use of getting or > setting the timeout as an int. The main

Re: [PATCH v2 05/11] firmware: use helpers for setting up a temporary cache timeout

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > We only use the timeout for the firmware fallback mechanism > except for trying to set the timeout during the cache setup > for resume/suspend. For those cases, setting the timeout should > be a no-op, so just reflect

Re: [PATCH v2 05/11] firmware: use helpers for setting up a temporary cache timeout

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > We only use the timeout for the firmware fallback mechanism > except for trying to set the timeout during the cache setup > for resume/suspend. For those cases, setting the timeout should > be a no-op, so just reflect this in code by

Re: [PATCH v2 04/11] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

On Fri, Feb 23, 2018 at 6:46 PM, 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 further, removing now all explicit #ifdefs around the code. In the

Re: [PATCH v2 04/11] firmware: simplify CONFIG_FW_LOADER_USER_HELPER_FALLBACK further

On Fri, Feb 23, 2018 at 6:46 PM, 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 further, removing now all explicit #ifdefs around the code. In the next revision, can

Re: [PATCH 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On 2018-02-28 00:02, Kees Cook wrote: On Tue, Feb 27, 2018 at 2:43 PM, 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

Re: [PATCH 1/2] fs/sysctl: fix potential page fault while unregistering sysctl table

On 2018-02-28 00:02, Kees Cook wrote: On Tue, Feb 27, 2018 at 2:43 PM, 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:

[PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

It seems that the expression threshold_us * 1000 will never exceed the 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 seems sensible [2]. [1] https://marc.info/?l=linux-kernel=151855021100725=2 [2] https://marc.info/?l=linux-kernel=151976318924615=2

[PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

It seems that the expression threshold_us * 1000 will never exceed the 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 seems sensible [2]. [1] https://marc.info/?l=linux-kernel=151855021100725=2 [2] https://marc.info/?l=linux-kernel=151976318924615=2

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

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 to mimic such kernel configurations to test them. > > Provided you

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

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 to mimic such kernel configurations to test them. > > Provided you build a kernel with: >

Re: [PATCH v2 10/11] test_firmware: add a library for shared helpers

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > 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

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

On Sat, Feb 03, 2018 at 01:28:15PM +0530, Abhishek Sahu wrote: > According to I2c specification, “If a master-receiver sends a > repeated START condition, it sends a not-acknowledge (A) just > before the repeated START condition”. QUP v2 supports sending > of NACK without stop with

Re: [PATCH v2 10/11] test_firmware: add a library for shared helpers

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > 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 > --- >

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

On Sat, Feb 03, 2018 at 01:28:15PM +0530, Abhishek Sahu wrote: > According to I2c specification, “If a master-receiver sends a > repeated START condition, it sends a not-acknowledge (A) just > before the repeated START condition”. QUP v2 supports sending > of NACK without stop with

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

On Sat, Feb 03, 2018 at 01:28:14PM +0530, Abhishek Sahu wrote: > The BAM mode requires buffer for start tag data and tx, rx SG > list. Currently, this is being taken for maximum transfer length > (65K). But an I2C transfer can have multiple messages and each > message can be of this maximum length

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

On Sat, Feb 03, 2018 at 01:28:14PM +0530, Abhishek Sahu wrote: > The BAM mode requires buffer for start tag data and tx, rx SG > list. Currently, this is being taken for maximum transfer length > (65K). But an I2C transfer can have multiple messages and each > message can be of this maximum length

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-27 03:43, Mark Rutland wrote: On Mon, Feb 26, 2018 at 06:11:45PM -0800, skan...@codeaurora.org wrote: On 2018-02-25 06:38, Mark Rutland wrote: > On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: > > Some PMUs events can be read from any CPU. So allow the PMU to mark >

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-27 03:43, Mark Rutland wrote: On Mon, Feb 26, 2018 at 06:11:45PM -0800, skan...@codeaurora.org wrote: On 2018-02-25 06:38, Mark Rutland wrote: > On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: > > Some PMUs events can be read from any CPU. So allow the PMU to mark >

Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

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 > features. This should make it easier to maintain and review code > changes.

Re: [PATCH v2 07/11] firmware: split firmware fallback functionality into its own file

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 > features. This should make it easier to maintain and review code > changes. > > The reason for

Re: [PATCH 4.14 00/54] 4.14.23-stable review

On Tue, Feb 27, 2018 at 07:36:18PM +0100, Greg Kroah-Hartman wrote: > On Tue, Feb 27, 2018 at 06:38:59AM -0800, Guenter Roeck wrote: > > On 02/27/2018 05:08 AM, Greg Kroah-Hartman wrote: > > > On Tue, Feb 27, 2018 at 02:59:39AM -0800, Guenter Roeck wrote: > > > > On 02/26/2018 12:21 PM, Greg

Re: [PATCH 4.14 00/54] 4.14.23-stable review

On Tue, Feb 27, 2018 at 07:36:18PM +0100, Greg Kroah-Hartman wrote: > On Tue, Feb 27, 2018 at 06:38:59AM -0800, Guenter Roeck wrote: > > On 02/27/2018 05:08 AM, Greg Kroah-Hartman wrote: > > > On Tue, Feb 27, 2018 at 02:59:39AM -0800, Guenter Roeck wrote: > > > > On 02/26/2018 12:21 PM, Greg

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Feb 27, 2018 at 10:03 PM, Mickaël Salaün wrote: > > On 27/02/2018 05:36, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün wrote: >>> Hi, >>> >>> >>> ## Why use the seccomp(2) syscall? >>> >>> Landlock use the same semantic as

Re: [PATCH bpf-next v8 00/11] Landlock LSM: Toward unprivileged sandboxing

On Tue, Feb 27, 2018 at 10:03 PM, Mickaël Salaün wrote: > > On 27/02/2018 05:36, Andy Lutomirski wrote: >> On Tue, Feb 27, 2018 at 12:41 AM, Mickaël Salaün wrote: >>> Hi, >>> >>> >>> ## Why use the seccomp(2) syscall? >>> >>> Landlock use the same semantic as seccomp to apply access rule >>>

Re: [PATCH v2 02/11] test_firmware: replace syfs fallback check with kconfig_has helper

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > 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. I don't see the reason to depend on config.gz, but it's a

Re: [PATCH v2 02/11] test_firmware: replace syfs fallback check with kconfig_has helper

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > 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. I don't see the reason to depend on config.gz, but it's a reasonable requirement

Re: [PATCH v2 01/11] test_firmware: enable custom fallback testing on limited kernel configs

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > When a kernel is not built with: > > CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y > > We don't currently enable testing fw_fallback.sh. For kernels that > still enable the fallback mechanism, its possible to use the

Re: [PATCH v2 01/11] test_firmware: enable custom fallback testing on limited kernel configs

On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez wrote: > When a kernel is not built with: > > CONFIG_HAS_FW_LOADER_USER_HELPER_FALLBACK=y > > We don't currently enable testing fw_fallback.sh. For kernels that > still enable the fallback mechanism, its possible to use the async > request

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