Re: [PATCH 2/6] dt-bindings: arm: Document RDA8810PL and Orange Pi 2G-IoT

On Tue, Jun 27, 2017 at 02:55:16AM +0200, Andreas Färber wrote: > Add bindings for RDA Micro RDA8810PL SoC and Orange Pi 2G-IoT board. > > Cc: serv...@rdamicro.com > Cc: zhao_ste...@263.net > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/arm/rda.txt |

Re: [PATCH 2/6] dt-bindings: arm: Document RDA8810PL and Orange Pi 2G-IoT

On Tue, Jun 27, 2017 at 02:55:16AM +0200, Andreas Färber wrote: > Add bindings for RDA Micro RDA8810PL SoC and Orange Pi 2G-IoT board. > > Cc: serv...@rdamicro.com > Cc: zhao_ste...@263.net > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/arm/rda.txt | 17

Re: [PATCH 1/6] dt-bindings: Add RDA Micro vendor prefix

On Tue, Jun 27, 2017 at 02:55:15AM +0200, Andreas Färber wrote: > RDA Microelectronics is a Chinese SoC manufacturer. > > Cc: serv...@rdamicro.com > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1

Re: [PATCH 1/6] dt-bindings: Add RDA Micro vendor prefix

On Tue, Jun 27, 2017 at 02:55:15AM +0200, Andreas Färber wrote: > RDA Microelectronics is a Chinese SoC manufacturer. > > Cc: serv...@rdamicro.com > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

From: Andrew Lunn Date: Thu, 29 Jun 2017 20:22:16 +0200 Is less broken a sufficient criteria for acceptance? Sometimes, it depends upon the situation. If you are continuing to resolve those issues, I'll wait and watch for future respins then.

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

From: Andrew Lunn Date: Thu, 29 Jun 2017 20:22:16 +0200 Is less broken a sufficient criteria for acceptance? Sometimes, it depends upon the situation. If you are continuing to resolve those issues, I'll wait and watch for future respins then.

Re: [PATCH] atmel_mxt_ts: Add support for reset line

On Tue, Jun 27, 2017 at 06:24:38PM +0200, Sebastian Reichel wrote: > At least some of the Atmel Maxtouch touchscreen controllers have a reset > pin. If this is not driven correctly the device will be held in reset > and will not respond. > > Add support for driving the reset line via GPIO as is

Re: [PATCH] atmel_mxt_ts: Add support for reset line

On Tue, Jun 27, 2017 at 06:24:38PM +0200, Sebastian Reichel wrote: > At least some of the Atmel Maxtouch touchscreen controllers have a reset > pin. If this is not driven correctly the device will be held in reset > and will not respond. > > Add support for driving the reset line via GPIO as is

Re: [systemd-devel] [PATCH] firmware: wake all waiters

On 06/28/2017 06:06 PM, Luis R. Rodriguez wrote: On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering wrote: On Wed, 28.06.17 00:24, Luis R. Rodriguez (mcg...@kernel.org) wrote: I think it was first packaged into systemd, and then it was split out to help those who want

Re: [systemd-devel] [PATCH] firmware: wake all waiters

On 06/28/2017 06:06 PM, Luis R. Rodriguez wrote: On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering wrote: On Wed, 28.06.17 00:24, Luis R. Rodriguez (mcg...@kernel.org) wrote: I think it was first packaged into systemd, and then it was split out to help those who want it external.

Re: [PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

On Wed, 28 Jun 2017 17:27:32 +1000 Alexey Kardashevskiy wrote: > On 24/06/17 01:17, Alex Williamson wrote: > > On Fri, 23 Jun 2017 15:06:37 +1000 > > Alexey Kardashevskiy wrote: > > > >> On 23/06/17 07:11, Alex Williamson wrote: > >>> On Thu, 15 Jun 2017

Re: [PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

On Wed, 28 Jun 2017 17:27:32 +1000 Alexey Kardashevskiy wrote: > On 24/06/17 01:17, Alex Williamson wrote: > > On Fri, 23 Jun 2017 15:06:37 +1000 > > Alexey Kardashevskiy wrote: > > > >> On 23/06/17 07:11, Alex Williamson wrote: > >>> On Thu, 15 Jun 2017 15:48:42 +1000 > >>> Alexey

Re: [PATCH 1/6] net: stmmac: support future possible different internal phy mode

From: Corentin Labbe Date: Thu, 29 Jun 2017 19:02:38 +0200 > On Thu, Jun 29, 2017 at 12:23:49PM -0400, David Miller wrote: >> From: Corentin Labbe >> Date: Tue, 27 Jun 2017 11:28:01 +0200 >> >> > The current way to find if the phy is

Re: [PATCH 1/6] net: stmmac: support future possible different internal phy mode

From: Corentin Labbe Date: Thu, 29 Jun 2017 19:02:38 +0200 > On Thu, Jun 29, 2017 at 12:23:49PM -0400, David Miller wrote: >> From: Corentin Labbe >> Date: Tue, 27 Jun 2017 11:28:01 +0200 >> >> > The current way to find if the phy is internal is to compare DT phy-mode >> > and

[PATCH v2 4/4] squashfs: Add zstd support

Add zstd compression and decompression support to SquashFS. zstd is a great fit for SquashFS because it can compress at ratios approaching xz, while decompressing twice as fast as zlib. For SquashFS in particular, it can decompress as fast as lzo and lz4. It also has the flexibility to turn down

[PATCH v2 4/4] squashfs: Add zstd support

Add zstd compression and decompression support to SquashFS. zstd is a great fit for SquashFS because it can compress at ratios approaching xz, while decompressing twice as fast as zlib. For SquashFS in particular, it can decompress as fast as lzo and lz4. It also has the flexibility to turn down

Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Jun 28, 2017 at 08:21:37PM +, Hunter, Adrian escreveu: >> Sorry for the top-post... >> >> Yeah, I've now mixed up the variable attribute: >> >> >>

Re: [PATCH V2 25/37] perf script: Add synthesized Intel PT power and ptwrite events

On 06/28/2017 11:26 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Jun 28, 2017 at 08:21:37PM +, Hunter, Adrian escreveu: >> Sorry for the top-post... >> >> Yeah, I've now mixed up the variable attribute: >> >> >>

Re: [tpmdd-devel] [PATCH 2/2] tpm: use tpm2_pcr_read() in tpm2_do_selftest()

On Thu, Jun 29, 2017 at 01:19:35AM +0300, Jarkko Sakkinen wrote: > On Fri, Jun 23, 2017 at 03:41:57PM +0200, Roberto Sassu wrote: > > tpm2_do_selftest() performs a PCR read during the TPM initialization phase. > > This patch replaces the PCR read code with a call to tpm2_pcr_read(). > > > >

Re: [tpmdd-devel] [PATCH 2/2] tpm: use tpm2_pcr_read() in tpm2_do_selftest()

On Thu, Jun 29, 2017 at 01:19:35AM +0300, Jarkko Sakkinen wrote: > On Fri, Jun 23, 2017 at 03:41:57PM +0200, Roberto Sassu wrote: > > tpm2_do_selftest() performs a PCR read during the TPM initialization phase. > > This patch replaces the PCR read code with a call to tpm2_pcr_read(). > > > >

Re: [PATCH net] net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()

From: Michal Kubecek Date: Thu, 29 Jun 2017 11:13:36 +0200 (CEST) > Recently I started seeing warnings about pages with refcount -1. The > problem was traced to packets being reused after their head was merged into > a GRO packet by skb_gro_receive(). While bisecting the issue

Re: [PATCH net] net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()

From: Michal Kubecek Date: Thu, 29 Jun 2017 11:13:36 +0200 (CEST) > Recently I started seeing warnings about pages with refcount -1. The > problem was traced to packets being reused after their head was merged into > a GRO packet by skb_gro_receive(). While bisecting the issue pointed to >

Re: [PATCH 1/2] tpm: use tpm_buf functions in tpm2_pcr_read()

On Thu, Jun 29, 2017 at 01:18:58AM +0300, Jarkko Sakkinen wrote: > On Fri, Jun 23, 2017 at 03:41:56PM +0200, Roberto Sassu wrote: > > tpm2_pcr_read() now builds the PCR read command buffer with tpm_buf > > functions. This solution is preferred to using a tpm2_cmd structure, > > as tpm_buf

Re: [PATCH 1/2] tpm: use tpm_buf functions in tpm2_pcr_read()

On Thu, Jun 29, 2017 at 01:18:58AM +0300, Jarkko Sakkinen wrote: > On Fri, Jun 23, 2017 at 03:41:56PM +0200, Roberto Sassu wrote: > > tpm2_pcr_read() now builds the PCR read command buffer with tpm_buf > > functions. This solution is preferred to using a tpm2_cmd structure, > > as tpm_buf

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, Paul. On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait() > must have executed before CPU 1's spin_lock(). However, even on x86, > CPU 0's prior writes can be reordered with its subsequent reads, which

Re: spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, Paul. On Thu, Jun 29, 2017 at 11:10:57AM -0700, Paul E. McKenney wrote: > If this code fragment doesn't deadlock, then CPU 0's spin_unlock_wait() > must have executed before CPU 1's spin_lock(). However, even on x86, > CPU 0's prior writes can be reordered with its subsequent reads, which

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

Quoting Alex Deucher : On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: Add function header comment to make it clear that local variable sw_cg is used for debugging and it should not be removed. Addresses-Coverity-ID: 1198635 Cc:

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

Quoting Alex Deucher : On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: Add function header comment to make it clear that local variable sw_cg is used for debugging and it should not be removed. Addresses-Coverity-ID: 1198635 Cc: Alex Deucher Signed-off-by: Gustavo A. R. Silva

Re: [PATCH] net: bridge: constify attribute_group structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 16:39:38 +0530 > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > > File size

Re: [PATCH] net: freescale: gianfar : constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:26:06 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text

Re: [PATCH] net: bridge: constify attribute_group structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 16:39:38 +0530 > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > > File size before: >text data

Re: [PATCH] net: freescale: gianfar : constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:26:06 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec

Re: [PATCH] net: constify attribute_group structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 16:31:26 +0530 > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > > File size

Re: [PATCH] net: smc91x: constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:21:00 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text

Re: [PATCH] net: constify attribute_group structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 16:31:26 +0530 > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > > File size before: >text data

Re: [PATCH] net: smc91x: constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:21:00 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec

Re: [PATCH] leds: lp55xx: make various arrays static const

Hi Colin, Thanks for the patch. Do you have some profiling results showing the benefit of these changes? It seems that these functions are called only on driver initialization. Making the local arrays static will prevent releasing this memory even though it will be no longer needed. Anyway, the

Re: [PATCH] leds: lp55xx: make various arrays static const

Hi Colin, Thanks for the patch. Do you have some profiling results showing the benefit of these changes? It seems that these functions are called only on driver initialization. Making the local arrays static will prevent releasing this memory even though it will be no longer needed. Anyway, the

Re: [PATCH] net: ibm: ibmveth: constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:14:50 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text

Re: [PATCH] net: ibm: ibmveth: constify dev_pm_ops structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 11:14:50 +0530 > dev_pm_ops are not supposed to change at runtime. All functions > working with dev_pm_ops provided by work with const > dev_pm_ops. So mark the non-const structs as const. > > File size before: >text data bss dec

Re: [PATCH] firmware: wake all waiters

On Thu, Jun 29, 2017 at 12:08 PM, Davidlohr Bueso wrote: > On Tue, 27 Jun 2017, Luis R. Rodriguez wrote: >> >> * As a side effect of this; the data structures are slimmer. >> * >> - * One would recommend using this wait queue where possible. >> + * NOTE: swait is for cases of

Re: [PATCH] firmware: wake all waiters

On Thu, Jun 29, 2017 at 12:08 PM, Davidlohr Bueso wrote: > On Tue, 27 Jun 2017, Luis R. Rodriguez wrote: >> >> * As a side effect of this; the data structures are slimmer. >> * >> - * One would recommend using this wait queue where possible. >> + * NOTE: swait is for cases of extreme memory

4.12.0-rc6: kernel BUG at arch/x86/mm/init_64.c:128!

The I hit the following kernel panic while hot-adding memory. [ cut here ] kernel BUG at arch/x86/mm/init_64.c:128! invalid opcode: [#1] SMP CPU: 10 PID: 6 Comm: kworker/u1024:0 Not tainted 4.12.0-rc6+ #2 Workqueue: kacpi_hotplug acpi_hotplug_work_fn

4.12.0-rc6: kernel BUG at arch/x86/mm/init_64.c:128!

The I hit the following kernel panic while hot-adding memory. [ cut here ] kernel BUG at arch/x86/mm/init_64.c:128! invalid opcode: [#1] SMP CPU: 10 PID: 6 Comm: kworker/u1024:0 Not tainted 4.12.0-rc6+ #2 Workqueue: kacpi_hotplug acpi_hotplug_work_fn

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 09:40:15PM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso wrote: > > > On Thu, 29 Jun 2017, Linus Torvalds wrote: > > > > > >> I actually think swait

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 09:40:15PM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso wrote: > > > On Thu, 29 Jun 2017, Linus Torvalds wrote: > > > > > >> I actually think swait is pure garbage.

[PATCH v2 1/4] lib: Add xxhash module

Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an extremely fast non-cryptographic hash algorithm for checksumming. The zstd compression and decompression modules added in the next patch require xxhash. I extracted it out from zstd since it is useful on its own. I copied the code

[PATCH v2 1/4] lib: Add xxhash module

Adds xxhash kernel module with xxh32 and xxh64 hashes. xxhash is an extremely fast non-cryptographic hash algorithm for checksumming. The zstd compression and decompression modules added in the next patch require xxhash. I extracted it out from zstd since it is useful on its own. I copied the code

[PATCH v2 0/4] Add xxhash and zstd modules

Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell Changelog: v1 -> v2: - Make pointer in lib/xxhash.c:394 non-const (1/4) - Use

[PATCH v2 0/4] Add xxhash and zstd modules

Hi all, This patch set adds xxhash, zstd compression, and zstd decompression modules. It also adds zstd support to BtrFS and SquashFS. Each patch has relevant summaries, benchmarks, and tests. Best, Nick Terrell Changelog: v1 -> v2: - Make pointer in lib/xxhash.c:394 non-const (1/4) - Use

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso wrote: > > On Thu, 29 Jun 2017, Linus Torvalds wrote: > > > >> I actually think swait is pure garbage. Most users only wake up one > >> process anyway, and using

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, Jun 29, 2017 at 11:59:29AM -0700, Linus Torvalds wrote: > On Thu, Jun 29, 2017 at 11:33 AM, Davidlohr Bueso wrote: > > On Thu, 29 Jun 2017, Linus Torvalds wrote: > > > >> I actually think swait is pure garbage. Most users only wake up one > >> process anyway, and using swait for that is

Re: [RFC v2 5/9] S.A.R.A. WX Protection

2017-06-28 1:04 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> +static int sara_check_vmflags(vm_flags_t vm_flags) >> +{ >> + u16 sara_wxp_flags = get_current_sara_wxp_flags(); >> + >> + if

Re: [RFC v2 5/9] S.A.R.A. WX Protection

2017-06-28 1:04 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> +static int sara_check_vmflags(vm_flags_t vm_flags) >> +{ >> + u16 sara_wxp_flags = get_current_sara_wxp_flags(); >> + >> + if (sara_enabled && wxprot_enabled) { >> +

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On 06/29/2017 02:17 AM, Linus Walleij wrote: > Sorry for slowness... > > On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli > wrote: >> On 03/16/2017 07:08 AM, Linus Walleij wrote: > >>> I guess then it is better to assume we will loose the state, or >>> push for more

Re: [PATCH fixes v3] pinctrl: Really force states during suspend/resume

On 06/29/2017 02:17 AM, Linus Walleij wrote: > Sorry for slowness... > > On Wed, Jun 21, 2017 at 11:23 PM, Florian Fainelli > wrote: >> On 03/16/2017 07:08 AM, Linus Walleij wrote: > >>> I guess then it is better to assume we will loose the state, or >>> push for more granular handling of S2/3

Re: [PATCH] amd-xgbe: fix spelling mistake: "avialable" -> "available"

From: Colin King Date: Wed, 28 Jun 2017 17:51:10 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in netdev_err message > > Signed-off-by: Colin Ian King Applied, thanks Colin.

Re: [PATCH] amd-xgbe: fix spelling mistake: "avialable" -> "available"

From: Colin King Date: Wed, 28 Jun 2017 17:51:10 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in netdev_err message > > Signed-off-by: Colin Ian King Applied, thanks Colin.

[tip:x86/urgent] perf/x86/intel/uncore: Fix wrong box pointer check

Commit-ID: 80c65fdb4c6920e332a9781a3de5877594b07522 Gitweb: http://git.kernel.org/tip/80c65fdb4c6920e332a9781a3de5877594b07522 Author: Kan Liang AuthorDate: Thu, 29 Jun 2017 12:09:26 -0700 Committer: Thomas Gleixner CommitDate: Thu, 29 Jun 2017

[tip:x86/urgent] perf/x86/intel/uncore: Fix wrong box pointer check

Commit-ID: 80c65fdb4c6920e332a9781a3de5877594b07522 Gitweb: http://git.kernel.org/tip/80c65fdb4c6920e332a9781a3de5877594b07522 Author: Kan Liang AuthorDate: Thu, 29 Jun 2017 12:09:26 -0700 Committer: Thomas Gleixner CommitDate: Thu, 29 Jun 2017 21:28:13 +0200 perf/x86/intel/uncore:

Re: [RFC v2 7/9] Trampoline emulation

2017-06-28 1:13 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Some programs need to generate part of their code at runtime. Luckily >> enough, in some cases they only generate well-known code sequences (the

Re: [RFC v2 7/9] Trampoline emulation

2017-06-28 1:13 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Some programs need to generate part of their code at runtime. Luckily >> enough, in some cases they only generate well-known code sequences (the >> "trampolines") that can be easily recognized

Re: linux-next: manual merge of the akpm-current tree with the kselftest tree

On Wed, 28 Jun 2017 18:31:11 +1000 Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the akpm-current tree got conflicts in: > > tools/testing/selftests/sysctl/common_tests > tools/testing/selftests/sysctl/run_numerictests >

Re: linux-next: manual merge of the akpm-current tree with the kselftest tree

On Wed, 28 Jun 2017 18:31:11 +1000 Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the akpm-current tree got conflicts in: > > tools/testing/selftests/sysctl/common_tests > tools/testing/selftests/sysctl/run_numerictests > tools/testing/selftests/sysctl/run_stringtests

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Andy, On 06/29/2017 05:30 AM, Andy Shevchenko wrote: +Cc: Hans On Mon, Jun 26, 2017 at 8:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to Whiskey Cove PMIC GPIO controller specification,

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Andy, On 06/29/2017 05:30 AM, Andy Shevchenko wrote: +Cc: Hans On Mon, Jun 26, 2017 at 8:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to Whiskey Cove PMIC GPIO controller specification, for GPIO pins 0-12, GPIO input and output register control address range from,

Re: [RFC v2 6/9] Creation of "pagefault_handler_x86" LSM hook

2017-06-28 1:07 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Creation of a new hook to let LSM modules handle user-space pagefaults on >> x86. >> It can be used to avoid segfaulting the originating process.

Re: [RFC v2 6/9] Creation of "pagefault_handler_x86" LSM hook

2017-06-28 1:07 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Creation of a new hook to let LSM modules handle user-space pagefaults on >> x86. >> It can be used to avoid segfaulting the originating process. >> If it's the case it can modify process

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

> So where can I get a handle on the people inside Intel who are obviously > using ACPI GPIO class for shoehorning what we in the linux kernel call > syscon or register bit misc access into the GPIO ACPI container just > because they feel it is convenient? It's a Windowsism and since Windows is

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

> So where can I get a handle on the people inside Intel who are obviously > using ACPI GPIO class for shoehorning what we in the linux kernel call > syscon or register bit misc access into the GPIO ACPI container just > because they feel it is convenient? It's a Windowsism and since Windows is

Re: [RFC v2 3/9] Creation of "check_vmflags" LSM hook

2017-06-28 1:05 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Creation of a new LSM hook to check if a given configuration of vmflags, >> for a new memory allocation request, should be allowed or not. >> It's

Re: [RFC v2 3/9] Creation of "check_vmflags" LSM hook

2017-06-28 1:05 GMT+02:00 Kees Cook : > On Thu, Jun 15, 2017 at 9:42 AM, Salvatore Mesoraca > wrote: >> Creation of a new LSM hook to check if a given configuration of vmflags, >> for a new memory allocation request, should be allowed or not. >> It's placed in "do_mmap", "do_brk_flags" and

Re: [PATCH 3/6] staging: iio: tsl2x7x: remove tsl2x7x_i2c_read()

On Thu, Jun 29, 2017 at 7:03 PM, Brian Masney wrote: > tsl2x7x_i2c_read() would call i2c_smbus_write_byte() and > i2c_smbus_read_byte(). These two i2c functions can be replaced with a > single call to i2c_smbus_read_byte_data(). This patch removes the > tsl2x7x_i2c_read()

Re: [PATCH 3/6] staging: iio: tsl2x7x: remove tsl2x7x_i2c_read()

On Thu, Jun 29, 2017 at 7:03 PM, Brian Masney wrote: > tsl2x7x_i2c_read() would call i2c_smbus_write_byte() and > i2c_smbus_read_byte(). These two i2c functions can be replaced with a > single call to i2c_smbus_read_byte_data(). This patch removes the > tsl2x7x_i2c_read() function and replaces

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: > Add function header comment to make it clear that local variable sw_cg > is used for debugging and it should not be removed. > > Addresses-Coverity-ID: 1198635 > Cc: Alex Deucher >

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: > Add function header comment to make it clear that local variable sw_cg > is used for debugging and it should not be removed. > > Addresses-Coverity-ID: 1198635 > Cc: Alex Deucher > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH v1] xen/input: add multi-touch support

On June 29, 2017 11:40:30 AM PDT, Oleksandr Andrushchenko wrote: >Hi, Dmitry! > >First of all thank you for both the comments and the patch > >On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: >> Hi Oleksandr, >> >> On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr

Re: [PATCH v1] xen/input: add multi-touch support

On June 29, 2017 11:40:30 AM PDT, Oleksandr Andrushchenko wrote: >Hi, Dmitry! > >First of all thank you for both the comments and the patch > >On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: >> Hi Oleksandr, >> >> On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko >wrote: >>> +

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 01:54 PM, Dan Williams wrote: > Allow volatile nfit ranges to participate in all the same infrastructure > provided for persistent memory regions. This seems to be a bit more than "other rework". > A resulting resulting namespace > device will still be called "pmem", but the

Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges

On 06/29/2017 01:54 PM, Dan Williams wrote: > Allow volatile nfit ranges to participate in all the same infrastructure > provided for persistent memory regions. This seems to be a bit more than "other rework". > A resulting resulting namespace > device will still be called "pmem", but the

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > People reported that they can not do a poweroff nor a > suspend to ram on their Mac Pro 11. After some investigations > it was found that, once the PCI bridge :00:1c.0 reassigns its > mm windows to ([mem 0x7fa0-0x7fbf] and >

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote: > People reported that they can not do a poweroff nor a > suspend to ram on their Mac Pro 11. After some investigations > it was found that, once the PCI bridge :00:1c.0 reassigns its > mm windows to ([mem 0x7fa0-0x7fbf] and >

Re: [PATCH v2 0/8] x86: undwarf unwinder

On Thu, Jun 29, 2017 at 09:12:56AM -0500, Josh Poimboeuf wrote: > > > I'm not tied to the 'undwarf' name, other naming ideas are welcome. > > > > Ha, a new bike shed painting job! ;-) > > > > I think 'undwarf' isn't a bad name, it's short, catchy and describes the > > purpose > > of the

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Linus, On 06/29/2017 05:17 AM, Linus Walleij wrote: On Mon, Jun 26, 2017 at 7:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to Whiskey Cove PMIC GPIO controller specification, for GPIO

Re: [PATCH v2 0/8] x86: undwarf unwinder

On Thu, Jun 29, 2017 at 09:12:56AM -0500, Josh Poimboeuf wrote: > > > I'm not tied to the 'undwarf' name, other naming ideas are welcome. > > > > Ha, a new bike shed painting job! ;-) > > > > I think 'undwarf' isn't a bad name, it's short, catchy and describes the > > purpose > > of the

Re: [PATCH v2 1/1] gpio: gpio-wcove: Fix GPIO control register offset calculation

Hi Linus, On 06/29/2017 05:17 AM, Linus Walleij wrote: On Mon, Jun 26, 2017 at 7:37 PM, wrote: From: Kuppuswamy Sathyanarayanan According to Whiskey Cove PMIC GPIO controller specification, for GPIO pins 0-12, GPIO input and output register control address range from, 0x4e44-0x4e50 for

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

Hi, On Thu, Jun 29, 2017 at 09:50:13PM +0300, Aaro Koskinen wrote: > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote: > > On 15/06/17 01:11, Aaro Koskinen wrote: > > > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there > > > is no display. > > > > Are you sure

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

Hi, On Thu, Jun 29, 2017 at 09:50:13PM +0300, Aaro Koskinen wrote: > On Thu, Jun 15, 2017 at 09:51:06AM +0300, Tomi Valkeinen wrote: > > On 15/06/17 01:11, Aaro Koskinen wrote: > > > When booting v4.12-rc5 on Nokia N900, omapdrm fails to probe and there > > > is no display. > > > > Are you sure

[PATCH] perf/x86/intel/uncore: fix wrong box pointer check

From: Kan Liang Should not init a NULL box. It will cause system crash. The issue looks like caused by a typo. It is introduced from: commit fff4b87e594a ("perf/x86/intel/uncore: Make package handling more robust") This was not noticed because there is no NULL box. Also,

[PATCH] perf/x86/intel/uncore: fix wrong box pointer check

From: Kan Liang Should not init a NULL box. It will cause system crash. The issue looks like caused by a typo. It is introduced from: commit fff4b87e594a ("perf/x86/intel/uncore: Make package handling more robust") This was not noticed because there is no NULL box. Also, for most boxes, they

[PATCH 21/37] binder: guarantee txn complete / errors delivered in-order

Since errors are tracked in the return_error/return_error2 fields of the binder_thread object and BR_TRANSACTION_COMPLETEs can be tracked either in those fields or via the thread todo work list, it is possible for errors to be reported ahead of the associated txn complete. Use the thread todo

[PATCH 21/37] binder: guarantee txn complete / errors delivered in-order

Since errors are tracked in the return_error/return_error2 fields of the binder_thread object and BR_TRANSACTION_COMPLETEs can be tracked either in those fields or via the thread todo work list, it is possible for errors to be reported ahead of the associated txn complete. Use the thread todo

[PATCH 14/37] binder: avoid race conditions when enqueuing txn

Currently, the transaction complete work item is queued after the transaction. This means that it is possible for the transaction to be handled and a reply to be enqueued in the current thread before the transaction complete is enqueued, which violates the protocol with userspace who may not

[PATCH 14/37] binder: avoid race conditions when enqueuing txn

Currently, the transaction complete work item is queued after the transaction. This means that it is possible for the transaction to be handled and a reply to be enqueued in the current thread before the transaction complete is enqueued, which violates the protocol with userspace who may not

[PATCH 17/37] binder: protect against two threads freeing buffer

Adds protection against malicious user code freeing the same buffer at the same time which could cause a crash. Cannot happen under normal use. Signed-off-by: Todd Kjos --- drivers/android/binder.c | 4 ++-- drivers/android/binder_alloc.c | 22 +-

[PATCH 17/37] binder: protect against two threads freeing buffer

Adds protection against malicious user code freeing the same buffer at the same time which could cause a crash. Cannot happen under normal use. Signed-off-by: Todd Kjos --- drivers/android/binder.c | 4 ++-- drivers/android/binder_alloc.c | 22 +-

[PATCH 16/37] binder: remove dead code in binder_get_ref_for_node

node is always non-NULL in binder_get_ref_for_node so the conditional and else clause are not needed Signed-off-by: Todd Kjos --- drivers/android/binder.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/android/binder.c

[PATCH 08/37] binder: remove binder_debug_no_lock mechanism

With the global lock, there was a mechanism to access binder driver debugging information with the global lock disabled to debug deadlocks or other issues. This mechanism is rarely (if ever) used anymore and wasn't needed during the development of fine-grained locking in the binder driver.

[PATCH 16/37] binder: remove dead code in binder_get_ref_for_node

node is always non-NULL in binder_get_ref_for_node so the conditional and else clause are not needed Signed-off-by: Todd Kjos --- drivers/android/binder.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c

[PATCH 08/37] binder: remove binder_debug_no_lock mechanism

With the global lock, there was a mechanism to access binder driver debugging information with the global lock disabled to debug deadlocks or other issues. This mechanism is rarely (if ever) used anymore and wasn't needed during the development of fine-grained locking in the binder driver.

<    3   4   5   6   7   8   9   10   11   12   >