[PATCH v4 1/3] perf: probe: factor out the ftrace README scanning

Simplify and separate out the ftrace README scanning logic into a separate helper. This is used subsequently to scan for all patterns of interest and to cache the result. Since we are only interested in availability of probe argument type x, we will only scan for that. Signed-off-by: Naveen N.

[PATCH v4 1/3] perf: probe: factor out the ftrace README scanning

Simplify and separate out the ftrace README scanning logic into a separate helper. This is used subsequently to scan for all patterns of interest and to cache the result. Since we are only interested in availability of probe argument type x, we will only scan for that. Signed-off-by: Naveen N.

Re: [PATCH v2 4/5] perf: kretprobes: offset from reloc_sym if kernel supports it

On 2017/02/24 05:11PM, Arnaldo Carvalho de Melo wrote: > Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu: > > On Fri, 24 Feb 2017 00:46:08 +0530 > > "Naveen N. Rao" wrote: > > > Thanks. I hope that's an Ack for this patchset? > > > > OK, for

Re: [PATCH v2 4/5] perf: kretprobes: offset from reloc_sym if kernel supports it

On 2017/02/24 05:11PM, Arnaldo Carvalho de Melo wrote: > Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu: > > On Fri, 24 Feb 2017 00:46:08 +0530 > > "Naveen N. Rao" wrote: > > > Thanks. I hope that's an Ack for this patchset? > > > > OK, for 1/5, 2/5, 3/5, and 5/5; > > > >

[PATCH v2] ARM: ptdump: Add domain to output

This adds the memory domain (on non-LPAE) to the PMD and PTE dumps. This isn't in the regular PMD bit struct because I couldn't find a clean way to fall back to retain some of the PMD bits when reporting PTE. So this is special-cased for now. New output example: ---[ Modules ]---

[PATCH v2 0/3] ARM: dts: BCM5301X: GIC_PPI bug, TWD WD and i2c Support

Changes in v2: * Rafal discovered an issue with the GIC_PPI flags being incorrect. Since there was a dependency on that DT entry in this series, I added a patch to correct the issue and reworked the TWD patch with the changes. These seemed to have been lost sometime last year. See

[PATCH v2 1/3] ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags

GIC_PPI flags were misconfigured for the timers, resulting in errors like: [0.00] GIC: PPI11 is secure or misconfigured Changing them to being edge triggered corrects the issue Suggested-by: Rafał Miłecki Signed-off-by: Jon Mason Fixes:

[PATCH v2] ARM: ptdump: Add domain to output

This adds the memory domain (on non-LPAE) to the PMD and PTE dumps. This isn't in the regular PMD bit struct because I couldn't find a clean way to fall back to retain some of the PMD bits when reporting PTE. So this is special-cased for now. New output example: ---[ Modules ]---

[PATCH v2 0/3] ARM: dts: BCM5301X: GIC_PPI bug, TWD WD and i2c Support

Changes in v2: * Rafal discovered an issue with the GIC_PPI flags being incorrect. Since there was a dependency on that DT entry in this series, I added a patch to correct the issue and reworked the TWD patch with the changes. These seemed to have been lost sometime last year. See

[PATCH v2 1/3] ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags

GIC_PPI flags were misconfigured for the timers, resulting in errors like: [0.00] GIC: PPI11 is secure or misconfigured Changing them to being edge triggered corrects the issue Suggested-by: Rafał Miłecki Signed-off-by: Jon Mason Fixes: d27509f1 ("ARM: BCM5301X: add dts files for

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote: > On Wed, 2017-03-01 at 18:02 +, James Hogan wrote: > > On 11 January 2017 at 19:48, Jason Uy wrote: > > > In the most common use case, the Synopsys DW UART driver does not > > > set the set_termios

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote: > On Wed, 2017-03-01 at 18:02 +, James Hogan wrote: > > On 11 January 2017 at 19:48, Jason Uy wrote: > > > In the most common use case, the Synopsys DW UART driver does not > > > set the set_termios callback function.  This

[PATCH] ftrace: add ftrace_graph_max_depth kernel parameter

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 debugfs. Signed-off-by: Todd Brandt

[PATCH] ftrace: add ftrace_graph_max_depth kernel parameter

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 debugfs. Signed-off-by: Todd Brandt ---

[PATCH v6 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe

[PATCH v6 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe

Re: v4.10: kernel stack frame pointer .. has bad value (null)

On Fri, Feb 24, 2017 at 11:04:39PM -0600, Josh Poimboeuf wrote: > On Thu, Feb 23, 2017 at 09:10:39PM +0100, Pavel Machek wrote: > > Hi! > > > > > > > > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind > > > > > > led > > > > > > to the startup_32_smp() frame at 0xf50cdf9c

Re: v4.10: kernel stack frame pointer .. has bad value (null)

On Fri, Feb 24, 2017 at 11:04:39PM -0600, Josh Poimboeuf wrote: > On Thu, Feb 23, 2017 at 09:10:39PM +0100, Pavel Machek wrote: > > Hi! > > > > > > > > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind > > > > > > led > > > > > > to the startup_32_smp() frame at 0xf50cdf9c

Re: ARM64 perf stacktraces on tracepoint events

On Thu, 2 Mar 2017 10:44:11 + Mark Rutland wrote: > [Adding James, Takahiro-san, and Will, for stacktracing and arm64 perf] > > On Wed, Mar 01, 2017 at 04:42:17PM -0800, Joel Fernandes wrote: > > Hi, > > > > On 3.18 kernel running on an arm64 device, I tried running:

Re: ARM64 perf stacktraces on tracepoint events

On Thu, 2 Mar 2017 10:44:11 + Mark Rutland wrote: > [Adding James, Takahiro-san, and Will, for stacktracing and arm64 perf] > > On Wed, Mar 01, 2017 at 04:42:17PM -0800, Joel Fernandes wrote: > > Hi, > > > > On 3.18 kernel running on an arm64 device, I tried running: > > perf record -a -g

[PATCH] USB: misc: ldusb: Fixed coding style issues

Fixed multiple coding style issues. Signed-off-by: Milian Reichardt --- drivers/usb/misc/ldusb.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c index

[PATCH] USB: misc: ldusb: Fixed coding style issues

Fixed multiple coding style issues. Signed-off-by: Milian Reichardt --- drivers/usb/misc/ldusb.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c index 3bc5356832db..77b76b468307 100644 ---

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:59 +0100, Arnd Bergmann wrote: > KASAN decides that passing a pointer to _m into an extern function > (_mlog_printk) is potentially dangerous, as that function might > keep a reference to that pointer after it goes out of scope, > or it might not know the correct length of

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, 2017-03-02 at 23:59 +0100, Arnd Bergmann wrote: > KASAN decides that passing a pointer to _m into an extern function > (_mlog_printk) is potentially dangerous, as that function might > keep a reference to that pointer after it goes out of scope, > or it might not know the correct length of

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Thu, Mar 02, 2017 at 11:49:49PM +0100, Arnd Bergmann wrote: > On Thu, Mar 2, 2017 at 2:03 AM, Josh Poimboeuf wrote: > > On Wed, Mar 01, 2017 at 11:42:54PM +0100, Arnd Bergmann wrote: > >> On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: > >> > On

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Thu, Mar 02, 2017 at 02:41:03PM +0100, Peter Zijlstra wrote: > On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote: > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index a6c8db1..7890661 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -1042,6 +1042,19

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Thu, Mar 02, 2017 at 11:49:49PM +0100, Arnd Bergmann wrote: > On Thu, Mar 2, 2017 at 2:03 AM, Josh Poimboeuf wrote: > > On Wed, Mar 01, 2017 at 11:42:54PM +0100, Arnd Bergmann wrote: > >> On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: > >> > On Wed, Mar 01, 2017 at 04:27:29PM +0100,

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Thu, Mar 02, 2017 at 02:41:03PM +0100, Peter Zijlstra wrote: > On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote: > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > index a6c8db1..7890661 100644 > > --- a/lib/Kconfig.debug > > +++ b/lib/Kconfig.debug > > @@ -1042,6 +1042,19

Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Mar 02, 2017 at 09:01:24PM +, Abel Vesa wrote: > On Tue, Feb 28, 2017 at 11:54:29AM +, Abel Vesa wrote: > > On Tue, Feb 28, 2017 at 11:46:38AM +, Russell King - ARM Linux wrote: > > > On Tue, Feb 28, 2017 at 11:22:27AM +, Abel Vesa wrote: > > > > On Tue, Feb 28, 2017 at

Re: [PATCHv4] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Thu, Mar 02, 2017 at 09:01:24PM +, Abel Vesa wrote: > On Tue, Feb 28, 2017 at 11:54:29AM +, Abel Vesa wrote: > > On Tue, Feb 28, 2017 at 11:46:38AM +, Russell King - ARM Linux wrote: > > > On Tue, Feb 28, 2017 at 11:22:27AM +, Abel Vesa wrote: > > > > On Tue, Feb 28, 2017 at

Re: [PATCH v3 5/9] fput: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 06:44:44PM +0100, Oleg Nesterov wrote: > On 02/14, Byungchul Park wrote: > > > > Although llist provides proper APIs, they are not used. Make them used. > > Reviewed-by: Oleg Nesterov Hello, Al Viro Sorry for my mistake at the previous spin. I should

Re: [PATCH v3 5/9] fput: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 06:44:44PM +0100, Oleg Nesterov wrote: > On 02/14, Byungchul Park wrote: > > > > Although llist provides proper APIs, they are not used. Make them used. > > Reviewed-by: Oleg Nesterov Hello, Al Viro Sorry for my mistake at the previous spin. I should have been more

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/01/17 10:22, Georgi Djakov wrote: > > diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig > new file mode 100644 > index ..103524b59905 > --- /dev/null > +++ b/drivers/interconnect/Kconfig > @@ -0,0 +1,10 @@ > +menuconfig INTERCONNECT > + bool "On-Chip

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/01/17 10:22, Georgi Djakov wrote: > > diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig > new file mode 100644 > index ..103524b59905 > --- /dev/null > +++ b/drivers/interconnect/Kconfig > @@ -0,0 +1,10 @@ > +menuconfig INTERCONNECT > + bool "On-Chip

[PATCH] extcon: int3496: add dependency on X86 as it's Intel specific

Add dependency on X86 so it doesn't show up on other arches and add a option for compile test so it still gets build coverage. Signed-off-by: Peter Robinson --- drivers/extcon/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] extcon: int3496: add dependency on X86 as it's Intel specific

Add dependency on X86 so it doesn't show up on other arches and add a option for compile test so it still gets build coverage. Signed-off-by: Peter Robinson --- drivers/extcon/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/Kconfig

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/02/2017 08:02 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: v4l2_pipeline_inherit_controls() will add the v4l2 controls from all subdev entities in a pipeline to a given video device. Signed-off-by: Steve Longerbeam

[PATCH net] rxrpc: Fix potential NULL-pointer exception

Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call state check that I added should have gone into the else-body of the if-statement where we actually have a call to check. Found by CoverityScan CID#1414316 ("Dereference after null check"). Fixes: 540b1c48c37a ("rxrpc: Fix

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/02/2017 08:02 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: v4l2_pipeline_inherit_controls() will add the v4l2 controls from all subdev entities in a pipeline to a given video device. Signed-off-by: Steve Longerbeam ---

[PATCH net] rxrpc: Fix potential NULL-pointer exception

Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call state check that I added should have gone into the else-body of the if-statement where we actually have a call to check. Found by CoverityScan CID#1414316 ("Dereference after null check"). Fixes: 540b1c48c37a ("rxrpc: Fix

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Thu, Mar 02, 2017 at 06:39:49AM -0800, Matthew Wilcox wrote: > On Thu, Mar 02, 2017 at 01:45:35PM +0900, byungchul.park wrote: > > From: Matthew Wilcox [mailto:wi...@infradead.org] > > > On Tue, Feb 28, 2017 at 07:15:47PM +0100, Peter Zijlstra wrote: > > > > (And we should not be returning to

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Thu, Mar 02, 2017 at 06:39:49AM -0800, Matthew Wilcox wrote: > On Thu, Mar 02, 2017 at 01:45:35PM +0900, byungchul.park wrote: > > From: Matthew Wilcox [mailto:wi...@infradead.org] > > > On Tue, Feb 28, 2017 at 07:15:47PM +0100, Peter Zijlstra wrote: > > > > (And we should not be returning to

Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote: > Since we cannot always generate exactly requested pixel clock > there's not much sense in checking requested_clock == clk_round_rate(). > In that case for quite some modes we'll be getting -EINVAL and no video > output at all. > >

Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

On Thu, Mar 02, 2017 at 08:27:54PM +0300, Alexey Brodkin wrote: > Since we cannot always generate exactly requested pixel clock > there's not much sense in checking requested_clock == clk_round_rate(). > In that case for quite some modes we'll be getting -EINVAL and no video > output at all. > >

[PATCH v7 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe

[PATCH v7 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe

[PATCH v7 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe

[PATCH v7 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe Signed-off-by:

[PATCH v6 0/4] New Microsemi PCI Switch Management Driver

Hi, Hopefully this is the last change necessary. The new code to handle unbind follows Jason's suggestions and is a lot easier to reason about. It's also been tested interrupting a number of operations. Thanks, Logan -- Changes since v5: * Reworked cleanup during unbind again. This time we

[PATCH v6 0/4] New Microsemi PCI Switch Management Driver

Hi, Hopefully this is the last change necessary. The new code to handle unbind follows Jason's suggestions and is a lot easier to reason about. It's also been tested interrupting a number of operations. Thanks, Logan -- Changes since v5: * Reworked cleanup during unbind again. This time we

Re: [PATCH v6 0/4] New Microsemi PCI Switch Management Driver

Hey, Ah, sorry, sorry. I noticed another minor mistake. I'll send a v7 in a second. Thanks, Logan On 02/03/17 04:07 PM, Logan Gunthorpe wrote: > Hi, > > Hopefully this is the last change necessary. The new code to handle > unbind follows Jason's suggestions and is a lot easier to reason

Re: [PATCH v6 0/4] New Microsemi PCI Switch Management Driver

Hey, Ah, sorry, sorry. I noticed another minor mistake. I'll send a v7 in a second. Thanks, Logan On 02/03/17 04:07 PM, Logan Gunthorpe wrote: > Hi, > > Hopefully this is the last change necessary. The new code to handle > unbind follows Jason's suggestions and is a lot easier to reason

[PATCH v6 1/4] MicroSemi Switchtec management interface driver

Microsemi's "Switchtec" line of PCI switch devices is already well supported by the kernel with standard PCI switch drivers. However, the Switchtec device advertises a special management endpoint with a separate PCI function address and class code. This endpoint enables some additional

[PATCH v6 1/4] MicroSemi Switchtec management interface driver

Microsemi's "Switchtec" line of PCI switch devices is already well supported by the kernel with standard PCI switch drivers. However, the Switchtec device advertises a special management endpoint with a separate PCI function address and class code. This endpoint enables some additional

[PATCH v7 1/4] MicroSemi Switchtec management interface driver

Microsemi's "Switchtec" line of PCI switch devices is already well supported by the kernel with standard PCI switch drivers. However, the Switchtec device advertises a special management endpoint with a separate PCI function address and class code. This endpoint enables some additional

[PATCH v7 1/4] MicroSemi Switchtec management interface driver

Microsemi's "Switchtec" line of PCI switch devices is already well supported by the kernel with standard PCI switch drivers. However, the Switchtec device advertises a special management endpoint with a separate PCI function address and class code. This endpoint enables some additional

[PATCH v7 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe

[PATCH v7 2/4] switchtec: Add user interface documentation

This adds standard documentation for the sysfs switchtec attributes and a RST formatted text file which documents the char device interface. Jonathan Corbet has indicated he will move this to a new user-space developer documentation book once it's created. Signed-off-by: Logan Gunthorpe

[PATCH v7 0/4] New Microsemi PCI Switch Management Driver

Because getting it right correctly the first time is appearantly hard and I caught this mistake while reading the email I had just sent :( I'm very sorry about the extra noise. Logan -- Changes since v6: * I screwed up the device_unregister path and left a potential use after free bug in.

[PATCH v7 0/4] New Microsemi PCI Switch Management Driver

Because getting it right correctly the first time is appearantly hard and I caught this mistake while reading the email I had just sent :( I'm very sorry about the extra noise. Logan -- Changes since v6: * I screwed up the device_unregister path and left a potential use after free bug in.

[PATCH v6 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe

[PATCH v6 3/4] switchtec: Add sysfs attributes to the Switchtec driver

This patch adds a few read-only sysfs attributes which provide some device information that is exposed from the devices. Primarily component and device names and versions. These are documented in Documentation/ABI/testing/sysfs-class-switchtec. Signed-off-by: Logan Gunthorpe Signed-off-by:

[PATCH v6 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe

[PATCH v6 4/4] switchtec: Add IOCTLs to the Switchtec driver

This patch introduces a couple of special IOCTLs which are provided to: * Inform userspace of firmware partition locations * Pass event counts and allow userspace to wait on events * Translate between PFF numbers used by the switch to port numbers. Signed-off-by: Logan Gunthorpe

[PATCH 0/3] cpufreq: intel_pstate: Fixes related to the passive mode

Hi, This series fixes some passive mode behavior related to limits and the cpu_frequency tracepoint. It depends on https://patchwork.kernel.org/patch/9594447/ (which is in linux-next already), but it doesn't depend on the other series I posted yesterday

[PATCH 0/3] cpufreq: intel_pstate: Fixes related to the passive mode

Hi, This series fixes some passive mode behavior related to limits and the cpu_frequency tracepoint. It depends on https://patchwork.kernel.org/patch/9594447/ (which is in linux-next already), but it doesn't depend on the other series I posted yesterday

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Thu, Mar 2, 2017 at 2:03 AM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 11:42:54PM +0100, Arnd Bergmann wrote: >> On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: >> > On Wed, Mar 01, 2017 at 04:27:29PM +0100, Arnd Bergmann wrote: >> >> > I

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Thu, Mar 2, 2017 at 2:03 AM, Josh Poimboeuf wrote: > On Wed, Mar 01, 2017 at 11:42:54PM +0100, Arnd Bergmann wrote: >> On Wed, Mar 1, 2017 at 5:53 PM, Josh Poimboeuf wrote: >> > On Wed, Mar 01, 2017 at 04:27:29PM +0100, Arnd Bergmann wrote: >> >> > I see no apparent reason for the ud2. >> >>

[RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1]. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV

[RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1]. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. When enabled, SEV

[PATCH v4 2/3] perf: kretprobes: offset from reloc_sym if kernel supports it

We indicate support for accepting sym+offset with kretprobes through a line in ftrace README. Parse the same to identify support and choose the appropriate format for kprobe_events. Signed-off-by: Naveen N. Rao --- tools/perf/util/probe-event.c | 12 +---

[PATCH v4 2/3] perf: kretprobes: offset from reloc_sym if kernel supports it

We indicate support for accepting sym+offset with kretprobes through a line in ftrace README. Parse the same to identify support and choose the appropriate format for kprobe_events. Signed-off-by: Naveen N. Rao --- tools/perf/util/probe-event.c | 12 +--- tools/perf/util/probe-file.c |

Re: [PATCH v3 2/9] bcache: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 04:26:23PM +0900, Byungchul Park wrote: > Although llist provides proper APIs, they are not used. Make them used. + koverstr...@google.com + jkos...@suse.cz I am not sure who I should cc for this subsystem.. Could you check this patch? Thanks, Byungchul > >

Re: [PATCH v3 2/9] bcache: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 04:26:23PM +0900, Byungchul Park wrote: > Although llist provides proper APIs, they are not used. Make them used. + koverstr...@google.com + jkos...@suse.cz I am not sure who I should cc for this subsystem.. Could you check this patch? Thanks, Byungchul > >

Re: [PATCH 07/20] PCI: implement Devres interface to map PCI config space

Hello, On Thu, Mar 02, 2017 at 02:50:00PM +0200, Andy Shevchenko wrote: > > I thought about that and did not do it because here we are remapping > > resources that are _not_ PCI bus resources (ie it is not PCI BARs we > > are remapping), keeping the devm_* prefix would be more consistent > > to

Re: [PATCH 07/20] PCI: implement Devres interface to map PCI config space

Hello, On Thu, Mar 02, 2017 at 02:50:00PM +0200, Andy Shevchenko wrote: > > I thought about that and did not do it because here we are remapping > > resources that are _not_ PCI bus resources (ie it is not PCI BARs we > > are remapping), keeping the devm_* prefix would be more consistent > > to

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

On 03/02/2017 07:53 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote: Add a new FRAME_TIMEOUT event to signal that a video capture or output device has timed out waiting for reception or transmit completion of a video frame. Signed-off-by:

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

On 03/02/2017 07:53 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote: Add a new FRAME_TIMEOUT event to signal that a video capture or output device has timed out waiting for reception or transmit completion of a video frame. Signed-off-by:

[PATCH net v5 1/2] net: ethernet: bgmac: init sequence bug

Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. The code now checks to see if the adapter needs to be brought out of reset (where as before it was doing an IDM write to bring

[PATCH net v5 1/2] net: ethernet: bgmac: init sequence bug

Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. The code now checks to see if the adapter needs to be brought out of reset (where as before it was doing an IDM write to bring

Re: [PATCH] jump_label: Fix anonymous union initialization

On 03/02/2017 04:42 PM, Steven Rostedt wrote: > On Thu, 2 Mar 2017 16:07:19 -0500 > Jason Baron wrote: > >> On 02/28/2017 11:32 AM, Boris Ostrovsky wrote: >>> Pre-4.6 gcc do not allow direct static initialization of members of >>> anonymous structs/unions. After commit

Re: [PATCH] jump_label: Fix anonymous union initialization

On 03/02/2017 04:42 PM, Steven Rostedt wrote: > On Thu, 2 Mar 2017 16:07:19 -0500 > Jason Baron wrote: > >> On 02/28/2017 11:32 AM, Boris Ostrovsky wrote: >>> Pre-4.6 gcc do not allow direct static initialization of members of >>> anonymous structs/unions. After commit 3821fd35b58d ("jump_label:

[PATCH net v5 2/2] net: ethernet: bgmac: mac address change bug

From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas Signed-off-by: Jon Mason

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 11:40 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote: >> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: >> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> > > The internal logging

Re: [PATCH] objtool: fix another gcc jump table detection issue

On Thu, Mar 2, 2017 at 11:57 PM, Josh Poimboeuf wrote: > > Arnd Bergmann reported a (false positive) objtool warning: > > drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: > rxe_responder()+0xfe: sibling call from callable instruction with changed > frame pointer >

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 11:40 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 23:22 +0100, Arnd Bergmann wrote: >> On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: >> > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> > > The internal logging infrastructure in ocfs2 causes special

Re: [PATCH] objtool: fix another gcc jump table detection issue

On Thu, Mar 2, 2017 at 11:57 PM, Josh Poimboeuf wrote: > > Arnd Bergmann reported a (false positive) objtool warning: > > drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: > rxe_responder()+0xfe: sibling call from callable instruction with changed > frame pointer > > The issue is in

[PATCH net v5 2/2] net: ethernet: bgmac: mac address change bug

From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas Signed-off-by: Jon Mason Fixes: 4e209001b86 ("bgmac: write mac

Re: [PATCH v3 1/9] llist: Provide a safe version for llist_for_each

On Tue, Feb 14, 2017 at 03:45:44PM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > Sometimes we have to dereference next field of llist node before entering > > loop becasue the node might be deleted or the next field might be > > modified within the loop. So

Re: [PATCH v3 1/9] llist: Provide a safe version for llist_for_each

On Tue, Feb 14, 2017 at 03:45:44PM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > Sometimes we have to dereference next field of llist node before entering > > loop becasue the node might be deleted or the next field might be > > modified within the loop. So this adds the safe version

[PATCH net v5 0/2] net: ethernet: bgmac: bug fixes

Changes in v5: * Rebased to the latest code and fixed up a compile error due to the mac_addr struct going away (found by David Miller) Changes in v4: * Added the udelays from the previous code (per David Miller) Changes in v3: * Reworked the init sequence patch to only remove the device reset

[PATCH net v5 0/2] net: ethernet: bgmac: bug fixes

Changes in v5: * Rebased to the latest code and fixed up a compile error due to the mac_addr struct going away (found by David Miller) Changes in v4: * Added the udelays from the previous code (per David Miller) Changes in v3: * Reworked the init sequence patch to only remove the device reset

Re: [Outreachy kernel] [PATCH 5/5] staging: rtl8712: Remove unnecessary cast on void pointer

On Fri, Mar 3, 2017 at 3:26 AM, Julia Lawall wrote: >> @@ -635,7 +635,7 @@ void r8712_reordering_ctrl_timeout_handler(void >> *pcontext) >> { >> unsigned long irql; >> struct recv_reorder_ctrl *preorder_ctrl = >> - (struct

Re: [Outreachy kernel] [PATCH 5/5] staging: rtl8712: Remove unnecessary cast on void pointer

On Fri, Mar 3, 2017 at 3:26 AM, Julia Lawall wrote: >> @@ -635,7 +635,7 @@ void r8712_reordering_ctrl_timeout_handler(void >> *pcontext) >> { >> unsigned long irql; >> struct recv_reorder_ctrl *preorder_ctrl = >> - (struct recv_reorder_ctrl *)pcontext;

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

On 03/02/2017 12:54 AM, Andy Shevchenko wrote: > On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote: >> In case a platform only defaults a "default" set of pins, but not a >> "sleep" set of pins, and this particular platform suspends and resumes >> in a way that the pin

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

On 03/02/2017 12:54 AM, Andy Shevchenko wrote: > On Wed, Mar 1, 2017 at 8:32 PM, Florian Fainelli wrote: >> In case a platform only defaults a "default" set of pins, but not a >> "sleep" set of pins, and this particular platform suspends and resumes >> in a way that the pin states are not

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> The internal logging infrastructure in ocfs2 causes special warning code to >> be >> used with KASAN, which produces rather large stack frames: > >> fs/ocfs2/super.c:

Re: [PATCH] [RFC] x86: avoid -mtune=atom for objtool warnings

On Thu, Mar 2, 2017 at 7:25 PM, Josh Poimboeuf wrote: >> It was on the current linux-next, so that commit should certainly be >> included. >> >> > Can you attach the object file? > > Here's the preliminary fix for this one (still needs more testing): It fixes the warning

[PATCH] ARM: dts: mvebu: remove unnecessary PCI range from 98dx3236

The Marvell 98dx3236 SoC only has a single PCIe x1 interface. The "Port 0.1 MEM" range was errantly kept when creating a specific dts for the SoC. Signed-off-by: Chris Packham --- arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 3 +-- 1 file changed, 1

Re: [PATCH 24/26] ocfs2: reduce stack size with KASAN

On Thu, Mar 2, 2017 at 6:46 PM, Joe Perches wrote: > On Thu, 2017-03-02 at 17:38 +0100, Arnd Bergmann wrote: >> The internal logging infrastructure in ocfs2 causes special warning code to >> be >> used with KASAN, which produces rather large stack frames: > >> fs/ocfs2/super.c: In function

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