Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley wrote: > On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: >> Hi Sergey, Xiong, >> >> Can you try below patch? >> >> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> > Hello, >> > >> >

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley wrote: > On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: >> Hi Sergey, Xiong, >> >> Can you try below patch? >> >> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> > Hello, >> > >> > commit

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 21:44, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: >> On 13/04/16 20:52, Luis R. Rodriguez wrote: >>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On 14/04/16 21:44, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 10:53:47AM +0100, George Dunlap wrote: >> On 13/04/16 20:52, Luis R. Rodriguez wrote: >>> On Wed, Apr 13, 2016 at 04:44:54PM +0100, George Dunlap wrote: On Thu, Apr 7, 2016 at 7:51 PM, Luis R. Rodriguez wrote: > So

Re: [PATCH] fujitsu-laptop: Support radio LED

On Fri, Apr 15, 2016 at 03:03:33PM +0930, Jonathan Woithe wrote: > On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote: > > > Signed-off-by: Michał Kępień > > > > Jonathan, please check your character set, a few mangled characters here > > which I have to fix up to

Re: [PATCH] fujitsu-laptop: Support radio LED

On Fri, Apr 15, 2016 at 03:03:33PM +0930, Jonathan Woithe wrote: > On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote: > > > Signed-off-by: Michał Kępień > > > > Jonathan, please check your character set, a few mangled characters here > > which I have to fix up to use. UTF-8 seems

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

* Denys Vlasenko wrote: > > In fact, the following patch seems to fix it: > > > > diff --git a/include/scsi/scsi_transport_fc.h > > b/include/scsi/scsi_transport_fc.h > > index bf66ea6..56b9e81 100644 > > --- a/include/scsi/scsi_transport_fc.h > > +++

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

* Denys Vlasenko wrote: > > In fact, the following patch seems to fix it: > > > > diff --git a/include/scsi/scsi_transport_fc.h > > b/include/scsi/scsi_transport_fc.h > > index bf66ea6..56b9e81 100644 > > --- a/include/scsi/scsi_transport_fc.h > > +++ b/include/scsi/scsi_transport_fc.h > > @@

Re: [PATCH] fujitsu-laptop: Support radio LED

On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote: > > Signed-off-by: Michał Kępień > > Jonathan, please check your character set, a few mangled characters here > which I have to fix up to use. UTF-8 seems to work reliably. Sorry about that. Normally UTF-8

Re: [PATCH] fujitsu-laptop: Support radio LED

On Thu, Apr 14, 2016 at 09:42:55PM -0700, Darren Hart wrote: > > Signed-off-by: Michał Kępień > > Jonathan, please check your character set, a few mangled characters here > which I have to fix up to use. UTF-8 seems to work reliably. Sorry about that. Normally UTF-8 stuff goes through just

Re: [PATCH 1/7] PM / devfreq: event: Add new Exynos NoC probe driver

On 2016년 04월 12일 17:07, Krzysztof Kozlowski wrote: > On 04/08/2016 07:00 AM, Chanwoo Choi wrote: >> This patch adds NoC (Network on Chip) Probe driver which provides >> the primitive values to get the performance data. The packets that the >> Network >> on Chip (NoC) probes detects are

Re: [PATCH 1/7] PM / devfreq: event: Add new Exynos NoC probe driver

On 2016년 04월 12일 17:07, Krzysztof Kozlowski wrote: > On 04/08/2016 07:00 AM, Chanwoo Choi wrote: >> This patch adds NoC (Network on Chip) Probe driver which provides >> the primitive values to get the performance data. The packets that the >> Network >> on Chip (NoC) probes detects are

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On Fri, Apr 15, 2016 at 10:18:58AM +0800, Li, Aubrey wrote: Hi Aubrey, > res = platform_get_resource(pdev, IORESOURCE_MEM, > PLAT_RESOURCE_ISP_DATA_INDEX); > - if (!res) { > - dev_err(>dev, "Failed to get res of

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On Fri, Apr 15, 2016 at 10:18:58AM +0800, Li, Aubrey wrote: Hi Aubrey, > res = platform_get_resource(pdev, IORESOURCE_MEM, > PLAT_RESOURCE_ISP_DATA_INDEX); > - if (!res) { > - dev_err(>dev, "Failed to get res of

linux-next: Tree for Apr 15

Hi all, Changes since 20160414: The tip tree still had its build failure for which I reverted a commit. The akpm-current tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 3999 3724 files changed, 148813 insertions(+), 87018 deletions

linux-next: Tree for Apr 15

Hi all, Changes since 20160414: The tip tree still had its build failure for which I reverted a commit. The akpm-current tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 3999 3724 files changed, 148813 insertions(+), 87018 deletions

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

On Thu, Apr 14, 2016 at 9:08 PM, Baoquan He wrote: > On 04/14/16 at 10:56am, Kees Cook wrote: >> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He wrote: >> > On 04/13/16 at 11:02pm, Kees Cook wrote: >> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

On Thu, Apr 14, 2016 at 9:08 PM, Baoquan He wrote: > On 04/14/16 at 10:56am, Kees Cook wrote: >> On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He wrote: >> > On 04/13/16 at 11:02pm, Kees Cook wrote: >> >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook wrote: >> >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo

Re: [PATCH] fujitsu-laptop: Support radio LED

On Tue, Apr 12, 2016 at 10:06:34PM +0930, Jonathan Woithe wrote: > Hi Darren > > On Sun, Apr 10, 2016 at 08:22:58PM +0930, Jonathan Woithe wrote: > > On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote: > > > Jonathan, Micha??, > > > > > > Where are we with this? The above reads as

Re: [PATCH] fujitsu-laptop: Support radio LED

On Tue, Apr 12, 2016 at 10:06:34PM +0930, Jonathan Woithe wrote: > Hi Darren > > On Sun, Apr 10, 2016 at 08:22:58PM +0930, Jonathan Woithe wrote: > > On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote: > > > Jonathan, Micha??, > > > > > > Where are we with this? The above reads as

[PATCH V2] regulator: pv88080: new regulator driver

From: James Ban This is the driver for the Powerventure PV88080 BUCKs regulator. It communicates via an I2C bus to the device. Signed-off-by: James Ban --- Changes since PATCH V1 - Removed unnecessary array. - Added detault

[PATCH V2] regulator: pv88080: new regulator driver

From: James Ban This is the driver for the Powerventure PV88080 BUCKs regulator. It communicates via an I2C bus to the device. Signed-off-by: James Ban --- Changes since PATCH V1 - Removed unnecessary array. - Added detault case. This patch applies against linux-next and next-20160413

[git pull] drm fixes

Hi Linus, This contains fixes for exynos, amdgpu, radeon, i915 and qxl. It also contains some fixes to the core drm edid parser. The qxl fix for a cursor hotspot issue, and the radeon are some MST fixes that I've been running locally and make my monitor a bit happier. The exynos ones fix some

[git pull] drm fixes

Hi Linus, This contains fixes for exynos, amdgpu, radeon, i915 and qxl. It also contains some fixes to the core drm edid parser. The qxl fix for a cursor hotspot issue, and the radeon are some MST fixes that I've been running locally and make my monitor a bit happier. The exynos ones fix some

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? This survives modprobe -r scsi_debug. > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> Hello, >> >> commit

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? This survives modprobe -r scsi_debug. > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> Hello, >> >> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96 >>

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote: > Hi, > > so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip. > After that, wifi is dead in the water. Anyone have a clue? > > And 4.5 seems fine, I'm typing from it as we speak. > ... > [ 661.142657] [

Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

On Fri, 2016-04-15 at 02:07 +, Borislav Petkov wrote: > Hi, > > so I'm seeing this when wlan0 tries to associate. On 4.6-rc2 + tip. > After that, wifi is dead in the water. Anyone have a clue? > > And 4.5 seems fine, I'm typing from it as we speak. > ... > [ 661.142657] [

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

On 04/14/16 at 10:56am, Kees Cook wrote: > On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He wrote: > > On 04/13/16 at 11:02pm, Kees Cook wrote: > >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook wrote: > >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar

Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support

On 04/14/16 at 10:56am, Kees Cook wrote: > On Thu, Apr 14, 2016 at 8:06 AM, Baoquan He wrote: > > On 04/13/16 at 11:02pm, Kees Cook wrote: > >> On Wed, Apr 13, 2016 at 7:11 AM, Kees Cook wrote: > >> > On Wed, Apr 13, 2016 at 3:19 AM, Ingo Molnar wrote: > >> >> > >> >> * Kees Cook wrote: > >>

[RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core platform

From: Ma Ling Wire-latency(RC delay) dominate modern computer performance, conventional serialized works cause cache line ping-pong seriously, the process spend lots of time and power to complete. specially on multi-core platform. However if the serialized works are

[RFC PATCH] aliworkqueue: Adaptive lock integration on multi-core platform

From: Ma Ling Wire-latency(RC delay) dominate modern computer performance, conventional serialized works cause cache line ping-pong seriously, the process spend lots of time and power to complete. specially on multi-core platform. However if the serialized works are sent to one core and

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote: > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote: > > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote: > > > This patch series removes the write() interface for user access in favor > > > of an > > >

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, Apr 14, 2016 at 01:48:31PM -0400, Ira Weiny wrote: > On Thu, Apr 14, 2016 at 10:45:50AM -0600, Jason Gunthorpe wrote: > > On Thu, Apr 14, 2016 at 08:41:35AM -0700, Dennis Dalessandro wrote: > > > This patch series removes the write() interface for user access in favor > > > of an > > >

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

Hi Dietmar, On Thu, Apr 14, 2016 at 01:52:43PM +0100, Dietmar Eggemann wrote: > On 13/04/16 19:44, Yuyang Du wrote: > > On Wed, Apr 13, 2016 at 05:28:18PM +0200, Vincent Guittot wrote: > > [...] > > > By "bailing out", you mean return without update because the delta is less > > than 1ms? > >

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

Hi Dietmar, On Thu, Apr 14, 2016 at 01:52:43PM +0100, Dietmar Eggemann wrote: > On 13/04/16 19:44, Yuyang Du wrote: > > On Wed, Apr 13, 2016 at 05:28:18PM +0200, Vincent Guittot wrote: > > [...] > > > By "bailing out", you mean return without update because the delta is less > > than 1ms? > >

Re: [PATCH 1/3] rxrpc: Don't permit use of connect() op and simplify sendmsg() op

David Miller wrote: > > Simplify the RxRPC user interface and remove the use of connect() to direct > > client calls. It is redundant given that sendmsg() can be given the target > > address and calls to multiple targets are permitted from a client socket > > and also from

Re: [PATCH 1/3] rxrpc: Don't permit use of connect() op and simplify sendmsg() op

David Miller wrote: > > Simplify the RxRPC user interface and remove the use of connect() to direct > > client calls. It is redundant given that sendmsg() can be given the target > > address and calls to multiple targets are permitted from a client socket > > and also from a service socket. >

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn wrote: > Hi Xiong > Sorry for the late reply > > On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote: >> How about this? >> >> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy >> >> Signed-off-by: Xiong

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn wrote: > Hi Xiong > Sorry for the late reply > > On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote: >> How about this? >> >> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy >> >> Signed-off-by: Xiong Zhou >> --- >>

[RT PATCH] cputime: remove raw locks introduced by RT patchset

Sebastian, This patch removes the raw spinlock operations when updating cputtime in the vtime_* functions in kernel/sched/cputime.c. Based on Frederic's commit b7ce2277f087fd052, there is no need for the raw spinlocks in vtime_* functions to guard against writer concurrency and the RT versions

[RT PATCH] cputime: remove raw locks introduced by RT patchset

Sebastian, This patch removes the raw spinlock operations when updating cputtime in the vtime_* functions in kernel/sched/cputime.c. Based on Frederic's commit b7ce2277f087fd052, there is no need for the raw spinlocks in vtime_* functions to guard against writer concurrency and the RT versions

Re: [PATCH 01/14] drm/amdgpu: use drm_crtc_send_vblank_event()

On 15.04.2016 02:48, Gustavo Padovan wrote: > From: Gustavo Padovan > > Replace the legacy drm_send_vblank_event() with the new helper function. > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c

Re: [PATCH 01/14] drm/amdgpu: use drm_crtc_send_vblank_event()

On 15.04.2016 02:48, Gustavo Padovan wrote: > From: Gustavo Padovan > > Replace the legacy drm_send_vblank_event() with the new helper function. > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- >

RE: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Sent: Friday, April 15, 2016 6:35 AM > To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang > Duan > Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes > > Subject:

RE: [PATCH 3/3] fec: move to new ethtool api {get|set}_link_ksettings

From: Philippe Reynes Sent: Friday, April 15, 2016 6:35 AM > To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang > Duan > Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes > > Subject: [PATCH 3/3] fec: move to new ethtool api

RE: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

> -Original Message- > From: tar...@gmail.com [mailto:tar...@gmail.com] On Behalf Of Jeff Kirsher > Sent: Thursday, April 14, 2016 7:21 PM > To: KY Srinivasan > Cc: David Miller ; netdev > ; LKML

RE: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

> -Original Message- > From: tar...@gmail.com [mailto:tar...@gmail.com] On Behalf Of Jeff Kirsher > Sent: Thursday, April 14, 2016 7:21 PM > To: KY Srinivasan > Cc: David Miller ; netdev > ; LKML ; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; >

RE: [PATCH 2/3] phy: add generic function to support ksetting support

From: Philippe Reynes Sent: Friday, April 15, 2016 6:35 AM > To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang > Duan > Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes > > Subject:

RE: [PATCH 2/3] phy: add generic function to support ksetting support

From: Philippe Reynes Sent: Friday, April 15, 2016 6:35 AM > To: da...@davemloft.net; de...@googlers.com; f.faine...@gmail.com; Fugang > Duan > Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org; Philippe Reynes > > Subject: [PATCH 2/3] phy: add generic function to support ksetting

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Thursday, April 14, 2016 4:18 PM > To: KY Srinivasan > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; >

RE: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

> -Original Message- > From: Alexander Duyck [mailto:alexander.du...@gmail.com] > Sent: Thursday, April 14, 2016 4:18 PM > To: KY Srinivasan > Cc: David Miller ; Netdev > ; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Robo Bot > ; Jason Wang ; >

Re: [PATCH] mpt3sas: Remove usage of 'struct timeval'

> "Tina" == Tina Ruchandani writes: Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit Tina> systems in year 2038 and beyond. This patch replaces the use of Tina> struct timeval for computing mpi_request.TimeStamp, and instead Tina> uses ktime_t

Re: [PATCH] mpt3sas: Remove usage of 'struct timeval'

> "Tina" == Tina Ruchandani writes: Tina> 'struct timeval' will have its tv_sec value overflow on 32-bit Tina> systems in year 2038 and beyond. This patch replaces the use of Tina> struct timeval for computing mpi_request.TimeStamp, and instead Tina> uses ktime_t which provides 64-bit

[PATCH v2 2/6] ARM: xen: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. Select a high priority of 192 to ensure that default restart handlers are replaced if Xen is running. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Reviewed-by:

[PATCH v2 3/6] ARM: PSCI: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. This enables support for replacing the PSCI restart handler with a different handler if necessary for a specific board. Select a priority of 129 to indicate a higher than default priority, but keep it as low as

[PATCH v2 0/6] ARM/ARM64: Drop arm_pm_restart

This is the final push to replace arm_pm_restart with the kernel restart handler. Finally drop arm_pm_restart after it is no longer used. --- v2: Rebased to v4.6-rc3 Added Reviewed-by/Acked/by/Tested-by tags Variable name change in patch 3/6.

[PATCH v2 2/6] ARM: xen: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. Select a high priority of 192 to ensure that default restart handlers are replaced if Xen is running. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Reviewed-by: Stefano Stabellini Signed-off-by: Guenter Roeck

[PATCH v2 3/6] ARM: PSCI: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. This enables support for replacing the PSCI restart handler with a different handler if necessary for a specific board. Select a priority of 129 to indicate a higher than default priority, but keep it as low as

[PATCH v2 0/6] ARM/ARM64: Drop arm_pm_restart

This is the final push to replace arm_pm_restart with the kernel restart handler. Finally drop arm_pm_restart after it is no longer used. --- v2: Rebased to v4.6-rc3 Added Reviewed-by/Acked/by/Tested-by tags Variable name change in patch 3/6.

Re: [PATCH] mpt3sas: fix possible NULL dereference

> "Sudip" == Sudip Mukherjee writes: Sudip> We are dereferencing ioc->sense_dma_pool in pci_pool_free() and Sudip> after that we are checking if it is NULL, before calling Sudip> pci_pool_destroy(). Lets check if it is NULL before calling both Sudip>

[PATCH v2 4/6] ARM: Register with kernel restart handler

By making use of the kernel restart handler, board specific restart handlers can be prioritized amongst available mechanisms for a particular board or system. Select the default priority of 128 to indicate that the restart callback in the machine description is the default restart mechanism.

Re: [PATCH] mpt3sas: fix possible NULL dereference

> "Sudip" == Sudip Mukherjee writes: Sudip> We are dereferencing ioc->sense_dma_pool in pci_pool_free() and Sudip> after that we are checking if it is NULL, before calling Sudip> pci_pool_destroy(). Lets check if it is NULL before calling both Sudip> pci_pool_free() and pci_pool_destroy().

[PATCH v2 4/6] ARM: Register with kernel restart handler

By making use of the kernel restart handler, board specific restart handlers can be prioritized amongst available mechanisms for a particular board or system. Select the default priority of 128 to indicate that the restart callback in the machine description is the default restart mechanism.

[PATCH v2 6/6] ARM: Remove arm_pm_restart

All users of arm_pm_restart have been converted to use the kernel restart handler. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Signed-off-by: Guenter Roeck --- v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags

[PATCH v2 6/6] ARM: Remove arm_pm_restart

All users of arm_pm_restart have been converted to use the kernel restart handler. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Signed-off-by: Guenter Roeck --- v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by tags arch/arm/include/asm/system_misc.h | 1 - arch/arm/kernel/reboot.c

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote: > Hello, Mike. > > On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote: > > Let /foo be an exclusive cpuset containing exclusive subset bar. > > How can any task acquire set foo affinity if B really really > > applies? My box calls

[PATCH v2 1/6] ARM: prima2: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. By doing this, the prima2 reset handler can be prioritized among other restart methods available on a particular board. Select a high priority of 192 since the original code overwrites the default arm restart

[PATCH v2 5/6] ARM64: Remove arm_pm_restart

All users of arm_pm_restart have been converted to use the kernel restart handler. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Acked-by: Catalin Marinas

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote: > Hello, Mike. > > On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote: > > Let /foo be an exclusive cpuset containing exclusive subset bar. > > How can any task acquire set foo affinity if B really really > > applies? My box calls

[PATCH v2 1/6] ARM: prima2: Register with kernel restart handler

Register with kernel restart handler instead of setting arm_pm_restart directly. By doing this, the prima2 reset handler can be prioritized among other restart methods available on a particular board. Select a high priority of 192 since the original code overwrites the default arm restart

[PATCH v2 5/6] ARM64: Remove arm_pm_restart

All users of arm_pm_restart have been converted to use the kernel restart handler. Acked-by: Arnd Bergmann Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Acked-by: Catalin Marinas Signed-off-by: Guenter Roeck --- v2: Rebased to v4.6-rc3, added Reviewed/by/Acked-by/Tested-by tags

[PATCH] libnvdimm, btt: add btt startup debug

Report the reason for btt probe failures when debug is enabled. Signed-off-by: Dan Williams --- drivers/nvdimm/btt.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index cc9fafed9362..68a7c3c1eed9

[PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow

The ACPI specification does not specify the state of data after a clear poison operation. Potential future libnvdimm bus implementations for other architectures also might not specify or disagree on the state of data after clear poison. Clarify why we write twice. Reported-by: Jeff Moyer

[PATCH] libnvdimm, btt: add btt startup debug

Report the reason for btt probe failures when debug is enabled. Signed-off-by: Dan Williams --- drivers/nvdimm/btt.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index cc9fafed9362..68a7c3c1eed9 100644 ---

[PATCH] libnvdimm, pmem: clarify the write+clear_poison+write flow

The ACPI specification does not specify the state of data after a clear poison operation. Potential future libnvdimm bus implementations for other architectures also might not specify or disagree on the state of data after clear poison. Clarify why we write twice. Reported-by: Jeff Moyer

Re: [PATCH] pm80xx: Remove bogus address masking in pm8001_ioremap()

> "David" == David Daney writes: David> It is unclear what the original intent of the masking was, but it David> is clearly incorrect to truncate a physical address before David> calling ioremap(). On systems where there are valid physical David> address bits above

Re: [PATCH] pm80xx: Remove bogus address masking in pm8001_ioremap()

> "David" == David Daney writes: David> It is unclear what the original intent of the masking was, but it David> is clearly incorrect to truncate a physical address before David> calling ioremap(). On systems where there are valid physical David> address bits above bit-31 (arm64 for

[PATCH] platform/chrome: cros_ec_dev - Populate compat_ioctl

compat_ioctl has to be populated for 32 bit userspace applications to work with 64 bit kernels. Signed-off-by: Guenter Roeck --- drivers/platform/chrome/cros_ec_dev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_dev.c

[PATCH] platform/chrome: cros_ec_dev - Populate compat_ioctl

compat_ioctl has to be populated for 32 bit userspace applications to work with 64 bit kernels. Signed-off-by: Guenter Roeck --- drivers/platform/chrome/cros_ec_dev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/platform/chrome/cros_ec_dev.c

Re: [PATCH v7 2/3] gpio: dwapb: convert device node to fwnode

On 2016/4/6 15:07, qiujiang wrote: > This patch converts device node to fwnode for dwapb driver, so > as to provide a unified fwnode for DT and ACPI bindings. > > Acked-by: Andy Shevchenko > Signed-off-by: qiujiang > --- >

Re: [PATCH v7 2/3] gpio: dwapb: convert device node to fwnode

On 2016/4/6 15:07, qiujiang wrote: > This patch converts device node to fwnode for dwapb driver, so > as to provide a unified fwnode for DT and ACPI bindings. > > Acked-by: Andy Shevchenko > Signed-off-by: qiujiang > --- > drivers/gpio/gpio-dwapb.c| 37 >

Re: [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'

> "Tina" == Tina Ruchandani writes: Tina, >> Applied to 4.6/scsi-queue. Tina> I am not seeing this patch in v4.6-rc3 in Linus's tree. Not sure how I messed that up. Sorry! Applied to 4.7/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH, RESEND 3] qla2xxx: Remove use of 'struct timeval'

> "Tina" == Tina Ruchandani writes: Tina, >> Applied to 4.6/scsi-queue. Tina> I am not seeing this patch in v4.6-rc3 in Linus's tree. Not sure how I messed that up. Sorry! Applied to 4.7/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan wrote: > Make adjustments to the Intel 10G VF driver to support > running on Hyper-V hosts. > > K. Y. Srinivasan (2): > ethernet: intel: Add the device ID's presented while running on > Hyper-V > intel: ixgbevf: Support

Re: [PATCH net-next 0/2] ethernet: intel: Support Hyper-V hosts

On Thu, Apr 14, 2016 at 4:55 PM, K. Y. Srinivasan wrote: > Make adjustments to the Intel 10G VF driver to support > running on Hyper-V hosts. > > K. Y. Srinivasan (2): > ethernet: intel: Add the device ID's presented while running on > Hyper-V > intel: ixgbevf: Support Windows hosts

Re: [PATCH 0/5] hisi_sas: v2 hw SATA fixes

> "John" == John Garry writes: John> This patchset introduces SATA support fixes for the HiSilicon v2 John> hw SAS controller. John> Fixes include: - attach issue for SATA disk attached through John> expander - intermittent issue for directly attaching multiple SATA

Re: [PATCH 0/5] hisi_sas: v2 hw SATA fixes

> "John" == John Garry writes: John> This patchset introduces SATA support fixes for the HiSilicon v2 John> hw SAS controller. John> Fixes include: - attach issue for SATA disk attached through John> expander - intermittent issue for directly attaching multiple SATA John> disks - add

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > This lets userland get the filesystem freezing status, aka whether the > filesystem is frozen or not. This is so that an application can know if > it should freeze the filesystem or if it isn't necessary when taking a > snapshot.

Re: [PATCH] fs: add the FIGETFROZEN ioctl call

On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote: > This lets userland get the filesystem freezing status, aka whether the > filesystem is frozen or not. This is so that an application can know if > it should freeze the filesystem or if it isn't necessary when taking a > snapshot.

Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access in enqueue_task_dl()

On 2016/04/15 at 09:58, Xunlei Pang wrote: > On 2016/04/14 at 23:31, Peter Zijlstra wrote: >> On Thu, Apr 14, 2016 at 07:37:06PM +0800, Xunlei Pang wrote: >>> We access @pi_task's data without any lock in enqueue_task_dl(), though >>> checked "dl_prio(pi_task->normal_prio)" condition, that's not

Re: [PATCH v3 5/6] sched/deadline/rtmutex: Fix unprotected PI access in enqueue_task_dl()

On 2016/04/15 at 09:58, Xunlei Pang wrote: > On 2016/04/14 at 23:31, Peter Zijlstra wrote: >> On Thu, Apr 14, 2016 at 07:37:06PM +0800, Xunlei Pang wrote: >>> We access @pi_task's data without any lock in enqueue_task_dl(), though >>> checked "dl_prio(pi_task->normal_prio)" condition, that's not

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On 2016/4/15 8:32, Darren Hart wrote: > On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote: >> On 2016/4/10 21:17, Andy Shevchenko wrote: >>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li >>> wrote: Currently the optional IPC resources prevent telemetry

Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources

On 2016/4/15 8:32, Darren Hart wrote: > On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote: >> On 2016/4/10 21:17, Andy Shevchenko wrote: >>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li >>> wrote: Currently the optional IPC resources prevent telemetry driver from probing if

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote: > > > This has nothing to do with dominance or anything nefarious, I'm asking > > > simply for a full engineering evaluation of all possibilities, with > > >

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 11:12:01PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 04:38:47PM -0400, Konrad Rzeszutek Wilk wrote: > > > This has nothing to do with dominance or anything nefarious, I'm asking > > > simply for a full engineering evaluation of all possibilities, with > > >

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: > > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > > > > On

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Thu, Apr 14, 2016 at 10:56:19PM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 14, 2016 at 03:56:53PM -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Apr 14, 2016 at 08:40:48PM +0200, Luis R. Rodriguez wrote: > > > On Wed, Apr 13, 2016 at 09:01:32PM -0400, Konrad Rzeszutek Wilk wrote: > > > > On

Re: [PATCH v6 3/4] soc: mediatek: Add MT2701 power dt-bindings

Hi Yingjoe, On Thu, 2016-04-14 at 18:56 +0800, Yingjoe Chen wrote: > On Thu, 2016-04-14 at 16:16 +0800, James Liao wrote: > > From: Shunli Wang > > > > Add power dt-bindings for MT2701. > > > > Signed-off-by: Shunli Wang > > Signed-off-by:

Re: [PATCH v6 3/4] soc: mediatek: Add MT2701 power dt-bindings

Hi Yingjoe, On Thu, 2016-04-14 at 18:56 +0800, Yingjoe Chen wrote: > On Thu, 2016-04-14 at 16:16 +0800, James Liao wrote: > > From: Shunli Wang > > > > Add power dt-bindings for MT2701. > > > > Signed-off-by: Shunli Wang > > Signed-off-by: James Liao > > Acked-by: Rob Herring > >

  1   2   3   4   5   6   7   8   9   10   >