[PATCH v2 4/4] mailbox: mailbox-test: add support for separate tx/rx buffer with single channel

This patch adds support for different MMIO region for Tx and Rx paths. If only one region is specified, it's assumed to be shared between Rx and Tx, thereby retaining backward compatibility. Also in order to support single channel dealing with both Tx and Rx with dedicated MMIO regions, Tx

[PATCH v2 4/4] mailbox: mailbox-test: add support for separate tx/rx buffer with single channel

This patch adds support for different MMIO region for Tx and Rx paths. If only one region is specified, it's assumed to be shared between Rx and Tx, thereby retaining backward compatibility. Also in order to support single channel dealing with both Tx and Rx with dedicated MMIO regions, Tx

[PATCH v2 0/4] mailbox: mailbox-test: support single channel with separate Tx and Rx buffer

Hi Jassi, Assuming mailbox-test was designed to be generic, I am trying to extend it to support single channel with separate Tx and Rx buffer. With these changes I am able to test arm_mhu driver. However I couldn't understand the intention of converting buffer to ASCII hex dump in read method. I

[PATCH v2 0/4] mailbox: mailbox-test: support single channel with separate Tx and Rx buffer

Hi Jassi, Assuming mailbox-test was designed to be generic, I am trying to extend it to support single channel with separate Tx and Rx buffer. With these changes I am able to test arm_mhu driver. However I couldn't understand the intention of converting buffer to ASCII hex dump in read method. I

Re: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

On Fri, Feb 19, 2016 at 03:00:29PM +, Marc Zyngier wrote: > Moving an SPI around doesn't require any extra work from the rest > of the stack, and specially not for MSI-generated SPIs. > > It is then worth returning IRQ_SET_MASK_OK_DONE instead of > IRQ_SET_MASK_OK, and simplify the other

Re: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

On Fri, Feb 19, 2016 at 03:00:29PM +, Marc Zyngier wrote: > Moving an SPI around doesn't require any extra work from the rest > of the stack, and specially not for MSI-generated SPIs. > > It is then worth returning IRQ_SET_MASK_OK_DONE instead of > IRQ_SET_MASK_OK, and simplify the other

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:34:43PM +0100, Thomas Petazzoni wrote: > This commits adds a new irqchip driver that handles the ODMI > controller found on Marvell 7K/8K processors. The ODMI controller > provide MSI interrupt functionality to on-board peripherals, much like > the GIC-v2m. > >

Re: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

On Fri, Feb 19, 2016 at 02:34:43PM +0100, Thomas Petazzoni wrote: > This commits adds a new irqchip driver that handles the ODMI > controller found on Marvell 7K/8K processors. The ODMI controller > provide MSI interrupt functionality to on-board peripherals, much like > the GIC-v2m. > >

Re: [PATCH v2 02/14] KVM: x86: simplify atomics in kvm_pit_ack_irq

On 19/02/2016 16:51, Radim Krčmář wrote: > The end result is going to be identical. I had a version that did > something similar and it was pretty tangled as well -- I wanted to > remove useless locks before re-using one for the ioctls. > (We need the protection earlier, because userspace can

Re: [PATCH v2 02/14] KVM: x86: simplify atomics in kvm_pit_ack_irq

On 19/02/2016 16:51, Radim Krčmář wrote: > The end result is going to be identical. I had a version that did > something similar and it was pretty tangled as well -- I wanted to > remove useless locks before re-using one for the ioctls. > (We need the protection earlier, because userspace can

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

On 19/02/2016 15:12, Marcelo Tosatti wrote: > >> > I need to check how often the timekeeper updates the parameters. > I'd assume once every tick, the function is called (the notifier). > > But you can optimize that away by only updating the TSC frequency > when mult/shift are updated, which

Re: [PATCH 4/4] KVM: x86: track actual TSC frequency from the timekeeper struct

On 19/02/2016 15:12, Marcelo Tosatti wrote: > >> > I need to check how often the timekeeper updates the parameters. > I'd assume once every tick, the function is called (the notifier). > > But you can optimize that away by only updating the TSC frequency > when mult/shift are updated, which

Re: [PATCH 0/7] Runtime PM support for AHCI host controller driver

On Thu, Feb 18, 2016 at 10:54:10AM +0200, Mika Westerberg wrote: > Linux already supports runtime PM of disks (drivers/scsi/sd.c) so that > after certain amount of idle time the disk is suspended automatically. This > series extends the support to AHCI host controllers. Whenever SATA ports > are

Re: [PATCH 0/7] Runtime PM support for AHCI host controller driver

On Thu, Feb 18, 2016 at 10:54:10AM +0200, Mika Westerberg wrote: > Linux already supports runtime PM of disks (drivers/scsi/sd.c) so that > after certain amount of idle time the disk is suspended automatically. This > series extends the support to AHCI host controllers. Whenever SATA ports > are

Re: [PATCH v2 02/14] KVM: x86: simplify atomics in kvm_pit_ack_irq

2016-02-18 19:04+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: >> -value = atomic_dec_return(>pending); >> -if (value < 0) >> -/* spurious acks can be generated if, for example, the >> - * PIC is being reset. Handle it gracefully here >> -

Re: [PATCH v2 02/14] KVM: x86: simplify atomics in kvm_pit_ack_irq

2016-02-18 19:04+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: >> -value = atomic_dec_return(>pending); >> -if (value < 0) >> -/* spurious acks can be generated if, for example, the >> - * PIC is being reset. Handle it gracefully here >> -

Re: [PATCH v1 1/4] net: ti: netcp: restore get/set_pad_info() functionality

On 02/19/2016 09:41 AM, Arnd Bergmann wrote: > On Thursday 18 February 2016 14:46:14 Murali Karicheri wrote: >> From: Arnd Bergmann >> >> The commit 899077791403 ("netcp: try to reduce type confusion in >> descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks >>

Re: [PATCH v1 1/4] net: ti: netcp: restore get/set_pad_info() functionality

On 02/19/2016 09:41 AM, Arnd Bergmann wrote: > On Thursday 18 February 2016 14:46:14 Murali Karicheri wrote: >> From: Arnd Bergmann >> >> The commit 899077791403 ("netcp: try to reduce type confusion in >> descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks >> get/set_pad_info()

Re: [PATCH v3 05/10] serial: mps2-uart: add support for early console

On 02/19/2016 01:57 AM, Andy Shevchenko wrote: > On Fri, Feb 19, 2016 at 11:45 AM, Vladimir Murzin > wrote: >> On 16/02/16 13:09, Vladimir Murzin wrote: > +EARLYCON_DECLARE(mps2, mps2_early_console_setup); >>> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart",

Re: [PATCH v3 05/10] serial: mps2-uart: add support for early console

On 02/19/2016 01:57 AM, Andy Shevchenko wrote: > On Fri, Feb 19, 2016 at 11:45 AM, Vladimir Murzin > wrote: >> On 16/02/16 13:09, Vladimir Murzin wrote: > +EARLYCON_DECLARE(mps2, mps2_early_console_setup); >>> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup); >

Re: [PATCH v1 8/8] mm: kasan: Initial memory quarantine implementation

On Fri, 19 Feb 2016, Dmitry Vyukov wrote: > No, this does not work. We've tried. > The problem is fragmentation. When all memory is occupied by slab, > it's already too late to reclaim memory. Free objects are randomly > scattered over memory, so if you have just 1% of live objects, the > chances

Re: [PATCH v1 8/8] mm: kasan: Initial memory quarantine implementation

On Fri, 19 Feb 2016, Dmitry Vyukov wrote: > No, this does not work. We've tried. > The problem is fragmentation. When all memory is occupied by slab, > it's already too late to reclaim memory. Free objects are randomly > scattered over memory, so if you have just 1% of live objects, the > chances

[GIT PULL] s390 patches for 4.5-rc5

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Several bug fixes * There are four different stack tracers, and three of them have bugs. For 4.5 the bugs are fix and we

[GIT PULL] s390 patches for 4.5-rc5

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Several bug fixes * There are four different stack tracers, and three of them have bugs. For 4.5 the bugs are fix and we

Re: [PATCH] xen/blback: Fit the important information of the thread in 17 characters

El 17/2/16 a les 17:31, Konrad Rzeszutek Wilk ha escrit: > The processes names are truncated to 17, while we had the length > of the process as name 20 - which meant that while we filled > it out with various details - the last 3 characters (which had > the queue number) never surfaced to the

Re: [PATCH] xen/blback: Fit the important information of the thread in 17 characters

El 17/2/16 a les 17:31, Konrad Rzeszutek Wilk ha escrit: > The processes names are truncated to 17, while we had the length > of the process as name 20 - which meant that while we filled > it out with various details - the last 3 characters (which had > the queue number) never surfaced to the

Re: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On Friday 19 February 2016 14:29:00 Chris Brandt wrote: > On 19 Feb 2016, Arnd Bergmann wrote: > > > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > > > Acked-by: Nicolas Pitre > > > > > > Is there a way to provide a default for defaults? > > > > We could

Re: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On Friday 19 February 2016 14:29:00 Chris Brandt wrote: > On 19 Feb 2016, Arnd Bergmann wrote: > > > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote: > > > > > > Acked-by: Nicolas Pitre > > > > > > Is there a way to provide a default for defaults? > > > > We could have something

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On 19 February 2016 at 05:09, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > arch/x86/mm/extable.c > > between commit: > > 548acf19234d ("x86/mm: Expand the exception table logic to allow new > handling

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On 19 February 2016 at 05:09, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > arch/x86/mm/extable.c > > between commit: > > 548acf19234d ("x86/mm: Expand the exception table logic to allow new > handling options") > > from the

[PATCH v3 5/7] ARM: dts: alpine: add the MSIX node

With the newly available MSIX driver for Alpine, add the corresponding node in the Alpine device tree. Signed-off-by: Antoine Tenart --- arch/arm/boot/dts/alpine.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/alpine.dtsi

[PATCH v3 5/7] ARM: dts: alpine: add the MSIX node

With the newly available MSIX driver for Alpine, add the corresponding node in the Alpine device tree. Signed-off-by: Antoine Tenart --- arch/arm/boot/dts/alpine.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi

[PATCH v3 4/7] arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi

Following the addition of the Alpine MSIX controller driver, add the corresponding node in the Alpine v2 device tree. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm64/boot/dts/al/alpine-v2.dtsi | 10

[PATCH v3 7/7] arm: alpine: select the Alpine MSI controller driver

Select the Alpine MSI controller driver when using an Alpine platform. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm/mach-alpine/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH 00/29] tracing: 'hist' triggers

Hi Masami, On Wed, 2016-02-17 at 02:57 +, 平松雅巳 / HIRAMATU，MASAMI wrote: > Hi Tom, > > Just a note that I've tested by my test scripts. > I'll try to add a test case for Namhyung's extension. > Thanks, much appreciated! Tom > Thanks, > > >From: Tom Zanussi

[PATCH v3 4/7] arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi

Following the addition of the Alpine MSIX controller driver, add the corresponding node in the Alpine v2 device tree. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm64/boot/dts/al/alpine-v2.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v3 7/7] arm: alpine: select the Alpine MSI controller driver

Select the Alpine MSI controller driver when using an Alpine platform. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm/mach-alpine/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-alpine/Kconfig b/arch/arm/mach-alpine/Kconfig index

Re: [PATCH 00/29] tracing: 'hist' triggers

Hi Masami, On Wed, 2016-02-17 at 02:57 +, 平松雅巳 / HIRAMATU，MASAMI wrote: > Hi Tom, > > Just a note that I've tested by my test scripts. > I'll try to add a test case for Namhyung's extension. > Thanks, much appreciated! Tom > Thanks, > > >From: Tom Zanussi

[PATCH v3 6/7] arm64: alpine: select the Alpine MSI controller driver

Select the Alpine MSI controller driver when using an Alpine platform. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v3 3/7] Documentation: bindings: document the Alpine MSIX driver

Following the addition of the Alpine MSIX driver, this patch adds the corresponding bindings documentation. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- .../interrupt-controller/al,alpine-msix.txt| 26

[PATCH v3 6/7] arm64: alpine: select the Alpine MSI controller driver

Select the Alpine MSI controller driver when using an Alpine platform. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index

[PATCH v3 3/7] Documentation: bindings: document the Alpine MSIX driver

Following the addition of the Alpine MSIX driver, this patch adds the corresponding bindings documentation. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg --- .../interrupt-controller/al,alpine-msix.txt| 26 ++ 1 file changed, 26 insertions(+) create

Re: [PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory()

On 02/19/2016 02:42 AM, Aleksey Makarov wrote: > Hi Peter, > > Thank you for review. > > On 02/19/2016 01:03 AM, Peter Hurley wrote: >> On 02/17/2016 07:36 PM, Zheng, Lv wrote: >>> Hi, >>> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org] Subject: Re: [PATCH v3 1/5] ACPI:

Re: [PATCH v3 1/5] ACPI: change __init to __ref for early_acpi_os_unmap_memory()

On 02/19/2016 02:42 AM, Aleksey Makarov wrote: > Hi Peter, > > Thank you for review. > > On 02/19/2016 01:03 AM, Peter Hurley wrote: >> On 02/17/2016 07:36 PM, Zheng, Lv wrote: >>> Hi, >>> From: Aleksey Makarov [mailto:aleksey.maka...@linaro.org] Subject: Re: [PATCH v3 1/5] ACPI:

[PATCH v3 0/7] irqchip: introduce the Alpine MSIX driver

Hi all, This series introduce the Alpine MSIX driver, and enables it in both the Alpine v1 and Alpine v2 device trees. This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support": https://lkml.org/lkml/2016/2/10/83 You can find the series at: https://github.com/atenart/linux.git

[PATCH v3 0/7] irqchip: introduce the Alpine MSIX driver

Hi all, This series introduce the Alpine MSIX driver, and enables it in both the Alpine v1 and Alpine v2 device trees. This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support": https://lkml.org/lkml/2016/2/10/83 You can find the series at: https://github.com/atenart/linux.git

[PATCH v3 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity

Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the affinity has been updated. When using stacked irqchips, returning IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips. Signed-off-by: Antoine Tenart Acked-by: Marc Zyngier

[PATCH v3 2/7] irqchip: add the Alpine MSIX interrupt controller

This patch adds the Alpine MSIX interrupt controller driver. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg Acked-by: Marc Zyngier --- drivers/irqchip/Kconfig | 6 +

[PATCH v3 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity

Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the affinity has been updated. When using stacked irqchips, returning IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips. Signed-off-by: Antoine Tenart Acked-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 2 +- 1

[PATCH v3 2/7] irqchip: add the Alpine MSIX interrupt controller

This patch adds the Alpine MSIX interrupt controller driver. Signed-off-by: Antoine Tenart Signed-off-by: Tsahee Zidenberg Acked-by: Marc Zyngier --- drivers/irqchip/Kconfig | 6 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-alpine-msi.c | 293

Re: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

Marc, On Fri, 19 Feb 2016 15:00:29 +, Marc Zyngier wrote: > Moving an SPI around doesn't require any extra work from the rest > of the stack, and specially not for MSI-generated SPIs. > > It is then worth returning IRQ_SET_MASK_OK_DONE instead of > IRQ_SET_MASK_OK, and simplify the other

Re: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

Marc, On Fri, 19 Feb 2016 15:00:29 +, Marc Zyngier wrote: > Moving an SPI around doesn't require any extra work from the rest > of the stack, and specially not for MSI-generated SPIs. > > It is then worth returning IRQ_SET_MASK_OK_DONE instead of > IRQ_SET_MASK_OK, and simplify the other

Re: [RFC v2 1/6] x86/boot: add BIT() to boot/bitops.h

On 02/19/2016 09:15 AM, Luis R. Rodriguez wrote: diff --git a/arch/x86/boot/bitops.h b/arch/x86/boot/bitops.h index 878e4b9940d9..232cff0ff4e3 100644 --- a/arch/x86/boot/bitops.h +++ b/arch/x86/boot/bitops.h @@ -40,4 +40,6 @@ static inline void set_bit(int nr, void *addr) asm("btsl

Re: [RFC v2 1/6] x86/boot: add BIT() to boot/bitops.h

On 02/19/2016 09:15 AM, Luis R. Rodriguez wrote: diff --git a/arch/x86/boot/bitops.h b/arch/x86/boot/bitops.h index 878e4b9940d9..232cff0ff4e3 100644 --- a/arch/x86/boot/bitops.h +++ b/arch/x86/boot/bitops.h @@ -40,4 +40,6 @@ static inline void set_bit(int nr, void *addr) asm("btsl

Re: [PATCH 12/55] perf tools: Enable config raw and numeric events

Em Fri, Feb 19, 2016 at 12:08:47PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Feb 19, 2016 at 11:44:00AM +, Wang Nan escreveu: > > This patch allows setting config terms for raw and numeric events. > > For example: > > > > # perf stat -e cycles/name=cyc/ ls > > ... > > 1821108

Re: [PATCH 12/55] perf tools: Enable config raw and numeric events

Em Fri, Feb 19, 2016 at 12:08:47PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, Feb 19, 2016 at 11:44:00AM +, Wang Nan escreveu: > > This patch allows setting config terms for raw and numeric events. > > For example: > > > > # perf stat -e cycles/name=cyc/ ls > > ... > > 1821108

Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.

On Sat 20-02-16 00:07:05, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 18-02-16 13:08:49, Michal Hocko wrote: > > > I guess we can safely remove the memcg > > > argument from oom_badness and oom_unkillable_task. At least from a quick > > > glance... > > > > No we cannot actually.

Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.

On Sat 20-02-16 00:07:05, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 18-02-16 13:08:49, Michal Hocko wrote: > > > I guess we can safely remove the memcg > > > argument from oom_badness and oom_unkillable_task. At least from a quick > > > glance... > > > > No we cannot actually.

Re: [PATCH 0/7] Runtime PM support for AHCI host controller driver

On 02/18/2016 09:40 AM, Tejun Heo wrote: Hello, Patchset looks good to me. Once Jens acks the first patch, I'll apply the whole series to libata/for-4.6 w/ the field initialization updated. You can add my acked-by to that one, looks good to me. -- Jens Axboe

Re: [PATCH 0/7] Runtime PM support for AHCI host controller driver

On 02/18/2016 09:40 AM, Tejun Heo wrote: Hello, Patchset looks good to me. Once Jens acks the first patch, I'll apply the whole series to libata/for-4.6 w/ the field initialization updated. You can add my acked-by to that one, looks good to me. -- Jens Axboe

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

2016-02-19 16:06+0100, Paolo Bonzini: > On 19/02/2016 16:04, Radim Krčmář wrote: ... so in patch 7 concurrent _writes_ of reinject are protected by the lock, but reads are done outside it (in pit_timer_fn). WDYT about making reinject an atomic_t? >> There was/is no harm in having

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

2016-02-19 16:06+0100, Paolo Bonzini: > On 19/02/2016 16:04, Radim Krčmář wrote: ... so in patch 7 concurrent _writes_ of reinject are protected by the lock, but reads are done outside it (in pit_timer_fn). WDYT about making reinject an atomic_t? >> There was/is no harm in having

Re: [PATCH 12/55] perf tools: Enable config raw and numeric events

Em Fri, Feb 19, 2016 at 11:44:00AM +, Wang Nan escreveu: > This patch allows setting config terms for raw and numeric events. > For example: > > # perf stat -e cycles/name=cyc/ ls > ... > 1821108 cyc > ... > > # perf stat -e r6530160/name=event/ ls > ... > 1103195 event >

Re: [PATCH 12/55] perf tools: Enable config raw and numeric events

Em Fri, Feb 19, 2016 at 11:44:00AM +, Wang Nan escreveu: > This patch allows setting config terms for raw and numeric events. > For example: > > # perf stat -e cycles/name=cyc/ ls > ... > 1821108 cyc > ... > > # perf stat -e r6530160/name=event/ ls > ... > 1103195 event >

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On 02/19/2016 08:08 AM, Luis R. Rodriguez wrote: There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the

Re: [PATCH 5/9] apm32: remove paravirt_enabled() use

On 02/19/2016 08:08 AM, Luis R. Rodriguez wrote: There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the

Re: [RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

Hi, On Tue, Feb 16, 2016 at 5:32 PM, Nicolas Boichat wrote: > From: Lisa Du > > There's one point was missed in the patch commit da49889deb34 ("staging: > binder: Support concurrent 32 bit and 64 bit processes."). When configure > BINDER_IPC_32BIT, the

Re: [RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

Hi, On Tue, Feb 16, 2016 at 5:32 PM, Nicolas Boichat wrote: > From: Lisa Du > > There's one point was missed in the patch commit da49889deb34 ("staging: > binder: Support concurrent 32 bit and 64 bit processes."). When configure > BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but

Re: [PATCH 10/55] perf stat: Forbid user passing improper config terms

Em Fri, Feb 19, 2016 at 11:43:58AM +, Wang Nan escreveu: > 'perf stat' accepts some config terms but doesn't apply them. For > example: > > # perf stat -e 'instructions/no-inherit/' -e 'instructions/inherit/' bash > # ls > # exit This seems to do the trick, but I wonder if we couldn't

Re: [PATCH] b43: fix memory leak

On Friday 19 February 2016 01:14 PM, Kalle Valo wrote: Michael Büsch writes: On Thu, 18 Feb 2016 18:04:36 +0530 Sudip Mukherjee wrote: From: Sudip Mukherjee On error we jumped to the label bcma_out and returned the error

Re: [PATCH 10/55] perf stat: Forbid user passing improper config terms

Em Fri, Feb 19, 2016 at 11:43:58AM +, Wang Nan escreveu: > 'perf stat' accepts some config terms but doesn't apply them. For > example: > > # perf stat -e 'instructions/no-inherit/' -e 'instructions/inherit/' bash > # ls > # exit This seems to do the trick, but I wonder if we couldn't

Re: [PATCH] b43: fix memory leak

On Friday 19 February 2016 01:14 PM, Kalle Valo wrote: Michael Büsch writes: On Thu, 18 Feb 2016 18:04:36 +0530 Sudip Mukherjee wrote: From: Sudip Mukherjee On error we jumped to the label bcma_out and returned the error code but we missed freeing dev. Signed-off-by: Sudip Mukherjee

Re: [tpmdd-devel] [PATCH] tpm_crb: fix bad name pointer usage with struct resource

On Thu, Feb 18, 2016 at 10:31:40AM -0700, Jason Gunthorpe wrote: > On Wed, Feb 17, 2016 at 04:20:16PM +0200, Jarkko Sakkinen wrote: > > Maybe for the release the safest bet would be anyway explicitly not > > use the name field? That's the safest bet given the release time > > frame. > > nulling

Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.

Michal Hocko wrote: > On Thu 18-02-16 13:08:49, Michal Hocko wrote: > > I guess we can safely remove the memcg > > argument from oom_badness and oom_unkillable_task. At least from a quick > > glance... > > No we cannot actually. oom_kill_process could select a child which is in > a different

Re: [tpmdd-devel] [PATCH] tpm_crb: fix bad name pointer usage with struct resource

On Thu, Feb 18, 2016 at 10:31:40AM -0700, Jason Gunthorpe wrote: > On Wed, Feb 17, 2016 at 04:20:16PM +0200, Jarkko Sakkinen wrote: > > Maybe for the release the safest bet would be anyway explicitly not > > use the name field? That's the safest bet given the release time > > frame. > > nulling

Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.

Michal Hocko wrote: > On Thu 18-02-16 13:08:49, Michal Hocko wrote: > > I guess we can safely remove the memcg > > argument from oom_badness and oom_unkillable_task. At least from a quick > > glance... > > No we cannot actually. oom_kill_process could select a child which is in > a different

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

On 19/02/2016 16:04, Radim Krčmář wrote: >> > >> > ... so in patch 7 concurrent _writes_ of reinject are protected by the >> > lock, but reads are done outside it (in pit_timer_fn). WDYT about >> > making reinject an atomic_t? > There was/is no harm in having reinject non-atomic. This patch

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

On 19/02/2016 16:04, Radim Krčmář wrote: >> > >> > ... so in patch 7 concurrent _writes_ of reinject are protected by the >> > lock, but reads are done outside it (in pit_timer_fn). WDYT about >> > making reinject an atomic_t? > There was/is no harm in having reinject non-atomic. This patch

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hello, I've applied the patchset to 4.5-rc4 and I'm now encountering two additional problems. The first related to debugfs entries, the second cocerning RCU locking. Here are the debugfs lines: exynos-bus bus_dmc: device_opp_debug_create_link: Failed to create link exynos-bus bus_dmc:

Re: [PATCH v4 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hello, I've applied the patchset to 4.5-rc4 and I'm now encountering two additional problems. The first related to debugfs entries, the second cocerning RCU locking. Here are the debugfs lines: exynos-bus bus_dmc: device_opp_debug_create_link: Failed to create link exynos-bus bus_dmc:

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

2016-02-18 19:08+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: >> +/* pit->pit_state.lock was overloaded to prevent userspace from getting >> + * an inconsistent state after running multiple KVM_REINJECT_CONTROL >> + * ioctls in parallel. Use a separate lock if that

Re: [PATCH v2 08/14] KVM: x86: remove notifiers from PIT discard policy

2016-02-18 19:08+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: >> +/* pit->pit_state.lock was overloaded to prevent userspace from getting >> + * an inconsistent state after running multiple KVM_REINJECT_CONTROL >> + * ioctls in parallel. Use a separate lock if that

Re: [PATCH v9 3/3] add support for DWC UFS Host Controller

On Thursday 18 February 2016 17:20:27 Joao Pinto wrote: > > Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 19 + > MAINTAINERS | 6 + > drivers/scsi/ufs/Kconfig | 51 +++ > drivers/scsi/ufs/Makefile |

Re: [PATCH v9 3/3] add support for DWC UFS Host Controller

On Thursday 18 February 2016 17:20:27 Joao Pinto wrote: > > Documentation/devicetree/bindings/ufs/ufs-dwc.txt | 19 + > MAINTAINERS | 6 + > drivers/scsi/ufs/Kconfig | 51 +++ > drivers/scsi/ufs/Makefile |

Re: [PATCH V3 2/2] sched: idle: IRQ based next prediction for idle period

On 02/18/2016 07:57 PM, Rafael J. Wysocki wrote: On Thu, Feb 18, 2016 at 11:25 AM, Daniel Lezcano wrote: On 02/17/2016 11:21 PM, Rafael J. Wysocki wrote: [ ... ] Reviewed-by: Nicolas Pitre Well, I'm likely overlooking something, but how is

Re: [PATCH V3 2/2] sched: idle: IRQ based next prediction for idle period

On 02/18/2016 07:57 PM, Rafael J. Wysocki wrote: On Thu, Feb 18, 2016 at 11:25 AM, Daniel Lezcano wrote: On 02/17/2016 11:21 PM, Rafael J. Wysocki wrote: [ ... ] Reviewed-by: Nicolas Pitre Well, I'm likely overlooking something, but how is this going to be hooked up to the code in

Re: [PATCH 1/2] vfs: make sure struct filename->iname is word-aligned

On Thu, Feb 18, 2016 at 09:10:21PM +0100, Rasmus Villemoes wrote: > > Sure, that would work as well. I don't really care how ->iname is pushed > out to offset 32, but I'd like to know if it's worth it. Do you have access to one of these platforms where unaligned access is really painful? The

[PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

Moving an SPI around doesn't require any extra work from the rest of the stack, and specially not for MSI-generated SPIs. It is then worth returning IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK, and simplify the other irqchips that rely on this behaviour (GICv2m and Marvell's ODMI controller).

Re: [PATCH 1/2] vfs: make sure struct filename->iname is word-aligned

On Thu, Feb 18, 2016 at 09:10:21PM +0100, Rasmus Villemoes wrote: > > Sure, that would work as well. I don't really care how ->iname is pushed > out to offset 32, but I'd like to know if it's worth it. Do you have access to one of these platforms where unaligned access is really painful? The

[PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method

Moving an SPI around doesn't require any extra work from the rest of the stack, and specially not for MSI-generated SPIs. It is then worth returning IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK, and simplify the other irqchips that rely on this behaviour (GICv2m and Marvell's ODMI controller).

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 15:53:06 +0100 luca abeni wrote: > Sorry about that; I was in hurry, and I tried to do the quickest > thing... I'll resend the patches in a more appropriate way on Monday. Thanks! No rush. -- Steve

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 15:53:06 +0100 luca abeni wrote: > Sorry about that; I was in hurry, and I tried to do the quickest > thing... I'll resend the patches in a more appropriate way on Monday. Thanks! No rush. -- Steve

Re: [RFC v2 7/7] kprobes: port to linker table

On Fri, Feb 19, 2016 at 02:15:11PM +, Russell King - ARM Linux wrote: > On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote: > > kprobe makes use of two custom sections: > > > > type name beginend > > init.data _kprobe_blacklist

Re: [RFC v2 7/7] kprobes: port to linker table

On Fri, Feb 19, 2016 at 02:15:11PM +, Russell King - ARM Linux wrote: > On Fri, Feb 19, 2016 at 05:45:59AM -0800, Luis R. Rodriguez wrote: > > kprobe makes use of two custom sections: > > > > type name beginend > > init.data _kprobe_blacklist

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 09:20:08 -0500 Steven Rostedt wrote: > On Fri, 19 Feb 2016 14:43:47 +0100 > luca abeni wrote: > > > > So, the first attached patch (to be applied over Juri's patch) just > > moves two __dl_sub_ac() and __dl_add_ac() invocations from

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

On Fri, 19 Feb 2016 09:20:08 -0500 Steven Rostedt wrote: > On Fri, 19 Feb 2016 14:43:47 +0100 > luca abeni wrote: > > > > So, the first attached patch (to be applied over Juri's patch) just > > moves two __dl_sub_ac() and __dl_add_ac() invocations from > > dl_overflow() to deadline.c, using

[RFC][PATCH 7/7] perf: Cure event->pending_disable race

Because event_sched_out() checks event->pending_disable _before_ actually disabling the event, it can happen that the event fires after it checks but before it gets disabled. This would leave event->pending_disable set and the queued irq_work will try and process it. However, if the event

[RFC][PATCH 6/7] perf: Fix race between event install and jump_labels

perf_install_in_context() relies upon the context switch hooks to have scheduled in events when the IPI misses its target -- after all, if the task has moved from the CPU (or wasn't running at all), it will have to context switch to run elsewhere. This however doesn't appear to be happening. It

[RFC][PATCH 4/7] perf: Fix scaling vs enable_on_exec

Oleg reported that enable_on_exec results in weird scale factors. The recent commit 3e349507d12d ("perf: Fix perf_enable_on_exec() event scheduling") caused this by moving task_ctx_sched_out() from before __perf_event_mask_enable() to after it. The overlooked concequence of that change is that

[RFC][PATCH 7/7] perf: Cure event->pending_disable race

Because event_sched_out() checks event->pending_disable _before_ actually disabling the event, it can happen that the event fires after it checks but before it gets disabled. This would leave event->pending_disable set and the queued irq_work will try and process it. However, if the event

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