Re: [PATCH v3 2/3] pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain

On Fri, Sep 23, 2016 at 02:58:47PM +0200, Linus Walleij wrote: > On Tue, Sep 20, 2016 at 2:15 PM, Mika Westerberg > wrote: > > > It turns out that for north and southwest communities, they can only > > generate GPIO interrupts for lower 8 interrupts (IntSel

Re: [PATCH v3 2/3] pinctrl: cherryview: Do not add all southwest and north GPIOs to IRQ domain

On Fri, Sep 23, 2016 at 02:58:47PM +0200, Linus Walleij wrote: > On Tue, Sep 20, 2016 at 2:15 PM, Mika Westerberg > wrote: > > > It turns out that for north and southwest communities, they can only > > generate GPIO interrupts for lower 8 interrupts (IntSel value). The upper > > part (8-15) can

[PATCH v4] staging: ion: Fix a coding style issue

This patch fixes the alignment of an allocation flag block comment and moves the comments before each #define. Signed-off-by: Antti Keränen --- In addition to fixing the alignment issue, this version of the patch moves the comments from after the define lines to before the

Re: [PATCH] staging: wlan-ng: avoid to introduce new typedefs

Drop it, please. It seems I wrongly included the original patch too. Sorry for inconvenience. Thanks, Sergio Paracuellos El 2016年09月23日 a las 18:59, Greg KH escribió: On Fri, Sep 23, 2016 at 03:45:18PM +0200, Sergio Paracuellos wrote: This patch fixes the following checkpatch.pl

[PATCH v4] staging: ion: Fix a coding style issue

This patch fixes the alignment of an allocation flag block comment and moves the comments before each #define. Signed-off-by: Antti Keränen --- In addition to fixing the alignment issue, this version of the patch moves the comments from after the define lines to before the define lines.

Re: [PATCH] staging: wlan-ng: avoid to introduce new typedefs

Drop it, please. It seems I wrongly included the original patch too. Sorry for inconvenience. Thanks, Sergio Paracuellos El 2016年09月23日 a las 18:59, Greg KH escribió: On Fri, Sep 23, 2016 at 03:45:18PM +0200, Sergio Paracuellos wrote: This patch fixes the following checkpatch.pl

Re: [PATCH net-next 08/15] rxrpc: Fix call timer

On 09/23/2016 06:16 PM, David Howells wrote: Fix the call timer in the following ways: (1) If call->resend_at or call->ack_at are before or equal to the current time, then ignore that timeout. (2) If call->expire_at is before or equal to the current time, then don't set the timer

Re: [PATCH net-next 08/15] rxrpc: Fix call timer

On 09/23/2016 06:16 PM, David Howells wrote: Fix the call timer in the following ways: (1) If call->resend_at or call->ack_at are before or equal to the current time, then ignore that timeout. (2) If call->expire_at is before or equal to the current time, then don't set the timer

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote: > Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting > MSI interrupts from the older revision. > > Signed-off-by: Sinan Kaya > --- > Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13

Re: [PATCH net-next 07/15] rxrpc: Fix accidental cancellation of scheduled resend by ACK parser

Hello. On 09/23/2016 06:16 PM, David Howells wrote: When rxrpc_input_soft_acks() is parsing the soft-ACKs from an ACK packet, it updates the Tx packet annotations in the annotation buffer. If a soft-ACK is an ACK, then we overwrite unack'd, nak'd or to-be-retransmitted states and that is

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote: > Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting > MSI interrupts from the older revision. > > Signed-off-by: Sinan Kaya > --- > Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 - > 1

Re: [PATCH net-next 07/15] rxrpc: Fix accidental cancellation of scheduled resend by ACK parser

Hello. On 09/23/2016 06:16 PM, David Howells wrote: When rxrpc_input_soft_acks() is parsing the soft-ACKs from an ACK packet, it updates the Tx packet annotations in the annotation buffer. If a soft-ACK is an ACK, then we overwrite unack'd, nak'd or to-be-retransmitted states and that is

Re: [PATCH v3 2/2] i2c: aspeed: added documentation for Aspeed I2C driver

On Mon, Sep 19, 2016 at 04:23:34PM -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C controller and > busses. > > Signed-off-by: Brendan Higgins > --- > Changes for v2: > - None > Changes for v3: > - Removed reference to "bus"

Re: [PATCH v3 2/2] i2c: aspeed: added documentation for Aspeed I2C driver

On Mon, Sep 19, 2016 at 04:23:34PM -0700, Brendan Higgins wrote: > Added device tree binding documentation for Aspeed I2C controller and > busses. > > Signed-off-by: Brendan Higgins > --- > Changes for v2: > - None > Changes for v3: > - Removed reference to "bus" device tree param > --- >

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote: > The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be > supported by the simple panel driver. > > Signed-off-by: Randy Li > --- > .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++ >

Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel

On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote: > The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be > supported by the simple panel driver. > > Signed-off-by: Randy Li > --- > .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++ >

Re: [PATCH v8 2/2] ARM: dts: add TOPEET itop elite based board

On Mon, Sep 19, 2016 at 11:48:23PM +0800, Randy Li wrote: > The TOPEET itop exynos 4412 have three versions base board. The > Elite version is the cheap one without too much peripheral devices > on it. > > Currently supported are serial console, wired networking(USB), > USB OTG in peripheral

Re: [PATCH v8 2/2] ARM: dts: add TOPEET itop elite based board

On Mon, Sep 19, 2016 at 11:48:23PM +0800, Randy Li wrote: > The TOPEET itop exynos 4412 have three versions base board. The > Elite version is the cheap one without too much peripheral devices > on it. > > Currently supported are serial console, wired networking(USB), > USB OTG in peripheral

Re: [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control

On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote: > Update #pwm-cells to 3 in order to support PWM signal polarity control. > > Signed-off-by: Bhuvanchandra DV > --- > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++--- >

Re: [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control

On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote: > Update #pwm-cells to 3 in order to support PWM signal polarity control. > > Signed-off-by: Bhuvanchandra DV > --- > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++--- > arch/arm/boot/dts/imx7s.dtsi

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Em Fri, 23 Sep 2016 09:26:34 -0700 Joe Perches escreveu: > On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote: > > So, let's use an unusual approach: manually convert the > > text at the MAINTAINERS file head, adding it at a new > >

Re: [RFC PATCH v3] docs-rst: user: add MAINTAINERS

Em Fri, 23 Sep 2016 09:26:34 -0700 Joe Perches escreveu: > On Fri, 2016-09-23 at 12:07 -0300, Mauro Carvalho Chehab wrote: > > So, let's use an unusual approach: manually convert the > > text at the MAINTAINERS file head, adding it at a new > > Documentation/user/MAINTAINERS.rst, and include, as

Re: [PATCH resend v3] i2c: hibvt: add Hisilicon BVT I2C controller driver

On Mon, Sep 19, 2016 at 07:29:50PM +0800, Pan Wen wrote: > add Hisilicon BVT I2C controller driver support. > > Signed-off-by: Pan Wen > --- > .../devicetree/bindings/i2c/i2c-hibvt.txt | 24 + Acked-by: Rob Herring > drivers/i2c/busses/Kconfig

Re: [PATCH resend v3] i2c: hibvt: add Hisilicon BVT I2C controller driver

On Mon, Sep 19, 2016 at 07:29:50PM +0800, Pan Wen wrote: > add Hisilicon BVT I2C controller driver support. > > Signed-off-by: Pan Wen > --- > .../devicetree/bindings/i2c/i2c-hibvt.txt | 24 + Acked-by: Rob Herring > drivers/i2c/busses/Kconfig | 10 + >

Re: [PATCH v2] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

On Sun, Sep 18, 2016 at 03:30:21PM +0800, Jiancheng Xue wrote: > Add CRG driver for Hi3798CV200 SoC. CRG(Clock and Reset > Generator) module generates clock and reset signals used > by other module blocks on SoC. > > Signed-off-by: Jiancheng Xue > --- > change log >

Re: [PATCH v2] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

On Sun, Sep 18, 2016 at 03:30:21PM +0800, Jiancheng Xue wrote: > Add CRG driver for Hi3798CV200 SoC. CRG(Clock and Reset > Generator) module generates clock and reset signals used > by other module blocks on SoC. > > Signed-off-by: Jiancheng Xue > --- > change log > v2: > - Fixed compiling error

Re: [PATCH] mtd: s3c2410: add device tree support

On Sat, Sep 17, 2016 at 12:22:40PM -0300, Sergio Prado wrote: > Tested on FriendlyARM Mini2440 > > Signed-off-by: Sergio Prado > --- > .../devicetree/bindings/mtd/samsung-s3c2410.txt| 70 +++ > drivers/mtd/nand/s3c2410.c | 129 >

Re: [PATCH] mtd: s3c2410: add device tree support

On Sat, Sep 17, 2016 at 12:22:40PM -0300, Sergio Prado wrote: > Tested on FriendlyARM Mini2440 > > Signed-off-by: Sergio Prado > --- > .../devicetree/bindings/mtd/samsung-s3c2410.txt| 70 +++ > drivers/mtd/nand/s3c2410.c | 129 > - >

Re: [PATCH v2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels

On Sat, Sep 17, 2016 at 11:34:22AM +0200, Peter Rosin wrote: > From: Gustaf Lindström > > The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel. > > Signed-off-by: Gustaf Lindström > Signed-off-by: Peter Rosin > --- >

Re: [PATCH v2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels

On Sat, Sep 17, 2016 at 11:34:22AM +0200, Peter Rosin wrote: > From: Gustaf Lindström > > The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel. > > Signed-off-by: Gustaf Lindström > Signed-off-by: Peter Rosin > --- > .../bindings/display/panel/sharp,lq150x1lg11.txt | 7 ++ >

[PATCH v2 3/3] cpufreq: brcmstb-avs-cpufreq: add debugfs support

In order to aid debugging, we add a debugfs interface to the driver that allows direct interaction with the AVS co-processor. The debugfs interface provides a means for reading all and writing some of the mailbox registers directly from the shell prompt and enables a user to execute the

[PATCH v2 3/3] cpufreq: brcmstb-avs-cpufreq: add debugfs support

In order to aid debugging, we add a debugfs interface to the driver that allows direct interaction with the AVS co-processor. The debugfs interface provides a means for reading all and writing some of the mailbox registers directly from the shell prompt and enables a user to execute the

[PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

This driver supports voltage and frequency scaling on Broadcom STB SoCs using AVS firmware with DFS and DVFS support. Actual frequency or voltage scaling is done exclusively by the AVS firmware. The driver merely provides a standard CPUfreq interface to other kernel components and userland, and

[PATCH v2 2/3] cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs

This driver supports voltage and frequency scaling on Broadcom STB SoCs using AVS firmware with DFS and DVFS support. Actual frequency or voltage scaling is done exclusively by the AVS firmware. The driver merely provides a standard CPUfreq interface to other kernel components and userland, and

[PATCH v2 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

Add the binding document for the new brcmstb-avs-cpufreq driver. Signed-off-by: Markus Mayer --- .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 77 ++ MAINTAINERS| 7 ++ 2 files changed, 84 insertions(+)

[PATCH v2 0/3] Broadcom AVS CPUfreq driver

This series contains the CPUfreq driver for Broadcom SoCs that use "AVS Firmware" for voltage and frequency scaling. All voltage and frequency transitions are performed by the firmware and are therefore hidden from Linux. The driver provides a standard CPUfreq interface to other kernel components

[PATCH v2 1/3] dt: cpufreq: brcm: New binding document for brcmstb-avs-cpufreq

Add the binding document for the new brcmstb-avs-cpufreq driver. Signed-off-by: Markus Mayer --- .../bindings/cpufreq/brcm,stb-avs-cpu-freq.txt | 77 ++ MAINTAINERS| 7 ++ 2 files changed, 84 insertions(+) create mode 100644

[PATCH v2 0/3] Broadcom AVS CPUfreq driver

This series contains the CPUfreq driver for Broadcom SoCs that use "AVS Firmware" for voltage and frequency scaling. All voltage and frequency transitions are performed by the firmware and are therefore hidden from Linux. The driver provides a standard CPUfreq interface to other kernel components

Re: [PATCH] mm: warn about allocations which stall for too long

On 09/23/2016 01:15 AM, Michal Hocko wrote: > + /* Make sure we know about allocations which stall for too long */ > + if (!(gfp_mask & __GFP_NOWARN) && time_after(jiffies, alloc_start + > stall_timeout)) { > + pr_warn("%s: page alloction stalls for %ums: order:%u >

Re: [PATCH] mm: warn about allocations which stall for too long

On 09/23/2016 01:15 AM, Michal Hocko wrote: > + /* Make sure we know about allocations which stall for too long */ > + if (!(gfp_mask & __GFP_NOWARN) && time_after(jiffies, alloc_start + > stall_timeout)) { > + pr_warn("%s: page alloction stalls for %ums: order:%u >

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 22, 2016 at 03:23:59PM -0700, Andy Lutomirski wrote: > On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Given all that, can we make the generic thread_info::flags an unsigned > > long, matching what the thread flag helpers implicitly assume? > > Yes. Want

Re: [RFC PATCH 2/8] thread_info: allow custom in-task thread_info

On Thu, Sep 22, 2016 at 03:23:59PM -0700, Andy Lutomirski wrote: > On Sep 21, 2016 12:28 AM, "Mark Rutland" wrote: > > Given all that, can we make the generic thread_info::flags an unsigned > > long, matching what the thread flag helpers implicitly assume? > > Yes. Want to send the patch or

Re: [PATCH v3 1/2] leds: ncp5623: Add device tree binding documentation

On Fri, Sep 16, 2016 at 01:34:31PM +0200, Florian Vaussard wrote: > Add device tree binding documentation for On Semiconductor NCP5623 I2C > LED driver. The driver can independently control the PWM of the 3 > channels with 32 levels of intensity. > > The current delivered by the current source

Re: [PATCH v3 1/2] leds: ncp5623: Add device tree binding documentation

On Fri, Sep 16, 2016 at 01:34:31PM +0200, Florian Vaussard wrote: > Add device tree binding documentation for On Semiconductor NCP5623 I2C > LED driver. The driver can independently control the PWM of the 3 > channels with 32 levels of intensity. > > The current delivered by the current source

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

> Afaict there's no actual need to hide the AUX buffer for this sampling > stuff; the user knows about all this and can simply mmap() the AUX part. > The sample could either point to locations in the AUX buffer, or (as I > think this code does) memcpy bits out. This would work for perf, but not

Re: [RFC PATCH 1/6] perf: Move mlock accounting to ring buffer allocation

> Afaict there's no actual need to hide the AUX buffer for this sampling > stuff; the user knows about all this and can simply mmap() the AUX part. > The sample could either point to locations in the AUX buffer, or (as I > think this code does) memcpy bits out. This would work for perf, but not

[PATCH] thread_info: use unsigned long for flags

The generic THREAD_INFO_IN_TASK definition of thread_info::flags is a u32, matching x86 prior to the introduction of THREAD_INFO_IN_TASK. However, common helpers like test_ti_thread_flag() implicitly assume that thread_info::flags has at least the size and alignment of unsigned long, and relying

[PATCH] thread_info: use unsigned long for flags

The generic THREAD_INFO_IN_TASK definition of thread_info::flags is a u32, matching x86 prior to the introduction of THREAD_INFO_IN_TASK. However, common helpers like test_ti_thread_flag() implicitly assume that thread_info::flags has at least the size and alignment of unsigned long, and relying

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On 9/23/2016 11:39 AM, Rob Herring wrote: >> Required properties: >> > -- compatible: must contain "qcom,hidma-1.0" >> > +- compatible: must contain "qcom,hidma-1.0" for initial HW or >> > "qcom,hidma-1.1" >> > +for MSI capable HW. > Do you have an SoC part number yet? If so, please use that

Re: [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI

On 9/23/2016 11:39 AM, Rob Herring wrote: >> Required properties: >> > -- compatible: must contain "qcom,hidma-1.0" >> > +- compatible: must contain "qcom,hidma-1.0" for initial HW or >> > "qcom,hidma-1.1" >> > +for MSI capable HW. > Do you have an SoC part number yet? If so, please use that

Re: [RFC PATCH 0/6] perf: Add AUX data sampling

On Fri, Sep 23, 2016 at 01:49:17PM +0200, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 02:27:20PM +0300, Alexander Shishkin wrote: > > Hi Peter, > > > > This is an RFC, I'm not sending the tooling bits in this series, > > although they can be found here [1]. > > > > This series introduces AUX

Re: [RFC PATCH 0/6] perf: Add AUX data sampling

On Fri, Sep 23, 2016 at 01:49:17PM +0200, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 02:27:20PM +0300, Alexander Shishkin wrote: > > Hi Peter, > > > > This is an RFC, I'm not sending the tooling bits in this series, > > although they can be found here [1]. > > > > This series introduces AUX

Re: [RFC] remove unnecessary condition in remove_inode_hugepages

On 09/22/2016 06:53 PM, zhong jiang wrote: > > At present, we need to call hugetlb_fix_reserve_count when > hugetlb_unrserve_pages fails, > and PagePrivate will decide hugetlb reserves counts. > > we obtain the page from page cache. and use page both lock_page and > mutex_lock. >

Re: [RFC] remove unnecessary condition in remove_inode_hugepages

On 09/22/2016 06:53 PM, zhong jiang wrote: > > At present, we need to call hugetlb_fix_reserve_count when > hugetlb_unrserve_pages fails, > and PagePrivate will decide hugetlb reserves counts. > > we obtain the page from page cache. and use page both lock_page and > mutex_lock. >

[PATCHv2] cpupower: Correct return type of cpu_power_is_cpu_online in cpufreq

When converting to a shared library in ac5a181d065d ("cpupower: Add cpuidle parts into library"), cpu_freq_cpu_exists was converted to cpupower_is_cpu_online. cpu_req_cpu_exists returned 0 on success and -ENOSYS on failure whereas cpupower_is_cpu_online returns 1 on success. Check for the correct

[PATCHv2] cpupower: Correct return type of cpu_power_is_cpu_online in cpufreq

When converting to a shared library in ac5a181d065d ("cpupower: Add cpuidle parts into library"), cpu_freq_cpu_exists was converted to cpupower_is_cpu_online. cpu_req_cpu_exists returned 0 on success and -ENOSYS on failure whereas cpupower_is_cpu_online returns 1 on success. Check for the correct

Re: [PATCH 1/2] Staging: ks7010: mark symbols static where possible

On Fri, Sep 23, 2016 at 09:22:29PM +0800, Baoyou Xie wrote: > We get 3 warnings when building kernel with W=1: > drivers/staging/ks7010/ks7010_sdio.c:90:6: warning: no previous prototype for > 'ks_wlan_hw_sleep_doze_request' [-Wmissing-prototypes] > drivers/staging/ks7010/ks7010_sdio.c:120:6:

Re: [PATCH 1/2] Staging: ks7010: mark symbols static where possible

On Fri, Sep 23, 2016 at 09:22:29PM +0800, Baoyou Xie wrote: > We get 3 warnings when building kernel with W=1: > drivers/staging/ks7010/ks7010_sdio.c:90:6: warning: no previous prototype for > 'ks_wlan_hw_sleep_doze_request' [-Wmissing-prototypes] > drivers/staging/ks7010/ks7010_sdio.c:120:6:

[PATCH v2 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op

Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) introduced a performance regression for systems using pcc-cpufreq and ondemand governor. This is measurable with different workloads. E.g. wall-clock time for kernel compilation significantly increased. The elimination of the

[PATCH v2 2/2] cpufreq/pcc-cpufreq: Make use of map_load_to_freq op

Commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) introduced a performance regression for systems using pcc-cpufreq and ondemand governor. This is measurable with different workloads. E.g. wall-clock time for kernel compilation significantly increased. The elimination of the

Re: [PATCH] staging: android: ion: mark symbols static where possible

On 09/23/2016 06:13 AM, Baoyou Xie wrote: We get 4 warnings when building kernel with W=1: drivers/staging/android/ion/ion_carveout_heap.c:36:17: warning: no previous prototype for 'ion_carveout_allocate' [-Wmissing-prototypes] drivers/staging/android/ion/ion_carveout_heap.c:50:6: warning: no

Re: [PATCH] staging: android: ion: mark symbols static where possible

On 09/23/2016 06:13 AM, Baoyou Xie wrote: We get 4 warnings when building kernel with W=1: drivers/staging/android/ion/ion_carveout_heap.c:36:17: warning: no previous prototype for 'ion_carveout_allocate' [-Wmissing-prototypes] drivers/staging/android/ion/ion_carveout_heap.c:50:6: warning: no

[PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

Introduce op for ondemand governor that is used to map load to frequency. It allows a cpufreq driver to provide a specific mapping function if the generic function is not optimal for the driver. Performance results (kernel compile with different number of jobs) based on 4.8.0-rc7 (with and w/o my

[PATCH v2 1/2] cpufreq/ondemand: Introduce op to customize mapping of load to frequency

Introduce op for ondemand governor that is used to map load to frequency. It allows a cpufreq driver to provide a specific mapping function if the generic function is not optimal for the driver. Performance results (kernel compile with different number of jobs) based on 4.8.0-rc7 (with and w/o my

Re: [PATCH] staging: wlan-ng: avoid to introduce new typedefs

On Fri, Sep 23, 2016 at 03:45:18PM +0200, Sergio Paracuellos wrote: > This patch fixes the following checkpatch.pl warning in p80211types.h: > WARNING: do not add new typedefs > > Signed-off-by: Sergio Paracuellos > --- Was this patch part of this series? It

Re: [PATCH] staging: wlan-ng: avoid to introduce new typedefs

On Fri, Sep 23, 2016 at 03:45:18PM +0200, Sergio Paracuellos wrote: > This patch fixes the following checkpatch.pl warning in p80211types.h: > WARNING: do not add new typedefs > > Signed-off-by: Sergio Paracuellos > --- Was this patch part of this series? It didn't have a number, so I'm

Re: [PATCH] greybus: audio: ensure module is set to avoid crash on dev_err message

On Fri, Sep 23, 2016 at 11:25:40AM +0100, Colin King wrote: > From: Colin Ian King > > Currently, if info is null, the dev_err message is dereferencing an > uninitialized module pointer. Instead, initialize module before the > dev_err call to fix this issue. > > Found

Re: [PATCH] greybus: audio: ensure module is set to avoid crash on dev_err message

On Fri, Sep 23, 2016 at 11:25:40AM +0100, Colin King wrote: > From: Colin Ian King > > Currently, if info is null, the dev_err message is dereferencing an > uninitialized module pointer. Instead, initialize module before the > dev_err call to fix this issue. > > Found using static analysis

[PATCH v2] signals: Avoid unnecessary taking of sighand->siglock

When running certain database workload on a high-end system with many CPUs, it was found that spinlock contention in the sigprocmask syscalls became a significant portion of the overall CPU cycles as shown below. 9.30% 9.30% 905387 dataserver /proc/kcore 0x7fff8163f4d2 [k]

[PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

Hi, following patches address the performance degradation due to commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) on systems using pcc-cpufreq driver and ondemand governor. Patch 1 introduces a generic_map_load_to_freq function which is similar to what is used since commit

[PATCH v2] signals: Avoid unnecessary taking of sighand->siglock

When running certain database workload on a high-end system with many CPUs, it was found that spinlock contention in the sigprocmask syscalls became a significant portion of the overall CPU cycles as shown below. 9.30% 9.30% 905387 dataserver /proc/kcore 0x7fff8163f4d2 [k]

[PATCH v2 0/2] cpufreq: pcc-cpufreq: Re-introduce deadband effect to reduce number of frequency changes

Hi, following patches address the performance degradation due to commit 6393d6a102 (cpufreq: ondemand: Eliminate the deadband effect) on systems using pcc-cpufreq driver and ondemand governor. Patch 1 introduces a generic_map_load_to_freq function which is similar to what is used since commit

Re: [PATCH] softirq: let ksoftirqd do its job

On Fri, 23 Sep 2016 13:53:33 +0200 Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 01:35:59PM +0200, Daniel Borkmann wrote: > > On 09/02/2016 08:39 AM, David Miller wrote: > > > > > >I'm just kind of assuming this won't go through my tree, but I can take > > >it if that's

[PATCH RT 2/7] timers: wakeup all timer waiters without holding the base lock

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior There should be no need to hold the base lock during the wakeup. There should be no boosting involved, the wakeup list has its own

Re: [PATCH] softirq: let ksoftirqd do its job

On Fri, 23 Sep 2016 13:53:33 +0200 Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 01:35:59PM +0200, Daniel Borkmann wrote: > > On 09/02/2016 08:39 AM, David Miller wrote: > > > > > >I'm just kind of assuming this won't go through my tree, but I can take > > >it if that's what everyone agrees

[PATCH RT 2/7] timers: wakeup all timer waiters without holding the base lock

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior There should be no need to hold the base lock during the wakeup. There should be no boosting involved, the wakeup list has its own lock so it should be

[PATCH RT 4/7] net: add a lock around icmp_sk()

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It looks like the this_cpu_ptr() access in icmp_sk() is protected with local_bh_disable(). To avoid missing serialization in -RT I

[PATCH RT 4/7] net: add a lock around icmp_sk()

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It looks like the this_cpu_ptr() access in icmp_sk() is protected with local_bh_disable(). To avoid missing serialization in -RT I am adding here a local

[RFC PATCH v2 4/5] tracing: extend sched_pi_setprio

Use the TRACE_EVENT_MAP macro to extend the sched_pi_setprio into sched_pi_update_prio. The pre-existing event is untouched. This gets rid of the old/new prio fields, and instead outputs the scheduling update based on the top waiter of the rtmutex. Boosting: sched_pi_update_prio: comm=lowprio1,

[RFC PATCH v2 3/5] tracing: extend scheduling tracepoints

Create alternate versions of the sched_switch, sched_waking and sched_process_fork tracepoint probes to output priority-related fields and PI top-waiter if any. This uses the TRACE_EVENT_MAP macro, so the instrumented code and the already existing tracepoints are untouched. We only expose the

[RFC PATCH v2 0/5] Additional scheduling information in tracepoints

This patchset is a proposal to extract more accurate scheduling information in the kernel trace. The existing scheduling tracepoints currently expose the "prio" field which is an internal detail of the kernel and is not enough to understand the behaviour of the scheduler. In order to get more

[PATCH RT 5/7] fs/dcache: resched/chill only if we make no progress

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() / cond_resched()

[PATCH RT 6/7] fs/dcache: incremental fixup of the retry routine

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It has been pointed out by tglx that on UP the non-RT task could spin its entire time slice because the lock owner is preempted.

[PATCH RT 3/7] net: add back the missing serialization in ip_send_unicast_reply()

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Some time ago Sami Pietikainen reported a crash on -RT in ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire

[RFC PATCH v2 4/5] tracing: extend sched_pi_setprio

Use the TRACE_EVENT_MAP macro to extend the sched_pi_setprio into sched_pi_update_prio. The pre-existing event is untouched. This gets rid of the old/new prio fields, and instead outputs the scheduling update based on the top waiter of the rtmutex. Boosting: sched_pi_update_prio: comm=lowprio1,

[RFC PATCH v2 3/5] tracing: extend scheduling tracepoints

Create alternate versions of the sched_switch, sched_waking and sched_process_fork tracepoint probes to output priority-related fields and PI top-waiter if any. This uses the TRACE_EVENT_MAP macro, so the instrumented code and the already existing tracepoints are untouched. We only expose the

[RFC PATCH v2 0/5] Additional scheduling information in tracepoints

This patchset is a proposal to extract more accurate scheduling information in the kernel trace. The existing scheduling tracepoints currently expose the "prio" field which is an internal detail of the kernel and is not enough to understand the behaviour of the scheduler. In order to get more

[PATCH RT 5/7] fs/dcache: resched/chill only if we make no progress

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Upstream commit 47be61845c77 ("fs/dcache.c: avoid soft-lockup in dput()") changed the condition _when_ cpu_relax() / cond_resched() was invoked. This

[PATCH RT 6/7] fs/dcache: incremental fixup of the retry routine

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior It has been pointed out by tglx that on UP the non-RT task could spin its entire time slice because the lock owner is preempted. This won't happen on !RT.

[PATCH RT 3/7] net: add back the missing serialization in ip_send_unicast_reply()

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior Some time ago Sami Pietikainen reported a crash on -RT in ip_send_unicast_reply() which was later fixed by Nicholas Mc Guire (v3.12.8-rt11). Later

[PATCH RT 0/7] Linux 3.4.112-rt144-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.4.112-rt144-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[RFC PATCH v2 5/5] tracing: add sched_update_prio

This tracepoint allows to keep track of all explicit priority changes of a task. It outputs the scheduling policy, the nice value, the rt_priority and the deadline-related attributes (dl_runtime, dl_deadline and dl_period). It is emitted in the code path of the sched_setscheduler, sched_setattr,

[PATCH RT 1/7] timers: wakeup all timer waiters

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is

[PATCH RT 7/7] Linux 3.4.112-rt144-rc1

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (Red Hat)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

[RFC PATCH v2 2/5] tracing: add TRACE_EVENT_MAP

This macro allows to create an alias of an existing TRACE_EVENT. A TRACE_EVENT_MAP connects a new probe to an existing tracepoint, so we can use it to create another output of the same tracepoint without changing the instrumented code. This allows to create alternate versions of existing

[RFC PATCH v2 1/5] sched: get effective policy and rt_prio

Helper functions to get the effective policy and rt_priority from the prio and policy values. This is useful in PI situations because these fields are not updated in the task, only the sched_class is temporarily modified. Cc: Peter Zijlstra Cc: Steven Rostedt (Red Hat)

[PATCH RT 0/7] Linux 3.4.112-rt144-rc1

Dear RT Folks, This is the RT stable review cycle of patch 3.4.112-rt144-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[RFC PATCH v2 5/5] tracing: add sched_update_prio

This tracepoint allows to keep track of all explicit priority changes of a task. It outputs the scheduling policy, the nice value, the rt_priority and the deadline-related attributes (dl_runtime, dl_deadline and dl_period). It is emitted in the code path of the sched_setscheduler, sched_setattr,

[PATCH RT 1/7] timers: wakeup all timer waiters

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The base lock is dropped during the invocation if the timer. That means it is possible that we have one waiter while timer1 is running and once this one

[PATCH RT 7/7] Linux 3.4.112-rt144-rc1

3.4.112-rt144-rc1 stable review patch. If anyone has any objections, please let me know. -- From: "Steven Rostedt (Red Hat)" --- localversion-rt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localversion-rt b/localversion-rt index

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