Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

From: Lars Ellenberg Date: Tue, 10 May 2016 11:40:23 +0200 > If we introduce a new config option, > we have to add it to the config scanner (one line), > define min, max, default and scale (four short defines), > and add it to the netlink definition here (one line). >

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

2016-03-15 13:10 GMT+03:00 Alexander Potapenko : > > static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } > static inline void kasan_free_shadow(const struct vm_struct *vm) {} > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > index 82169fb..799c98e

Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

From: Lars Ellenberg Date: Tue, 10 May 2016 11:40:23 +0200 > If we introduce a new config option, > we have to add it to the config scanner (one line), > define min, max, default and scale (four short defines), > and add it to the netlink definition here (one line). > Done, rest of the code is

Re: [PATCH v8 7/7] mm: kasan: Initial memory quarantine implementation

2016-03-15 13:10 GMT+03:00 Alexander Potapenko : > > static inline int kasan_module_alloc(void *addr, size_t size) { return 0; } > static inline void kasan_free_shadow(const struct vm_struct *vm) {} > diff --git a/lib/test_kasan.c b/lib/test_kasan.c > index 82169fb..799c98e 100644 > ---

[PATCH 0/3] Input: soc_button_array fixes and question

Hi, This series has been triggered by the Surface 3 I have been given. The way Microsoft follows its own specs is always intriguing. As written in drivers/platform/x86/surfacepro3_button.c, the PNP0C40 ACPI device which should follow the specification doesn't have any GPIO listed (thus the first

[PATCH 0/3] Input: soc_button_array fixes and question

Hi, This series has been triggered by the Surface 3 I have been given. The way Microsoft follows its own specs is always intriguing. As written in drivers/platform/x86/surfacepro3_button.c, the PNP0C40 ACPI device which should follow the specification doesn't have any GPIO listed (thus the first

[PATCH 3/3] Input - soc_button_array: make sure one GPIO is not assigned twice

The Surface 3 declares twice the GPIO as GpioInt and GpioIo in its ACPI table. Given that we do not keep the gpiod around, but the actual number associated to, there is a chance while enumerating the GPIOs that one gets assigned twice. Make sure a previous button has not been mapped already to the

[PATCH 3/3] Input - soc_button_array: make sure one GPIO is not assigned twice

The Surface 3 declares twice the GPIO as GpioInt and GpioIo in its ACPI table. Given that we do not keep the gpiod around, but the actual number associated to, there is a chance while enumerating the GPIOs that one gets assigned twice. Make sure a previous button has not been mapped already to the

[PATCH 2/3] Input - soc_button_array: bail out earlier if gpiod_count is null

The PNP0C40 device of the Surface 3 doesn't have any GPIO attached to it. Instead of trying to access the GPIO, request the count beforehand and bail out if it is null or if an error is returned. Signed-off-by: Benjamin Tissoires ---

[PATCH 2/3] Input - soc_button_array: bail out earlier if gpiod_count is null

The PNP0C40 device of the Surface 3 doesn't have any GPIO attached to it. Instead of trying to access the GPIO, request the count beforehand and bail out if it is null or if an error is returned. Signed-off-by: Benjamin Tissoires --- drivers/input/misc/soc_button_array.c | 5 + 1 file

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

Hi Alex, On 05/10/2016 05:29 PM, Alex Williamson wrote: > On Wed, 4 May 2016 11:54:15 + > Eric Auger wrote: > >> The user is allowed to register a reserved MSI IOVA range by using the >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. >>

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

Hi Alex, On 05/10/2016 05:29 PM, Alex Williamson wrote: > On Wed, 4 May 2016 11:54:15 + > Eric Auger wrote: > >> The user is allowed to register a reserved MSI IOVA range by using the >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. >> This region is stored in

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

On 2016-05-03 03:22 PM, Eric Anholt wrote: robert.f...@collabora.com writes: From: Robert Foss As per the documentation in drm_crtc.h, atomic_commit should return -EBUSY if an asycnhronous update is requested and there is an earlier update pending. Note: docs

Re: [PATCH v2] drm/vc4: Return -EBUSY if there's already a pending flip event.

On 2016-05-03 03:22 PM, Eric Anholt wrote: robert.f...@collabora.com writes: From: Robert Foss As per the documentation in drm_crtc.h, atomic_commit should return -EBUSY if an asycnhronous update is requested and there is an earlier update pending. Note: docs cited here are drm_crtc.h,

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

On Wed, 4 May 2016 11:54:15 + Eric Auger wrote: > The user is allowed to register a reserved MSI IOVA range by using the > DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. > This region is stored in the vfio_dma rb tree. At that point the

Re: [PATCH v9 4/7] vfio: allow reserved msi iova registration

On Wed, 4 May 2016 11:54:15 + Eric Auger wrote: > The user is allowed to register a reserved MSI IOVA range by using the > DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. > This region is stored in the vfio_dma rb tree. At that point the iova > range is not mapped

[PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

When setting the IRQ type we don't check the return value to see if it is set correctly. Due to this, failures to set the IRQ type have gone unnoticed and because these failures were not catastrophic have not had an impact on the system. Ideally, we should return an error if we fail to set the

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

On Tue, May 03, 2016 at 10:04:03PM +0200, Miklos Szeredi wrote: > Hi Al, > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > overlayfs-next > > This fixes two issues with overlayfs. > > Thanks, > Miklos > > --- > Miklos Szeredi (3): > vfs: rename: check backing inode

[PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

When setting the IRQ type we don't check the return value to see if it is set correctly. Due to this, failures to set the IRQ type have gone unnoticed and because these failures were not catastrophic have not had an impact on the system. Ideally, we should return an error if we fail to set the

Re: [GIT PULL] overlayfs fixes for 4.6-rc7

On Tue, May 03, 2016 at 10:04:03PM +0200, Miklos Szeredi wrote: > Hi Al, > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > overlayfs-next > > This fixes two issues with overlayfs. > > Thanks, > Miklos > > --- > Miklos Szeredi (3): > vfs: rename: check backing inode

[PATCH 01/11] genirq: Ensure IRQ descriptor is valid when setting-up the IRQ

In the function, setup_irq(), we don't check that the descriptor returned from irq_to_desc() is valid before we start using it. For example chip_bus_lock() called from setup_irq(), assumes that the descriptor pointer is valid and doesn't check before dereferencing it. In many other functions

[PATCH 01/11] genirq: Ensure IRQ descriptor is valid when setting-up the IRQ

In the function, setup_irq(), we don't check that the descriptor returned from irq_to_desc() is valid before we start using it. For example chip_bus_lock() called from setup_irq(), assumes that the descriptor pointer is valid and doesn't check before dereferencing it. In many other functions

[PATCH 04/11] irqchip/gic: Don't unnecessarily write the IRQ configuration

If the interrupt configuration matches the current configuration, then don't bother writing the configuration again. Signed-off-by: Jon Hunter Acked-by: Marc Zyngier --- drivers/irqchip/irq-gic-common.c | 8 ++-- 1 file changed, 6 insertions(+),

[PATCH 04/11] irqchip/gic: Don't unnecessarily write the IRQ configuration

If the interrupt configuration matches the current configuration, then don't bother writing the configuration again. Signed-off-by: Jon Hunter Acked-by: Marc Zyngier --- drivers/irqchip/irq-gic-common.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH 00/11] Various IRQ and GIC fixes and clean-ups

Most of these patches were originally part of the series to add support for the Tegra210 AGIC [0]. However, given that series has grown and some of the changes to the IRQ core needed some more review/testing, per an offline discussion with Marc Z, I have split out the more trivial fixes and

[PATCH 00/11] Various IRQ and GIC fixes and clean-ups

Most of these patches were originally part of the series to add support for the Tegra210 AGIC [0]. However, given that series has grown and some of the changes to the IRQ core needed some more review/testing, per an offline discussion with Marc Z, I have split out the more trivial fixes and

[PATCH 03/11] irqchip: Mask the non-type/sense bits when translating an IRQ

The firmware parameter that contains the IRQ sense bits may also contain other data. When return the IRQ type, bits outside of these sense bits should be masked. If these bits are not masked and irq_create_fwspec_mapping() is called to map an IRQ, then the comparison of the type returned from

[PATCH 03/11] irqchip: Mask the non-type/sense bits when translating an IRQ

The firmware parameter that contains the IRQ sense bits may also contain other data. When return the IRQ type, bits outside of these sense bits should be masked. If these bits are not masked and irq_create_fwspec_mapping() is called to map an IRQ, then the comparison of the type returned from

Re: sched: tweak select_idle_sibling to look for idle threads

On Tue, 2016-05-10 at 09:49 +0200, Mike Galbraith wrote: > Only whacking > cfs_rq_runnable_load_avg() with a rock makes schbench -m -t > -a work well. 'Course a rock in its gearbox also > rendered load balancing fairly busted for the general case :) Smaller rock doesn't injure heavy tbench,

Re: sched: tweak select_idle_sibling to look for idle threads

On Tue, 2016-05-10 at 09:49 +0200, Mike Galbraith wrote: > Only whacking > cfs_rq_runnable_load_avg() with a rock makes schbench -m -t > -a work well. 'Course a rock in its gearbox also > rendered load balancing fairly busted for the general case :) Smaller rock doesn't injure heavy tbench,

[PATCH 06/11] irqchip/gic: Don't initialise chip if mapping IO space fails

If we fail to map the address space for the GIC distributor or CPU interface, then don't attempt to initialise the chip, just WARN and return. Signed-off-by: Jon Hunter Acked-by: Marc Zyngier --- drivers/irqchip/irq-gic.c | 8 ++-- 1 file

[PATCH 06/11] irqchip/gic: Don't initialise chip if mapping IO space fails

If we fail to map the address space for the GIC distributor or CPU interface, then don't attempt to initialise the chip, just WARN and return. Signed-off-by: Jon Hunter Acked-by: Marc Zyngier --- drivers/irqchip/irq-gic.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

[PATCH 08/15] perf tools: Rewrite strbuf not to die()

From: Masami Hiramatsu Rewrite strbuf implementation not to use die() nor xrealloc(). Instead of die(), now most of the API returns error code or 0 if succeeded. Suggested-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu

[PATCH 08/15] perf tools: Rewrite strbuf not to die()

From: Masami Hiramatsu Rewrite strbuf implementation not to use die() nor xrealloc(). Instead of die(), now most of the API returns error code or 0 if succeeded. Suggested-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

Re: [PATCH 1/2] kselftests/ftrace: Detect tracefs mount point

On 05/10/2016 08:53 AM, Namhyung Kim wrote: > Currently ftracetest assumes tracing directory is located under > $DEBUGFS/tracing. But it's possible to mount tracefs directly without > debugfs. > > Signed-off-by: Namhyung Kim Looks good to me. Steve! Ack if you are good

Re: Is it really correct to check for breakpoint in kernel space against ptracer's address space?

On Tue, May 10, 2016 at 4:50 AM, Ruslan Kabatsayev wrote: > On Tue, May 10, 2016 at 6:33 AM, Andy Lutomirski wrote: >> Is there any reason at all for TASK_SIZE to be different from TASK_SIZE_MAX? > > The distinction originally appears to have been

[PATCH 02/15] perf stat: Scale values by unit before metrics

From: Andi Kleen Scale values by unit before passing them to the metrics printing functions. This is needed for TopDown, because it needs to scale the slots correctly by pipeline width / SMTness. For existing metrics it shouldn't make any difference, as those generally

Re: Is it really correct to check for breakpoint in kernel space against ptracer's address space?

On Tue, May 10, 2016 at 4:50 AM, Ruslan Kabatsayev wrote: > On Tue, May 10, 2016 at 6:33 AM, Andy Lutomirski wrote: >> Is there any reason at all for TASK_SIZE to be different from TASK_SIZE_MAX? > > The distinction originally appears to have been introduced by commit 8492980. Hmm. Anyway,

[PATCH 02/15] perf stat: Scale values by unit before metrics

From: Andi Kleen Scale values by unit before passing them to the metrics printing functions. This is needed for TopDown, because it needs to scale the slots correctly by pipeline width / SMTness. For existing metrics it shouldn't make any difference, as those generally use events that don't

Re: [PATCH 1/2] kselftests/ftrace: Detect tracefs mount point

On 05/10/2016 08:53 AM, Namhyung Kim wrote: > Currently ftracetest assumes tracing directory is located under > $DEBUGFS/tracing. But it's possible to mount tracefs directly without > debugfs. > > Signed-off-by: Namhyung Kim Looks good to me. Steve! Ack if you are good with this patch. I can

Re: [PATCH 2/2] kselftests/ftrace: Add a test case for event pid filtering

On 05/10/2016 08:53 AM, Namhyung Kim wrote: > Check event is filtered by set_event_pid and options/event-fork. > > Signed-off-by: Namhyung Kim Looks good to me. Steve! Ack if you are good with this patch. I can get this into 4.8-rc1 thanks, -- Shuah > --- >

[PATCH 13/15] perf pmu: Make pmu_formats_string to check return value of strbuf

From: Masami Hiramatsu Make pmu_formats_string() to check return value of strbuf APIs so that it can detect errors in it. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 05/11] irqchip/gic: WARN if setting the interrupt type for a PPI fails

Setting the interrupt type for private peripheral interrupts (PPIs) may not be supported by a given GIC because it is IMPLEMENTATION DEFINED whether this is allowed. There is no way to know if setting the type is supported for a given GIC and so the value written is read back to verify it matches

[PATCH 05/11] irqchip/gic: WARN if setting the interrupt type for a PPI fails

Setting the interrupt type for private peripheral interrupts (PPIs) may not be supported by a given GIC because it is IMPLEMENTATION DEFINED whether this is allowed. There is no way to know if setting the type is supported for a given GIC and so the value written is read back to verify it matches

[PATCH 13/15] perf pmu: Make pmu_formats_string to check return value of strbuf

From: Masami Hiramatsu Make pmu_formats_string() to check return value of strbuf APIs so that it can detect errors in it. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054744.6158.37810.stgit@devbox Signed-off-by: Arnaldo Carvalho

Re: [PATCH 2/2] kselftests/ftrace: Add a test case for event pid filtering

On 05/10/2016 08:53 AM, Namhyung Kim wrote: > Check event is filtered by set_event_pid and options/event-fork. > > Signed-off-by: Namhyung Kim Looks good to me. Steve! Ack if you are good with this patch. I can get this into 4.8-rc1 thanks, -- Shuah > --- >

[PATCH V7 01/11] PCI: Provide common functions for ECAM mapping

From: Jayachandran C Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in drivers/pci/host/pci-host-common.h. The

[PATCH V7 01/11] PCI: Provide common functions for ECAM mapping

From: Jayachandran C Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in drivers/pci/host/pci-host-common.h. The file defines a new 'struct

[PATCH 07/15] perf symbols: Fix handling of zero-length symbols.

From: Chris Phlipot This change introduces a fix to symbols__find, so that it is able to find symbols of length zero (where start == end). The current code has the following problem: - The current implementation of symbols__find is unable to find any symbols of length

[PATCH 07/15] perf symbols: Fix handling of zero-length symbols.

From: Chris Phlipot This change introduces a fix to symbols__find, so that it is able to find symbols of length zero (where start == end). The current code has the following problem: - The current implementation of symbols__find is unable to find any symbols of length zero. - The db-export

[PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64.

It is perfectly fine to use ACPI_PCI_HOST_GENERIC for ARM64, so lets get rid of PCI init and RAW ACPI accessor empty stubs and go with full-blown PCI host controller driver. Signed-off-by: Tomasz Nowicki To: Catalin Marinas To: Lorenzo Pieralisi

[PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64.

It is perfectly fine to use ACPI_PCI_HOST_GENERIC for ARM64, so lets get rid of PCI init and RAW ACPI accessor empty stubs and go with full-blown PCI host controller driver. Signed-off-by: Tomasz Nowicki To: Catalin Marinas To: Lorenzo Pieralisi To: Will Deacon To: Arnd Bergmann ---

[PATCH V7 06/11] pci, acpi: Provide a way to assign bus domain number.

This patch provides a way to set the ACPI domain number in PCI code. pci_create_root_bus is called with NULL as parent in ACPI. This ends up calling pci_bus_assign_domain_nr with a NULL parent. So we define acpi_pci_bus_domain_nr() which is meant to retrieve the PCI domain number based on 'struct

[PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

This patch provides a way to set the ACPI companion in PCI code. We define acpi_pci_set_companion() to set the ACPI companion pointer and call it from PCI core code. The function is stub for now. Signed-off-by: Jayachandran C Signed-off-by: Tomasz Nowicki

[PATCH V7 04/11] pci: Add new function to unmap IO resources.

It is very useful to release I/O resources so that the same I/O resources can be allocated again (pci_remap_iospace), like in PCI hotplug removal scenario. Therefore this patch implements new pci_unmap_iospace call which unmaps I/O space as the symmetry to pci_remap_iospace. Signed-off-by: Sinan

[PATCH V7 06/11] pci, acpi: Provide a way to assign bus domain number.

This patch provides a way to set the ACPI domain number in PCI code. pci_create_root_bus is called with NULL as parent in ACPI. This ends up calling pci_bus_assign_domain_nr with a NULL parent. So we define acpi_pci_bus_domain_nr() which is meant to retrieve the PCI domain number based on 'struct

[PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

This patch provides a way to set the ACPI companion in PCI code. We define acpi_pci_set_companion() to set the ACPI companion pointer and call it from PCI core code. The function is stub for now. Signed-off-by: Jayachandran C Signed-off-by: Tomasz Nowicki --- drivers/pci/probe.c | 2 ++

[PATCH V7 04/11] pci: Add new function to unmap IO resources.

It is very useful to release I/O resources so that the same I/O resources can be allocated again (pci_remap_iospace), like in PCI hotplug removal scenario. Therefore this patch implements new pci_unmap_iospace call which unmaps I/O space as the symmetry to pci_remap_iospace. Signed-off-by: Sinan

[PATCH V7 09/11] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code.

To enable PCI legacy IRQs on platforms booting with ACPI, arch code should include ACPI specific callbacks that parse and set-up the device IRQ number, equivalent to the DT boot path. Owing to the current ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings cannot be parsed at

[PATCH V7 09/11] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code.

To enable PCI legacy IRQs on platforms booting with ACPI, arch code should include ACPI specific callbacks that parse and set-up the device IRQ number, equivalent to the DT boot path. Owing to the current ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings cannot be parsed at

[PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code.

No functional changes in this patch. PCI I/O space mapping code does not depend on OF, therefore it can be moved to PCI core code. This way we will be able to use it e.g. in ACPI PCI code. Suggested-by: Lorenzo Pieralisi Signed-off-by: Tomasz Nowicki

[PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code.

No functional changes in this patch. PCI I/O space mapping code does not depend on OF, therefore it can be moved to PCI core code. This way we will be able to use it e.g. in ACPI PCI code. Suggested-by: Lorenzo Pieralisi Signed-off-by: Tomasz Nowicki CC: Arnd Bergmann CC: Liviu Dudau ---

[PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

This patch is going to implement generic PCI host controller for ACPI world, similar to what pci-host-generic.c driver does for DT world. All such drivers, which we have seen so far, were implemented within arch/ directory since they had some arch assumptions (x86 and ia64). However, they all are

[PATCH V7 10/11] arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus enumeration.

ACPI requires to run acpi_pci_{add|remove}_bus while new PCI bus is created. This allows to do some ACPI-specific additional configuration, like PCI hotplug slot enumeration. In order to fulfill these requirements, we implement arch-specific pcibios_{add|remove}_bus calls and call

[PATCH V7 00/11] Support for generic ACPI based PCI host controller

>From the functionality point of view this series may be split into the following logic parts: 1. New ECAM API and update for users of the pci-host-common API 2. Necessary fixes as the preparation for using driver on ARM64. 3. Use new MCFG interface and implement generic ACPI based PCI host

[PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

This patch is going to implement generic PCI host controller for ACPI world, similar to what pci-host-generic.c driver does for DT world. All such drivers, which we have seen so far, were implemented within arch/ directory since they had some arch assumptions (x86 and ia64). However, they all are

[PATCH V7 10/11] arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus enumeration.

ACPI requires to run acpi_pci_{add|remove}_bus while new PCI bus is created. This allows to do some ACPI-specific additional configuration, like PCI hotplug slot enumeration. In order to fulfill these requirements, we implement arch-specific pcibios_{add|remove}_bus calls and call

[PATCH V7 00/11] Support for generic ACPI based PCI host controller

>From the functionality point of view this series may be split into the following logic parts: 1. New ECAM API and update for users of the pci-host-common API 2. Necessary fixes as the preparation for using driver on ARM64. 3. Use new MCFG interface and implement generic ACPI based PCI host

Re: [PATCH v2] kconfig: add unexpected data itself to warning

On Wed, Apr 27, 2016 at 09:20:17PM +0200, Paul Bolle wrote: > Hi Michal, > > On wo, 2016-03-16 at 21:27 +0100, Paul Bolle wrote: > > If the .config parser runs into unexpected data it emits warnings > > like: > > .config:6911:warning: unexpected data > > > > Add the unexpected data itself to

[PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API

From: Jayachandran C Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_ecam_ops' The changes are mostly to use 'struct pci_config_window'

[PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources.

Platforms that have memory mapped IO port (such as ARM64) need special handling for PCI I/O resources. For host bridge's resource probing case these resources need to be fixed up with pci_register_io_range/pci_remap_iospace etc. The same I/O resources need to be released after hotplug removal so

Re: [PATCH v2] kconfig: add unexpected data itself to warning

On Wed, Apr 27, 2016 at 09:20:17PM +0200, Paul Bolle wrote: > Hi Michal, > > On wo, 2016-03-16 at 21:27 +0100, Paul Bolle wrote: > > If the .config parser runs into unexpected data it emits warnings > > like: > > .config:6911:warning: unexpected data > > > > Add the unexpected data itself to

[PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API

From: Jayachandran C Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_ecam_ops' The changes are mostly to use 'struct pci_config_window' in place of 'struct

[PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources.

Platforms that have memory mapped IO port (such as ARM64) need special handling for PCI I/O resources. For host bridge's resource probing case these resources need to be fixed up with pci_register_io_range/pci_remap_iospace etc. The same I/O resources need to be released after hotplug removal so

[PATCH 03/15] perf script: Fix incorrect python db-export error message

From: Chris Phlipot Fix the error message printed when attempting and failing to create the call path root incorrectly references the call return process. This change fixes the message to properly reference the failure to create the call path root. Signed-off-by: Chris

[PATCH 03/15] perf script: Fix incorrect python db-export error message

From: Chris Phlipot Fix the error message printed when attempting and failing to create the call path root incorrectly references the call return process. This change fixes the message to properly reference the failure to create the call path root. Signed-off-by: Chris Phlipot Cc: Adrian

[PATCH 14/15] perf help: Do not use ALLOC_GROW in add_cmd_list

From: Masami Hiramatsu Replace ALLOC_GROW with normal realloc code in add_cmd_list() so that it can handle errors directly. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 14/15] perf help: Do not use ALLOC_GROW in add_cmd_list

From: Masami Hiramatsu Replace ALLOC_GROW with normal realloc code in add_cmd_list() so that it can handle errors directly. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054752.6158.30562.stgit@devbox Signed-off-by: Arnaldo

[PATCH 10/15] perf help: Make check_emacsclient_version to check strbuf APIs

From: Masami Hiramatsu Make check_emacsclient_version() to check the return value of strbuf APIs so that it can handle errors in strbuf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra

[PATCH 10/15] perf help: Make check_emacsclient_version to check strbuf APIs

From: Masami Hiramatsu Make check_emacsclient_version() to check the return value of strbuf APIs so that it can handle errors in strbuf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054716.6158.11755.stgit@devbox Signed-off-by:

[PATCH 09/15] perf probe: Check the return value of strbuf APIs

From: Masami Hiramatsu Check the return value of strbuf APIs in perf-probe related code, so that it can handle errors in strbuf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 09/15] perf probe: Check the return value of strbuf APIs

From: Masami Hiramatsu Check the return value of strbuf APIs in perf-probe related code, so that it can handle errors in strbuf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054707.6158.69861.stgit@devbox Signed-off-by: Arnaldo

[PATCH 11/15] perf tools: Make alias handler to check return value of strbuf

From: Masami Hiramatsu Make alias handler and sq_quote_argv to check the return value of strbuf APIs. In sq_quote_argv() calls die(), but this fix handles strbuf failure as a special case and returns to caller, since the caller - handle_alias() also has to check the return

[PATCH 12/15] perf header: Make topology checkers to check return value of strbuf

From: Masami Hiramatsu Make topology checkers to check the return value of strbuf APIs so that it can detect errors in it. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

Re: [BISECTED] Regression v4.6-rc1 : nanosleep doesn't return on AT91SAM9

Le 10/05/2016 16:59, Richard Genoud a écrit : > 2016-05-10 16:47 GMT+02:00 Boris Brezillon > : >> Hi Richard, >> >> On Tue, 10 May 2016 16:25:25 +0200 >> Richard Genoud wrote: >> >>> 2016-05-10 15:58 GMT+02:00 Richard Genoud

[PATCH 11/15] perf tools: Make alias handler to check return value of strbuf

From: Masami Hiramatsu Make alias handler and sq_quote_argv to check the return value of strbuf APIs. In sq_quote_argv() calls die(), but this fix handles strbuf failure as a special case and returns to caller, since the caller - handle_alias() also has to check the return value of other strbuf

[PATCH 12/15] perf header: Make topology checkers to check return value of strbuf

From: Masami Hiramatsu Make topology checkers to check the return value of strbuf APIs so that it can detect errors in it. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054735.6158.98650.stgit@devbox Signed-off-by: Arnaldo Carvalho

Re: [BISECTED] Regression v4.6-rc1 : nanosleep doesn't return on AT91SAM9

Le 10/05/2016 16:59, Richard Genoud a écrit : > 2016-05-10 16:47 GMT+02:00 Boris Brezillon > : >> Hi Richard, >> >> On Tue, 10 May 2016 16:25:25 +0200 >> Richard Genoud wrote: >> >>> 2016-05-10 15:58 GMT+02:00 Richard Genoud : Hi, Starting with 4.6-rc1, a sleep 1 doesn't return :

[PATCH 15/15] perf tools: Remove xrealloc and ALLOC_GROW

From: Masami Hiramatsu Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 15/15] perf tools: Remove xrealloc and ALLOC_GROW

From: Masami Hiramatsu Remove unused xrealloc() and ALLOC_GROW() from libperf. Signed-off-by: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20160510054801.6158.6204.stgit@devbox Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/Build | 1

[PATCH 08/11] irqchip/gic: Return an error if GIC initialisation fails

If the GIC initialisation fails, then currently we do not return an error or clean-up afterwards. Although for root controllers, this failure may be fatal anyway, for secondary controllers, it may not be fatal and so return an error on failure and clean-up. Update the functions gic_cpu_init() and

[GIT PULL 00/15] perf/core improvements and fixes

in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160510 for you to fetch changes up to 452e84012595d681f254a3a0d733fb0b18ffaf42: perf tools: Remove xrealloc and ALLOC_GROW (2016-05-10 11:58:27 -0300

[PATCH 08/11] irqchip/gic: Return an error if GIC initialisation fails

If the GIC initialisation fails, then currently we do not return an error or clean-up afterwards. Although for root controllers, this failure may be fatal anyway, for secondary controllers, it may not be fatal and so return an error on failure and clean-up. Update the functions gic_cpu_init() and

[GIT PULL 00/15] perf/core improvements and fixes

in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160510 for you to fetch changes up to 452e84012595d681f254a3a0d733fb0b18ffaf42: perf tools: Remove xrealloc and ALLOC_GROW (2016-05-10 11:58:27 -0300

[PATCH 01/15] perf callchain: Recording 'dwarf' callchains do not need DWARF unwinding support

From: He Kuang There is no need to check for DWARF unwinding support when using the 'dwarf' callchain record method, as this will only ask the kernel to collect stack dumps for later DWARF CFI processing, which can be done in another machine, where the support for DWARF

[PATCH 01/15] perf callchain: Recording 'dwarf' callchains do not need DWARF unwinding support

From: He Kuang There is no need to check for DWARF unwinding support when using the 'dwarf' callchain record method, as this will only ask the kernel to collect stack dumps for later DWARF CFI processing, which can be done in another machine, where the support for DWARF unwinding need to be

[PATCH 05/15] perf tests: Add test to check backward ring buffer

From: Wang Nan This test checks reading from backward ring buffer. Test result: # ~/perf test 'ring buffer' 45: Test backward reading from ring buffer : Ok The test case is a while loop which calls prctl(PR_SET_NAME) multiple times. Each prctl

[PATCH 04/15] perf tools: Support reading from backward ring buffer

From: Wang Nan perf_evlist__mmap_read_backward() is introduced for reading backward ring buffer. Since direction for reading such ring buffer is different from the direction kernel writing to it, and since user need to fetch most recent record from it, a

[PATCH 05/15] perf tests: Add test to check backward ring buffer

From: Wang Nan This test checks reading from backward ring buffer. Test result: # ~/perf test 'ring buffer' 45: Test backward reading from ring buffer : Ok The test case is a while loop which calls prctl(PR_SET_NAME) multiple times. Each prctl should issue 2 events: one

[PATCH 04/15] perf tools: Support reading from backward ring buffer

From: Wang Nan perf_evlist__mmap_read_backward() is introduced for reading backward ring buffer. Since direction for reading such ring buffer is different from the direction kernel writing to it, and since user need to fetch most recent record from it, a perf_evlist__mmap_read_catchup() is

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