Re: [patch V2 3/7] futex: Add op for hash preallocation

On Sat, May 07, 2016 at 10:47:38AM +0200, Thomas Gleixner wrote: > On Fri, 6 May 2016, Darren Hart wrote: > > So this seems like it could be tricky for the user as system libraries, like > > glibc, make use of futexes. Can we guarantee that "sys_futex" is not called > > by > > the time main() is

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Sat, May 07, 2016 at 10:47:38AM +0200, Thomas Gleixner wrote: > On Fri, 6 May 2016, Darren Hart wrote: > > So this seems like it could be tricky for the user as system libraries, like > > glibc, make use of futexes. Can we guarantee that "sys_futex" is not called > > by > > the time main() is

Re: [PATCH] ARM: at91: Add DT support for Olimex SAM9-L9260 board.

Le 19/05/2016 01:29, Rob Herring a écrit : > On Wed, May 18, 2016 at 06:02:46PM +0530, Raashid Muhammed wrote: >> From: Raashid Muhammed >> >> sam9-l9260 is a low cost board designed by Olimex. >> >> More infomation is available at: >>

Re: [PATCH] ARM: at91: Add DT support for Olimex SAM9-L9260 board.

Le 19/05/2016 01:29, Rob Herring a écrit : > On Wed, May 18, 2016 at 06:02:46PM +0530, Raashid Muhammed wrote: >> From: Raashid Muhammed >> >> sam9-l9260 is a low cost board designed by Olimex. >> >> More infomation is available at: >> https://www.olimex.com/Products/ARM/Atmel/SAM9-L9260/ >> >>

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > +static int futex_preallocate_hash(unsigned int slots) > +{ > +#ifdef CONFIG_FUTEX_PRIVATE_HASH > + struct mm_struct *mm = current->mm; > + struct futex_hash_bucket *hb; > + unsigned int bits; > + > + /* Try to

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > +static int futex_preallocate_hash(unsigned int slots) > +{ > +#ifdef CONFIG_FUTEX_PRIVATE_HASH > + struct mm_struct *mm = current->mm; > + struct futex_hash_bucket *hb; > + unsigned int bits; > + > + /* Try to

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > From: Sebastian Siewior > > The per process hash is allocated on the fly at the first futex operation of a > process. The size of the hash is determined by a system wide default setting > controlled by the

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > From: Sebastian Siewior > > The per process hash is allocated on the fly at the first futex operation of a > process. The size of the hash is determined by a system wide default setting > controlled by the sys admin, This is

Re: [patch V2 2/7] futex: Hash private futexes per process

On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote: > +static struct futex_hash_bucket *hash_futex(union futex_key *key) > +{ > +#ifdef CONFIG_FUTEX_PRIVATE_HASH > + struct mm_struct *mm = current->mm; > + unsigned int slot; > + > + /* > + * Futexes which use the per

Re: [patch V2 2/7] futex: Hash private futexes per process

On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote: > +static struct futex_hash_bucket *hash_futex(union futex_key *key) > +{ > +#ifdef CONFIG_FUTEX_PRIVATE_HASH > + struct mm_struct *mm = current->mm; > + unsigned int slot; > + > + /* > + * Futexes which use the per

[tip:perf/urgent] perf: Update MAINTAINERS for x86 move

Commit-ID: b0a434fb7412937d55f15b8897c5646c81497bbe Gitweb: http://git.kernel.org/tip/b0a434fb7412937d55f15b8897c5646c81497bbe Author: Peter Zijlstra AuthorDate: Thu, 19 May 2016 12:30:19 +0200 Committer: Ingo Molnar CommitDate: Thu, 19 May 2016

[tip:perf/urgent] perf: Update MAINTAINERS for x86 move

Commit-ID: b0a434fb7412937d55f15b8897c5646c81497bbe Gitweb: http://git.kernel.org/tip/b0a434fb7412937d55f15b8897c5646c81497bbe Author: Peter Zijlstra AuthorDate: Thu, 19 May 2016 12:30:19 +0200 Committer: Ingo Molnar CommitDate: Thu, 19 May 2016 14:19:30 +0200 perf: Update MAINTAINERS

Re: [patch V2 2/7] futex: Hash private futexes per process

On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote: > +struct futex_hash { > + struct raw_spinlock lock; raw_spinlock_t ? > + unsigned inthash_bits; > + struct futex_hash_bucket*hash; > +}; > +static void

Re: [patch V2 2/7] futex: Hash private futexes per process

On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote: > +struct futex_hash { > + struct raw_spinlock lock; raw_spinlock_t ? > + unsigned inthash_bits; > + struct futex_hash_bucket*hash; > +}; > +static void

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

> To be honest I don't know how the PHY LEDs could be set by LED triggers. > Wouldn't that require to create triggers for each value which can be written > to LEDxH and LEDxL? In my case the hardware requires some specific setting > due > to LED connections. Supporting all possibilities is

Re: [PATCH 1/1 RFC] net/phy: Add Lantiq PHY driver

> To be honest I don't know how the PHY LEDs could be set by LED triggers. > Wouldn't that require to create triggers for each value which can be written > to LEDxH and LEDxL? In my case the hardware requires some specific setting > due > to LED connections. Supporting all possibilities is

[PATCH v2] 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, fixed the bug pointed out by Eric. Posting since

[PATCH v2] 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, fixed the bug pointed out by Eric. Posting since several people

[GIT PULL] First batch of KVM changes for 4.7

r documentation purposes". ... Also, that caused conflicts with irqchip patches from the tip tree. They aren't particularly nasty, but I've placed my resolution anyway at refs/heads/merge-20160519 in the git://git.kernel.org/pub/

[GIT PULL] First batch of KVM changes for 4.7

r documentation purposes". ... Also, that caused conflicts with irqchip patches from the tip tree. They aren't particularly nasty, but I've placed my resolution anyway at refs/heads/merge-20160519 in the git://git.kernel.org/pub/

Re: [PATCH] mm: compact: fix zoneindex in compact

On 05/19/2016 02:11 PM, Vlastimil Babka wrote: > On 05/19/2016 01:58 PM, Chen Feng wrote: >> While testing the kcompactd in my platform 3G MEM only DMA ZONE. >> I found the kcompactd never wakeup. It seems the zoneindex >> has already minus 1 before. So the traverse here should be <=. > > Ouch,

Re: [PATCH] mm: compact: fix zoneindex in compact

On 05/19/2016 02:11 PM, Vlastimil Babka wrote: > On 05/19/2016 01:58 PM, Chen Feng wrote: >> While testing the kcompactd in my platform 3G MEM only DMA ZONE. >> I found the kcompactd never wakeup. It seems the zoneindex >> has already minus 1 before. So the traverse here should be <=. > > Ouch,

Re: [PATCH] mm: compact: fix zoneindex in compact

On 05/19/2016 01:58 PM, Chen Feng wrote: > While testing the kcompactd in my platform 3G MEM only DMA ZONE. > I found the kcompactd never wakeup. It seems the zoneindex > has already minus 1 before. So the traverse here should be <=. Ouch, thanks! > Signed-off-by: Chen Feng

Re: [PATCH] mm: compact: fix zoneindex in compact

On 05/19/2016 01:58 PM, Chen Feng wrote: > While testing the kcompactd in my platform 3G MEM only DMA ZONE. > I found the kcompactd never wakeup. It seems the zoneindex > has already minus 1 before. So the traverse here should be <=. Ouch, thanks! > Signed-off-by: Chen Feng Fixes: 0f87baf4f7fb

Re: [PATCH] ARM: lpc32xx: fix NR_IRQS confict

Hi Arnd, On Thu, 2016-05-19 at 13:04 +0300, Vladimir Zapolskiy wrote: > Hi Arnd, > > On 19.05.2016 11:35, Arnd Bergmann wrote: > > With the change to sparse IRQs, the lpc32xx platform gets a warning about > > conflicting macros: > > > > In file included from arch/arm/mach-lpc32xx/irq.c:31:0: >

Re: [PATCH] ARM: lpc32xx: fix NR_IRQS confict

Hi Arnd, On Thu, 2016-05-19 at 13:04 +0300, Vladimir Zapolskiy wrote: > Hi Arnd, > > On 19.05.2016 11:35, Arnd Bergmann wrote: > > With the change to sparse IRQs, the lpc32xx platform gets a warning about > > conflicting macros: > > > > In file included from arch/arm/mach-lpc32xx/irq.c:31:0: >

Re: [PATCH] amdgpu/uvd: use kmemdup

Am 19.05.2016 um 13:49 schrieb Muhammad Falak R Wani: On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote: Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani: Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed

Re: [PATCH] amdgpu/uvd: use kmemdup

Am 19.05.2016 um 13:49 schrieb Muhammad Falak R Wani: On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote: Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani: Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed

Re: perf probe -L on ubuntu 16.04

Em Thu, May 19, 2016 at 11:00:39AM +0900, Masami Hiramatsu escreveu: > On Mon, 16 May 2016 22:56:36 -0300 > Arnaldo Carvalho de Melo wrote: > > Have you ever tried using 'perf probe' on ubuntu? > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r) > >

Re: perf probe -L on ubuntu 16.04

Em Thu, May 19, 2016 at 11:00:39AM +0900, Masami Hiramatsu escreveu: > On Mon, 16 May 2016 22:56:36 -0300 > Arnaldo Carvalho de Melo wrote: > > Have you ever tried using 'perf probe' on ubuntu? > > acme@ubuntu:~/git/linux$ sudo apt-cache search linux-image-$(uname -r) > >

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

Thanks Stephen! Anna will be managing pushing the NFS client changes to Linus during this merge window, so I'm assuming she will include this and your other fixup in her pull request. Cheers Trond On Wed, May 18, 2016 at 8:58 PM, Stephen Rothwell wrote: > Hi Trond, > >

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

Thanks Stephen! Anna will be managing pushing the NFS client changes to Linus during this merge window, so I'm assuming she will include this and your other fixup in her pull request. Cheers Trond On Wed, May 18, 2016 at 8:58 PM, Stephen Rothwell wrote: > Hi Trond, > > After merging the nfs

Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

On Thu, 19 May 2016, Geert Uytterhoeven wrote: > > In file included from drivers/scsi/mac_scsi.c:335: > drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline > after being called > drivers/scsi/NCR5380.h:295: warning: previous declaration of > `NCR5380_poll_politely'

Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

On Thu, 19 May 2016, Geert Uytterhoeven wrote: > > In file included from drivers/scsi/mac_scsi.c:335: > drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline > after being called > drivers/scsi/NCR5380.h:295: warning: previous declaration of > `NCR5380_poll_politely'

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: >> Without calling the cpufreq hook for a remote wakeup it is possible >> for such a wakeup to go unnoticed by cpufreq on the target CPU

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: >> Without calling the cpufreq hook for a remote wakeup it is possible >> for such a wakeup to go unnoticed by cpufreq on the target CPU for up >> to a full tick. This can occur if

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

2016-05-19 19:56 GMT+08:00 Christian Borntraeger : > On 05/19/2016 01:48 PM, Wanpeng Li wrote: >> 2016-05-19 19:42 GMT+08:00 Christian Borntraeger : >>> On 05/19/2016 01:35 PM, Wanpeng Li wrote: 2016-05-19 19:23 GMT+08:00 Christian Borntraeger

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

2016-05-19 19:56 GMT+08:00 Christian Borntraeger : > On 05/19/2016 01:48 PM, Wanpeng Li wrote: >> 2016-05-19 19:42 GMT+08:00 Christian Borntraeger : >>> On 05/19/2016 01:35 PM, Wanpeng Li wrote: 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : > On 05/19/2016 11:26 AM, Wanpeng Li wrote:

Re: [PATCH net-next] tuntap: introduce tx skb ring

On Wed, 18 May 2016 19:26:38 +0300 "Michael S. Tsirkin" wrote: > On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote: > > I agree. It is sad to see everybody is implementing the same thing, > > open coding an array/circular based ring buffer. This kind of

Re: [PATCH net-next] tuntap: introduce tx skb ring

On Wed, 18 May 2016 19:26:38 +0300 "Michael S. Tsirkin" wrote: > On Wed, May 18, 2016 at 10:13:59AM +0200, Jesper Dangaard Brouer wrote: > > I agree. It is sad to see everybody is implementing the same thing, > > open coding an array/circular based ring buffer. This kind of code is > > hard to

[PATCH] mm: compact: fix zoneindex in compact

While testing the kcompactd in my platform 3G MEM only DMA ZONE. I found the kcompactd never wakeup. It seems the zoneindex has already minus 1 before. So the traverse here should be <=. Signed-off-by: Chen Feng --- mm/compaction.c | 2 +- 1 file changed, 1

[PATCH] mm: compact: fix zoneindex in compact

While testing the kcompactd in my platform 3G MEM only DMA ZONE. I found the kcompactd never wakeup. It seems the zoneindex has already minus 1 before. So the traverse here should be <=. Signed-off-by: Chen Feng --- mm/compaction.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

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

On 05/19/2016 01:48 PM, Wanpeng Li wrote: > 2016-05-19 19:42 GMT+08:00 Christian Borntraeger : >> On 05/19/2016 01:35 PM, Wanpeng Li wrote: >>> 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : On 05/19/2016 11:26 AM, Wanpeng Li wrote:

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

On 05/19/2016 01:48 PM, Wanpeng Li wrote: > 2016-05-19 19:42 GMT+08:00 Christian Borntraeger : >> On 05/19/2016 01:35 PM, Wanpeng Li wrote: >>> 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : On 05/19/2016 11:26 AM, Wanpeng Li wrote: I think in general a good idea to poll if a

[PATCH 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

From: Honghui Zhang Add the dtsi node of iommu and smi for mt2701. Signed-off-by: Honghui Zhang --- arch/arm/boot/dts/mt2701.dtsi | 51 +++ 1 file changed, 51 insertions(+) diff --git

[PATCH v2 3/5] memory/mediatek: add support for mt2701

From: Honghui Zhang Mediatek SMI has two generations of HW architecture, mt8173 uses the second generation of SMI HW while mt2701 uses the first generation HW of SMI. There's slight differences between the two generations, for generation 2, the register which control

[PATCH 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701

From: Honghui Zhang Add the dtsi node of iommu and smi for mt2701. Signed-off-by: Honghui Zhang --- arch/arm/boot/dts/mt2701.dtsi | 51 +++ 1 file changed, 51 insertions(+) diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi

[PATCH v2 3/5] memory/mediatek: add support for mt2701

From: Honghui Zhang Mediatek SMI has two generations of HW architecture, mt8173 uses the second generation of SMI HW while mt2701 uses the first generation HW of SMI. There's slight differences between the two generations, for generation 2, the register which control the iommu port access PA or

[PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW

From: Honghui Zhang Mediatek SoC's M4U has two generations of HW architcture. Generation one uses flat, one layer pagetable, and was shipped with ARM architecture, it only supports 4K size page mapping. MT2701 SoC uses this generation one m4u HW. Generation two uses

[PATCH v2 2/5] iommu/mediatek: move the common struct into header file

From: Honghui Zhang Move the struct defines of mtk iommu into a new header files for common use. Signed-off-by: Honghui Zhang --- drivers/iommu/mtk_iommu.c | 62 +--- drivers/iommu/mtk_iommu.h | 90

Re: [PATCH net V2] tuntap: correctly wake up process during uninit

On Thu, May 19, 2016 at 01:36:51PM +0800, Jason Wang wrote: > We used to check dev->reg_state against NETREG_REGISTERED after each > time we are woke up. But after commit 9e641bdcfa4e ("net-tun: > restructure tun_do_read for better sleep/wakeup efficiency"), it uses > skb_recv_datagram() which

[PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW

From: Honghui Zhang Mediatek SoC's M4U has two generations of HW architcture. Generation one uses flat, one layer pagetable, and was shipped with ARM architecture, it only supports 4K size page mapping. MT2701 SoC uses this generation one m4u HW. Generation two uses the ARM short-descriptor

[PATCH v2 2/5] iommu/mediatek: move the common struct into header file

From: Honghui Zhang Move the struct defines of mtk iommu into a new header files for common use. Signed-off-by: Honghui Zhang --- drivers/iommu/mtk_iommu.c | 62 +--- drivers/iommu/mtk_iommu.h | 90 +++ 2 files changed,

Re: [PATCH net V2] tuntap: correctly wake up process during uninit

On Thu, May 19, 2016 at 01:36:51PM +0800, Jason Wang wrote: > We used to check dev->reg_state against NETREG_REGISTERED after each > time we are woke up. But after commit 9e641bdcfa4e ("net-tun: > restructure tun_do_read for better sleep/wakeup efficiency"), it uses > skb_recv_datagram() which

[PATCH v2 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

From: Honghui Zhang This patch defines the local arbitor port IDs for mediatek SoC MT2701 and add descriptions of binding for mediatek generation one iommu and smi. Signed-off-by: Honghui Zhang ---

[PATCH v2 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi

From: Honghui Zhang This patch defines the local arbitor port IDs for mediatek SoC MT2701 and add descriptions of binding for mediatek generation one iommu and smi. Signed-off-by: Honghui Zhang --- .../devicetree/bindings/iommu/mediatek,iommu.txt | 13 +++-

[PATCH v2 0/5] MT2701 iommu support

From: Honghui Zhang Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart Multimedia Interface)have two generations HW. They basically sharing the same hardware block diagram, but have some difference as below: Generation one m4u only supports one

[PATCH v4 5/6] perf callchain: Support x86 target platform

Support x86(32-bit) cross platform callchain unwind. Signed-off-by: He Kuang --- tools/perf/arch/x86/include/libunwind/libunwind-arch.h | 18 ++ tools/perf/arch/x86/util/unwind-libunwind.c| 12 +--- tools/perf/util/Build

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

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 x86(64-bit) machine. This patch shows proper error messages when we do remote unwind

Re: [PATCH] amdgpu/uvd: use kmemdup

On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote: > Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani: > >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. > > >

[PATCH v2 0/5] MT2701 iommu support

From: Honghui Zhang Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart Multimedia Interface)have two generations HW. They basically sharing the same hardware block diagram, but have some difference as below: Generation one m4u only supports one layer, flat pagetable addressing,

[PATCH v4 5/6] perf callchain: Support x86 target platform

Support x86(32-bit) cross platform callchain unwind. Signed-off-by: He Kuang --- tools/perf/arch/x86/include/libunwind/libunwind-arch.h | 18 ++ tools/perf/arch/x86/util/unwind-libunwind.c| 12 +--- tools/perf/util/Build | 6

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

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 x86(64-bit) machine. This patch shows proper error messages when we do remote unwind

Re: [PATCH] amdgpu/uvd: use kmemdup

On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote: > Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani: > >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. > > >

[PATCH v4 3/6] perf tools: Separate local and remote unwind support detection

This patch changes original CONFIG_LIBUNWIND/NO_LIBUNWIND to CONFIG_LOCAL_LIBUNWIND/NO_LOCAL_LIBUNWIND for retaining local unwind features. CONFIG_LIBUNWIND stands for either local or remote or both unwind are supported and NO_LIBUNWIND means neither local nor remote libunwind are supported.

[PATCH v4 3/6] perf tools: Separate local and remote unwind support detection

This patch changes original CONFIG_LIBUNWIND/NO_LIBUNWIND to CONFIG_LOCAL_LIBUNWIND/NO_LOCAL_LIBUNWIND for retaining local unwind features. CONFIG_LIBUNWIND stands for either local or remote or both unwind are supported and NO_LIBUNWIND means neither local nor remote libunwind are supported.

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

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 | 5 +++--

[PATCH v4 4/6] perf callchain: Add support for cross-platform unwind

Use thread specific unwind ops to unwind cross-platform callchains. Before this patch, unwind methods is suitable for local unwind, this patch changes the fixed methods to thread/map related. Each time a map is inserted, we find the target arch and see if this platform can be remote unwind. In

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

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 | 5 +++-- tools/perf/builtin-diff.c

[PATCH v4 4/6] perf callchain: Add support for cross-platform unwind

Use thread specific unwind ops to unwind cross-platform callchains. Before this patch, unwind methods is suitable for local unwind, this patch changes the fixed methods to thread/map related. Each time a map is inserted, we find the target arch and see if this platform can be remote unwind. In

[PATCH v4 0/6] Add support for remote unwind

v3 url: http://thread.gmane.org/gmane.linux.kernel/2220387 Currently, perf script uses host unwind methods(local unwind) to parse perf.data callchain info regardless of the target architecture. So we get wrong result and no promotion when do remote unwind on other platforms/machines. This

[PATCH v4 6/6] perf callchain: Support aarch64 cross-platform

Support aarch64 cross platform callchain unwind. Signed-off-by: He Kuang --- .../perf/arch/arm64/include/libunwind/libunwind-arch.h | 18 ++ tools/perf/arch/arm64/util/unwind-libunwind.c | 5 - tools/perf/config/Makefile

[PATCH v4 6/6] perf callchain: Support aarch64 cross-platform

Support aarch64 cross platform callchain unwind. Signed-off-by: He Kuang --- .../perf/arch/arm64/include/libunwind/libunwind-arch.h | 18 ++ tools/perf/arch/arm64/util/unwind-libunwind.c | 5 - tools/perf/config/Makefile | 12

[PATCH v4 0/6] Add support for remote unwind

v3 url: http://thread.gmane.org/gmane.linux.kernel/2220387 Currently, perf script uses host unwind methods(local unwind) to parse perf.data callchain info regardless of the target architecture. So we get wrong result and no promotion when do remote unwind on other platforms/machines. This

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

2016-05-19 19:42 GMT+08:00 Christian Borntraeger : > On 05/19/2016 01:35 PM, Wanpeng Li wrote: >> 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : >>> On 05/19/2016 11:26 AM, Wanpeng Li wrote: >>> >>> I think in general a good idea to poll if a

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

2016-05-19 19:42 GMT+08:00 Christian Borntraeger : > On 05/19/2016 01:35 PM, Wanpeng Li wrote: >> 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : >>> On 05/19/2016 11:26 AM, Wanpeng Li wrote: >>> >>> I think in general a good idea to poll if a timer will expire soon. >>> >>> Some patch

Re: [PATCH] udf: Check for IS_ERR in udf_get_pblock_meta25

On Wed 18-05-16 10:35:31, Laura Abbott wrote: > udf_find_metadata_inode_efe returns an error pointer, not just > NULL. Check the return with IS_ERR appropriately. > > Signed-off-by: Laura Abbott > --- > Came out of https://bugzilla.redhat.com/show_bug.cgi?id=1301295, I

Re: [PATCH] udf: Check for IS_ERR in udf_get_pblock_meta25

On Wed 18-05-16 10:35:31, Laura Abbott wrote: > udf_find_metadata_inode_efe returns an error pointer, not just > NULL. Check the return with IS_ERR appropriately. > > Signed-off-by: Laura Abbott > --- > Came out of https://bugzilla.redhat.com/show_bug.cgi?id=1301295, I never > heard back from

защита на системата

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

защита на системата

Паролата ви ще изтече в следващите 24 часа, за да се избегне това кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш Е-поща и получи нова поща. Благодаря Системен администратор. © 2016 Всички права запазени.

Re: [RFC PATCH 1/2] Input: rotary-encoder- Add support for absolute encoder

Hi, On 05/19/2016 04:55 PM, Krzysztof Kozlowski wrote: [...] > On 05/19/2016 11:04 AM, Vignesh R wrote: >> diff --git a/drivers/input/misc/rotary_encoder.c >> b/drivers/input/misc/rotary_encoder.c >> index c7fc8d4fb080..8f60289fb6cd 100644 >> --- a/drivers/input/misc/rotary_encoder.c >> +++

Re: [RFC PATCH 1/2] Input: rotary-encoder- Add support for absolute encoder

Hi, On 05/19/2016 04:55 PM, Krzysztof Kozlowski wrote: [...] > On 05/19/2016 11:04 AM, Vignesh R wrote: >> diff --git a/drivers/input/misc/rotary_encoder.c >> b/drivers/input/misc/rotary_encoder.c >> index c7fc8d4fb080..8f60289fb6cd 100644 >> --- a/drivers/input/misc/rotary_encoder.c >> +++

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

在 2016/5/19 19:04, Robin Murphy 写道: On 19/05/16 03:44, x00195127 wrote: we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

在 2016/5/19 19:04, Robin Murphy 写道: On 19/05/16 03:44, x00195127 wrote: we find that some apps will read cpuinfo when start up, they need the string as follows: "Processor : AArch64 Processor rev 0 (aarch64)" Then thay could load the corresponding libs. But now arm64 platform's

Re: [PATCH 5/6] cpufreq: Reuse gov_attr_* macros in schedutil governor

On Thu, May 19, 2016 at 4:13 AM, Viresh Kumar wrote: > On 18-05-16, 23:01, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar >> wrote: >> > These macros can be used by governors which don't use the common >> > governor

Re: [PATCH 5/6] cpufreq: Reuse gov_attr_* macros in schedutil governor

On Thu, May 19, 2016 at 4:13 AM, Viresh Kumar wrote: > On 18-05-16, 23:01, Rafael J. Wysocki wrote: >> On Wed, May 18, 2016 at 2:25 PM, Viresh Kumar >> wrote: >> > These macros can be used by governors which don't use the common >> > governor code present in cpufreq_governor.c and should be

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

On 05/19/2016 01:35 PM, Wanpeng Li wrote: > 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : >> On 05/19/2016 11:26 AM, Wanpeng Li wrote: >> >> I think in general a good idea to poll if a timer will expire soon. >> >> Some patch comments: >> >> Same for all non-x86 archs:

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

On 05/19/2016 01:35 PM, Wanpeng Li wrote: > 2016-05-19 19:23 GMT+08:00 Christian Borntraeger : >> On 05/19/2016 11:26 AM, Wanpeng Li wrote: >> >> I think in general a good idea to poll if a timer will expire soon. >> >> Some patch comments: >> >> Same for all non-x86 archs: >>> +static inline

Re: [PATCHv6 2/8] dma-debug: add support for resource mappings

On 19/05/16 12:21, Niklas Söderlund wrote: Hi Konrad, Thanks for your feedback. On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote: +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size, + int direction, dma_addr_t dma_addr) +{ +

Re: [PATCHv6 2/8] dma-debug: add support for resource mappings

On 19/05/16 12:21, Niklas Söderlund wrote: Hi Konrad, Thanks for your feedback. On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote: +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size, + int direction, dma_addr_t dma_addr) +{ +

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, I guess (from the error code) this is to do with your patch not having short one line subject before the detailed explanation of what your patch does. The automated script might be treating your patch detailed description as subject line. More can be found in the patch submitting guideline.

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

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 done with this patch. > > > > In

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, I guess (from the error code) this is to do with your patch not having short one line subject before the detailed explanation of what your patch does. The automated script might be treating your patch detailed description as subject line. More can be found in the patch submitting guideline.

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

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 done with this patch. > > > > In POWER8 there is a regression

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

2016-05-19 19:23 GMT+08:00 Christian Borntraeger : > On 05/19/2016 11:26 AM, Wanpeng Li wrote: > > I think in general a good idea to poll if a timer will expire soon. > > Some patch comments: > > Same for all non-x86 archs: >> +static inline unsigned int

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

2016-05-19 19:23 GMT+08:00 Christian Borntraeger : > On 05/19/2016 11:26 AM, Wanpeng Li wrote: > > I think in general a good idea to poll if a timer will expire soon. > > Some patch comments: > > Same for all non-x86 archs: >> +static inline unsigned int kvm_arch_timer_remaining(struct kvm_vcpu

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

On Thu, May 19, 2016 at 01:31:16PM +0200, Peter Zijlstra wrote: > Where the __special_marker__ marks the whole { } scope as being the > inside of LL/SC and all variables must be in registers before we start. > If the compiler is not able to guarantee this, it must generate a > compile time error

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

On Thu, May 19, 2016 at 01:31:16PM +0200, Peter Zijlstra wrote: > Where the __special_marker__ marks the whole { } scope as being the > inside of LL/SC and all variables must be in registers before we start. > If the compiler is not able to guarantee this, it must generate a > compile time error

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: Hi On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17, 2016 at 6:59 PM, Shawn Lin wrote: Could you try this patch to see

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

Hi, On 2016/5/19 1:37, Doug Anderson wrote: Hi, On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: Hi On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17, 2016 at 6:59 PM, Shawn Lin wrote: Could you try this patch to see if you can still find HLE? @@ -2356,12 +2356,22 @@

<    5   6   7   8   9   10   11   12   13   14   >