Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, 2017-03-03 at 06:32 -0800, Eric Dumazet wrote: > On Fri, 2017-03-03 at 15:11 +0100, Dmitry Vyukov wrote: > > On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang > > wrote: > > > On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov > > > wrote: > > >> Hi, > > >> > > >> I've got the following error

[PATCH v3 3/7] tpm: export tpm2_flush_context_cmd

Signed-off-by: Jarkko Sakkinen Tested-by: James Bottomley Reviewed-by: James Bottomley --- drivers/char/tpm/tpm.h | 2 ++ drivers/char/tpm/tpm2-cmd.c | 62 + 2 files changed, 31 insertions(+), 33 deletions(-) diff --git

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, 2017-03-03 at 16:06 +0100, Dmitry Vyukov wrote: > Something that compiles is definitely better :) > Reapplied. Just to be clear : This is not the proper patch. This only reduces the race. bh_lock_sock() does not prevent a user process from owning the socket. We need another protection,

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, 2017-03-03 at 16:06 +0100, Dmitry Vyukov wrote: > Something that compiles is definitely better :) > Reapplied. Just to be clear : This is not the proper patch. This only reduces the race. bh_lock_sock() does not prevent a user process from owning the socket. We need another protection,

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 03:28pm, Borislav Petkov wrote: > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > > And another meaning of defining kernel iamge size and mapping size > > differently is we can randomize the limited kernel image in the mapping > > area. If they are the same or kernel

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 03:28pm, Borislav Petkov wrote: > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > > And another meaning of defining kernel iamge size and mapping size > > differently is we can randomize the limited kernel image in the mapping > > area. If they are the same or kernel

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, Mar 3, 2017 at 4:06 PM, Dmitry Vyukov wrote: > On Fri, Mar 3, 2017 at 3:48 PM, Eric Dumazet wrote: >> On Fri, 2017-03-03 at 06:32 -0800, Eric Dumazet wrote: >>> On Fri, 2017-03-03 at 15:11 +0100, Dmitry Vyukov wrote: >>> > On Mon, Feb 13, 2017

Re: [tpmdd-devel] [PATCH v2] tpm: do not suspend/resume if power stays on

On Thu, Mar 02, 2017 at 04:42:57PM +0100, Enric Balletbo i Serra wrote: > From: Sonny Rao > > The suspend/resume behavior of the TPM can be controlled by setting > "powered-while-suspended" in the DTS. This is useful for the cases > when hardware does not power-off the

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, Mar 3, 2017 at 4:06 PM, Dmitry Vyukov wrote: > On Fri, Mar 3, 2017 at 3:48 PM, Eric Dumazet wrote: >> On Fri, 2017-03-03 at 06:32 -0800, Eric Dumazet wrote: >>> On Fri, 2017-03-03 at 15:11 +0100, Dmitry Vyukov wrote: >>> > On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang >>> > wrote: >>> >

Re: [tpmdd-devel] [PATCH v2] tpm: do not suspend/resume if power stays on

On Thu, Mar 02, 2017 at 04:42:57PM +0100, Enric Balletbo i Serra wrote: > From: Sonny Rao > > The suspend/resume behavior of the TPM can be controlled by setting > "powered-while-suspended" in the DTS. This is useful for the cases > when hardware does not power-off the TPM. > > Signed-off-by:

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote: > > Currently, all heaps are compiled in all the time. In switching to > a better platform model, let's allow these to be compiled out for good > measure. > > Signed-off-by: Laura Abbott I'm not the biggest fan

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote: > > Currently, all heaps are compiled in all the time. In switching to > a better platform model, let's allow these to be compiled out for good > measure. > > Signed-off-by: Laura Abbott I'm not the biggest fan of making everything

Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

Hi, On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: > This series add OF device ID tables to RTC I2C drivers whose devices are > either used in Device Tree source files or are listed in binding docs as > a compatible string. > > That's done because the plan is to change the I2C

Re: [PATCH 1/3] futex: remove duplicated code

On 3/3/2017 7:27 AM, Jiri Slaby wrote: There is code duplicated over all architecture's headers for futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, and comparison of the result. Remove this duplication and leave up to the arches only the needed assembly which is now in

Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

Hi, On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: > This series add OF device ID tables to RTC I2C drivers whose devices are > either used in Device Tree source files or are listed in binding docs as > a compatible string. > > That's done because the plan is to change the I2C

Re: [PATCH 1/3] futex: remove duplicated code

On 3/3/2017 7:27 AM, Jiri Slaby wrote: There is code duplicated over all architecture's headers for futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, and comparison of the result. Remove this duplication and leave up to the arches only the needed assembly which is now in

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 3:33 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: >> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko >> wrote: >> >> Would KMSAN also force local variables to be

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 3:33 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: >> On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko >> wrote: >> >> Would KMSAN also force local variables to be non-overlapping the way that >> asan-stack=1 and

Re: [PATCH 26/26] kasan: rework Kconfig settings

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 97d62c2da6c2..27c838c40a36 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK > config FRAME_WARN > int "Warn for stack

Re: [PATCH 26/26] kasan: rework Kconfig settings

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 97d62c2da6c2..27c838c40a36 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK > config FRAME_WARN > int "Warn for stack

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 11:07pm, Baoquan He wrote: > On 03/03/17 at 03:28pm, Borislav Petkov wrote: > > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > > > And another meaning of defining kernel iamge size and mapping size > > > differently is we can randomize the limited kernel image in the

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 11:07pm, Baoquan He wrote: > On 03/03/17 at 03:28pm, Borislav Petkov wrote: > > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > > > And another meaning of defining kernel iamge size and mapping size > > > differently is we can randomize the limited kernel image in the

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: >> When CONFIG_KASAN is enabled, we have several functions that use rather >> large kernel stacks, e.g. >> >> drivers/isdn/hardware/eicon/message.c: In function

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

On Fri, Mar 3, 2017 at 3:20 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: >> When CONFIG_KASAN is enabled, we have several functions that use rather >> large kernel stacks, e.g. >> >> drivers/isdn/hardware/eicon/message.c: In function 'group_optimization': >>

Re: Conversion of w83627ehf to hwmon_device_register_with_info ?

Hi Peter, On Fri, 3 Mar 2017 01:33:01 +0100, Peter Hüwe wrote: > is anybody else working on the conversion of the w83627ehf to the new > hwmon_device_register_with_info interface? Not me. -- Jean Delvare SUSE L3 Support

Re: Conversion of w83627ehf to hwmon_device_register_with_info ?

Hi Peter, On Fri, 3 Mar 2017 01:33:01 +0100, Peter Hüwe wrote: > is anybody else working on the conversion of the w83627ehf to the new > hwmon_device_register_with_info interface? Not me. -- Jean Delvare SUSE L3 Support

Re: [PATCH 2/3] mmc: sdhci-acpi: Check device status before calling fix_up_power()

Hi Hans, Adrian, On Sat, 25 Feb 2017 18:23:56 +0100, Hans de Goede wrote: > Calling acpi_device_fix_up_power() on a device which is not present > is not a good idea. How bad is it? This was introduced by commit e5bbf30733f9, which was backported to several stable branches. If it causes real

Re: [PATCH 2/3] mmc: sdhci-acpi: Check device status before calling fix_up_power()

Hi Hans, Adrian, On Sat, 25 Feb 2017 18:23:56 +0100, Hans de Goede wrote: > Calling acpi_device_fix_up_power() on a device which is not present > is not a good idea. How bad is it? This was introduced by commit e5bbf30733f9, which was backported to several stable branches. If it causes real

Re: [PATCH 3/4] watchodg: sama5d4: simplify probe

On 03/03/2017 01:29 AM, Alexandre Belloni wrote: On 03/03/2017 at 09:03:25 +0100, Thomas Petazzoni wrote: On Thu, 2 Mar 2017 18:31:13 +0100, Alexandre Belloni wrote: + irq = irq_of_parse_and_map(pdev->dev.of_node, 0); Any reason to use irq_of_parse_and_map() over the more

Re: [PATCH 26/26] kasan: rework Kconfig settings

On Fri, Mar 3, 2017 at 3:51 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > >> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index 97d62c2da6c2..27c838c40a36 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@

Re: [PATCH 3/4] watchodg: sama5d4: simplify probe

On 03/03/2017 01:29 AM, Alexandre Belloni wrote: On 03/03/2017 at 09:03:25 +0100, Thomas Petazzoni wrote: On Thu, 2 Mar 2017 18:31:13 +0100, Alexandre Belloni wrote: + irq = irq_of_parse_and_map(pdev->dev.of_node, 0); Any reason to use irq_of_parse_and_map() over the more

Re: [PATCH 26/26] kasan: rework Kconfig settings

On Fri, Mar 3, 2017 at 3:51 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > >> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug >> index 97d62c2da6c2..27c838c40a36 100644 >> --- a/lib/Kconfig.debug >> +++ b/lib/Kconfig.debug >> @@ -216,10 +216,9 @@ config

[PATCH 02/10] Updated max98927_reg table with physical defaults. Replaced max98927.h for better legibility

Signed-off-by: Ryan Lee --- Some register values in 'max98927_reg_map' table was not physical default. Random mix of strangely formatted #defines and numbers was fixed. Reclassified register definition in 'max98927.h' for better legibility. Unused definition has

[PATCH 02/10] Updated max98927_reg table with physical defaults. Replaced max98927.h for better legibility

Signed-off-by: Ryan Lee --- Some register values in 'max98927_reg_map' table was not physical default. Random mix of strangely formatted #defines and numbers was fixed. Reclassified register definition in 'max98927.h' for better legibility. Unused definition has been removed, too.

mm: use-after-free in zap_page_range

Hello, Yesterday Andrea helped me to extend syzkaller descriptions to accommodate the new userfaultfd features: https://github.com/google/syzkaller/commit/e7fc37e3cc9909ac38afc13e4f00c299d05cabf5 And here we go. UFFDIO_API seems to be necessary to trigger this. If you add new APIs don't neglect

mm: use-after-free in zap_page_range

Hello, Yesterday Andrea helped me to extend syzkaller descriptions to accommodate the new userfaultfd features: https://github.com/google/syzkaller/commit/e7fc37e3cc9909ac38afc13e4f00c299d05cabf5 And here we go. UFFDIO_API seems to be necessary to trigger this. If you add new APIs don't neglect

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" : > > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > >>  > I'm a bit worried by that to be honest. You claim to support the A31, > >>  > yet

Re: [linux-sunxi] Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote: > > > 02.03.2017, 22:09, "Maxime Ripard" : > > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > >>  > I'm a bit worried by that to be honest. You claim to support the A31, > >>  > yet jugdging by the current state of

[for-next][PATCH 3/7] module: set __jump_table alignment to 8

From: David Daney For powerpc the __jump_table section in modules is not aligned, this causes a WARN_ON() splat when loading a module containing a __jump_table. Strict alignment became necessary with commit 3821fd35b58d ("jump_label: Reduce the size of struct

[for-next][PATCH 3/7] module: set __jump_table alignment to 8

From: David Daney For powerpc the __jump_table section in modules is not aligned, this causes a WARN_ON() splat when loading a module containing a __jump_table. Strict alignment became necessary with commit 3821fd35b58d ("jump_label: Reduce the size of struct static_key"), currently in

[for-next][PATCH 4/7] jump_label: Fix anonymous union initialization

From: Boris Ostrovsky Pre-4.6 gcc do not allow direct static initialization of members of anonymous structs/unions. After commit 3821fd35b58d ("jump_label: Reduce the size of struct static_key") STATIC_KEY_INIT_{TRUE|FALSE} definitions cannot be compiled with those

[for-next][PATCH 4/7] jump_label: Fix anonymous union initialization

From: Boris Ostrovsky Pre-4.6 gcc do not allow direct static initialization of members of anonymous structs/unions. After commit 3821fd35b58d ("jump_label: Reduce the size of struct static_key") STATIC_KEY_INIT_{TRUE|FALSE} definitions cannot be compiled with those older compilers. Placing

[for-next][PATCH 5/7] jump_label: Add comment about initialization order for anonymous unions

From: "Steven Rostedt (VMware)" Commit 3821fd35b58d ("jump_label: Reduce the size of struct static_key") broke old compilers that could not handle static initialization of anonymous unions. Boris fixed it with a patch that added brackets around the static initializer. But

[for-next][PATCH 5/7] jump_label: Add comment about initialization order for anonymous unions

From: "Steven Rostedt (VMware)" Commit 3821fd35b58d ("jump_label: Reduce the size of struct static_key") broke old compilers that could not handle static initialization of anonymous unions. Boris fixed it with a patch that added brackets around the static initializer. But this creates a

[for-next][PATCH 7/7] ftrace/graph: Add ftrace_graph_max_depth kernel parameter

From: Todd Brandt Early trace callgraphs can be extremely large on systems with several seconds of boot time. The max_depth parameter limits how deep the graph trace goes and reduces the output size. This parameter is the same as the max_graph_depth file in

[for-next][PATCH 7/7] ftrace/graph: Add ftrace_graph_max_depth kernel parameter

From: Todd Brandt Early trace callgraphs can be extremely large on systems with several seconds of boot time. The max_depth parameter limits how deep the graph trace goes and reduces the output size. This parameter is the same as the max_graph_depth file in tracefs. Link:

[for-next][PATCH 6/7] tracing: Add #undef to fix compile error

From: Rik van Riel There are several trace include files that define TRACE_INCLUDE_FILE. Include several of them in the same .c file (as I currently have in some code I am working on), and the compile will blow up with a "warning: "TRACE_INCLUDE_FILE" redefined #define

[for-next][PATCH 6/7] tracing: Add #undef to fix compile error

From: Rik van Riel There are several trace include files that define TRACE_INCLUDE_FILE. Include several of them in the same .c file (as I currently have in some code I am working on), and the compile will blow up with a "warning: "TRACE_INCLUDE_FILE" redefined #define TRACE_INCLUDE_FILE

[for-next][PATCH 1/7] tracing: Fix code comment for ftrace_ops_get_func()

From: Chunyu Hu There is no function 'ftrace_ops_recurs_func' existing in the current code, it was renamed to ftrace_ops_assist_func() in commit c68c0fa29341 ("ftrace: Have ftrace_ops_get_func() handle RCU and PER_CPU flags too"). Update the comment to the correct function

[for-next][PATCH 1/7] tracing: Fix code comment for ftrace_ops_get_func()

From: Chunyu Hu There is no function 'ftrace_ops_recurs_func' existing in the current code, it was renamed to ftrace_ops_assist_func() in commit c68c0fa29341 ("ftrace: Have ftrace_ops_get_func() handle RCU and PER_CPU flags too"). Update the comment to the correct function name. Link:

[for-next][PATCH 2/7] ftrace/graph: Do not modify the EMPTY_HASH for the function_graph filter

From: "Steven Rostedt (VMware)" On boot up, if the kernel command line sets a graph funtion with the kernel command line options "ftrace_graph_filter" or "ftrace_graph_notrace" then it updates the corresponding function graph hash, ftrace_graph_hash or

[for-next][PATCH 2/7] ftrace/graph: Do not modify the EMPTY_HASH for the function_graph filter

From: "Steven Rostedt (VMware)" On boot up, if the kernel command line sets a graph funtion with the kernel command line options "ftrace_graph_filter" or "ftrace_graph_notrace" then it updates the corresponding function graph hash, ftrace_graph_hash or ftrace_graph_notrace_hash respectively.

[for-next][PATCH 0/7] tracing: Fixes for 4.11

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 65a50c656276b0846bea09dd011c0a3d35b77f3e Boris Ostrovsky (1): jump_label: Fix anonymous union initialization Chunyu Hu (1): tracing: Fix code comment for ftrace_ops_get_func() David Daney

[for-next][PATCH 0/7] tracing: Fixes for 4.11

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 65a50c656276b0846bea09dd011c0a3d35b77f3e Boris Ostrovsky (1): jump_label: Fix anonymous union initialization Chunyu Hu (1): tracing: Fix code comment for ftrace_ops_get_func() David Daney

[PATCH v3] clk: imx: clk-imx6ul: The i.mx6ul has no aips_tz3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Reviewed-by: Fabio Estevam Signed-off-by: Robin van der Gracht --- Fixed another title typo in v3 drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4

[PATCH v3] clk: imx: clk-imx6ul: The i.mx6ul has no aips_tz3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Reviewed-by: Fabio Estevam Signed-off-by: Robin van der Gracht --- Fixed another title typo in v3 drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH 1/4] tty/serial: atmel: move atmel_serial header into driver directory

atmel_serial.h is only used by atmel_serial.c, so there's no need for it to lie in include/linux. Suggested-by: Joe Perches Signed-off-by: Richard Genoud --- MAINTAINERS | 2 +-

[PATCH 1/4] tty/serial: atmel: move atmel_serial header into driver directory

atmel_serial.h is only used by atmel_serial.c, so there's no need for it to lie in include/linux. Suggested-by: Joe Perches Signed-off-by: Richard Genoud --- MAINTAINERS | 2 +- drivers/tty/serial/atmel_serial.c| 2 +- {include/linux

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-03 11:27 GMT+01:00 Daniel Vetter : > On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote: >> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote: >> > Hi, >> > >> > There's been some recent discussions[1] about Ion-like frameworks. There's >> >

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

2017-03-03 11:27 GMT+01:00 Daniel Vetter : > On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote: >> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote: >> > Hi, >> > >> > There's been some recent discussions[1] about Ion-like frameworks. There's >> > apparently interest in

[PATCH v6 0/4] drm/dp: Implement CRC debugfs API

Hi, this series builds up on the API for exposing captured CRCs through debugfs. It adds new DP helpers for starting and stopping CRC capture and gets the Rockchip driver to use it. With these patches, tests in IGT such as kms_pipe_crc_basic and kms_plane do pass on RK3288. In this v6, the

[PATCH v6 0/4] drm/dp: Implement CRC debugfs API

Hi, this series builds up on the API for exposing captured CRCs through debugfs. It adds new DP helpers for starting and stopping CRC capture and gets the Rockchip driver to use it. With these patches, tests in IGT such as kms_pipe_crc_basic and kms_plane do pass on RK3288. In this v6, the

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 03/02/2017 11:29 PM, Mats Karrman wrote: On 2017-03-03 04:13, Guenter Roeck wrote: On 03/02/2017 07:22 AM, Mats Karrman wrote: Looking forward, one thing I have run into is how to connect the typec driver with a driver for an alternate mode. E.g. the DisplayPort Alternate Mode

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 03/02/2017 11:29 PM, Mats Karrman wrote: On 2017-03-03 04:13, Guenter Roeck wrote: On 03/02/2017 07:22 AM, Mats Karrman wrote: Looking forward, one thing I have run into is how to connect the typec driver with a driver for an alternate mode. E.g. the DisplayPort Alternate Mode

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

On Fri, Mar 03, 2017 at 09:37:24AM +0100, Michal Hocko wrote: > Btw. can I assume your Acked-by? Yeah, Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

On Fri, Mar 03, 2017 at 09:37:24AM +0100, Michal Hocko wrote: > Btw. can I assume your Acked-by? Yeah, Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi, On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > On 2017-03-03 04:13, Guenter Roeck wrote: > > > On 03/02/2017 07:22 AM, Mats Karrman wrote: > > > > > > Looking forward, one thing I have run into is how to connect the typec > > > driver with a > > > driver for an

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi, On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote: > On 2017-03-03 04:13, Guenter Roeck wrote: > > > On 03/02/2017 07:22 AM, Mats Karrman wrote: > > > > > > Looking forward, one thing I have run into is how to connect the typec > > > driver with a > > > driver for an

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Peter, On Fri, Mar 03, 2017 at 11:35:29AM +0800, Peter Chen wrote: > On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote: > > +/* --- */ > > +/* Driver callbacks to report role updates */ > > + > > +/** > > + * typec_set_data_role - Report data

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Peter, On Fri, Mar 03, 2017 at 11:35:29AM +0800, Peter Chen wrote: > On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote: > > +/* --- */ > > +/* Driver callbacks to report role updates */ > > + > > +/** > > + * typec_set_data_role - Report data

Re: [PATCH v2 6/9] kasan: improve slab object description

On 03/03/2017 04:52 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin > wrote: >> On 03/02/2017 04:48 PM, Andrey Konovalov wrote: >>> Changes slab object description from: >>> >>> Object at 880068388540, in cache kmalloc-128 size: 128

Re: [PATCH v2 6/9] kasan: improve slab object description

On 03/03/2017 04:52 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin > wrote: >> On 03/02/2017 04:48 PM, Andrey Konovalov wrote: >>> Changes slab object description from: >>> >>> Object at 880068388540, in cache kmalloc-128 size: 128 >>> >>> to: >>> >>> The

Re: [PATCH 1/3] firmware: dmi_scan: Add dmi_product_name kernel cmdline option

Hi, On 03-03-17 10:24, Jean Delvare wrote: Hi Hans, On Sat, 25 Feb 2017 18:23:55 +0100, Hans de Goede wrote: Unfortunately some firmware has all the DMI strings filled with: "Default String" (or something equally useless). This makes it impossible to apply DMI based quirks to certain

Re: [PATCH 1/3] firmware: dmi_scan: Add dmi_product_name kernel cmdline option

Hi, On 03-03-17 10:24, Jean Delvare wrote: Hi Hans, On Sat, 25 Feb 2017 18:23:55 +0100, Hans de Goede wrote: Unfortunately some firmware has all the DMI strings filled with: "Default String" (or something equally useless). This makes it impossible to apply DMI based quirks to certain

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 03/02/2017 08:52 PM, Peter Chen wrote: On Thu, Mar 02, 2017 at 08:29:07PM -0800, Guenter Roeck wrote: On 03/02/2017 07:35 PM, Peter Chen wrote: On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote: +/* --- */ +/* Driver callbacks to report

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On 03/02/2017 08:52 PM, Peter Chen wrote: On Thu, Mar 02, 2017 at 08:29:07PM -0800, Guenter Roeck wrote: On 03/02/2017 07:35 PM, Peter Chen wrote: On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote: +/* --- */ +/* Driver callbacks to report

Re: [PATCH] HID: hid-multitouch: change for touch height/width

On Mar 03 2017 or thereabouts, hn.c...@weidahitech.com wrote: > From: HungNien Chen > > This change is from Jonathan Clarke and have been discussed in previous > thread(2017/01/24). Just doing a slight change in quirk name from Benjamin's > comment. Hi, The patch looks

Re: [PATCH] HID: hid-multitouch: change for touch height/width

On Mar 03 2017 or thereabouts, hn.c...@weidahitech.com wrote: > From: HungNien Chen > > This change is from Jonathan Clarke and have been discussed in previous > thread(2017/01/24). Just doing a slight change in quirk name from Benjamin's > comment. Hi, The patch looks fine now, but this is

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: > On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko wrote: >> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin >> wrote: > @@ -416,6 +416,17 @@ static __always_inline void

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 3:30 PM, Arnd Bergmann wrote: > On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko wrote: >> On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin >> wrote: > @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s

[PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to RTC I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to RTC I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH 01/13] rtc: rv8803: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/sh-sci.c | 12 +--- 1 file

[PATCH 01/13] rtc: rv8803: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/sh-sci.c | 12 +--- 1 file changed, 5 insertions(+),

[PATCH 05/13] rtc: rx8010: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 05/13] rtc: rx8010: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 04/13] rtc: ds1307: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 04/13] rtc: ds1307: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 02/13] rtc: rv3029: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 02/13] rtc: rv3029: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 09/13] rtc: isl1208: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 09/13] rtc: isl1208: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 07/13] rtc: rtc-ds1672: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 07/13] rtc: rtc-ds1672: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin > wrote: >>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile >>> void *p, void *res, int s >>> */ >>> #define

[PATCH 11/13] rtc: rx8581: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 2:55 PM, Alexander Potapenko wrote: > On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin > wrote: >>> @@ -416,6 +416,17 @@ static __always_inline void __write_once_size(volatile >>> void *p, void *res, int s >>> */ >>> #define noinline_for_stack noinline >>> >>> +/* >>>

[PATCH 11/13] rtc: rx8581: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

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