Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi Nikolaus, On Tue, Jun 27, 2017 at 07:46:51AM +0200, H. Nikolaus Schaller wrote: > Hi, > > > Am 26.06.2017 um 22:12 schrieb Sakari Ailus : > > > > Hi Nikolaus, > > > > On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: > >> If a camera module driver

Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi Nikolaus, On Tue, Jun 27, 2017 at 07:46:51AM +0200, H. Nikolaus Schaller wrote: > Hi, > > > Am 26.06.2017 um 22:12 schrieb Sakari Ailus : > > > > Hi Nikolaus, > > > > On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: > >> If a camera module driver specifies a format that

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

Hi, Julia Thanks for your kindly hit. I will try this patch The problem is accidental. I will try to reproduce it. BTW, could you help to give the link about the emails which discuss about " nsfs: mark dentry with DCACHE_RCUACCESS ". I cannot find them(just patch email)

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

Hi, Julia Thanks for your kindly hit. I will try this patch The problem is accidental. I will try to reproduce it. BTW, could you help to give the link about the emails which discuss about " nsfs: mark dentry with DCACHE_RCUACCESS ". I cannot find them(just patch email)

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

On 23 June 2017 at 12:40, Linus Torvalds wrote: > On Thu, Jun 22, 2017 at 4:56 PM, Rafael J. Wysocki wrote: >> >> Some recent Dell laptops, including the XPS13 model numbers 9360 and >> 9365, cannot be woken up from suspend-to-idle by pressing

Re: [PATCH] ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems

On 23 June 2017 at 12:40, Linus Torvalds wrote: > On Thu, Jun 22, 2017 at 4:56 PM, Rafael J. Wysocki wrote: >> >> Some recent Dell laptops, including the XPS13 model numbers 9360 and >> 9365, cannot be woken up from suspend-to-idle by pressing the power >> button which is unexpected and makes

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

> Am 26.06.2017 um 13:16 schrieb Pavel Machek : > > Hi! > >>> You may want to try this one: >>> >>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef >>> Author: Pavel >>> Date: Mon Feb 13 21:26:51 2017 +0100 >>> >>> omap3isp: fix VP2SDR bit so capture (not

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

> Am 26.06.2017 um 13:16 schrieb Pavel Machek : > > Hi! > >>> You may want to try this one: >>> >>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef >>> Author: Pavel >>> Date: Mon Feb 13 21:26:51 2017 +0100 >>> >>> omap3isp: fix VP2SDR bit so capture (not preview) works >>> >>> This

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : > > On 06/26/2017 12:35 PM, Hugues FRUCHET wrote: >>> What I am missing to support the GTA04 camera is the control of the >>> optional "vana-supply". >>> So the driver does not power up the camera module when needed and

Re: [PATCH v1 1/6] DT bindings: add bindings for ov965x camera module

> Am 26.06.2017 um 22:04 schrieb Sylwester Nawrocki : > > On 06/26/2017 12:35 PM, Hugues FRUCHET wrote: >>> What I am missing to support the GTA04 camera is the control of the >>> optional "vana-supply". >>> So the driver does not power up the camera module when needed and therefore >>>

Re: [PATCH] arm: dts: omap3: Remove interrupt-parent property

On Tuesday 27 June 2017 11:03 AM, kart...@techveda.org wrote: > From: Karthik Tummala > Please change the subject of the patch to something which is more meaningful and which reflect the changes done to the code base. > All nodes inhert "interrupt-parent" property from

Re: [PATCH] arm: dts: omap3: Remove interrupt-parent property

On Tuesday 27 June 2017 11:03 AM, kart...@techveda.org wrote: > From: Karthik Tummala > Please change the subject of the patch to something which is more meaningful and which reflect the changes done to the code base. > All nodes inhert "interrupt-parent" property from root > node. So removed

Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi, > Am 26.06.2017 um 22:12 schrieb Sakari Ailus : > > Hi Nikolaus, > > On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: >> If a camera module driver specifies a format that is not >> supported by omap3isp this ends in a NULL pointer >> dereference

Re: [PATCH] media: omap3isp: handle NULL return of omap3isp_video_format_info() in ccdc_is_shiftable().

Hi, > Am 26.06.2017 um 22:12 schrieb Sakari Ailus : > > Hi Nikolaus, > > On Mon, Jun 26, 2017 at 07:54:19PM +0200, H. Nikolaus Schaller wrote: >> If a camera module driver specifies a format that is not >> supported by omap3isp this ends in a NULL pointer >> dereference instead of a simple

[PATCH] drm/i915: Fix an error checking test

'dma_buf_vmap' returns NULL on error, not an error pointer. Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop") Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 6 +++--- 1 file changed, 3 insertions(+),

[PATCH] drm/i915: Fix an error checking test

'dma_buf_vmap' returns NULL on error, not an error pointer. Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop") Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCH 4/4] sched,fair: remove effective_load

On Mon, Jun 26, 2017 at 03:34:49PM -0400, Rik van Riel wrote: > On Mon, 2017-06-26 at 18:12 +0200, Peter Zijlstra wrote: > > On Mon, Jun 26, 2017 at 11:20:54AM -0400, Rik van Riel wrote: > > > > > Oh, indeed.  I guess in wake_affine() we should test > > > whether the CPUs are in the same NUMA

Re: [PATCH 4/4] sched,fair: remove effective_load

On Mon, Jun 26, 2017 at 03:34:49PM -0400, Rik van Riel wrote: > On Mon, 2017-06-26 at 18:12 +0200, Peter Zijlstra wrote: > > On Mon, Jun 26, 2017 at 11:20:54AM -0400, Rik van Riel wrote: > > > > > Oh, indeed.  I guess in wake_affine() we should test > > > whether the CPUs are in the same NUMA

Re: [PATCH 4/4] remoteproc/davinci: streamline the interrupt management

On Mon 26 Jun 09:09 PDT 2017, Suman Anna wrote: > Hi Bjorn, > > On 06/25/2017 04:19 PM, Bjorn Andersson wrote: > > On Thu 18 May 15:09 PDT 2017, Suman Anna wrote: > > > >> The davinci remoteproc driver is currently requesting its interrupt > >> that deals with the virtio kicks in probe, and

Re: [PATCH 4/4] remoteproc/davinci: streamline the interrupt management

On Mon 26 Jun 09:09 PDT 2017, Suman Anna wrote: > Hi Bjorn, > > On 06/25/2017 04:19 PM, Bjorn Andersson wrote: > > On Thu 18 May 15:09 PDT 2017, Suman Anna wrote: > > > >> The davinci remoteproc driver is currently requesting its interrupt > >> that deals with the virtio kicks in probe, and

Re: [PATCH v1 2/6] [media] ov9650: add device tree support

On Mon, Jun 26, 2017 at 07:46:34PM +0200, H. Nikolaus Schaller wrote: > Hi, > > > Am 26.06.2017 um 18:31 schrieb Sakari Ailus : > > > > Hi Hugues, > > > > On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote: > >> @@ -1545,15 +1577,22 @@ static int

Re: [PATCH v1 2/6] [media] ov9650: add device tree support

On Mon, Jun 26, 2017 at 07:46:34PM +0200, H. Nikolaus Schaller wrote: > Hi, > > > Am 26.06.2017 um 18:31 schrieb Sakari Ailus : > > > > Hi Hugues, > > > > On Thu, Jun 22, 2017 at 05:05:38PM +0200, Hugues Fruchet wrote: > >> @@ -1545,15 +1577,22 @@ static int ov965x_remove(struct i2c_client

[PATCH] arm: dts: omap3: Remove interrupt-parent property

From: Karthik Tummala All nodes inhert "interrupt-parent" property from root node. So removed that property from usbhsohci, usbhsehci, ssi_port1, ssi_port2 nodes. Signed-off-by: Karthik Tummala --- arch/arm/boot/dts/omap3.dtsi | 4 1 file

[PATCH] arm: dts: omap3: Remove interrupt-parent property

From: Karthik Tummala All nodes inhert "interrupt-parent" property from root node. So removed that property from usbhsohci, usbhsehci, ssi_port1, ssi_port2 nodes. Signed-off-by: Karthik Tummala --- arch/arm/boot/dts/omap3.dtsi | 4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

Adam, I’ve applied the same patch in my tree. I’ll send out the update [1] once it's reviewed, since I also reduced the stack usage of functions using over 1 KB of stack space. You’re right that div_u64() will work, since the FSE functions are only called on blocks of at most 128 KB at a time.

Re: [PATCH] lib/zstd: use div_u64() to let it build on 32-bit

Adam, I’ve applied the same patch in my tree. I’ll send out the update [1] once it's reviewed, since I also reduced the stack usage of functions using over 1 KB of stack space. You’re right that div_u64() will work, since the FSE functions are only called on blocks of at most 128 KB at a time.

Re: [PATCH] mm/memory_hotplug: remove an unused variable in move_pfn_range_to_zone()

On Tue 27-06-17 10:26:38, Anshuman Khandual wrote: > On 06/27/2017 04:49 AM, Wei Yang wrote: > > There is an unused variable in move_pfn_range_to_zone(). > > > > This patch just removes it. > > > > Signed-off-by: Wei Yang > > --- > > mm/memory_hotplug.c | 1 - > > 1

Re: [PATCH] mm/memory_hotplug: remove an unused variable in move_pfn_range_to_zone()

On Tue 27-06-17 10:26:38, Anshuman Khandual wrote: > On 06/27/2017 04:49 AM, Wei Yang wrote: > > There is an unused variable in move_pfn_range_to_zone(). > > > > This patch just removes it. > > > > Signed-off-by: Wei Yang > > --- > > mm/memory_hotplug.c | 1 - > > 1 file changed, 1 deletion(-)

[PATCH 2/3] dts: RISC-V local interrupt controller docs

This patch adds documentation on the RISC-V local interrupt controller, which is a per-hart interrupt controller that manages all interrupts entering a RISC-V hart. This interrupt controller is present on all RISC-V systems. Signed-off-by: Palmer Dabbelt ---

[PATCH 3/3] dts: RISC-V PLIC documentation

This patch adds documentation for the platform-level interrupt controller (PLIC) found in all RISC-V systems. This interrupt controller routes interrupts from all the devices in the system to each hart-local interrupt controller. Note: the DTS bindings for the PLIC aren't set in stone yet, as we

[PATCH 1/3] dts: RISC-V vendor prefix

RISC-V systems use device tree to specify the memory layout of the system. This patch reserves the "riscv" vendor prefix, which will be used for devices that are specified by the various RISC-V ISA specifications. Signed-off-by: Palmer Dabbelt ---

[PATCH 2/3] dts: RISC-V local interrupt controller docs

This patch adds documentation on the RISC-V local interrupt controller, which is a per-hart interrupt controller that manages all interrupts entering a RISC-V hart. This interrupt controller is present on all RISC-V systems. Signed-off-by: Palmer Dabbelt ---

[PATCH 3/3] dts: RISC-V PLIC documentation

This patch adds documentation for the platform-level interrupt controller (PLIC) found in all RISC-V systems. This interrupt controller routes interrupts from all the devices in the system to each hart-local interrupt controller. Note: the DTS bindings for the PLIC aren't set in stone yet, as we

[PATCH 1/3] dts: RISC-V vendor prefix

RISC-V systems use device tree to specify the memory layout of the system. This patch reserves the "riscv" vendor prefix, which will be used for devices that are specified by the various RISC-V ISA specifications. Signed-off-by: Palmer Dabbelt ---

RISC-V Device Tree Documentation

As part of submitting the RISC-V Linux port it was suggested that we write some documentation that describes our device tree bindings. Our port is still in progress, but it was suggested that we start sending patches to the relevant parties. There is one outstanding issue to resolve with the

RISC-V Device Tree Documentation

As part of submitting the RISC-V Linux port it was suggested that we write some documentation that describes our device tree bindings. Our port is still in progress, but it was suggested that we start sending patches to the relevant parties. There is one outstanding issue to resolve with the

[PATCH v4] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/usb/host/ohci-pxa27x.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ohci-pxa27x.c

[PATCH v4] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/usb/host/ohci-pxa27x.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c index

[PATCH] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- Changes in v3: Change log correction. Add change log below '---'. Changes in v2: Remove useless initialization of retval.

[PATCH] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

clk_prepare_enable() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- Changes in v3: Change log correction. Add change log below '---'. Changes in v2: Remove useless initialization of retval. drivers/usb/host/ohci-pxa27x.c | 10

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Rob/Florian, Thanks for input but still don't see any need for SoC specific compatible stings. IP revision specific yes. On 17-06-22 06:04 PM, Florian Fainelli wrote: On 06/22/2017 05:42 PM, Scott Branden wrote: On 17-06-21 08:19 PM, Rob Herring wrote: On Tue, Jun 20, 2017 at 3:48 PM,

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Hi Rob/Florian, Thanks for input but still don't see any need for SoC specific compatible stings. IP revision specific yes. On 17-06-22 06:04 PM, Florian Fainelli wrote: On 06/22/2017 05:42 PM, Scott Branden wrote: On 17-06-21 08:19 PM, Rob Herring wrote: On Tue, Jun 20, 2017 at 3:48 PM,

Re: [PATCH 3/3] Make LSM Writable Hooks a command line option

Hi Igor, [auto build test ERROR on mmotm/master] [cannot apply to linus/master linux/master v4.12-rc7 next-20170626] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Igor-Stoppa/ro-protection

Re: [PATCH 3/3] Make LSM Writable Hooks a command line option

Hi Igor, [auto build test ERROR on mmotm/master] [cannot apply to linus/master linux/master v4.12-rc7 next-20170626] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Igor-Stoppa/ro-protection

[PATCH 1/2] irqchip: RISC-V Local Interrupt Controller Driver

This patch adds a driver that manages the local interrupts on each RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual. The local interrupt controller manages software interrupts, timer interrupts, and hardware interrupts (which are routed via the platform level interrupt

[PATCH 1/2] irqchip: RISC-V Local Interrupt Controller Driver

This patch adds a driver that manages the local interrupts on each RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual. The local interrupt controller manages software interrupts, timer interrupts, and hardware interrupts (which are routed via the platform level interrupt

[PATCH 2/2] irqchip: New RISC-V PLIC Driver

This patch adds a driver for the Platform Level Interrupt Controller (PLIC) specified as part of the RISC-V supervisor level ISA manual. The PLIC connocts global interrupt sources to the local interrupt controller on each hart. A PLIC is present on all RISC-V systems. Signed-off-by: Palmer

[PATCH 2/2] irqchip: New RISC-V PLIC Driver

This patch adds a driver for the Platform Level Interrupt Controller (PLIC) specified as part of the RISC-V supervisor level ISA manual. The PLIC connocts global interrupt sources to the local interrupt controller on each hart. A PLIC is present on all RISC-V systems. Signed-off-by: Palmer

RISC-V Interrupt Controllers

This patch set contains two interrupt controller drivers for RISC-V systems: the local interrupt controller is a per-hart controller, and the PLIC is a per-chip controller.

RISC-V Interrupt Controllers

This patch set contains two interrupt controller drivers for RISC-V systems: the local interrupt controller is a per-hart controller, and the PLIC is a per-chip controller.

Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

The series aims at isolating data conversions of time_t based structures: struct timespec and struct itimerspec at user space boundaries. This helps to later change the underlying types to handle y2038 changes to these. >>> >>> Nice... A few questions: >>> >>> * what about

Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

The series aims at isolating data conversions of time_t based structures: struct timespec and struct itimerspec at user space boundaries. This helps to later change the underlying types to handle y2038 changes to these. >>> >>> Nice... A few questions: >>> >>> * what about

Re: [PATCH] mm/memory_hotplug: remove an unused variable in move_pfn_range_to_zone()

On 06/27/2017 04:49 AM, Wei Yang wrote: > There is an unused variable in move_pfn_range_to_zone(). > > This patch just removes it. > > Signed-off-by: Wei Yang > --- > mm/memory_hotplug.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/mm/memory_hotplug.c

Re: [PATCH] mm/memory_hotplug: remove an unused variable in move_pfn_range_to_zone()

On 06/27/2017 04:49 AM, Wei Yang wrote: > There is an unused variable in move_pfn_range_to_zone(). > > This patch just removes it. > > Signed-off-by: Wei Yang > --- > mm/memory_hotplug.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index

[PATCH] tty: New RISC-V SBI console driver

The RISC-V ISA defines a simple console that is availiable via SBI calls on all systems. This patch adds a driver for this console interface that can act as both a target for early printk and as the system console. Signed-off-by: Palmer Dabbelt --- drivers/tty/hvc/Kconfig

[PATCH] tty: New RISC-V SBI console driver

The RISC-V ISA defines a simple console that is availiable via SBI calls on all systems. This patch adds a driver for this console interface that can act as both a target for early printk and as the system console. Signed-off-by: Palmer Dabbelt --- drivers/tty/hvc/Kconfig | 11 +

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

Hi, Sebastian I just add the RT patches, nothing else. Thanks Feng >-Original Message- >From: Sebastian Andrzej Siewior [mailto:sebastian.siew...@linutronix.de] >Sent: Monday, June 26, 2017 10:55 PM >To: Steven Rostedt >Cc: Feng Feng24 Liu; Mike Galbraith;

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

Hi, Sebastian I just add the RT patches, nothing else. Thanks Feng >-Original Message- >From: Sebastian Andrzej Siewior [mailto:sebastian.siew...@linutronix.de] >Sent: Monday, June 26, 2017 10:55 PM >To: Steven Rostedt >Cc: Feng Feng24 Liu; Mike Galbraith;

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

HI steve I have installed the openstack on the server, and create & destroy some virtual machines. Then I left it to run for about 2 days without do nothing. The problem happened I don't know what proc file it read by now, since when I found the problem on Monday, the

RE: BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 !//RE: kernel BUG at kernel/locking/rtmutex.c:1027

HI steve I have installed the openstack on the server, and create & destroy some virtual machines. Then I left it to run for about 2 days without do nothing. The problem happened I don't know what proc file it read by now, since when I found the problem on Monday, the

linux-next: build warning after merge of the rpmsg tree

Hi Bjorn, After merging the rpmsg tree, today's linux-next build (arm_multi_v7_defconfig) produced this warning: drivers/i2c/Kconfig:7:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations"

linux-next: build warning after merge of the rpmsg tree

Hi Bjorn, After merging the rpmsg tree, today's linux-next build (arm_multi_v7_defconfig) produced this warning: drivers/i2c/Kconfig:7:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations"

Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface

On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote: > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL > command buffer and OCC response buffer that can be used to send > inband commands to OCC. This patch

Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface

On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote: > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL > command buffer and OCC response buffer that can be used to send > inband commands to OCC. This patch

linux-next: manual merge of the scsi tree with the jc_docs tree

Hi all, Today's linux-next merge of the scsi tree got a conflict in: drivers/scsi/scsi_transport_fc.c between commit: 739aca06a2d2 ("scsi: fix some kernel-doc markups") from the jc_docs tree and commit: 134699d2a896 ("scsi: fix typos and grammar in comments of scsi_transport_fc.c")

linux-next: manual merge of the scsi tree with the jc_docs tree

Hi all, Today's linux-next merge of the scsi tree got a conflict in: drivers/scsi/scsi_transport_fc.c between commit: 739aca06a2d2 ("scsi: fix some kernel-doc markups") from the jc_docs tree and commit: 134699d2a896 ("scsi: fix typos and grammar in comments of scsi_transport_fc.c")

stdout-path (was Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board)

On 06/26/2017 07:25 PM, Alexey Brodkin wrote: + + chosen { + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1"; Use stdout-path for the console. Really, the bootargs should be blank and populated by the bootloader

stdout-path (was Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board)

On 06/26/2017 07:25 PM, Alexey Brodkin wrote: + + chosen { + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8 console=ttyS0,115200n8 debug print-fatal-signals=1"; Use stdout-path for the console. Really, the bootargs should be blank and populated by the bootloader

Re: [PATCH 0/6] sched: Minor fixes and cleanups

On 24-05-17, 10:59, Viresh Kumar wrote: > Hi, > > The first patch fixes a potential regression we may observe on the UP > systems and the others are doing minor optimizations in the scheduler > core. > > They are all tested on ARM 32 (exynos) and 64 (hikey) bit platforms. Hi Ingo/Peter, Do you

Re: [PATCH 0/6] sched: Minor fixes and cleanups

On 24-05-17, 10:59, Viresh Kumar wrote: > Hi, > > The first patch fixes a potential regression we may observe on the UP > systems and the others are doing minor optimizations in the scheduler > core. > > They are all tested on ARM 32 (exynos) and 64 (hikey) bit platforms. Hi Ingo/Peter, Do you

Re: [PATCH v2] nvme: explicitly disable APST on quirked devices

On Tue, Jun 27, 2017 at 2:05 AM, Andy Lutomirski wrote: > On Mon, Jun 26, 2017 at 12:01 AM, Kai-Heng Feng > wrote: >> A user reports APST is enabled, even when the NVMe is quirked or with >> option "default_ps_max_latency_us=0". >> >> The current

Re: [PATCH v2] nvme: explicitly disable APST on quirked devices

On Tue, Jun 27, 2017 at 2:05 AM, Andy Lutomirski wrote: > On Mon, Jun 26, 2017 at 12:01 AM, Kai-Heng Feng > wrote: >> A user reports APST is enabled, even when the NVMe is quirked or with >> option "default_ps_max_latency_us=0". >> >> The current logic will not set APST if the device is quirked.

[PATCH] lib/zstd: use div_u64() to let it build on 32-bit

David Sterba wrote: > > Thus, you want do_div() instead of /; do check widths and signedness of > > arguments. > > No do_div please, div_u64 or div64_u64. Good to know, the interface of do_div() is indeed weird. I guess Nick has found and fixed the offending divisions in his tree already, but

[PATCH] lib/zstd: use div_u64() to let it build on 32-bit

David Sterba wrote: > > Thus, you want do_div() instead of /; do check widths and signedness of > > arguments. > > No do_div please, div_u64 or div64_u64. Good to know, the interface of do_div() is indeed weird. I guess Nick has found and fixed the offending divisions in his tree already, but

Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns

On 27-06-17, 02:15, Rafael J. Wysocki wrote: > On Monday, May 22, 2017 04:57:27 PM Viresh Kumar wrote: > > On 22-05-17, 19:17, Leo Yan wrote: > > > This afternoon Amit pointed me for this patch, should fix as below? > > > Otherwise it seems directly assign the same value from unit 'ns' to > > >

Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns

On 27-06-17, 02:15, Rafael J. Wysocki wrote: > On Monday, May 22, 2017 04:57:27 PM Viresh Kumar wrote: > > On 22-05-17, 19:17, Leo Yan wrote: > > > This afternoon Amit pointed me for this patch, should fix as below? > > > Otherwise it seems directly assign the same value from unit 'ns' to > > >

Re: [block] 044f1daaaa kernel BUG at block/blk-mq.c:415!

On 06/26/2017 09:53 PM, Fengguang Wu wrote: > Greetings, > > Sorry the report is a bit late, this bug looks still active: > First I've heard about it! > [ 36.037364] sector 2, nr/cnr 0/2 > [ 36.037367] bio 88001af84e80, biotail 88001af84e80, len 0 > [ 36.037367] bio

Re: [block] 044f1daaaa kernel BUG at block/blk-mq.c:415!

On 06/26/2017 09:53 PM, Fengguang Wu wrote: > Greetings, > > Sorry the report is a bit late, this bug looks still active: > First I've heard about it! > [ 36.037364] sector 2, nr/cnr 0/2 > [ 36.037367] bio 88001af84e80, biotail 88001af84e80, len 0 > [ 36.037367] bio

[PATCH blktests v2] loop/002: Regression testing for loop device flush

Add a regression testing for loop device. when an unbound device be close that take too long time. kernel will consume serveral orders of magnitude more wall time than it does for a mounted device. Signed-off-by: James Wang --- tests/loop/002 | 63

[PATCH blktests v2] loop/002: Regression testing for loop device flush

Add a regression testing for loop device. when an unbound device be close that take too long time. kernel will consume serveral orders of magnitude more wall time than it does for a mounted device. Signed-off-by: James Wang --- tests/loop/002 | 63

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Tue, 2017-06-27 at 11:42 +0930, Andrew Jeffery wrote: > The AST2400 contains several USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller There's also a USB1.1 HID-only device-controller, but it's a legacy piece

Re: [PATCH 1/4] ARM: aspeed: g4: Add USB functions to pinctrl bindings

On Tue, 2017-06-27 at 11:42 +0930, Andrew Jeffery wrote: > The AST2400 contains several USB controllers: > > * USB 1.1 Host Controller > * USB 2.0 Host Controller > * Combined USB 2.0 Virtual Hub and USB 1.1 HID Controller There's also a USB1.1 HID-only device-controller, but it's a legacy piece

[PATCH] kref: Avoid null pointer dereference after WARN

From: Daniel Micay The WARN_ON() checking for a NULL release pointer should be a BUG() since continuing with a NULL release pointer will lead to a NULL pointer dereference anyway. The kref_put() case is extracted from PaX, and Kees Cook noted it should be extended to the

[PATCH] kref: Avoid null pointer dereference after WARN

From: Daniel Micay The WARN_ON() checking for a NULL release pointer should be a BUG() since continuing with a NULL release pointer will lead to a NULL pointer dereference anyway. The kref_put() case is extracted from PaX, and Kees Cook noted it should be extended to the other two cases.

Re: [PATCH 1/3] Protectable memory support

Hi Igor, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.12-rc7 next-20170626] [cannot apply to linus/master linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH 1/3] Protectable memory support

Hi Igor, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.12-rc7 next-20170626] [cannot apply to linus/master linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] netfilter: ip_tables: remove useless variable assignment in get_info()

Hi Joe, Quoting Joe Perches : On Mon, 2017-06-26 at 17:34 -0500, Gustavo A. R. Silva wrote: Value assigned to variable _ret_ at line 970 is overwritten either at line 986 or 988, before it can be used. This makes such variable assignment useless. Addresses-Coverity-ID:

Re: [PATCH] netfilter: ip_tables: remove useless variable assignment in get_info()

Hi Joe, Quoting Joe Perches : On Mon, 2017-06-26 at 17:34 -0500, Gustavo A. R. Silva wrote: Value assigned to variable _ret_ at line 970 is overwritten either at line 986 or 988, before it can be used. This makes such variable assignment useless. Addresses-Coverity-ID: 1226932 [] diff

c88d71508e ("x86/boot/64: Rewrite startup_64() in C"): BUG: kernel reboot-without-warning in boot stage

05:12 G 47 00 2 x86/boot/compressed: Enable 5-level paging during decompression stage # extra tests on HEAD of linux-review/jglisse-redhat-com/x86-mm-hotplug-fix-BUG_ON-after-hotremove-by-not-freeing-pud-v3/20170626-012348 git bisect bad 5bf715cc5f1a53ee61f1ac08eec750dc190bec79

c88d71508e ("x86/boot/64: Rewrite startup_64() in C"): BUG: kernel reboot-without-warning in boot stage

-redhat-com/x86-mm-hotplug-fix-BUG_ON-after-hotremove-by-not-freeing-pud-v3/20170626-012348 git bisect bad 5bf715cc5f1a53ee61f1ac08eec750dc190bec79 # 05:12 B 0 25 51 0 x86/mm/hotplug: fix BUG_ON() after hotremove by not freeing pud v3 # extra tests on tree/branch tip/x86/mm git bisect

Re: linux-next: build failure after merge of the kspp tree

On Mon, 26 Jun 2017, Kees Cook wrote: > >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels") > >> Signed-off-by: Stephen Rothwell > > Acked-by: John Johansen > > Hi James, > > Just a ping; this needs to get into

Re: linux-next: build failure after merge of the kspp tree

On Mon, 26 Jun 2017, Kees Cook wrote: > >> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels") > >> Signed-off-by: Stephen Rothwell > > Acked-by: John Johansen > > Hi James, > > Just a ping; this needs to get into -next to avoid build errors. Surely Linus will resolve

Re: [GIT PULL] seccomp updates for next

On Mon, 26 Jun 2017, Kees Cook wrote: > Hi James, > > Please pull these seccomp changes for next. These are all tiny changes, > but I got delayed sending them to you. I'd like have these land for v4.13; > I should have sent them for v4.12. :P Pulled to -next, thanks. -- James Morris

Re: [GIT PULL] seccomp updates for next

On Mon, 26 Jun 2017, Kees Cook wrote: > Hi James, > > Please pull these seccomp changes for next. These are all tiny changes, > but I got delayed sending them to you. I'd like have these land for v4.13; > I should have sent them for v4.12. :P Pulled to -next, thanks. -- James Morris

Re: [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback

Hi, Andrew On 2017/6/26 21:42, Andrew Lunn wrote: > On Mon, Jun 26, 2017 at 10:10:39AM +0800, Lin Yun Sheng wrote: >> Use function set_loopback in phy_driver to setup phy loopback >> when doing ethtool self test. >> >> Signed-off-by: Lin Yun Sheng >> --- >>

Re: [PATCH NET V5 2/2] net: hns: Use phy_driver to setup Phy loopback

Hi, Andrew On 2017/6/26 21:42, Andrew Lunn wrote: > On Mon, Jun 26, 2017 at 10:10:39AM +0800, Lin Yun Sheng wrote: >> Use function set_loopback in phy_driver to setup phy loopback >> when doing ethtool self test. >> >> Signed-off-by: Lin Yun Sheng >> --- >>

Re: [PATCH V4] tools/testing/selftests/sysctl: Add pre-check to the value of writes_strict

On Mon, Jun 26, 2017 at 5:52 PM, Orson Zhai wrote: > Sysctl test will fail in some items if the value of /proc/sys/kernel > /sysctrl_writes_strict is 0 as the default value in kernel older than v4.5. > > Make this test more robus and compatible with older kernel by checking

Re: [PATCH V4] tools/testing/selftests/sysctl: Add pre-check to the value of writes_strict

On Mon, Jun 26, 2017 at 5:52 PM, Orson Zhai wrote: > Sysctl test will fail in some items if the value of /proc/sys/kernel > /sysctrl_writes_strict is 0 as the default value in kernel older than v4.5. > > Make this test more robus and compatible with older kernel by checking and > update

Re: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

On Mon, Jun 26, 2017 at 11:42:05AM -0700, Moritz Fischer wrote: > Hi Xiao / Wu, > > general question, can't you make the /* */ comments > for the structs kernel-doc ([1]) markup instead (see below)? Hi Moritz, Thanks for your review. Sure, will fix this issue for all patches. Hao > > > On

Re: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

On Mon, Jun 26, 2017 at 11:42:05AM -0700, Moritz Fischer wrote: > Hi Xiao / Wu, > > general question, can't you make the /* */ comments > for the structs kernel-doc ([1]) markup instead (see below)? Hi Moritz, Thanks for your review. Sure, will fix this issue for all patches. Hao > > > On

  1   2   3   4   5   6   7   8   9   10   >