[PATCH v3 3/8] arm64: add io{read,write}64be accessors

This will allow device drivers to consistently use io{read,write}XXbe also for 64-bit accesses. Acked-by: Catalin Marinas Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă --- arch/arm64/include/asm/io.h | 4

[PATCH v3 3/8] arm64: add io{read,write}64be accessors

This will allow device drivers to consistently use io{read,write}XXbe also for 64-bit accesses. Acked-by: Catalin Marinas Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă --- arch/arm64/include/asm/io.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v3 5/8] crypto: caam - fix offset field in hw sg entries

From: Cristian Stoica The offset field is 13 bits wide; make sure we don't overwrite more than that in the caam hardware scatter gather structure. Signed-off-by: Cristian Stoica Signed-off-by: Horia Geantă ---

[PATCH v3 5/8] crypto: caam - fix offset field in hw sg entries

From: Cristian Stoica The offset field is 13 bits wide; make sure we don't overwrite more than that in the caam hardware scatter gather structure. Signed-off-by: Cristian Stoica Signed-off-by: Horia Geantă --- drivers/crypto/caam/desc.h | 2 +- drivers/crypto/caam/sg_sw_sec4.h | 8

[PATCH v3 8/8] arm64: dts: ls1043a: add crypto node

LS1043A has a SEC v5.4 security engine. For now don't add rtic or sec_mon subnodes, since these features haven't been tested yet. Signed-off-by: Horia Geantă --- To go into kernel 4.8 via crypto tree. arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +++

[PATCH v3 8/8] arm64: dts: ls1043a: add crypto node

LS1043A has a SEC v5.4 security engine. For now don't add rtic or sec_mon subnodes, since these features haven't been tested yet. Signed-off-by: Horia Geantă --- To go into kernel 4.8 via crypto tree. arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +++

[PATCH v3 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Acked-by: Michael Ellerman Signed-off-by: Horia Geantă --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff

[PATCH v3 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Acked-by: Michael Ellerman Signed-off-by: Horia Geantă --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/kernel/iomap.c

[PATCH v3 6/8] crypto: caam - handle core endianness != caam endianness

There are SoCs like LS1043A where CAAM endianness (BE) does not match the default endianness of the core (LE). Moreover, there are requirements for the driver to handle cases like CPU_BIG_ENDIAN=y on ARM-based SoCs. This requires for a complete rewrite of the I/O accessors. PPC-specific accessors

[PATCH v3 6/8] crypto: caam - handle core endianness != caam endianness

There are SoCs like LS1043A where CAAM endianness (BE) does not match the default endianness of the core (LE). Moreover, there are requirements for the driver to handle cases like CPU_BIG_ENDIAN=y on ARM-based SoCs. This requires for a complete rewrite of the I/O accessors. PPC-specific accessors

[RFC PATCH v2 1/3] arch/powerpc : Add detour buffer support for optprobes

Detour buffer contains instructions to create an in memory pt_regs. After the execution of prehandler a call is made for instruction emulation. The NIP is decided after the probed instruction is executed. Hence a branch instruction is created to the NIP returned by emulate_step(). Instruction

[RFC PATCH v2 1/3] arch/powerpc : Add detour buffer support for optprobes

Detour buffer contains instructions to create an in memory pt_regs. After the execution of prehandler a call is made for instruction emulation. The NIP is decided after the probed instruction is executed. Hence a branch instruction is created to the NIP returned by emulate_step(). Instruction

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 17:03, Christian Borntraeger wrote: > > > Would this work too and be simpler? > > > Hmm, your patch does only fiddle with the grow/shrink logic (which might > > > be a good idea independently of this change), but the original patch > > > actually takes into account that we have a

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 17:03, Christian Borntraeger wrote: > > > Would this work too and be simpler? > > > Hmm, your patch does only fiddle with the grow/shrink logic (which might > > > be a good idea independently of this change), but the original patch > > > actually takes into account that we have a

Re: [PATCH] drm/amd/powerplay/hwmgr: use kmemdup

On Thu, May 19, 2016 at 7:15 AM, Muhammad Falak R Wani wrote: > Use kmemdup when some other buffer is immediately copied into allocated > region. It replaces call to allocation followed by memcpy, by a single > call to kmemdup. > > Signed-off-by: Muhammad Falak R Wani

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 04:56 PM, Paolo Bonzini wrote: > > > On 19/05/2016 16:52, Christian Borntraeger wrote: Would this work too and be simpler? >> Hmm, your patch does only fiddle with the grow/shrink logic (which might >> be a good idea independently of this change), but the original patch >>

Re: [PATCH] drm/amd/powerplay/hwmgr: use kmemdup

On Thu, May 19, 2016 at 7:15 AM, Muhammad Falak R Wani wrote: > Use kmemdup when some other buffer is immediately copied into allocated > region. It replaces call to allocation followed by memcpy, by a single > call to kmemdup. > > Signed-off-by: Muhammad Falak R Wani Applied the hwmgr patches.

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 04:56 PM, Paolo Bonzini wrote: > > > On 19/05/2016 16:52, Christian Borntraeger wrote: Would this work too and be simpler? >> Hmm, your patch does only fiddle with the grow/shrink logic (which might >> be a good idea independently of this change), but the original patch >>

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 04:41:17PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > > Agreed, these sorts of instruction sequences make a lot of sense. > > Of course, if you stuff too many intructions and cache misses between > > the LL and the SC,

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 04:41:17PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > > Agreed, these sorts of instruction sequences make a lot of sense. > > Of course, if you stuff too many intructions and cache misses between > > the LL and the SC,

Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2

* Peter Ujfalusi [160519 01:10]: > On 05/18/2016 10:30 PM, Tony Lindgren wrote: > > Ideally the adma support would be a separate loadable module, > > similar how the cppi41dma is a child of the OTG controller. > > The Master DMA is part of the hsmmc IP block. If the same

Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2

* Peter Ujfalusi [160519 01:10]: > On 05/18/2016 10:30 PM, Tony Lindgren wrote: > > Ideally the adma support would be a separate loadable module, > > similar how the cppi41dma is a child of the OTG controller. > > The Master DMA is part of the hsmmc IP block. If the same ADMA module is > present

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 16:52, Christian Borntraeger wrote: >> > Would this work too and be simpler? > Hmm, your patch does only fiddle with the grow/shrink logic (which might > be a good idea independently of this change), but the original patch > actually takes into account that we have a guaranteed

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 16:52, Christian Borntraeger wrote: >> > Would this work too and be simpler? > Hmm, your patch does only fiddle with the grow/shrink logic (which might > be a good idea independently of this change), but the original patch > actually takes into account that we have a guaranteed

Re: [PATCH 3/5] drm: mediatek: fixup drm_gem_object_lookup API change

On 18/05/16 18:07, Arnd Bergmann wrote: The drm_gem_object_lookup() function prototype changed while this driver was added, so it fails to build now: drivers/gpu/drm/mediatek/mtk_drm_gem.c: In function 'mtk_drm_gem_dumb_map_offset': drivers/gpu/drm/mediatek/mtk_drm_gem.c:142:30: error:

Re: [PATCH 3/5] drm: mediatek: fixup drm_gem_object_lookup API change

On 18/05/16 18:07, Arnd Bergmann wrote: The drm_gem_object_lookup() function prototype changed while this driver was added, so it fails to build now: drivers/gpu/drm/mediatek/mtk_drm_gem.c: In function 'mtk_drm_gem_dumb_map_offset': drivers/gpu/drm/mediatek/mtk_drm_gem.c:142:30: error:

Re: [PATCH 2/5] drm: mediatek: add CONFIG_OF dependency

On 18/05/16 18:07, Arnd Bergmann wrote: The mediatek DRM driver can be configured for compile testing with CONFIG_OF disabled, but then fails to link: drivers/gpu/built-in.o: In function `mtk_drm_bind': analogix_dp_reg.c:(.text+0x52888): undefined reference to `of_find_device_by_node'

Re: [PATCH 2/5] drm: mediatek: add CONFIG_OF dependency

On 18/05/16 18:07, Arnd Bergmann wrote: The mediatek DRM driver can be configured for compile testing with CONFIG_OF disabled, but then fails to link: drivers/gpu/built-in.o: In function `mtk_drm_bind': analogix_dp_reg.c:(.text+0x52888): undefined reference to `of_find_device_by_node'

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 03:57 PM, Paolo Bonzini wrote: > > > On 19/05/2016 15:27, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic halt-polling, lower-end of message passing workload >> latency

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 03:57 PM, Paolo Bonzini wrote: > > > On 19/05/2016 15:27, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic halt-polling, lower-end of message passing workload >> latency TCP_RR's poll time < 10us) we

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > + dev->class = _class; > + dev->parent = parent; > + dev->type = _partner_dev_type; > + dev_set_name(dev, "%s-partner", dev_name(>dev)); > + > + ret = device_register(dev); > + if (ret) { > +

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > + dev->class = _class; > + dev->parent = parent; > + dev->type = _partner_dev_type; > + dev_set_name(dev, "%s-partner", dev_name(>dev)); > + > + ret = device_register(dev); > + if (ret) { > +

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > The purpose of this class is to provide unified interface for user > space to get the status and basic information about USB Type-C > Connectors in the system, control data role swapping, and when USB PD > is available, also power role

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > The purpose of this class is to provide unified interface for user > space to get the status and basic information about USB Type-C > Connectors in the system, control data role swapping, and when USB PD > is available, also power role

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

Em Thu, May 19, 2016 at 11:47:38AM +, He Kuang escreveu: > Currently, perf script uses host unwind methods to parse perf.data > callchain info regardless of the target architecture. So we get wrong > result and no promotion when unwinding callchains of x86(32-bit) on What you mean by

Re: [PATCH v4 2/6] perf tools: Promote proper messages for cross-platform unwind

Em Thu, May 19, 2016 at 11:47:38AM +, He Kuang escreveu: > Currently, perf script uses host unwind methods to parse perf.data > callchain info regardless of the target architecture. So we get wrong > result and no promotion when unwinding callchains of x86(32-bit) on What you mean by

RE: ioatdma(Intel(R) I/OAT DMA Engine init failed)

> -Original Message- > From: Gavin Guo [mailto:gavin@canonical.com] > Sent: Wednesday, May 18, 2016 8:19 PM > To: Jiang, Dave > Cc: Koul, Vinod ; dmaeng...@vger.kernel.org; > linux-kernel@vger.kernel.org; Williams, Dan J >

RE: ioatdma(Intel(R) I/OAT DMA Engine init failed)

> -Original Message- > From: Gavin Guo [mailto:gavin@canonical.com] > Sent: Wednesday, May 18, 2016 8:19 PM > To: Jiang, Dave > Cc: Koul, Vinod ; dmaeng...@vger.kernel.org; > linux-kernel@vger.kernel.org; Williams, Dan J > > Subject: Re: ioatdma(Intel(R) I/OAT DMA Engine init

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Thu, May 19, 2016 at 06:39:41PM +0800, Zhu Guihua wrote: > [Problem] > > cpuid <-> nodeid mapping is firstly established at boot time. And workqueue > caches > the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time. > > When doing node online/offline, cpuid <-> nodeid mapping

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Thu, May 19, 2016 at 06:39:41PM +0800, Zhu Guihua wrote: > [Problem] > > cpuid <-> nodeid mapping is firstly established at boot time. And workqueue > caches > the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time. > > When doing node online/offline, cpuid <-> nodeid mapping

Re: Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

On Wed, May 18, 2016 at 10:11 PM, Guenter Roeck wrote: > Hi, > > some of my ppc qemu tests crash with the following log message. > > VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available >

Re: Crash in -next due to 'drivers/of: Fix depth when unflattening devicetree'

On Wed, May 18, 2016 at 10:11 PM, Guenter Roeck wrote: > Hi, > > some of my ppc qemu tests crash with the following log message. > > VFS: Cannot open root device "hda" or unknown-block(0,0): error -6 > Please append a correct "root=" boot option; here are the available > partitions: > 0100

RE: new driver for drivers/virt/?

> -Original Message- > From: Sell, Timothy C > Sent: Wednesday, May 18, 2016 6:25 PM > To: 'Thomas Gleixner' > Cc: mi...@kernel.org; dave.han...@linux.intel.com; > ti...@freescale.com; ga...@kernel.crashing.org; Kershner, David A; > cor...@lwn.net; mi...@redhat.com; h...@zytor.com;

RE: new driver for drivers/virt/?

> -Original Message- > From: Sell, Timothy C > Sent: Wednesday, May 18, 2016 6:25 PM > To: 'Thomas Gleixner' > Cc: mi...@kernel.org; dave.han...@linux.intel.com; > ti...@freescale.com; ga...@kernel.crashing.org; Kershner, David A; > cor...@lwn.net; mi...@redhat.com; h...@zytor.com;

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > Agreed, these sorts of instruction sequences make a lot of sense. > Of course, if you stuff too many intructions and cache misses between > the LL and the SC, the SC success probability starts dropping, but short > seqeunces of

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > Agreed, these sorts of instruction sequences make a lot of sense. > Of course, if you stuff too many intructions and cache misses between > the LL and the SC, the SC success probability starts dropping, but short > seqeunces of

Re: [RFC PATCH] Increase in idle power with schedutil

On Thu, May 19, 2016 at 1:40 PM, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 11:11:51PM +0200, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat >> wrote: >> > This patch adds driver callback for fast_switch

Re: [RFC PATCH] Increase in idle power with schedutil

On Thu, May 19, 2016 at 1:40 PM, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 11:11:51PM +0200, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:53 PM, Shilpasri G Bhat >> wrote: >> > This patch adds driver callback for fast_switch and below observations >> > on schedutil governor are

Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource

On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas Söderlund wrote: > Hi Konrad, > > Thanks for your feedback. > > On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote: > > > > > > -In some circumstances dma_map_single() and dma_map_page() will fail to > > > create > > > -a mapping. A

Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource

On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas Söderlund wrote: > Hi Konrad, > > Thanks for your feedback. > > On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote: > > > > > > -In some circumstances dma_map_single() and dma_map_page() will fail to > > > create > > > -a mapping. A

Re: [PATCH v2 5/9] powerpc/powernv: Move idle related macros to cpuidle.h

On Tue, May 03, 2016 at 01:54:34PM +0530, Shreyas B. Prabhu wrote: > Move idle related macros to a common location asm/cpuidle.h so that > they can be used for stop instruction support. > > Signed-off-by: Shreyas B. Prabhy Reviewed-by: Gautham R. Shenoy

Re: [PATCH v2 5/9] powerpc/powernv: Move idle related macros to cpuidle.h

On Tue, May 03, 2016 at 01:54:34PM +0530, Shreyas B. Prabhu wrote: > Move idle related macros to a common location asm/cpuidle.h so that > they can be used for stop instruction support. > > Signed-off-by: Shreyas B. Prabhy Reviewed-by: Gautham R. Shenoy -- Thanks and Regards gautham.

Re: [PATCH v2 4/9] powerpc/powernv: Make power7_powersave_common more generic

On Wed, May 18, 2016 at 12:21:17PM +0530, Shreyas B Prabhu wrote: > With this patch, r5 which is the third parameter to > power_powersave_common contains the return address that needs to be > written to SRR0. So here I'm keeping r5 unaltered and using r7 for the MSR. Ok. Reviewed-by: Gautham R.

Re: [PATCH v2 4/9] powerpc/powernv: Make power7_powersave_common more generic

On Wed, May 18, 2016 at 12:21:17PM +0530, Shreyas B Prabhu wrote: > With this patch, r5 which is the third parameter to > power_powersave_common contains the return address that needs to be > written to SRR0. So here I'm keeping r5 unaltered and using r7 for the MSR. Ok. Reviewed-by: Gautham R.

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

Hi Shreyas, On Wed, May 18, 2016 at 12:37:56PM +0530, Shreyas B Prabhu wrote: [..snip..] > >> diff --git a/arch/powerpc/kernel/exceptions-64s.S > >> b/arch/powerpc/kernel/exceptions-64s.S > >> index 7716ceb..7ebfbb0 100644 > >> --- a/arch/powerpc/kernel/exceptions-64s.S > >> +++

Re: [PATCH v2 2/9] powerpc/kvm: make hypervisor state restore a function

Hi Shreyas, On Wed, May 18, 2016 at 12:37:56PM +0530, Shreyas B Prabhu wrote: [..snip..] > >> diff --git a/arch/powerpc/kernel/exceptions-64s.S > >> b/arch/powerpc/kernel/exceptions-64s.S > >> index 7716ceb..7ebfbb0 100644 > >> --- a/arch/powerpc/kernel/exceptions-64s.S > >> +++

Re: get_maintainer.pl and MAINTAINERS file

On Thu, May 19, 2016 at 2:57 PM, Kalle Valo wrote: > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > driver") > > Robin van der Gracht writes: > >>> And 4th, what is with the insane number of people on cc:? Use >>>

Re: get_maintainer.pl and MAINTAINERS file

On Thu, May 19, 2016 at 2:57 PM, Kalle Valo wrote: > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > driver") > > Robin van der Gracht writes: > >>> And 4th, what is with the insane number of people on cc:? Use >>> get_maintainer.pl correctly please, and don't

Re: [PATCH] fbcon: use default if cursor blink interval is not valid

On Thu, 19 May 2016, Pavel Machek wrote: > Hi! > > > Two current [1] and three previous [2] systems locked during boot > > because the cursor flash timer was set using an ops->cur_blink_jiffies > > value of 0. Previous patches attempted to solve the problem by moving > > variable initialization

Re: [PATCH] fbcon: use default if cursor blink interval is not valid

On Thu, 19 May 2016, Pavel Machek wrote: > Hi! > > > Two current [1] and three previous [2] systems locked during boot > > because the cursor flash timer was set using an ops->cur_blink_jiffies > > value of 0. Previous patches attempted to solve the problem by moving > > variable initialization

Re: [PATCH v4 1/6] perf tools: Set buildid dir under symfs when --symfs is provided

On 5/19/16 5:47 AM, He Kuang wrote: This patch moves the reference of buildid dir to 'symfs/.debug' and skips the local buildid dir when '--symfs' is given, so that every single file opened by perf is relateive to symfs directory now. Signed-off-by: He Kuang ---

RE: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

Hi Steve, Thanks for the explanation. I will take care of your comments and send v2 of the same patch. Thanks, Soumya. -Original Message- From: Steven Rostedt [mailto:rost...@goodmis.org] Sent: Thursday, May 19, 2016 6:41 PM To: N, Soumya P Cc: mi...@redhat.com;

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > > Peter Zijlstra wrote: > > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > > loop and not a loop around an

Re: [PATCH v4 1/6] perf tools: Set buildid dir under symfs when --symfs is provided

On 5/19/16 5:47 AM, He Kuang wrote: This patch moves the reference of buildid dir to 'symfs/.debug' and skips the local buildid dir when '--symfs' is given, so that every single file opened by perf is relateive to symfs directory now. Signed-off-by: He Kuang --- tools/perf/builtin-annotate.c

RE: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

Hi Steve, Thanks for the explanation. I will take care of your comments and send v2 of the same patch. Thanks, Soumya. -Original Message- From: Steven Rostedt [mailto:rost...@goodmis.org] Sent: Thursday, May 19, 2016 6:41 PM To: N, Soumya P Cc: mi...@redhat.com;

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > > Peter Zijlstra wrote: > > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > > loop and not a loop around an LL/SC cmpxchg. > > > I

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 8:51 PM, Rob Herring wrote: > On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: >> On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: >>> On 5/18/2016 3:58 PM, Rhyland Klein wrote: On 5/18/2016 3:36 PM, Rob

Re: drivers/of: crash on boot

On Wed, May 18, 2016 at 8:51 PM, Rob Herring wrote: > On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: >> On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: >>> On 5/18/2016 3:58 PM, Rhyland Klein wrote: On 5/18/2016 3:36 PM, Rob Herring wrote: > On Wed, May 18, 2016 at 10:34 AM,

[PATCH 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

As observed with the latest ThinkPad docks, we unfortunately can't rely on docks keeping us updated with hotplug events that happened while we were suspended. On top of that, even if the number of connectors remains the same between suspend and resume it's still not safe to assume that there were

[PATCH 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

As observed with the latest ThinkPad docks, we unfortunately can't rely on docks keeping us updated with hotplug events that happened while we were suspended. On top of that, even if the number of connectors remains the same between suspend and resume it's still not safe to assume that there were

[PATCH 2/2] drm/i915/mst: Reset MST after resume when necessary

A follow-up to the previous commit, we skip checking the status of the MST device and completely reprobe it if drm_dp_mst_topology_mgr_resume() returns -EINVAL. Cc: sta...@vger.kernel.org Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_dp.c | 11 +-- 1 file

[PATCH 2/2] drm/i915/mst: Reset MST after resume when necessary

A follow-up to the previous commit, we skip checking the status of the MST device and completely reprobe it if drm_dp_mst_topology_mgr_resume() returns -EINVAL. Cc: sta...@vger.kernel.org Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_dp.c | 11 +-- 1 file changed, 9 insertions(+),

[PATCH] [SCSI] aacraid: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aacraid/commctrl.c | 7 +++ 1 file changed, 3

[PATCH] [SCSI] aacraid: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aacraid/commctrl.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 15:27, Wanpeng Li wrote: > From: Wanpeng Li > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of dynamic halt-polling, lower-end of message passing workload > latency TCP_RR's poll time < 10us) we can treat it as a short halt, >

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 19/05/2016 15:27, Wanpeng Li wrote: > From: Wanpeng Li > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of dynamic halt-polling, lower-end of message passing workload > latency TCP_RR's poll time < 10us) we can treat it as a short halt, > and poll to wait it

Re: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 13:49:16 + "N, Soumya P" wrote: > Hi Steve, > > Thanks for the explanation. > I will take care of your comments and send v2 of the same patch. > I'll also note that in our forum (LKML), we do not do "top posting". We practice "inline replying" and

Re: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 13:49:16 + "N, Soumya P" wrote: > Hi Steve, > > Thanks for the explanation. > I will take care of your comments and send v2 of the same patch. > I'll also note that in our forum (LKML), we do not do "top posting". We practice "inline replying" and "trimming". See

Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

On Wed, May 18, 2016 at 09:25:17PM -0700, Josh Triplett wrote: > On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote: > > I spend some time to make tools/testing/selftest/rcutorture run on PPC, > > here are some documention and fixes made while I was trying. > > > > The scripts are able to

Re: [PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

On Wed, May 18, 2016 at 09:25:17PM -0700, Josh Triplett wrote: > On Thu, May 19, 2016 at 11:42:20AM +0800, Boqun Feng wrote: > > I spend some time to make tools/testing/selftest/rcutorture run on PPC, > > here are some documention and fixes made while I was trying. > > > > The scripts are able to

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote: > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote: > > The option "-soundhw pcspk" gives me a error on PPC as follow: > > > > qemu-system-ppc64: ISA bus not available for pcspk > > > > , which means this option doesn't

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote: > On Thu, May 19, 2016 at 11:42:23AM +0800, Boqun Feng wrote: > > The option "-soundhw pcspk" gives me a error on PPC as follow: > > > > qemu-system-ppc64: ISA bus not available for pcspk > > > > , which means this option doesn't

[PATCH] [SCSI] aic7xxx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aic7xxx/aic7xxx_core.c | 4 ++-- 1 file changed, 2

[PATCH] [SCSI] aic7xxx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aic7xxx/aic7xxx_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v4] skb_array: array based FIFO for skbs

A simple array based FIFO of pointers. Intended for net stack so uses skbs for type safety, but we can replace with with void * if others find it useful outside of net stack. Signed-off-by: Michael S. Tsirkin --- Still untested. Posting since several people expressed interest

[PATCH] [SCSI] aic79xx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aic7xxx/aic79xx_core.c | 4 ++-- 1 file changed, 2

[PATCH v4] skb_array: array based FIFO for skbs

A simple array based FIFO of pointers. Intended for net stack so uses skbs for type safety, but we can replace with with void * if others find it useful outside of net stack. Signed-off-by: Michael S. Tsirkin --- Still untested. Posting since several people expressed interest in helping test

[PATCH] [SCSI] aic79xx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/scsi/aic7xxx/aic79xx_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On Thu, 19 May 2016, Srinivas Kandagatla wrote: > This patch protects system from crashing at shutdown in > cases where usb host is not added yet from OTG controller driver. > As ehci_setup() not done yet, so stop accessing registers or > variables initialized as part of ehci_setup(). > > The

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On Thu, 19 May 2016, Srinivas Kandagatla wrote: > This patch protects system from crashing at shutdown in > cases where usb host is not added yet from OTG controller driver. > As ehci_setup() not done yet, so stop accessing registers or > variables initialized as part of ehci_setup(). > > The

[PATCH] USB: serial: cp210x: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/usb/serial/cp210x.c | 4 +--- 1 file changed, 1 insertion(+), 3

[PATCH] USB: serial: cp210x: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/usb/serial/cp210x.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff

[PATCH] brcmfmac: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +-- 1

[PATCH] brcmfmac: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +-- 1 file changed, 1

[PATCH] net: usb: ch9200: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/usb/ch9200.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH] net: usb: ch9200: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/usb/ch9200.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH v3] xen: add steal_clock support on x86

On 19/05/16 15:26, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. >

Re: [PATCH v3] xen: add steal_clock support on x86

On 19/05/16 15:26, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. >

[PATCH 2/2] Input: migor-ts: mark PM functions as __maybe_unused

The migor touchscreen driver is now available for COMPILE_TEST, so we run into a harmless randconfig warning on ARM when CONFIG_PM is disabled: drivers/input/touchscreen/migor_ts.c:216:12: error: 'migor_ts_resume' defined but not used [-Werror=unused-function]

[PATCH] ps3_gelic: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 4 ++-- 1 file

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