Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-26 10:32+0300, km...@yandex-team.ru: > From: Dmitry Bilunov > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > control interface via rdmsr/wrmsr instructions. One could detect the > presence of this feature by issuing one of these instructions

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-26 10:32+0300, km...@yandex-team.ru: > From: Dmitry Bilunov > > Intel CPUs having Turbo Boost feature implement an MSR to provide a > control interface via rdmsr/wrmsr instructions. One could detect the > presence of this feature by issuing one of these instructions and > handling the

Re: [PATCH] ata: Use IS_ENABLED() instead of checking for built-in or module

On Wed, May 18, 2016 at 04:11:28PM -0400, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas

Re: [PATCH] ata: Use IS_ENABLED() instead of checking for built-in or module

On Wed, May 18, 2016 at 04:11:28PM -0400, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas Applied to libata/for-4.8.

[PATCH] gpu: host1x: hw: intr_hw: Remove create_workqueue

With concurrency managed workqueues, use of dedicated workqueues can be replaced by using system_wq. Drop host->intr_wq by using system_wq. Since there is only a single work item, increase of concurrency level by switching to system_wq should not break anything. cancel_work_sync() is used to

[PATCH] gpu: host1x: hw: intr_hw: Remove create_workqueue

With concurrency managed workqueues, use of dedicated workqueues can be replaced by using system_wq. Drop host->intr_wq by using system_wq. Since there is only a single work item, increase of concurrency level by switching to system_wq should not break anything. cancel_work_sync() is used to

[RFC PATCH 2/2] tracing: add sched_set_prio tracepoint

This tracepoint allows to keep track of all priority changes made by all sites that can change this value. The impacted system calls are sched_setscheduler, sched_setattr, sched_process_fork and set_user_nice. The priority inheritance mechanism from rt_mutex gets also instrumented with this

[RFC PATCH 2/2] tracing: add sched_set_prio tracepoint

This tracepoint allows to keep track of all priority changes made by all sites that can change this value. The impacted system calls are sched_setscheduler, sched_setattr, sched_process_fork and set_user_nice. The priority inheritance mechanism from rt_mutex gets also instrumented with this

Re: [PATCH 24/54] MAINTAINERS: Add file patterns for ata device tree bindings

On Sun, May 22, 2016 at 11:06:01AM +0200, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Tejun Heo > Cc:

Re: [PATCH 24/54] MAINTAINERS: Add file patterns for ata device tree bindings

On Sun, May 22, 2016 at 11:06:01AM +0200, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven > Cc: Tejun Heo > Cc: linux-...@vger.kernel.org Applied to libata/for-4.8.

[RFC PATCH 1/2] sched: encapsulate priority changes in a sched_set_prio static function

Currently, the priority of tasks is modified directly in the scheduling functions. Encapsulate priority updates to enable instrumentation of priority changes. This will enable analysis of real-time scheduling delays per thread priority, which cannot be performed accurately if we only trace the

[RFC PATCH 1/2] sched: encapsulate priority changes in a sched_set_prio static function

Currently, the priority of tasks is modified directly in the scheduling functions. Encapsulate priority updates to enable instrumentation of priority changes. This will enable analysis of real-time scheduling delays per thread priority, which cannot be performed accurately if we only trace the

[PATCH] fpga: zynq-fpga: fix build failure

While building m32r allmodconfig the build is failing with the error: ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined! Xilinx Zynq FPGA is using DMA but there was no dependency while building. Signed-off-by: Sudip Mukherjee --- drivers/fpga/Kconfig |

[PATCH] fpga: zynq-fpga: fix build failure

While building m32r allmodconfig the build is failing with the error: ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined! Xilinx Zynq FPGA is using DMA but there was no dependency while building. Signed-off-by: Sudip Mukherjee --- drivers/fpga/Kconfig | 1 + 1 file changed, 1

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/27/2016 03:48 PM, Guenter Roeck wrote: > On 05/27/2016 01:25 AM, Neil Armstrong wrote: > [ ... ] +data->wdt_dev.max_hw_heartbeat_ms = GXBB_WDT_TCNT_SETUP_MASK; +data->wdt_dev.min_hw_heartbeat_ms = 1; >>> >>> Does the device require a minimum time between heartbeats ? >>>

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/27/2016 03:48 PM, Guenter Roeck wrote: > On 05/27/2016 01:25 AM, Neil Armstrong wrote: > [ ... ] +data->wdt_dev.max_hw_heartbeat_ms = GXBB_WDT_TCNT_SETUP_MASK; +data->wdt_dev.min_hw_heartbeat_ms = 1; >>> >>> Does the device require a minimum time between heartbeats ? >>>

Re: [PATCH] pata_atiixp: fix trivial indentation misalignment on if statement

On Mon, May 16, 2016 at 12:35:03PM +0100, Colin King wrote: > From: Colin Ian King > > Remove extraneous space on if statement and on the following line, > trivial fix, no functional change > > Signed-off-by: Colin Ian King Applied to

Re: [PATCH] pata_atiixp: fix trivial indentation misalignment on if statement

On Mon, May 16, 2016 at 12:35:03PM +0100, Colin King wrote: > From: Colin Ian King > > Remove extraneous space on if statement and on the following line, > trivial fix, no functional change > > Signed-off-by: Colin Ian King Applied to libata/for-4.8. Thanks. -- tejun

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-27 09:49+0300, km...@yandex-team.ru: > 26.05.2016, 23:44, "Gabriel L. Somlo" : >> On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote: >>>  2016-05-26 10:32+0300, km...@yandex-team.ru: >>>  > This patch implements a dummy handler for MSR_IA32_PERF_CTL to avoid

Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-27 09:49+0300, km...@yandex-team.ru: > 26.05.2016, 23:44, "Gabriel L. Somlo" : >> On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote: >>>  2016-05-26 10:32+0300, km...@yandex-team.ru: >>>  > This patch implements a dummy handler for MSR_IA32_PERF_CTL to avoid the >>>  > crashes.

Re: Regression in i915 in kernel 4.6.0-git - bisected to f21a21983ef13a031

The latest mainline kernel (commit 3f59de0) shows a regression. The symptom is that as soon as the kernel is started, the display is blanked, and it is never turned on again. This problem was bisected to commit f21a21983ef13a031250c4c3f6018e29a549d0f1 ("drm/i915: Splitting intel_dp_detect").

Re: Regression in i915 in kernel 4.6.0-git - bisected to f21a21983ef13a031

The latest mainline kernel (commit 3f59de0) shows a regression. The symptom is that as soon as the kernel is started, the display is blanked, and it is never turned on again. This problem was bisected to commit f21a21983ef13a031250c4c3f6018e29a549d0f1 ("drm/i915: Splitting intel_dp_detect").

Re: [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants

On 05/27/2016 10:17 AM, Neil Armstrong wrote: > Hi, > On 05/26/2016 06:29 PM, Sudeep Holla wrote: >> Hi Neil, >>> To keep the spirit of the SCPI interface, add a thin "register" layer to get >>> the ops from the parent node and switch the drivers using the ops to use >>> the new of_scpi_ops_get()

Re: [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants

On 05/27/2016 10:17 AM, Neil Armstrong wrote: > Hi, > On 05/26/2016 06:29 PM, Sudeep Holla wrote: >> Hi Neil, >>> To keep the spirit of the SCPI interface, add a thin "register" layer to get >>> the ops from the parent node and switch the drivers using the ops to use >>> the new of_scpi_ops_get()

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 08:09:09PM +0900, Seung-Woo Kim wrote: > After commit, "b968091 security_d_instantiate(): move to the point prior to > attaching dentry to inode", booting on system with > systemd and security smack, following kernel panic occurs. /*

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

On Fri, May 27, 2016 at 08:09:09PM +0900, Seung-Woo Kim wrote: > After commit, "b968091 security_d_instantiate(): move to the point prior to > attaching dentry to inode", booting on system with > systemd and security smack, following kernel panic occurs. /*

[PATCH v2 10/10] h8300: Add

This will improve the performance of hash_32() and hash_64(), but due to complete lack of multi-bit shift instructions on H8, performance will still be bad in surrounding code. Designing H8-specific hash algorithms to work around that is a separate project. (But if the maintainers would like to

[PATCH v2 10/10] h8300: Add

This will improve the performance of hash_32() and hash_64(), but due to complete lack of multi-bit shift instructions on H8, performance will still be bad in surrounding code. Designing H8-specific hash algorithms to work around that is a separate project. (But if the maintainers would like to

[PATCH] wl3501_cs: avoid bogus gcc-6 warning

gcc-6 on x86 started warning about wl3501_get_encode when building with -O2: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’: drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1686:19:

[PATCH] wl3501_cs: avoid bogus gcc-6 warning

gcc-6 on x86 started warning about wl3501_get_encode when building with -O2: drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’: drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used uninitialized in this function drivers/net/wireless/wl3501_cs.c:1686:19:

[PATCH v2 09/10] microblaze: Add

Microblaze is an FPGA soft core that can be configured various ways. If it is configured without a multiplier, the standard __hash_32() will require a call to __mulsi3, which is a slow software loop. Instead, use a shift-and-add sequence for the constant multiply. GCC knows how to do this, but

[PATCH v2 09/10] microblaze: Add

Microblaze is an FPGA soft core that can be configured various ways. If it is configured without a multiplier, the standard __hash_32() will require a call to __mulsi3, which is a slow software loop. Instead, use a shift-and-add sequence for the constant multiply. GCC knows how to do this, but

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On Fri, 27 May 2016 16:56:01 +0200 Sebastian Andrzej Siewior wrote: > >We use to have a patch where a console could flag itself as atomic. > >That is, that it doesn't call any sleeping locks. What happened to that. > > > >IIRC, the video console was one such console.

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On Fri, 27 May 2016 16:56:01 +0200 Sebastian Andrzej Siewior wrote: > >We use to have a patch where a console could flag itself as atomic. > >That is, that it doesn't call any sleeping locks. What happened to that. > > > >IIRC, the video console was one such console. Otherwise, we lose out on >

[PATCH v2 08/10] m68k: Add

This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at

[PATCH v2 08/10] m68k: Add

This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at

[PATCH v2 07/10] : Add support for architecture-specific functions

This is just the infrastructure; there are no users yet. This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares the existence of . That file may define its own versions of various functions, and define HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones. Included is a

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, May 26, 2016 at 07:15:49AM -0700, Eric Dumazet wrote: > On Thu, 2016-05-26 at 16:59 +0300, Vladimir Davydov wrote: > > On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > > > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > > > On Tue, May 24, 2016 at

[PATCH v2 07/10] : Add support for architecture-specific functions

This is just the infrastructure; there are no users yet. This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares the existence of . That file may define its own versions of various functions, and define HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones. Included is a

Re: [PATCH RESEND 7/8] pipe: account to kmemcg

On Thu, May 26, 2016 at 07:15:49AM -0700, Eric Dumazet wrote: > On Thu, 2016-05-26 at 16:59 +0300, Vladimir Davydov wrote: > > On Thu, May 26, 2016 at 04:04:55PM +0900, Minchan Kim wrote: > > > On Wed, May 25, 2016 at 01:30:11PM +0300, Vladimir Davydov wrote: > > > > On Tue, May 24, 2016 at

[PATCH v2 00/10] String hash improvements

This is just the arch-specific part, updated as per requests. * Fix the stupidly overcomplex m68k conditionals (per Geert Uytterhoeven) * Renamed the arch file to (per Geert Uytterhoeven) * Improved the comments on the progress of shift-and-add (Philippe De Muyter) * Added a self-test (per

[PATCH v2 00/10] String hash improvements

This is just the arch-specific part, updated as per requests. * Fix the stupidly overcomplex m68k conditionals (per Geert Uytterhoeven) * Renamed the arch file to (per Geert Uytterhoeven) * Improved the comments on the progress of shift-and-add (Philippe De Muyter) * Added a self-test (per

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

* Steven Rostedt | 2016-05-27 10:12:51 [-0400]: >On Fri, 27 May 2016 15:58:12 +0200 >Sebastian Andrzej Siewior wrote: > >> On -RT we try to acquire sleeping locks which might lead to warnings >> from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on >>

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

* Steven Rostedt | 2016-05-27 10:12:51 [-0400]: >On Fri, 27 May 2016 15:58:12 +0200 >Sebastian Andrzej Siewior wrote: > >> On -RT we try to acquire sleeping locks which might lead to warnings >> from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on >> RT). >> We don't print in

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri 27-05-16 17:45:49, Vladimir Davydov wrote: > On Fri, May 27, 2016 at 04:26:26PM +0200, Michal Hocko wrote: [...] > > I am doing quite large changes in this area and this would cause many > > conflicts. Do you think you can postpone this after my patchset [1] gets > > sorted out please? > >

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri 27-05-16 17:45:49, Vladimir Davydov wrote: > On Fri, May 27, 2016 at 04:26:26PM +0200, Michal Hocko wrote: [...] > > I am doing quite large changes in this area and this would cause many > > conflicts. Do you think you can postpone this after my patchset [1] gets > > sorted out please? > >

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri, May 27, 2016 at 04:26:26PM +0200, Michal Hocko wrote: > On Fri 27-05-16 17:17:42, Vladimir Davydov wrote: > > When selecting an oom victim, we use the same heuristic for both memory > > cgroup and global oom. The only difference is the scope of tasks to > > select the victim from. So we

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri, May 27, 2016 at 04:26:26PM +0200, Michal Hocko wrote: > On Fri 27-05-16 17:17:42, Vladimir Davydov wrote: > > When selecting an oom victim, we use the same heuristic for both memory > > cgroup and global oom. The only difference is the scope of tasks to > > select the victim from. So we

Re: [PATCH v2 0/6] of: overlays: New target methods

Hi Frank, > On May 27, 2016, at 00:15 , Frank Rowand wrote: > > On 5/16/2016 1:18 PM, Pantelis Antoniou wrote: >> This patchset implements two new target methods. >> >> A target index method which allows selecting different >> targets according to an argument using an

Re: [PATCH v2 0/6] of: overlays: New target methods

Hi Frank, > On May 27, 2016, at 00:15 , Frank Rowand wrote: > > On 5/16/2016 1:18 PM, Pantelis Antoniou wrote: >> This patchset implements two new target methods. >> >> A target index method which allows selecting different >> targets according to an argument using an extended API and >> a

Re: [PATCH v2] perf tools: Add arch/*/include/generated/ to .gitignore

Em Fri, May 27, 2016 at 07:01:14PM +0900, Taeung Song escreveu: > Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build > syscall table .c header from kernel's syscall_64.tbl") that automatically > generate per-arch syscall table arrays e.g. > >

Re: [PATCH v2] perf tools: Add arch/*/include/generated/ to .gitignore

Em Fri, May 27, 2016 at 07:01:14PM +0900, Taeung Song escreveu: > Commit 1b700c9975008615ad470cf79acc8455ce60a695 ("perf tools: Build > syscall table .c header from kernel's syscall_64.tbl") that automatically > generate per-arch syscall table arrays e.g. > >

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 27.05.2016 15:46, Jon Hunter wrote: On 26/05/16 18:01, Dmitry Osipenko wrote: On 26.05.2016 18:27, Jon Hunter wrote: On 26/05/16 15:57, Dmitry Osipenko wrote: ... That's how I see it: +--+ |CPU 0 |

Re: [PATCH] soc/tegra: pmc: Fix "scheduling while atomic"

On 27.05.2016 15:46, Jon Hunter wrote: On 26/05/16 18:01, Dmitry Osipenko wrote: On 26.05.2016 18:27, Jon Hunter wrote: On 26/05/16 15:57, Dmitry Osipenko wrote: ... That's how I see it: +--+ |CPU 0 |

Re: [PATCH 1/2] mm: oom: add memcg to oom_control

On Fri 27-05-16 17:17:41, Vladimir Davydov wrote: > It's a part of oom context just like allocation order and nodemask, so > let's move it to oom_control instead of passing it in the argument list. Don't remember why we haven't done that when the structure was adde. > Signed-off-by: Vladimir

Re: [PATCH 1/2] mm: oom: add memcg to oom_control

On Fri 27-05-16 17:17:41, Vladimir Davydov wrote: > It's a part of oom context just like allocation order and nodemask, so > let's move it to oom_control instead of passing it in the argument list. Don't remember why we haven't done that when the structure was adde. > Signed-off-by: Vladimir

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri 27-05-16 17:17:42, Vladimir Davydov wrote: > When selecting an oom victim, we use the same heuristic for both memory > cgroup and global oom. The only difference is the scope of tasks to > select the victim from. So we could just export an iterator over all > memcg tasks and keep all oom

Re: [PATCH v6 02/12] mm: migrate: support non-lru movable page migration

On 05/20/2016 04:23 PM, Minchan Kim wrote: We have allowed migration for only LRU pages until now and it was enough to make high-order pages. But recently, embedded system(e.g., webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) so we have seen several reports about troubles

Re: [PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

On Fri 27-05-16 17:17:42, Vladimir Davydov wrote: > When selecting an oom victim, we use the same heuristic for both memory > cgroup and global oom. The only difference is the scope of tasks to > select the victim from. So we could just export an iterator over all > memcg tasks and keep all oom

Re: [PATCH v6 02/12] mm: migrate: support non-lru movable page migration

On 05/20/2016 04:23 PM, Minchan Kim wrote: We have allowed migration for only LRU pages until now and it was enough to make high-order pages. But recently, embedded system(e.g., webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory) so we have seen several reports about troubles

Re: [PATCH 1/1] usbip: don't call stub_device_reset() during stub_disconnect()

Hello, Excuse me for disturbing, could I have a feedback? On 20.05.2016 12:37, Alexander Popov wrote: > stub_disconnect() calls stub_device_reset() during usb_unbind_device() when > usb device is locked. So usb_lock_device_for_reset() in stub_device_reset() > in that case polls for one second

Re: [PATCH 1/1] usbip: don't call stub_device_reset() during stub_disconnect()

Hello, Excuse me for disturbing, could I have a feedback? On 20.05.2016 12:37, Alexander Popov wrote: > stub_disconnect() calls stub_device_reset() during usb_unbind_device() when > usb device is locked. So usb_lock_device_for_reset() in stub_device_reset() > in that case polls for one second

[PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document say that the "interrupts" property in the child node is optional. So the property being missed shouldn't be treated as an error. Signed-off-by: Javier Martinez Canillas ---

[PATCH 7/8] mwifiex: don't print an error if an optional DT property is missing

The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document say that the "interrupts" property in the child node is optional. So the property being missed shouldn't be treated as an error. Signed-off-by: Javier Martinez Canillas ---

[PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function

Hello, While booting a system with a mwifiex WiFi card, I noticed the following missleading error message: [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available This error only applies to platforms that define a child node for the SDIO device, but it's currently shown even in

[PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function

Hello, While booting a system with a mwifiex WiFi card, I noticed the following missleading error message: [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available This error only applies to platforms that define a child node for the SDIO device, but it's currently shown even in

[PATCH 6/8] mwifiex: check if mwifiex_sdio_probe_of() fails and return error

The function can fail so the returned value should be checked and the error propagated to the caller in case of a failure. Signed-off-by: Javier Martinez Canillas --- drivers/net/wireless/marvell/mwifiex/sdio.c | 9 +++-- 1 file changed, 7 insertions(+), 2

[PATCH 4/8] mwifiex: consolidate mwifiex_sdio_probe() error paths

Instead of duplicating part of the cleanups needed in case of an error in .probe callback, have a single error path and use goto labels as is common practice in the kernel. This also has the nice side effect that the cleanup operations are made in the inverse order of their counterparts, which

[PATCH 1/8] mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node

SDIO is an auto enumerable bus so the SDIO devices are matched using the sdio_device_id table and not using compatible strings from a OF id table. However, commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt support") allowed to match nodes defined as child of the SDIO host

[PATCH 1/8] mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node

SDIO is an auto enumerable bus so the SDIO devices are matched using the sdio_device_id table and not using compatible strings from a OF id table. However, commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt support") allowed to match nodes defined as child of the SDIO host

[PATCH 6/8] mwifiex: check if mwifiex_sdio_probe_of() fails and return error

The function can fail so the returned value should be checked and the error propagated to the caller in case of a failure. Signed-off-by: Javier Martinez Canillas --- drivers/net/wireless/marvell/mwifiex/sdio.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git

[PATCH 4/8] mwifiex: consolidate mwifiex_sdio_probe() error paths

Instead of duplicating part of the cleanups needed in case of an error in .probe callback, have a single error path and use goto labels as is common practice in the kernel. This also has the nice side effect that the cleanup operations are made in the inverse order of their counterparts, which

[PATCH 8/8] mwifiex: use better message and error code when OF node doesn't match

The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document lists the possible compatible strings that a SDIO child node can have, so the driver checks if the defined in the node matches. But the error message when that's not the case is misleading, so change for one

[PATCH 3/8] mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()

There's only a check if mwifiex_add_card() returned a nonzero value, but the actual error code is neither stored nor propagated to the caller. So instead of always returning -1 (which is -EPERM and not a suitable errno code in this case), propagate the value returned by mwifiex_add_card(). Patch

[PATCH 5/8] mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()

It's better to have the device name prefixed in the error message. Signed-off-by: Javier Martinez Canillas --- drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c

[PATCH 8/8] mwifiex: use better message and error code when OF node doesn't match

The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT binding document lists the possible compatible strings that a SDIO child node can have, so the driver checks if the defined in the node matches. But the error message when that's not the case is misleading, so change for one

[PATCH 3/8] mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()

There's only a check if mwifiex_add_card() returned a nonzero value, but the actual error code is neither stored nor propagated to the caller. So instead of always returning -1 (which is -EPERM and not a suitable errno code in this case), propagate the value returned by mwifiex_add_card(). Patch

[PATCH 5/8] mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()

It's better to have the device name prefixed in the error message. Signed-off-by: Javier Martinez Canillas --- drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c

[PATCH 2/8] mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()

If the sdio_enable_func() function fails on .probe, the -EIO errno code is always returned but that could make more difficult to debug and find the cause of why the function actually failed. Since the driver/device core prints the value returned by .probe in its error message propagate what was

[PATCH 2/8] mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()

If the sdio_enable_func() function fails on .probe, the -EIO errno code is always returned but that could make more difficult to debug and find the cause of why the function actually failed. Since the driver/device core prints the value returned by .probe in its error message propagate what was

[PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

When selecting an oom victim, we use the same heuristic for both memory cgroup and global oom. The only difference is the scope of tasks to select the victim from. So we could just export an iterator over all memcg tasks and keep all oom related logic in oom_kill.c, but instead we duplicate pieces

[PATCH 2/2] mm: oom: deduplicate victim selection code for memcg and global oom

When selecting an oom victim, we use the same heuristic for both memory cgroup and global oom. The only difference is the scope of tasks to select the victim from. So we could just export an iterator over all memcg tasks and keep all oom related logic in oom_kill.c, but instead we duplicate pieces

[PATCH 1/2] mm: oom: add memcg to oom_control

It's a part of oom context just like allocation order and nodemask, so let's move it to oom_control instead of passing it in the argument list. Signed-off-by: Vladimir Davydov --- drivers/tty/sysrq.c | 1 + include/linux/oom.h | 8 +--- mm/memcontrol.c | 5

[PATCH 1/2] mm: oom: add memcg to oom_control

It's a part of oom context just like allocation order and nodemask, so let's move it to oom_control instead of passing it in the argument list. Signed-off-by: Vladimir Davydov --- drivers/tty/sysrq.c | 1 + include/linux/oom.h | 8 +--- mm/memcontrol.c | 5 +++-- mm/oom_kill.c

Re: [RFC PATCH 0/4] cgroup aware workqueues

On Fri, May 27, 2016 at 12:22:19PM +0300, Michael Rapoport wrote: > I've run two guests without any CPU pinning and without any actual > interaction with cgroups > Here's the results (in MBits/sec): > > size | 64 | 256 | 1024 | 4096 | 16384 >

Re: [RFC PATCH 0/4] cgroup aware workqueues

On Fri, May 27, 2016 at 12:22:19PM +0300, Michael Rapoport wrote: > I've run two guests without any CPU pinning and without any actual > interaction with cgroups > Here's the results (in MBits/sec): > > size | 64 | 256 | 1024 | 4096 | 16384 >

Re: [PATCH] mm: zap ZONE_OOM_LOCKED

On Fri 27-05-16 17:08:13, Vladimir Davydov wrote: > Not used since oom_lock was instroduced. > > Signed-off-by: Vladimir Davydov Acked-by: Michal Hocko > --- > include/linux/mmzone.h | 1 - > mm/oom_kill.c | 4 ++-- > 2 files changed, 2

Re: [PATCH] mm: zap ZONE_OOM_LOCKED

On Fri 27-05-16 17:08:13, Vladimir Davydov wrote: > Not used since oom_lock was instroduced. > > Signed-off-by: Vladimir Davydov Acked-by: Michal Hocko > --- > include/linux/mmzone.h | 1 - > mm/oom_kill.c | 4 ++-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On Fri, 27 May 2016 15:58:12 +0200 Sebastian Andrzej Siewior wrote: > On -RT we try to acquire sleeping locks which might lead to warnings > from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on > RT). > We don't print in general from a IRQ off region so

Re: [PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On Fri, 27 May 2016 15:58:12 +0200 Sebastian Andrzej Siewior wrote: > On -RT we try to acquire sleeping locks which might lead to warnings > from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on > RT). > We don't print in general from a IRQ off region so we should not try >

[PATCH] mm: zap ZONE_OOM_LOCKED

Not used since oom_lock was instroduced. Signed-off-by: Vladimir Davydov --- include/linux/mmzone.h | 1 - mm/oom_kill.c | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index

[PATCH] mm: zap ZONE_OOM_LOCKED

Not used since oom_lock was instroduced. Signed-off-by: Vladimir Davydov --- include/linux/mmzone.h | 1 - mm/oom_kill.c | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 02069c23486d..3388ccbab7d6 100644 ---

Re: [RFC PATCH] usb: typec: Various API updates and fixes

On 05/27/2016 12:55 AM, Heikki Krogerus wrote: Hi, [ ... ] --- This patch applies on top of '[RFC PATCHv2] usb: USB Type-C Connector Class' from Heikki Krogerus. It provided the changes I made to get the code operational. drivers/usb/type-c/typec.c | 134

Re: [RFC PATCH] usb: typec: Various API updates and fixes

On 05/27/2016 12:55 AM, Heikki Krogerus wrote: Hi, [ ... ] --- This patch applies on top of '[RFC PATCHv2] usb: USB Type-C Connector Class' from Heikki Krogerus. It provided the changes I made to get the code operational. drivers/usb/type-c/typec.c | 134

[PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On -RT we try to acquire sleeping locks which might lead to warnings from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on RT). We don't print in general from a IRQ off region so we should not try this via console_unblank() / bust_spinlocks() as well. Signed-off-by: Sebastian

[PATCH RT] kernel/printk: Don't try to print from IRQ/NMI region

On -RT we try to acquire sleeping locks which might lead to warnings from lockdep or a warn_on() from spin_try_lock() (which is a rtmutex on RT). We don't print in general from a IRQ off region so we should not try this via console_unblank() / bust_spinlocks() as well. Signed-off-by: Sebastian

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/27/2016 01:25 AM, Neil Armstrong wrote: [ ... ] +data->wdt_dev.max_hw_heartbeat_ms = GXBB_WDT_TCNT_SETUP_MASK; +data->wdt_dev.min_hw_heartbeat_ms = 1; Does the device require a minimum time between heartbeats ? Just asking, because you violate it yourself below. If you want to

Re: [RFC PATCH 1/3] watchdog: Add Meson GXBB Watchdog Driver

On 05/27/2016 01:25 AM, Neil Armstrong wrote: [ ... ] +data->wdt_dev.max_hw_heartbeat_ms = GXBB_WDT_TCNT_SETUP_MASK; +data->wdt_dev.min_hw_heartbeat_ms = 1; Does the device require a minimum time between heartbeats ? Just asking, because you violate it yourself below. If you want to

Re: [PATCH v2 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On 05/20/2016 12:22 AM, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 6:15 PM, Aleksey Makarov > wrote: >> This patchset adds support for ACPI_TABLE_UPGRADE for ARM64 Hi Catalin, Will, Can you review these patches and consider ACKing the ARM64 part [5/5]

Re: [PATCH v2 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On 05/20/2016 12:22 AM, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 6:15 PM, Aleksey Makarov > wrote: >> This patchset adds support for ACPI_TABLE_UPGRADE for ARM64 Hi Catalin, Will, Can you review these patches and consider ACKing the ARM64 part [5/5] please? Thank you Aleksey

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