Re: [PATCH] igb: check memory allocation failure

Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit : On 8/27/17 2:42 AM, Christophe JAILLET wrote: Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by:

Re: [PATCH] igb: check memory allocation failure

Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit : On 8/27/17 2:42 AM, Christophe JAILLET wrote: Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by:

Re: [PATCH] Fix: xtensa: add missing sync_core

Hi Mathieu, On Mon, Aug 28, 2017 at 12:36 AM, Mathieu Desnoyers wrote: > The membarrier system call now requires all architectures to implement > sync_core(). On Xtensa, it is provided by the EXTW instruction. > > [ Completely untested! Can someone on the xtensa

Re: [PATCH] Fix: xtensa: add missing sync_core

Hi Mathieu, On Mon, Aug 28, 2017 at 12:36 AM, Mathieu Desnoyers wrote: > The membarrier system call now requires all architectures to implement > sync_core(). On Xtensa, it is provided by the EXTW instruction. > > [ Completely untested! Can someone on the xtensa side confirm whether > EXTW is

[PATCH] acpi: apei: call into AER handling regardless of severity

Currently the GHES code only calls into the AER driver for recoverable type errors. This is incorrect because errors of other severities do not get logged by the AER driver and do not get exposed to user space via the AER trace event. So, call into the AER driver for PCIe errors regardless of the

[PATCH] acpi: apei: call into AER handling regardless of severity

Currently the GHES code only calls into the AER driver for recoverable type errors. This is incorrect because errors of other severities do not get logged by the AER driver and do not get exposed to user space via the AER trace event. So, call into the AER driver for PCIe errors regardless of the

[PATCH] PCI/AER: don't call recovery process for correctable errors

Correctable errors do not need any software intervention, so avoid calling into the software recovery process for correctable errors. Signed-off-by: Tyler Baicar --- drivers/pci/pcie/aer/aerdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH] PCI/AER: don't call recovery process for correctable errors

Correctable errors do not need any software intervention, so avoid calling into the software recovery process for correctable errors. Signed-off-by: Tyler Baicar --- drivers/pci/pcie/aer/aerdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH V3] acpi: apei: clear error status before acknowledging the error

On Mon, 2017-08-28 at 10:53 -0600, Tyler Baicar wrote: > Currently we acknowledge errors before clearing the error status. > This could cause a new error to be populated by firmware in-between > the error acknowledgment and the error status clearing which would > cause the second error's status to

Re: [PATCH V3] acpi: apei: clear error status before acknowledging the error

On Mon, 2017-08-28 at 10:53 -0600, Tyler Baicar wrote: > Currently we acknowledge errors before clearing the error status. > This could cause a new error to be populated by firmware in-between > the error acknowledgment and the error status clearing which would > cause the second error's status to

RE: linux-next: manual merge of the scsi tree with the staging tree

Adding sparmaintai...@unisys.com. -Sameer Wadgaonkar -Original Message- From: g...@kroah.com [mailto:g...@kroah.com] Sent: Monday, August 28, 2017 12:44 PM To: Bart Van Assche Cc: s...@canb.auug.org.au; linux-kernel@vger.kernel.org; j...@linux.vnet.ibm.com;

RE: linux-next: manual merge of the scsi tree with the staging tree

Adding sparmaintai...@unisys.com. -Sameer Wadgaonkar -Original Message- From: g...@kroah.com [mailto:g...@kroah.com] Sent: Monday, August 28, 2017 12:44 PM To: Bart Van Assche Cc: s...@canb.auug.org.au; linux-kernel@vger.kernel.org; j...@linux.vnet.ibm.com; h...@suse.de;

Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

Hi Hans, On Mon, Aug 28, 2017 at 9:04 AM, Hans de Goede wrote: > Hi, > > > On 16-08-17 22:28, Liam Breck wrote: >> >> Hi Hans, >> >> On Tue, Aug 15, 2017 at 1:04 PM, Hans de Goede >> wrote: >>> >>> On some devices the USB Type-C port power (USB PD 2.0)

Re: [PATCH v9 2/2] dt-bindings: new binding for ps/2 gpio devices

On Fri, Aug 25, 2017 at 01:03:23PM -0500, Rob Herring wrote: > On Mon, Aug 21, 2017 at 09:31:42PM +0200, Danilo Krummrich wrote: > > The PS/2 gpio device binding defines the gpio pins (data and clock) > > as well as the interrupt which should be used to drive the ps/2 bus. > > It is expected to

Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

Hi Hans, On Mon, Aug 28, 2017 at 9:04 AM, Hans de Goede wrote: > Hi, > > > On 16-08-17 22:28, Liam Breck wrote: >> >> Hi Hans, >> >> On Tue, Aug 15, 2017 at 1:04 PM, Hans de Goede >> wrote: >>> >>> On some devices the USB Type-C port power (USB PD 2.0) negotiation is >>> done by a separate

Re: [PATCH v9 2/2] dt-bindings: new binding for ps/2 gpio devices

On Fri, Aug 25, 2017 at 01:03:23PM -0500, Rob Herring wrote: > On Mon, Aug 21, 2017 at 09:31:42PM +0200, Danilo Krummrich wrote: > > The PS/2 gpio device binding defines the gpio pins (data and clock) > > as well as the interrupt which should be used to drive the ps/2 bus. > > It is expected to

Re: [PATCH v9 1/2] serio: PS/2 gpio bit banging driver for serio bus

On Mon, Aug 21, 2017 at 09:31:41PM +0200, Danilo Krummrich wrote: > This driver provides PS/2 serio bus support by implementing bit banging > with the GPIO API. The GPIO pins, data and clock, can be configured with > a node in the device tree or by generic device properties (GDP). > > Writing to

Re: [PATCH v9 1/2] serio: PS/2 gpio bit banging driver for serio bus

On Mon, Aug 21, 2017 at 09:31:41PM +0200, Danilo Krummrich wrote: > This driver provides PS/2 serio bus support by implementing bit banging > with the GPIO API. The GPIO pins, data and clock, can be configured with > a node in the device tree or by generic device properties (GDP). > > Writing to

Re: [ANNOUNCE] 4.1.42-rt50

On 2017-08-16 15:42:28 [-0500], Julia Cartwright wrote: > Hello RT Folks! > > I'm pleased to announce the 4.1.42-rt50 stable release. Okay. So this seemed to happen around v4.1.19 RT where this chunk got in: +#define assert_rcu_or_wq_mutex_or_pool_mutex(wq) \ +

Re: [ANNOUNCE] 4.1.42-rt50

On 2017-08-16 15:42:28 [-0500], Julia Cartwright wrote: > Hello RT Folks! > > I'm pleased to announce the 4.1.42-rt50 stable release. Okay. So this seemed to happen around v4.1.19 RT where this chunk got in: +#define assert_rcu_or_wq_mutex_or_pool_mutex(wq) \ +

[PATCH v2 1/2] OF: move extern declarations of of_stdout inside ifdef

Move extern declarations of "of_stdout" pointer inside "CONFIG_OF" ifdef to be able to get rid of "CONFIG_OF" ifdef in its usage places. Acked-by: Rob Herring Suggested-by: Steven Rostedt Signed-off-by: Eugeniy Paltsev ---

[PATCH v2 1/2] OF: move extern declarations of of_stdout inside ifdef

Move extern declarations of "of_stdout" pointer inside "CONFIG_OF" ifdef to be able to get rid of "CONFIG_OF" ifdef in its usage places. Acked-by: Rob Herring Suggested-by: Steven Rostedt Signed-off-by: Eugeniy Paltsev --- include/linux/of.h | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH v2 2/2] console: don't select first registered console if stdout-path used

In the current implementation we take the first console that registers if we didn't select one. But if we specify console via "stdout-path" property in device tree we don't want first console that registers here to be selected. Otherwise we may choose wrong console - for example if some console

[PATCH v2 2/2] console: don't select first registered console if stdout-path used

In the current implementation we take the first console that registers if we didn't select one. But if we specify console via "stdout-path" property in device tree we don't want first console that registers here to be selected. Otherwise we may choose wrong console - for example if some console

[PATCH v2 0/2] console: don't select first registered console if stdout-path used

Don't select first registered console if one is specified by the device tree via the stdout-path (or linux,stdout-path) chosen node properties. Eugeniy Paltsev (2): OF: move extern declarations of of_stdout inside ifdef console: don't select first registered console if stdout-path used

[PATCH v2 0/2] console: don't select first registered console if stdout-path used

Don't select first registered console if one is specified by the device tree via the stdout-path (or linux,stdout-path) chosen node properties. Eugeniy Paltsev (2): OF: move extern declarations of of_stdout inside ifdef console: don't select first registered console if stdout-path used

Re: [PATCH v3 4/5] input: Add MediaTek PMIC keys support

Hi Chen, On Fri, Aug 25, 2017 at 02:32:32PM +0800, Chen Zhong wrote: > +static int mtk_pmic_key_setup(struct mtk_pmic_keys *keys, > + struct pmic_keys_info *info) > +{ > + int ret; > + > + info->keys = keys; > + > + ret = regmap_update_bits(keys->regmap,

Re: [PATCH v3 4/5] input: Add MediaTek PMIC keys support

Hi Chen, On Fri, Aug 25, 2017 at 02:32:32PM +0800, Chen Zhong wrote: > +static int mtk_pmic_key_setup(struct mtk_pmic_keys *keys, > + struct pmic_keys_info *info) > +{ > + int ret; > + > + info->keys = keys; > + > + ret = regmap_update_bits(keys->regmap,

Re: kvm splat in mmu_spte_clear_track_bits

Bernhard Held wrote: > On 08/27/2017 at 02:35 PM, Adam Borowski wrote: >> 4.13-rc5 retested fails >> Crashed only after two hours or so of testing. >> 4.13-rc4 apparently works >> It survived several hours of varied tests (like 5 debian-installer runs, a >> win10 point release

Re: kvm splat in mmu_spte_clear_track_bits

Bernhard Held wrote: > On 08/27/2017 at 02:35 PM, Adam Borowski wrote: >> 4.13-rc5 retested fails >> Crashed only after two hours or so of testing. >> 4.13-rc4 apparently works >> It survived several hours of varied tests (like 5 debian-installer runs, a >> win10 point release upgrade, some hurd

Re: [PATCH 1/6] staging: usb: typec: tcpm set port type callback

On Sun, Aug 27, 2017 at 11:16 AM, Guenter Roeck wrote: > > On 08/27/2017 11:01 AM, Greg Kroah-Hartman wrote: >> >> On Sat, Aug 26, 2017 at 10:23:24PM -0700, Badhri Jagan Sridharan wrote: >>> >>> The port type callback call enquires the tcpc_dev if >>> the requested port type

Re: [PATCH 1/6] staging: usb: typec: tcpm set port type callback

On Sun, Aug 27, 2017 at 11:16 AM, Guenter Roeck wrote: > > On 08/27/2017 11:01 AM, Greg Kroah-Hartman wrote: >> >> On Sat, Aug 26, 2017 at 10:23:24PM -0700, Badhri Jagan Sridharan wrote: >>> >>> The port type callback call enquires the tcpc_dev if >>> the requested port type is supported. If

Re: [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed

On 08/27/2017 07:36 PM, Ming Lei wrote: > On Wed, Aug 23, 2017 at 11:34 AM, Ming Lei wrote: >> On Wed, Aug 9, 2017 at 9:44 AM, Ming Lei wrote: >>> Hi David, >>> >>> On Wed, Aug 9, 2017 at 2:13 AM, David Jeffery wrote: On

Re: [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed

On 08/27/2017 07:36 PM, Ming Lei wrote: > On Wed, Aug 23, 2017 at 11:34 AM, Ming Lei wrote: >> On Wed, Aug 9, 2017 at 9:44 AM, Ming Lei wrote: >>> Hi David, >>> >>> On Wed, Aug 9, 2017 at 2:13 AM, David Jeffery wrote: On 08/07/2017 07:53 PM, Ming Lei wrote: > On Tue, Aug 8, 2017 at

[PATCH V3] acpi: apei: clear error status before acknowledging the error

Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would cause the second error's status to be cleared without being handled. So, clear the error status

[PATCH V3] acpi: apei: clear error status before acknowledging the error

Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would cause the second error's status to be cleared without being handled. So, clear the error status

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, 28 Aug 2017, Peter Zijlstra wrote: > Well, ideally something like this would start the system with all the > 'crap' threads in !root cgroup. But that means cgroupfs needs to be > populated with at least two directories on boot. And current cgroup > cruft doesn't expect that. Maybe an

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, 28 Aug 2017, Peter Zijlstra wrote: > Well, ideally something like this would start the system with all the > 'crap' threads in !root cgroup. But that means cgroupfs needs to be > populated with at least two directories on boot. And current cgroup > cruft doesn't expect that. Maybe an

Re: [PATCH] input: misc: don't build m68kspkr when mach_beep is undefined

On Thu, Aug 24, 2017 at 04:44:27PM +0200, Alexandre Belloni wrote: > mach_beep is defined arch/m68k/kernel/setup_mm.c which is compiled only > when MMU is selected. > > To avoid linking errors, make INPUT_M68K_BEEP depend on MMU. Hmm, can we maybe pull mach_beep from setup_mm.c to setup.c? MMU

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, 28 Aug 2017, Peter Zijlstra wrote: > > I think that change is good maybe even a bugfix. I had some people be very > > surprised when they set affinities to multiple cpus and the processeds > > kept sticking to one cpu because of isolcpus. > > Those people cannot read. And no its not a bug

Re: [PATCH] input: misc: don't build m68kspkr when mach_beep is undefined

On Thu, Aug 24, 2017 at 04:44:27PM +0200, Alexandre Belloni wrote: > mach_beep is defined arch/m68k/kernel/setup_mm.c which is compiled only > when MMU is selected. > > To avoid linking errors, make INPUT_M68K_BEEP depend on MMU. Hmm, can we maybe pull mach_beep from setup_mm.c to setup.c? MMU

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, 28 Aug 2017, Peter Zijlstra wrote: > > I think that change is good maybe even a bugfix. I had some people be very > > surprised when they set affinities to multiple cpus and the processeds > > kept sticking to one cpu because of isolcpus. > > Those people cannot read. And no its not a bug

cocci: remove unnecessary casts of void * while avoiding casts with __user or __force ?

A simple cocci script that removes unnecessary casts of a void * will also remove casts with __force or __user e.g.: -   xemaclite_aligned_write(address_ptr, (u32 __force *) addr, ETH_ALEN); +   xemaclite_aligned_write(address_ptr, addr, ETH_ALEN); Is there a simple mechanism to avoid

cocci: remove unnecessary casts of void * while avoiding casts with __user or __force ?

A simple cocci script that removes unnecessary casts of a void * will also remove casts with __force or __user e.g.: -   xemaclite_aligned_write(address_ptr, (u32 __force *) addr, ETH_ALEN); +   xemaclite_aligned_write(address_ptr, addr, ETH_ALEN); Is there a simple mechanism to avoid

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

On Mon, Aug 28, 2017 at 7:51 AM, Liang, Kan wrote: > > I tried this patch and https://lkml.org/lkml/2017/8/27/222 together. > But they don't fix the issue. I can still get the similar call stack. So the main issue was that I *really* hated Tim's patch #2, and the patch to

Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit

On Mon, Aug 28, 2017 at 7:51 AM, Liang, Kan wrote: > > I tried this patch and https://lkml.org/lkml/2017/8/27/222 together. > But they don't fix the issue. I can still get the similar call stack. So the main issue was that I *really* hated Tim's patch #2, and the patch to clean up the page wait

RE: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

> -Original Message- > From: Haiyang Zhang > Sent: Monday, August 28, 2017 8:57 AM > To: Stephen Hemminger ; Eduardo Otubo > ; KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Stephen >

RE: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

> -Original Message- > From: Haiyang Zhang > Sent: Monday, August 28, 2017 8:57 AM > To: Stephen Hemminger ; Eduardo Otubo > ; KY Srinivasan > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Stephen > Hemminger ; David Miller > > Subject: RE: [PATCHv2]

Re: [PATCH 0/9] constify amba_id

On 24 August 2017 at 10:35, Arvind Yadav wrote: > amba_id are not supposed to change at runtime. All functions > working with const amba_id. So mark the non-const structs as const. > > Arvind Yadav (9): > [PATCH 1/9] coresight: constify amba_id > [PATCH 2/9]

Re: [PATCH 0/9] constify amba_id

On 24 August 2017 at 10:35, Arvind Yadav wrote: > amba_id are not supposed to change at runtime. All functions > working with const amba_id. So mark the non-const structs as const. > > Arvind Yadav (9): > [PATCH 1/9] coresight: constify amba_id > [PATCH 2/9] coresight: etb10: constify amba_id

Re: [PATCH v2 17/19] perf, tools, stat: Support duration_time for metrics

On Mon, Aug 28, 2017 at 11:19:31AM +0200, Jiri Olsa wrote: > On Fri, Aug 11, 2017 at 04:26:32PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Some of the metrics formulas (like GFLOPs) need to know how long > > the measurement period is. Support an internal event

Re: [PATCH v2 17/19] perf, tools, stat: Support duration_time for metrics

On Mon, Aug 28, 2017 at 11:19:31AM +0200, Jiri Olsa wrote: > On Fri, Aug 11, 2017 at 04:26:32PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Some of the metrics formulas (like GFLOPs) need to know how long > > the measurement period is. Support an internal event called duration_time, >

Re: [PATCH v2 14/19] perf, tools, stat: Support JSON metrics in perf stat

On Mon, Aug 28, 2017 at 11:19:21AM +0200, Jiri Olsa wrote: > On Fri, Aug 11, 2017 at 04:26:29PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Add generic support for standalone metrics specified in JSON files > > to perf stat. A metric is a formula that uses

Re: [PATCH v2 14/19] perf, tools, stat: Support JSON metrics in perf stat

On Mon, Aug 28, 2017 at 11:19:21AM +0200, Jiri Olsa wrote: > On Fri, Aug 11, 2017 at 04:26:29PM -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > Add generic support for standalone metrics specified in JSON files > > to perf stat. A metric is a formula that uses multiple events > > to

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, Aug 28, 2017 at 04:36:06PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > > On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > > > * Most SCSI drivers exist under drivers/scsi, including the virtio-scsi > > > and > > >

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, Aug 28, 2017 at 04:36:06PM +, Bart Van Assche wrote: > On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > > On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > > > * Most SCSI drivers exist under drivers/scsi, including the virtio-scsi > > > and > > >

Re: [PATCH v1] selftests: Enhance kselftest_harness.h to print which assert failed

On 08/06/2017 05:23 PM, Mickaël Salaün wrote: > When a test process is not able to write to TH_LOG_STREAM, this step > mechanism enable to print the assert number which triggered the failure. > This can be enabled by setting _metadata->no_print to true at the > beginning of the test sequence. > >

Re: [PATCH v1] selftests: Enhance kselftest_harness.h to print which assert failed

On 08/06/2017 05:23 PM, Mickaël Salaün wrote: > When a test process is not able to write to TH_LOG_STREAM, this step > mechanism enable to print the assert number which triggered the failure. > This can be enabled by setting _metadata->no_print to true at the > beginning of the test sequence. > >

Re: [PATCH v2] input/xen-kbdfront: Enable auto repeat for xen keyboard frontend driver

On Thu, Aug 24, 2017 at 09:54:14AM -0400, Liang Yan wrote: > Long pressed key could not show right in XEN vncviewer after tigervnc > client changed the way how to send repeat keys, from "Down Up Down Up > ..." to "Down Down ... Up". This will report autorepeat to input by > checking if same key

Re: [PATCH v2] input/xen-kbdfront: Enable auto repeat for xen keyboard frontend driver

On Thu, Aug 24, 2017 at 09:54:14AM -0400, Liang Yan wrote: > Long pressed key could not show right in XEN vncviewer after tigervnc > client changed the way how to send repeat keys, from "Down Up Down Up > ..." to "Down Down ... Up". This will report autorepeat to input by > checking if same key

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > > * Most SCSI drivers exist under drivers/scsi, including the virtio-scsi and > > xen-scsifront drivers. So why has the visorhba driver been added under > >

Re: linux-next: manual merge of the scsi tree with the staging tree

On Mon, 2017-08-28 at 18:05 +0200, g...@kroah.com wrote: > On Mon, Aug 28, 2017 at 03:41:28PM +, Bart Van Assche wrote: > > * Most SCSI drivers exist under drivers/scsi, including the virtio-scsi and > > xen-scsifront drivers. So why has the visorhba driver been added under > >

[PATCH v2] USB: xhci: reducing HS port auto-resume latency.

From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a HS port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for

[PATCH v2] USB: xhci: reducing HS port auto-resume latency.

From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a HS port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined

Re: WARNING: possible circular locking dependency detected

On Mon, Aug 28, 2017 at 05:06:17PM +0200, Peter Zijlstra wrote: > On Mon, Aug 28, 2017 at 04:58:08PM +0200, Peter Zijlstra wrote: > > On Fri, Aug 25, 2017 at 12:03:04PM +0200, Borislav Petkov wrote: > > > Hey, > > > > > > tglx says I have something for ya :-) > > > > > >

Re: WARNING: possible circular locking dependency detected

On Mon, Aug 28, 2017 at 05:06:17PM +0200, Peter Zijlstra wrote: > On Mon, Aug 28, 2017 at 04:58:08PM +0200, Peter Zijlstra wrote: > > On Fri, Aug 25, 2017 at 12:03:04PM +0200, Borislav Petkov wrote: > > > Hey, > > > > > > tglx says I have something for ya :-) > > > > > >

[PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

Add a driver for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. This driver implementes core MFD/serdev device as well as communication

[PATCH v6 0/2] ZII RAVE platform driver

Hi everyone, This patch series is v6 of the driver for supervisory processor found on RAVE series of devices from ZII. Supervisory processor is a PIC microcontroller connected to various electrical subsystems on RAVE devices whose firmware implements protocol to command/qery them. Changes since

[PATCH v6 0/2] ZII RAVE platform driver

Hi everyone, This patch series is v6 of the driver for supervisory processor found on RAVE series of devices from ZII. Supervisory processor is a PIC microcontroller connected to various electrical subsystems on RAVE devices whose firmware implements protocol to command/qery them. Changes since

[PATCH v6 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

Add Device Tree bindings for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. Cc: cphe...@gmail.com Cc: Lucas Stach Cc:

[PATCH v6 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

Add Device Tree bindings for RAVE Supervisory Processor, an MCU implementing varoius bits of housekeeping functionality (watchdoging, backlight control, LED control, etc) on RAVE family of products by Zodiac Inflight Innovations. Cc: cphe...@gmail.com Cc: Lucas Stach Cc: Nikita Yushchenko Cc:

Re: [PATCH V10 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/24/2017 05:07 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [PATCH V10 1/2] powerpc/numa: Update CPU topology when VPHN enabled

On 08/24/2017 05:07 PM, Michael Bringmann wrote: > > powerpc/numa: Correct the currently broken capability to set the > topology for shared CPUs in LPARs. At boot time for shared CPU > lpars, the topology for each shared CPU is set to node zero, however, > this is now updated correctly using the

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, Aug 28, 2017 at 05:27:15PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 28, 2017 at 03:31:16PM +0200, Peter Zijlstra wrote: > > I'm fairly sure that was very intentional. If you want to isolate stuff > > you don't want load-balancing. > > Yes I guess that was intentional. In fact

Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on housekeeping

On Mon, Aug 28, 2017 at 05:27:15PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 28, 2017 at 03:31:16PM +0200, Peter Zijlstra wrote: > > I'm fairly sure that was very intentional. If you want to isolate stuff > > you don't want load-balancing. > > Yes I guess that was intentional. In fact

Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface support

On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote: >On Mon, 31 Jul 2017 12:03:46 -0400 >William Breathitt Gray wrote: > >> This patch adds support for the IIO generic counter interface to the >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface

Re: [PATCH 3/3] iio: 104-quad-8: Add IIO generic counter interface support

On Sun, Aug 20, 2017 at 01:11:18PM +0100, Jonathan Cameron wrote: >On Mon, 31 Jul 2017 12:03:46 -0400 >William Breathitt Gray wrote: > >> This patch adds support for the IIO generic counter interface to the >> 104-QUAD-8 driver. The existing 104-QUAD-8 device interface should not >> be affected

Re: [PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Mon, Aug 28, 2017 at 8:51 AM, Greg Kroah-Hartman wrote: > On Fri, Jul 28, 2017 at 07:27:04AM -0700, Andrey Smirnov wrote: >> Cc: cphe...@gmail.com >> Cc: Lucas Stach >> Cc: Nikita Yushchenko >> Cc: Rob

Re: [PATCH v5 2/2] dt-bindings: mfd: Add bindings for ZII RAVE devices

On Mon, Aug 28, 2017 at 8:51 AM, Greg Kroah-Hartman wrote: > On Fri, Jul 28, 2017 at 07:27:04AM -0700, Andrey Smirnov wrote: >> Cc: cphe...@gmail.com >> Cc: Lucas Stach >> Cc: Nikita Yushchenko >> Cc: Rob Herring >> Cc: Mark Rutland >> Cc: devicet...@vger.kernel.org >> Cc:

Re: [PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

On Thu, Aug 24, 2017 at 9:04 AM, Pavel Machek wrote: > On Fri 2017-07-28 07:27:03, Andrey Smirnov wrote: >> Add a driver for RAVE Supervisory Processor, an MCU implementing >> varoius bits of housekeeping functionality (watchdoging, backlight >> control, LED control, etc) on RAVE

Re: [PATCH v5 1/2] platform: Add driver for RAVE Supervisory Processor

On Thu, Aug 24, 2017 at 9:04 AM, Pavel Machek wrote: > On Fri 2017-07-28 07:27:03, Andrey Smirnov wrote: >> Add a driver for RAVE Supervisory Processor, an MCU implementing >> varoius bits of housekeeping functionality (watchdoging, backlight >> control, LED control, etc) on RAVE family of

[PATCH] i40iw: make some structures const

Make some structures const as they are only used during a copy operation. Signed-off-by: Bhumika Goyal --- drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_uk.c

[PATCH] i40iw: make some structures const

Make some structures const as they are only used during a copy operation. Signed-off-by: Bhumika Goyal --- drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_uk.c

Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag

Hi Mike, On Sun, Aug 27, 2017 at 11:10 PM, Mike Galbraith wrote: > On Sun, 2017-08-27 at 22:27 -0700, Joel Fernandes wrote: >> Hi Mike, >> >> On Sun, Aug 27, 2017 at 11:07 AM, Mike Galbraith wrote: >> > On Sat, 2017-08-26 at 23:39 -0700, Joel Fernandes wrote: >> >>

Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag

Hi Mike, On Sun, Aug 27, 2017 at 11:10 PM, Mike Galbraith wrote: > On Sun, 2017-08-27 at 22:27 -0700, Joel Fernandes wrote: >> Hi Mike, >> >> On Sun, Aug 27, 2017 at 11:07 AM, Mike Galbraith wrote: >> > On Sat, 2017-08-26 at 23:39 -0700, Joel Fernandes wrote: >> >> >> >> Also about real world

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, 28 Aug 2017 18:07:37 +0200, Bernhard Held wrote: > > On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: > > On Mon, 28 Aug 2017 17:26:05 +0200, > > Bernhard Held wrote: > >> I get crashes with Win10 in kvm > >> > > Did you get the crash reliably? > > I've been struggling how to trigger it

Re: kvm splat in mmu_spte_clear_track_bits

On Mon, 28 Aug 2017 18:07:37 +0200, Bernhard Held wrote: > > On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: > > On Mon, 28 Aug 2017 17:26:05 +0200, > > Bernhard Held wrote: > >> I get crashes with Win10 in kvm > >> > > Did you get the crash reliably? > > I've been struggling how to trigger it

Re: [PATCH] Documentation: fix little inconsistencies

On Mon, Aug 28, 2017 at 11:46:39AM +0200, Pavel Machek wrote: > Fix little inconsistencies in Documentation: make case and spacing > match surrounding text, fix ascii-art. > > Signed-off-by: Pavel Machek > > diff --git a/Documentation/filesystems/ext4.txt >

Re: [PATCH] Documentation: fix little inconsistencies

On Mon, Aug 28, 2017 at 11:46:39AM +0200, Pavel Machek wrote: > Fix little inconsistencies in Documentation: make case and spacing > match surrounding text, fix ascii-art. > > Signed-off-by: Pavel Machek > > diff --git a/Documentation/filesystems/ext4.txt > b/Documentation/filesystems/ext4.txt

Re: [PATCH v3 2/3] rtc: Add Realtek RTD1295

Hi, Seems fine to me, one small comment: On 28/08/2017 at 13:10:40 +0200, Andreas Färber wrote: > +static int rtd119x_rtc_remove(struct platform_device *pdev) > +{ > + struct rtd119x_rtc *data = platform_get_drvdata(pdev); > + > + rtd119x_rtc_set_enabled(>dev, false); > + > +

Re: [PATCH v3 2/3] rtc: Add Realtek RTD1295

Hi, Seems fine to me, one small comment: On 28/08/2017 at 13:10:40 +0200, Andreas Färber wrote: > +static int rtd119x_rtc_remove(struct platform_device *pdev) > +{ > + struct rtd119x_rtc *data = platform_get_drvdata(pdev); > + > + rtd119x_rtc_set_enabled(>dev, false); > + > +

Re: [PATCH v2 04/14] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

Hi, On 17-08-17 23:41, Rob Herring wrote: On Tue, Aug 15, 2017 at 10:04:52PM +0200, Hans de Goede wrote: This is board specific info so it should come from board config, such as devicetree. I've chosen to prefix these with "fcs," treating them as fusb302 driver specific for now. We may want

Re: [PATCH v2 04/14] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

Hi, On 17-08-17 23:41, Rob Herring wrote: On Tue, Aug 15, 2017 at 10:04:52PM +0200, Hans de Goede wrote: This is board specific info so it should come from board config, such as devicetree. I've chosen to prefix these with "fcs," treating them as fusb302 driver specific for now. We may want

Re: kvm splat in mmu_spte_clear_track_bits

On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: I get crashes with Win10 in kvm Did you get the crash reliably? I've been struggling how to trigger it efficiently, but currently in vain. The memory pressure isn't a single key to trigger

Re: kvm splat in mmu_spte_clear_track_bits

On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: I get crashes with Win10 in kvm Did you get the crash reliably? I've been struggling how to trigger it efficiently, but currently in vain. The memory pressure isn't a single key to trigger

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

On Tue, Aug 15, 2017 at 04:51:02PM +0930, Andrew Jeffery wrote: > In addition to the base, low and high clock configuration, the AC timing > register #1 on the AST2400 houses fields controlling: > > 1. tBUF: Minimum delay between Stop and Start conditions > 2. tHDSTA: Hold time for the Start

Re: [PATCH] i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency

On Tue, Aug 15, 2017 at 04:51:02PM +0930, Andrew Jeffery wrote: > In addition to the base, low and high clock configuration, the AC timing > register #1 on the AST2400 houses fields controlling: > > 1. tBUF: Minimum delay between Stop and Start conditions > 2. tHDSTA: Hold time for the Start

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, Aug 28, 2017 at 03:56:44PM +, Haiyang Zhang wrote: > > > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Monday, August 28, 2017 11:16 AM > > To: Eduardo Otubo > > Cc: linux-kernel@vger.kernel.org;

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, Aug 28, 2017 at 03:56:44PM +, Haiyang Zhang wrote: > > > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Monday, August 28, 2017 11:16 AM > > To: Eduardo Otubo > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;

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