Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, Mar 09, 2018 at 04:21:37PM -0800, Daniel Lustig wrote: > On 3/9/2018 2:57 PM, Palmer Dabbelt wrote: > > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.and...@gmail.com wrote: > >> On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: > >>> On Fri, 09 Mar 2018 10:36:44 PST

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, Mar 09, 2018 at 04:21:37PM -0800, Daniel Lustig wrote: > On 3/9/2018 2:57 PM, Palmer Dabbelt wrote: > > On Fri, 09 Mar 2018 13:30:08 PST (-0800), parri.and...@gmail.com wrote: > >> On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: > >>> On Fri, 09 Mar 2018 10:36:44 PST

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

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 CONFIG_FW_LOADER_USER_HELPER=y o CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y 3) When

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

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 CONFIG_FW_LOADER_USER_HELPER=y o CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y 3) When

[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

[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 --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 2 +- drivers/base/firmware_loader/fallback.c | 13 ++--- 2 files changed, 11

[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

Users of the custom firmware fallback interface is are not supposed to use the firmware cache interface, this can happen if for instance the one of the APIs which use the firmware cache is used first with one firmware file and then the request_firmware_nowait(uevent=false) API is used with the

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

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. fw_add_devm_name() adds device's name onto the

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

Users of the custom firmware fallback interface is are not supposed to use the firmware cache interface, this can happen if for instance the one of the APIs which use the firmware cache is used first with one firmware file and then the request_firmware_nowait(uevent=false) API is used with the

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

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. fw_add_devm_name() adds device's name onto the

[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

[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

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

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

[PATCH v3 18/20] 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

[PATCH v3 18/20] 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

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

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: CONFIG_TEST_FIRMWARE=y CONFIG_FW_LOADER=y

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

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: CONFIG_TEST_FIRMWARE=y CONFIG_FW_LOADER=y

[PATCH v3 19/20] 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

[PATCH v3 19/20] 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

[PATCH v3 20/20] 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. Cantabile has reported

[PATCH v3 20/20] 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. Cantabile has reported

[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

[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

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 working on and the addition of the new API call request_firmware_cache() for fixing a corner case suspend issue on some type of cards with an optimization in place where the firmware

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

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 working on and the addition of the new API call request_firmware_cache() for fixing a corner case suspend issue on some type of cards with an optimization in place where the firmware

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

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 find who is

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] EDAC, sb_edac: Remove VLA usage

On Fri, Mar 09, 2018 at 09:02:18PM -0600, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. > > Fixed as part of the directive to remove all VLAs from > the kernel: https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by:

Re: [PATCH] EDAC, sb_edac: Remove VLA usage

On Fri, Mar 09, 2018 at 09:02:18PM -0600, Gustavo A. R. Silva wrote: > In preparation to enabling -Wvla, remove VLA and replace it > with a fixed-length array instead. > > Fixed as part of the directive to remove all VLAs from > the kernel: https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by:

Re: [PATCH v2 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

Hi Tim, On Mon, Mar 5, 2018 at 7:02 PM, Tim Harvey wrote: > + > + hwmon@1 { /* A1: Input Voltage */ > + type = <1>; > + reg = <0x02>; Unit address (@1) does not match the 'reg' value. If

Re: [PATCH v2 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings

Hi Tim, On Mon, Mar 5, 2018 at 7:02 PM, Tim Harvey wrote: > + > + hwmon@1 { /* A1: Input Voltage */ > + type = <1>; > + reg = <0x02>; Unit address (@1) does not match the 'reg' value. If someone build this

Re: [RFC PATCH -tip 0/9] kprobes: Cleanup jprobe implementation

On Fri, 9 Mar 2018 18:54:02 -0500 Steven Rostedt wrote: > On Fri, 9 Mar 2018 21:35:17 +0900 > Masami Hiramatsu wrote: > > > Hello, > > > > Since we decided to remove jprobe from kernel last year, > > its APIs are disabled and we worked on moving

Re: [RFC PATCH -tip 0/9] kprobes: Cleanup jprobe implementation

On Fri, 9 Mar 2018 18:54:02 -0500 Steven Rostedt wrote: > On Fri, 9 Mar 2018 21:35:17 +0900 > Masami Hiramatsu wrote: > > > Hello, > > > > Since we decided to remove jprobe from kernel last year, > > its APIs are disabled and we worked on moving in-kernel > > jprobe users to kprobes or

Re: [PATCH] device_handler: remove VLAs

Hi Bart, On Fri, 9 Mar 2018 22:48:10 +, Bart Van Assche wrote: > On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote: > > In preparation to enabling -Wvla, remove VLAs and replace them with > > fixed-length arrays instead. > > > > scsi_dh_{alua,emc,rdac} use

Re: [PATCH] device_handler: remove VLAs

Hi Bart, On Fri, 9 Mar 2018 22:48:10 +, Bart Van Assche wrote: > On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote: > > In preparation to enabling -Wvla, remove VLAs and replace them with > > fixed-length arrays instead. > > > > scsi_dh_{alua,emc,rdac} use variable-length array

[GIT PULL] Kbuild fixes for v4.16-rc5

Hi Linus, Please pull more Kbuild fixes for v4.16. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git

[GIT PULL] Kbuild fixes for v4.16-rc5

Hi Linus, Please pull more Kbuild fixes for v4.16. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

Hi Bart, On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche wrote: > On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: > > +/* > > + * SCSI command sizes are as follows, in bytes, for fixed size commands, > > per > > + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

Hi Bart, On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche wrote: > On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: > > +/* > > + * SCSI command sizes are as follows, in bytes, for fixed size commands, > > per > > + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Sat, Mar 10, 2018 at 12:50:46PM +0100, Linus Walleij wrote: > On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer > wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked up by

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Sat, Mar 10, 2018 at 12:50:46PM +0100, Linus Walleij wrote: > On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer > wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > > and

arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cdb06e9d8f520c969676e7d6778cffe5894f079f commit: 101110f6271ce956a049250c907bc960030577f8 Kbuild: always define endianess in kconfig.h date: 2 weeks ago config: h8300-h8300h-sim_defconfig (attached as

arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: cdb06e9d8f520c969676e7d6778cffe5894f079f commit: 101110f6271ce956a049250c907bc960030577f8 Kbuild: always define endianess in kconfig.h date: 2 weeks ago config: h8300-h8300h-sim_defconfig (attached as

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 14:12, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: >> Without them, it is easy to crash the driver when just playing with >> microcode files > > You're not supposed to play with the microcode files. If you do and > something breaks,

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 14:12, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: >> Without them, it is easy to crash the driver when just playing with >> microcode files > > You're not supposed to play with the microcode files. If you do and > something breaks,

[PATCH] ARM: dts: uniphier: use proper SPDX-License-Identifier style

According to Documentation/process/license-rules.rst, move the SPDX License Identifier to the very top of the file. I used C++ comment style not only for the SPDX line but for the entire block because this seems Linus' preference [1]. I also dropped the parentheses to follow the examples in that

[PATCH] ARM: dts: uniphier: use proper SPDX-License-Identifier style

According to Documentation/process/license-rules.rst, move the SPDX License Identifier to the very top of the file. I used C++ comment style not only for the SPDX line but for the entire block because this seems Linus' preference [1]. I also dropped the parentheses to follow the examples in that

[PATCH] arm64: dts: uniphier: use proper SPDX-License-Identifier style

According to Documentation/process/license-rules.rst, move the SPDX License Identifier to the very top of the file. I used C++ comment style not only for the SPDX line but for the entire block because this seems Linus' preference [1]. I also dropped the parentheses to follow the examples in that

[PATCH] arm64: dts: uniphier: use proper SPDX-License-Identifier style

According to Documentation/process/license-rules.rst, move the SPDX License Identifier to the very top of the file. I used C++ comment style not only for the SPDX line but for the entire block because this seems Linus' preference [1]. I also dropped the parentheses to follow the examples in that

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On Fri, Mar 09, 2018 at 06:06:29PM -0500, Waiman Long wrote: > So you are talking about sched_relax_domain_level and That one I wouldn't be sad to see the back of. > sched_load_balance. This one, that's critical. And this is the perfect time to try and fix the whole isolcpus issue. The primary

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On Fri, Mar 09, 2018 at 06:06:29PM -0500, Waiman Long wrote: > So you are talking about sched_relax_domain_level and That one I wouldn't be sad to see the back of. > sched_load_balance. This one, that's critical. And this is the perfect time to try and fix the whole isolcpus issue. The primary

Re: 4.16-rc3 fails to resume on MacBookPro10,1 -

Hi! > > Ok, I've just tested linux-next, and it works ok for me on thinkpad > > x60. (But that's probably rather different configuration from the > > macbook). > > > > Unfortunately, I could not deduce anything useful from the > > backtraces. Andrew, could you try v4.15 with KPTI disabled ? > > >

Re: 4.16-rc3 fails to resume on MacBookPro10,1 -

Hi! > > Ok, I've just tested linux-next, and it works ok for me on thinkpad > > x60. (But that's probably rather different configuration from the > > macbook). > > > > Unfortunately, I could not deduce anything useful from the > > backtraces. Andrew, could you try v4.15 with KPTI disabled ? > > >

Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b

On 9.3.2018 20:05, Rob Herring wrote: > On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. wrote: >> Hi, >> >> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b >> makes microblaze unbootable. >> >> I'm sorry I can't provide any console output, as nothing

Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b

On 9.3.2018 20:05, Rob Herring wrote: > On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. wrote: >> Hi, >> >> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b >> makes microblaze unbootable. >> >> I'm sorry I can't provide any console output, as nothing appears at all, >> even

Re: KASAN: use-after-free Read in sctp_association_free (2)

On Sat, Mar 10, 2018 at 03:58:04PM +0800, Xin Long wrote: > On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman wrote: > > On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote: > >> Hello, > >> > >> syzbot hit the following crash on net-next commit > >>

Re: KASAN: use-after-free Read in sctp_association_free (2)

On Sat, Mar 10, 2018 at 03:58:04PM +0800, Xin Long wrote: > On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman wrote: > > On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote: > >> Hello, > >> > >> syzbot hit the following crash on net-next commit > >> fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu

Re: [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

Hi Andrew, Thank you very much for taking care of this. Please find my answers to your remarks below. On Fri, 9 Mar 2018 14:12:52 -0800 Andrew Morton wrote: > On Fri, 09 Mar 2018 21:41:38 +0100 Greg Kurz wrote: > > > If it was interrupted by a

Re: [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

Hi Andrew, Thank you very much for taking care of this. Please find my answers to your remarks below. On Fri, 9 Mar 2018 14:12:52 -0800 Andrew Morton wrote: > On Fri, 09 Mar 2018 21:41:38 +0100 Greg Kurz wrote: > > > If it was interrupted by a signal, the 9p client may need to send some > >

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: > Without them, it is easy to crash the driver when just playing with > microcode files You're not supposed to play with the microcode files. If you do and something breaks, you get to keep the pieces. If the official microcode

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On Sat, Mar 10, 2018 at 01:26:00PM +0100, Maciej S. Szmigiero wrote: > Without them, it is easy to crash the driver when just playing with > microcode files You're not supposed to play with the microcode files. If you do and something breaks, you get to keep the pieces. If the official microcode

Re: [PATCH v3 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

On Thu, 2018-03-08 at 13:47 -0800, J Freyensee wrote: > Looks better :-). > > > Acked-by: Jay Freyensee Thank you. /Jarkko

Re: [PATCH v3 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

On Thu, 2018-03-08 at 13:47 -0800, J Freyensee wrote: > Looks better :-). > > > Acked-by: Jay Freyensee Thank you. /Jarkko

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote: > On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare wrote: > > However it doesn't make sense to commit this change unless there will > > be at least one user of it. What is the status of the piece of code > > which was supposed to

Re: [PATCH][V2] firmware: dmi_scan: add DMI_OEM_STRING support to dmi_matches

On Fri, 9 Mar 2018 10:56:07 -0800, Alex Hung wrote: > On Fri, Mar 9, 2018 at 5:33 AM, Jean Delvare wrote: > > However it doesn't make sense to commit this change unless there will > > be at least one user of it. What is the status of the piece of code > > which was supposed to use this new

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Wed, 2018-03-07 at 11:35 -0500, Mimi Zohar wrote: > On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > > On Tue, 06 Mar 2018 13:36:36 -0500 > > Mimi Zohar wrote: > > > > > I've heard that some maintainers are moving away from cover letters, > > > since they

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Wed, 2018-03-07 at 11:35 -0500, Mimi Zohar wrote: > On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > > On Tue, 06 Mar 2018 13:36:36 -0500 > > Mimi Zohar wrote: > > > > > I've heard that some maintainers are moving away from cover letters, > > > since they are not include in the git

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > On Tue, 06 Mar 2018 13:36:36 -0500 > Mimi Zohar wrote: > > > I've heard that some maintainers are moving away from cover letters, > > since they are not include in the git repo and are lost. > > If I get a

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Wed, 2018-03-07 at 08:54 -0700, Jonathan Corbet wrote: > On Tue, 06 Mar 2018 13:36:36 -0500 > Mimi Zohar wrote: > > > I've heard that some maintainers are moving away from cover letters, > > since they are not include in the git repo and are lost. > > If I get a patch series with a cover

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Tue, 2018-03-06 at 13:36 -0500, Mimi Zohar wrote: > I've heard that some maintainers are moving away from cover letters, > since they are not include in the git repo and are lost. I've seen > Andrew Morton cut and paste the cover letter in the first patch > description of the patch set. When

Re: [PATCH 1/3 RESEND] tpm: add longer timeouts for creation commands.

On Tue, 2018-03-06 at 13:36 -0500, Mimi Zohar wrote: > I've heard that some maintainers are moving away from cover letters, > since they are not include in the git repo and are lost. I've seen > Andrew Morton cut and paste the cover letter in the first patch > description of the patch set. When

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 10:18, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode file since it does very little >> consistency checking on data loaded

Re: [PATCH] x86/microcode/AMD: check microcode file sanity before loading it

On 10.03.2018 10:18, Borislav Petkov wrote: > On Sat, Mar 10, 2018 at 01:34:45AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode file since it does very little >> consistency checking on data loaded

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Fri, 09 Mar 2018 21:36:12 +, Christoffer Dall wrote: > > On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: > > I'd be more confident if we did forbid P+A for such interrupts > > altogether, as they really feel like another kind of HW interrupt. > > How about a slightly bigger

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Fri, 09 Mar 2018 21:36:12 +, Christoffer Dall wrote: > > On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: > > I'd be more confident if we did forbid P+A for such interrupts > > altogether, as they really feel like another kind of HW interrupt. > > How about a slightly bigger

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

Hi! On Sat 2018-03-10 12:19:29, Lars-Peter Clausen wrote: > On 03/10/2018 12:01 AM, Pavel Machek wrote: > [...] > >> What file are you opening to cause this? > > > > Strace says: > > > > openat(7, "in_intensity_both_thresh_rising_en", > >>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3 > > fstat64(3,

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

Hi! On Sat 2018-03-10 12:19:29, Lars-Peter Clausen wrote: > On 03/10/2018 12:01 AM, Pavel Machek wrote: > [...] > >> What file are you opening to cause this? > > > > Strace says: > > > > openat(7, "in_intensity_both_thresh_rising_en", > >>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3 > > fstat64(3,

Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions

On Thu, Mar 8, 2018 at 9:36 PM, Alex Lemberg wrote: > On 3/2/18 4:53 AM, Linus Walleij wrote: >> What we need to do is make the "special partitions" part of the >> main block device and stop spawning these special block >> devices for each boot partions or general

Re: [PATCH] mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions

On Thu, Mar 8, 2018 at 9:36 PM, Alex Lemberg wrote: > On 3/2/18 4:53 AM, Linus Walleij wrote: >> What we need to do is make the "special partitions" part of the >> main block device and stop spawning these special block >> devices for each boot partions or general partitions. In addition, >>

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer wrote: > The aim of this patchset is to move the GPIO subsystem's documentation > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > and compiled into HTML. Awesome! > I moved everything except

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer wrote: > The aim of this patchset is to move the GPIO subsystem's documentation > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > and compiled into HTML. Awesome! > I moved everything except for sysfs.txt, because

Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally

On Sat, 10 Mar 2018 03:23:18 +, peng hao wrote: > >> For emulation devices just like vga, keeping coherent dcache between > >> guest and host timely is needed. > >> Now the display of vnc-viewer will not update continuously and the > >> patch can fix up. > >> > >> Signed-off-by: Peng Hao

Re: [PATCH] KVM:arm/arm64: dcache need be coherent unconditionally

On Sat, 10 Mar 2018 03:23:18 +, peng hao wrote: > >> For emulation devices just like vga, keeping coherent dcache between > >> guest and host timely is needed. > >> Now the display of vnc-viewer will not update continuously and the > >> patch can fix up. > >> > >> Signed-off-by: Peng Hao >

Re: Nokia N900: refcount_t underflow, use after free

Hi! > >>> Well, there certainly seems to be an obvious bug wherein > >>> isp_detach_iommu() just releases the mapping directly without calling > >>> arm_iommu_detach_device() to balance the equivalent attach. That can't > >>> be helping. > >> > >> Indeed, I have been able to reproduce the same

Re: [PATCH 09/11] media: vsp1: Provide support for extended command pools

On 09/03/18 22:04, Kieran Bingham wrote: > VSPD and VSP-DL devices can provide extended display lists supporting > extended command display list objects. > > These extended commands require their own dma memory areas for a header > and body specific to the command type. > > Implement a command

Re: Nokia N900: refcount_t underflow, use after free

Hi! > >>> Well, there certainly seems to be an obvious bug wherein > >>> isp_detach_iommu() just releases the mapping directly without calling > >>> arm_iommu_detach_device() to balance the equivalent attach. That can't > >>> be helping. > >> > >> Indeed, I have been able to reproduce the same

Re: [PATCH 09/11] media: vsp1: Provide support for extended command pools

On 09/03/18 22:04, Kieran Bingham wrote: > VSPD and VSP-DL devices can provide extended display lists supporting > extended command display list objects. > > These extended commands require their own dma memory areas for a header > and body specific to the command type. > > Implement a command

Re: [PATCH 3/5 V2] tpm2: add longer timeouts for creation commands.

On Tue, 2018-03-06 at 15:19 +, Winkler, Tomas wrote: > > On Tue, 2018-03-06 at 11:25 +0200, Tomas Winkler wrote: > > > TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve > > > generation of crypto keys which can be a computationally intensive task. > > > The timeout is set to

Re: [PATCH 3/5 V2] tpm2: add longer timeouts for creation commands.

On Tue, 2018-03-06 at 15:19 +, Winkler, Tomas wrote: > > On Tue, 2018-03-06 at 11:25 +0200, Tomas Winkler wrote: > > > TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve > > > generation of crypto keys which can be a computationally intensive task. > > > The timeout is set to

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

2018-03-10 8:01 GMT+09:00 Pavel Machek : > Hi! > >> > Hmm. Looks like there's a lot of fun to be had with sysfs. >> > >> > >> > pavel@n900:~$ uname -a >> > Linux n900 4.16.0-rc4-59690-g7f84626-dirty #543 Thu Mar 8 19:53:30 CET >> > 2018 armv7l GNU/Linux >> > >> > [ 306.402496]

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

2018-03-10 8:01 GMT+09:00 Pavel Machek : > Hi! > >> > Hmm. Looks like there's a lot of fun to be had with sysfs. >> > >> > >> > pavel@n900:~$ uname -a >> > Linux n900 4.16.0-rc4-59690-g7f84626-dirty #543 Thu Mar 8 19:53:30 CET >> > 2018 armv7l GNU/Linux >> > >> > [ 306.402496] bq2415x: command

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

On 03/10/2018 12:01 AM, Pavel Machek wrote: [...] >> What file are you opening to cause this? > > Strace says: > > openat(7, "in_intensity_both_thresh_rising_en", >>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 > ioctl(3, SNDCTL_TMR_TIMEBASE

Re: Nokia N900: v4.16-rc4: oops in iio when grepping sysfs

On 03/10/2018 12:01 AM, Pavel Machek wrote: [...] >> What file are you opening to cause this? > > Strace says: > > openat(7, "in_intensity_both_thresh_rising_en", >>> O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 > ioctl(3, SNDCTL_TMR_TIMEBASE

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > On Fri, 9 Mar 2018 00:40:16 +0100 > Jonathan Neuschäfer wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked

Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST

On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > On Fri, 9 Mar 2018 00:40:16 +0100 > Jonathan Neuschäfer wrote: > > > The aim of this patchset is to move the GPIO subsystem's documentation > > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > > and

<    1   2   3   4   5   6   7   >