Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

On Tue, May 24, 2016 at 11:29 PM, Jaewon Kim wrote: > From: Jaewon > > There was an alignment mismatch issue for CMA and it was fixed by > commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with > CMA setup"). > However

Re: [RESEND][PATCH] drivers: of: of_reserved_mem: fixup the CMA alignment not to affect dma-coherent

On Tue, May 24, 2016 at 11:29 PM, Jaewon Kim wrote: > From: Jaewon > > There was an alignment mismatch issue for CMA and it was fixed by > commit 1cc8e3458b51 ("drivers: of: of_reserved_mem: fixup the alignment with > CMA setup"). > However the way of the commit considers not only

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: Driver for interrupt combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. An interrupt combiner in this block combines a set of interrupts by OR'ing

Re: [PATCH V3 2/2] irqchip: qcom: Add IRQ combiner driver

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: Driver for interrupt combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. An interrupt combiner in this block combines a set of interrupts by OR'ing

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: This allows irqchip drivers to associate an ACPI DSDT device to an IRQ domain and provides support for using the ResourceSource in Extended IRQ Resources to find the domain and map the IRQs specified on that

Re: [PATCH V3 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: This allows irqchip drivers to associate an ACPI DSDT device to an IRQ domain and provides support for using the ResourceSource in Extended IRQ Resources to find the domain and map the IRQs specified on that

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: Add support for IRQ combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. The first patch adds support for ResourceSource/IRQ domain mapping when using

Re: [PATCH V3 0/2] irqchip: qcom: Add IRQ combiner driver

Adding linux-arm-kernel and linux-acpi On 2016-05-13 12:16, Agustin Vega-Frias wrote: Add support for IRQ combiners in the Top-level Control and Status Registers (TCSR) hardware block in Qualcomm Technologies chips. The first patch adds support for ResourceSource/IRQ domain mapping when using

[PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

Commit 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()") introduced a regression for systems booted with 'noefi' kernel option. In particular, I observe early kernel hang in efi_find_mirror() on for_each_efi_memory_desc() call. As we don't have efi memmap we enter this

[PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

Commit 78ce248faa3c ("efi: Iterate over efi.memmap in for_each_efi_memory_desc()") introduced a regression for systems booted with 'noefi' kernel option. In particular, I observe early kernel hang in efi_find_mirror() on for_each_efi_memory_desc() call. As we don't have efi memmap we enter this

RE: [PATCH RFC kernel] balloon: speed up inflating/deflating process

> > > Interesting. How about instead of tell host, we do multiple scans, > > > each time ignoring pages out of range? > > > > > > for (pfn = min pfn; pfn < max pfn; pfn += 1G) { > > > foreach page > > > if page pfn < pfn || page pfn >= pfn + 1G > > >

RE: [PATCH RFC kernel] balloon: speed up inflating/deflating process

> > > Interesting. How about instead of tell host, we do multiple scans, > > > each time ignoring pages out of range? > > > > > > for (pfn = min pfn; pfn < max pfn; pfn += 1G) { > > > foreach page > > > if page pfn < pfn || page pfn >= pfn + 1G > > >

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

On Wed, 2016-05-25 at 17:04 +0300, Heikki Krogerus wrote: > I'm not against leaving the responsibility of registering the alternate > modes to the drivers. I'm a little bit worried about relying then on > the drivers to also handle the unregistering accordingly, but I can > live with that. But we

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

On Wed, 2016-05-25 at 17:04 +0300, Heikki Krogerus wrote: > I'm not against leaving the responsibility of registering the alternate > modes to the drivers. I'm a little bit worried about relying then on > the drivers to also handle the unregistering accordingly, but I can > live with that. But we

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Wed, May 25, 2016 at 01:39:30PM +0800, Boqun Feng wrote: > On Tue, May 24, 2016 at 09:53:29PM -0700, Paul E. McKenney wrote: > > On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > > > On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > > > >Introduce smp_acquire__after_ctrl_dep(), this

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Wed, May 25, 2016 at 01:39:30PM +0800, Boqun Feng wrote: > On Tue, May 24, 2016 at 09:53:29PM -0700, Paul E. McKenney wrote: > > On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > > > On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > > > >Introduce smp_acquire__after_ctrl_dep(), this

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/25/2016 01:24 AM, Al Viro wrote: On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote: On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote: On May 24, 2016, at 2:36 PM, Larry Finger wrote: On 05/24/2016 02:25 PM, Matthew McClintock wrote:

Re: Regression in 4.6.0-git - bisected to commit dd254f5a382c

On 05/25/2016 01:24 AM, Al Viro wrote: On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote: On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote: On May 24, 2016, at 2:36 PM, Larry Finger wrote: On 05/24/2016 02:25 PM, Matthew McClintock wrote: On May 24, 2016, at 2:16

[PATCH] intel_menlow: prevent NULL pointer dereference

The function acpi_driver_data() will dereference its parameter; make sure to check for NULL pointer before we call it. Signed-off-by: Vincent Stehlé Cc: Sujith Thomas Cc: Darren Hart Cc: Zhang Rui

[PATCH] intel_menlow: prevent NULL pointer dereference

The function acpi_driver_data() will dereference its parameter; make sure to check for NULL pointer before we call it. Signed-off-by: Vincent Stehlé Cc: Sujith Thomas Cc: Darren Hart Cc: Zhang Rui Cc: Len Brown --- drivers/platform/x86/intel_menlow.c | 8 ++-- 1 file changed, 6

Re: [PATCH v6 11/12] zsmalloc: page migration support

Hello Minchan, On (05/25/16 14:14), Minchan Kim wrote: [..] > > > do you also want to kick the deferred page release from the shrinker > > > callback, for example? > > > > Yeb, it can be. I will do it at next revision. :) > > Thanks! > > > > I tried it now but I feel strongly we want to fix

Re: [PATCH v6 11/12] zsmalloc: page migration support

Hello Minchan, On (05/25/16 14:14), Minchan Kim wrote: [..] > > > do you also want to kick the deferred page release from the shrinker > > > callback, for example? > > > > Yeb, it can be. I will do it at next revision. :) > > Thanks! > > > > I tried it now but I feel strongly we want to fix

[PATCH v4 6/7] ASoC: omap-mcbsp: sidetone: Use the new callback for iclk handling

The McBSP sidetone (in OMAP3 McBSP2 and 3 module) is working with the module's interface clock. When the sidetone is enabled the iclk must not idle because it will result in choppy sidetone. Switch to use the new callback for handling the iclk allow/deny idle configuration. For this the driver

minor patch to lib/raid6/Makefile

I've been doing some cross-compilation on my Mac, and one of the little hiccups is that lib/raid6 won't build due to a small command-line incompatibility between GNU awk and the one that comes with MacOS. Patch attached. (I have nothing like commit access; I'm hoping someone else can apply

[PATCH v4 6/7] ASoC: omap-mcbsp: sidetone: Use the new callback for iclk handling

The McBSP sidetone (in OMAP3 McBSP2 and 3 module) is working with the module's interface clock. When the sidetone is enabled the iclk must not idle because it will result in choppy sidetone. Switch to use the new callback for handling the iclk allow/deny idle configuration. For this the driver

minor patch to lib/raid6/Makefile

I've been doing some cross-compilation on my Mac, and one of the little hiccups is that lib/raid6 won't build due to a small command-line incompatibility between GNU awk and the one that comes with MacOS. Patch attached. (I have nothing like commit access; I'm hoping someone else can apply

[PATCH v4 5/7] ASoC: omap-mcbsp: Rename omap_mcbsp_sysfs_remove() to omap_mcbsp_cleanup()

The function will do more then removing the sysfs files in the future. Signed-off-by: Peter Ujfalusi Acked-by: Mark Brown --- sound/soc/omap/mcbsp.c | 2 +- sound/soc/omap/mcbsp.h | 2 +- sound/soc/omap/omap-mcbsp.c | 2 +- 3 files changed,

[PATCH v4 5/7] ASoC: omap-mcbsp: Rename omap_mcbsp_sysfs_remove() to omap_mcbsp_cleanup()

The function will do more then removing the sysfs files in the future. Signed-off-by: Peter Ujfalusi Acked-by: Mark Brown --- sound/soc/omap/mcbsp.c | 2 +- sound/soc/omap/mcbsp.h | 2 +- sound/soc/omap/omap-mcbsp.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v4 7/7] ARM: OMAP2+: McBSP: Remove the old iclk allow/deny idle code

The new pdata callback (force_ick_on) is now used by the driver and the old callback related code can be removed. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-omap2/mcbsp.c | 18 -- include/linux/platform_data/asoc-ti-mcbsp.h | 1 - 2

[PATCH v4 4/7] ARM: OMAP3: pdata-quirks: Add support for McBSP2/3 sidetone handling

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. To prevent the iclk idling the driver expects to have pdata callback to call. With this patch the callback is going to be set up for DT boot also.

[PATCH v4 7/7] ARM: OMAP2+: McBSP: Remove the old iclk allow/deny idle code

The new pdata callback (force_ick_on) is now used by the driver and the old callback related code can be removed. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-omap2/mcbsp.c | 18 -- include/linux/platform_data/asoc-ti-mcbsp.h | 1 - 2 files changed, 19

[PATCH v4 4/7] ARM: OMAP3: pdata-quirks: Add support for McBSP2/3 sidetone handling

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. To prevent the iclk idling the driver expects to have pdata callback to call. With this patch the callback is going to be set up for DT boot also.

[PATCH v4 2/7] ARM: dts: omap3: Add clocks to McBSP nodes

Add clock properties to the McBSP nodes. McBSP2 and 3 need to have ick also since the Sidetone block of these modules are operating using the McBSP interface clock. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/omap3.dtsi | 10 ++ 1 file changed, 10

[PATCH v4 3/7] ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. The new callback expects to receive the *clk of the module's ick and not the id number of the McBSP. This will allow us more cleanups and going to

[PATCH v4 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

Hi, Changes since v3: - Rebased on next-20160525 [1] to apply cleanly - Fixed subject line for patch5 - Added Mark's acked-by to the ASoC patches [1] "ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3" is gone missing from linux-next - it was in next-201605

[PATCH v4 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the sidetone only receives the ICLK from the main McBSP module. Since the McBSP and sidetone is using the very same clock from PRCM level the sidetone must not have the prcm section to check the clock status since the sidetone is

[PATCH v4 2/7] ARM: dts: omap3: Add clocks to McBSP nodes

Add clock properties to the McBSP nodes. McBSP2 and 3 need to have ick also since the Sidetone block of these modules are operating using the McBSP interface clock. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/omap3.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v4 3/7] ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. The new callback expects to receive the *clk of the module's ick and not the id number of the McBSP. This will allow us more cleanups and going to

[PATCH v4 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

Hi, Changes since v3: - Rebased on next-20160525 [1] to apply cleanly - Fixed subject line for patch5 - Added Mark's acked-by to the ASoC patches [1] "ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3" is gone missing from linux-next - it was in next-201605

[PATCH v4 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the sidetone only receives the ICLK from the main McBSP module. Since the McBSP and sidetone is using the very same clock from PRCM level the sidetone must not have the prcm section to check the clock status since the sidetone is

Re: [PATCH 2/2] ARM: dts: Add async-bridge clock to MFC power domain for Exynos5420

Hello Krzysztof, On 05/25/2016 03:48 AM, Krzysztof Kozlowski wrote: > On 05/24/2016 07:41 PM, Javier Martinez Canillas wrote: >> The MFC IP is also inter-connected by an Async-Bridge so the CLK_ACLK333 >> has to be ungated during a power domain switch. Trying to do it when the >> clock is gated

Re: [PATCH 2/2] ARM: dts: Add async-bridge clock to MFC power domain for Exynos5420

Hello Krzysztof, On 05/25/2016 03:48 AM, Krzysztof Kozlowski wrote: > On 05/24/2016 07:41 PM, Javier Martinez Canillas wrote: >> The MFC IP is also inter-connected by an Async-Bridge so the CLK_ACLK333 >> has to be ungated during a power domain switch. Trying to do it when the >> clock is gated

[PATCH 3/3] ibmvscsis: clean up functions

From: bryantly This patch removes forward declarations and re-organizes the functions within the driver. This patch also fixes MAINTAINERS for ibmvscsis. Signed-off-by: bryantly --- MAINTAINERS |4 +-

[PATCH 3/3] ibmvscsis: clean up functions

From: bryantly This patch removes forward declarations and re-organizes the functions within the driver. This patch also fixes MAINTAINERS for ibmvscsis. Signed-off-by: bryantly --- MAINTAINERS |4 +- drivers/scsi/ibmvscsi/ibmvscsis.c | 2709

[PATCH 2/3] ibmvscsis: Addressing Bart's comments

From: bryantly This patch contains cleaning up the code for styling and also addresses Bart's comments. Signed-off-by: bryantly --- MAINTAINERS | 4 +- drivers/scsi/Kconfig | 36 +--

[PATCH 2/3] ibmvscsis: Addressing Bart's comments

From: bryantly This patch contains cleaning up the code for styling and also addresses Bart's comments. Signed-off-by: bryantly --- MAINTAINERS | 4 +- drivers/scsi/Kconfig | 36 +-- drivers/scsi/Makefile | 4 +-

Re: [PATCH v5 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events

Em Wed, May 25, 2016 at 09:47:37PM +0800, Wangnan (F) escreveu: > > Sorry, before calling filter here should check if rec->overwrite_evlist > > is not NULL. > > I'll resend this patch with this problem fixed soon. > > Please ignore the full v5 series and see v6 instead. The final two patches >

Re: [PATCH 0/2] ARM: dts: Fix imprecise external abort error when accessing Exynos MFC

Hello Marek, On 05/25/2016 02:51 AM, Marek Szyprowski wrote: > Hello, > > > On 2016-05-24 19:41, Javier Martinez Canillas wrote: >> This series fixes an imprecise external abort error when accessing the >> Exynos MFC registers due the power domain configuration requiring the >> aclk333 clock to

[PATCH v4 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the sidetone only receives the ICLK from the main McBSP module. Since the McBSP and sidetone is using the very same clock from PRCM level the sidetone must not have the prcm section to check the clock status since the sidetone is

[PATCH v4 2/7] ARM: dts: omap3: Add clocks to McBSP nodes

Add clock properties to the McBSP nodes. McBSP2 and 3 need to have ick also since the Sidetone block of these modules are operating using the McBSP interface clock. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/omap3.dtsi | 10 ++ 1 file changed, 10

[PATCH v4 3/7] ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. The new callback expects to receive the *clk of the module's ick and not the id number of the McBSP. This will allow us more cleanups and going to

[PATCH v4 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

Hi, Changes since v3: - Rebased on next-20160525 [1] to apply cleanly - Fixed subject line for patch5 - Added Mark's acked-by to the ASoC patches [1] "ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3" is gone missing from linux-next - it was in next-201605

Re: [PATCH v5 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events

Em Wed, May 25, 2016 at 09:47:37PM +0800, Wangnan (F) escreveu: > > Sorry, before calling filter here should check if rec->overwrite_evlist > > is not NULL. > > I'll resend this patch with this problem fixed soon. > > Please ignore the full v5 series and see v6 instead. The final two patches >

Re: [PATCH 0/2] ARM: dts: Fix imprecise external abort error when accessing Exynos MFC

Hello Marek, On 05/25/2016 02:51 AM, Marek Szyprowski wrote: > Hello, > > > On 2016-05-24 19:41, Javier Martinez Canillas wrote: >> This series fixes an imprecise external abort error when accessing the >> Exynos MFC registers due the power domain configuration requiring the >> aclk333 clock to

[PATCH v4 1/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data

The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the sidetone only receives the ICLK from the main McBSP module. Since the McBSP and sidetone is using the very same clock from PRCM level the sidetone must not have the prcm section to check the clock status since the sidetone is

[PATCH v4 2/7] ARM: dts: omap3: Add clocks to McBSP nodes

Add clock properties to the McBSP nodes. McBSP2 and 3 need to have ick also since the Sidetone block of these modules are operating using the McBSP interface clock. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/omap3.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git

[PATCH v4 3/7] ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration

McBSP2/3 module's sidetone module operates using the module's ICLK clock. When the Sidetone is in use the interface clock of the module must not idle. The new callback expects to receive the *clk of the module's ick and not the id number of the McBSP. This will allow us more cleanups and going to

[PATCH v4 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

Hi, Changes since v3: - Rebased on next-20160525 [1] to apply cleanly - Fixed subject line for patch5 - Added Mark's acked-by to the ASoC patches [1] "ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3" is gone missing from linux-next - it was in next-201605

IBM VSCSI Target Driver Initial Patch Sets

This patch series addresses comments by Joe with runing checkpatch with a --strict. It cleans up all the misc styling and removes all the forward declarations. The patch also addresses all of Bart's comments besides the preallocation of buffers before IO starts and the merging of unpack_lun with

IBM VSCSI Target Driver Initial Patch Sets

This patch series addresses comments by Joe with runing checkpatch with a --strict. It cleans up all the misc styling and removes all the forward declarations. The patch also addresses all of Bart's comments besides the preallocation of buffers before IO starts and the merging of unpack_lun with

[RFC 0/1] i2c: omap: Add support for switching to slave mode

I2C controller on most of the omap devices has both master and slave capability but the i2c framework has been missing support for registering a bus in slave mode for long. Recently the i2c slave support has been added to i2c framework, the following patch adds the required support for omap_i2c

[RFC 0/1] i2c: omap: Add support for switching to slave mode

I2C controller on most of the omap devices has both master and slave capability but the i2c framework has been missing support for registering a bus in slave mode for long. Recently the i2c slave support has been added to i2c framework, the following patch adds the required support for omap_i2c

[RFC 1/1] drivers: i2c: omap: Add slave support

I2C controller on most of the omap devices has both master and slave capability but the i2c framework has been missing support for registering a bus in slave mode for long. Recently the i2c slave support has been added to i2c framework, the following patch adds the required support for omap_i2c

[RFC 1/1] drivers: i2c: omap: Add slave support

I2C controller on most of the omap devices has both master and slave capability but the i2c framework has been missing support for registering a bus in slave mode for long. Recently the i2c slave support has been added to i2c framework, the following patch adds the required support for omap_i2c

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

On Wed, May 25, 2016 at 06:21:54AM -0700, Guenter Roeck wrote: > On 05/25/2016 04:51 AM, Heikki Krogerus wrote: > > On Tue, May 24, 2016 at 12:28:26PM -0700, Guenter Roeck wrote: > > > On Thu, May 19, 2016 at 03:44:54PM +0300, Heikki Krogerus wrote: > > > > The purpose of this class is to provide

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

On Wed, May 25, 2016 at 06:21:54AM -0700, Guenter Roeck wrote: > On 05/25/2016 04:51 AM, Heikki Krogerus wrote: > > On Tue, May 24, 2016 at 12:28:26PM -0700, Guenter Roeck wrote: > > > On Thu, May 19, 2016 at 03:44:54PM +0300, Heikki Krogerus wrote: > > > > The purpose of this class is to provide

[PATCH v3] qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree

From: Raja Mani Include dts support for two wifi block present on ipq4019 SoC. Corresponding dt binding documentation has been added in ath.git as below commit id a47aaa69 and the commit message is "dt: bindings: add new dt entry for pre calibration in qcom, ath10k.txt".

[PATCH v3] qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree

From: Raja Mani Include dts support for two wifi block present on ipq4019 SoC. Corresponding dt binding documentation has been added in ath.git as below commit id a47aaa69 and the commit message is "dt: bindings: add new dt entry for pre calibration in qcom, ath10k.txt". Signed-off-by: Raja

[PATCH v6 10/10] perf record: Unmap overwrite evlist when event terminate

When see POLLERR or POLLHUP, unmap ring buffer from both the main evlist and overwrite evlist. Signed-off-by: Wang Nan Cc: He Kuang Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu

[PATCH v6 10/10] perf record: Unmap overwrite evlist when event terminate

When see POLLERR or POLLHUP, unmap ring buffer from both the main evlist and overwrite evlist. Signed-off-by: Wang Nan Cc: He Kuang Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: pi3or...@163.com --- tools/perf/builtin-record.c | 30

[PATCH v6 01/10] perf tools: Check 'base' pointer before checking refcnt when put a mmap

evlist->mmap[i]->refcnt could be 0 if an evlist has no evsel or all evsels don't match the evlist during mmap. For example, when all evsels are overwritable but the evlist itself is normal. To avoid crashing, perf should check 'base' pointer before checking refcnt, and raise bug only when base is

[PATCH v6 01/10] perf tools: Check 'base' pointer before checking refcnt when put a mmap

evlist->mmap[i]->refcnt could be 0 if an evlist has no evsel or all evsels don't match the evlist during mmap. For example, when all evsels are overwritable but the evlist itself is normal. To avoid crashing, perf should check 'base' pointer before checking refcnt, and raise bug only when base is

[PATCH v6 04/10] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

[PATCH v6 04/10] perf record: Introduce rec->overwrite_evlist for overwritable events

Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's corresponding attributes, with these two evlists an event goes to either

Re: Builtin microcode does nothing..

On 05/25/2016 11:31 AM, Borislav Petkov wrote: > On Sat, May 21, 2016 at 09:51:18AM +0200, Borislav Petkov wrote: >> I'll ping you once I'm done testing here. > > Ok, I've just uploaded a branch, it passes testing here. > > http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git, branch

Re: Builtin microcode does nothing..

On 05/25/2016 11:31 AM, Borislav Petkov wrote: > On Sat, May 21, 2016 at 09:51:18AM +0200, Borislav Petkov wrote: >> I'll ping you once I'm done testing here. > > Ok, I've just uploaded a branch, it passes testing here. > > http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git, branch

Re: [PATCH v5 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events

On 2016/5/25 18:16, Wangnan (F) wrote: On 2016/5/25 13:03, Wang Nan wrote: Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's

Re: [PATCH v5 4/8] perf record: Introduce rec->overwrite_evlist for overwritable events

On 2016/5/25 18:16, Wangnan (F) wrote: On 2016/5/25 13:03, Wang Nan wrote: Create an auxiliary evlist for overwritable events. Before mmap, build this evlist and set 'overwrite' and 'backward' attribute. Since perf_evlist__mmap_ex() only maps events when evsel->overwrite matches evlist's

[PATCH v2] thermal: imx: depend on imx SoC arch

Not much use unless the SoC is selected so depend on the ARCH_MXC and COMPILE_TEST like all the other thermal drivers. v2: drop extraneous OF Signed-off-by: Peter Robinson --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2] thermal: imx: depend on imx SoC arch

Not much use unless the SoC is selected so depend on the ARCH_MXC and COMPILE_TEST like all the other thermal drivers. v2: drop extraneous OF Signed-off-by: Peter Robinson --- drivers/thermal/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/Kconfig

[PATCH v6 09/10] tools: Pass arg to fdarray__filter's call back function

Before this patch there's no way to pass arguments to fdarray__filter's call back function. This improvement will be used by 'perf record' to support unmapping ring buffer for both main evlist and overwrite evlist. Without this patch there's no way to track overwrite evlist from 'struct fdarray'.

[PATCH v6 08/10] perf tools: Check write_backward during evlist config

Before this patch, when using overwritable ring buffer on an old kernel, error message is misleading: # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a Error: The raw_syscalls:sys_enter event is not supported. This patch output clear error message to tell user his/her kernel is too old:

[PATCH v6 07/10] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v6 09/10] tools: Pass arg to fdarray__filter's call back function

Before this patch there's no way to pass arguments to fdarray__filter's call back function. This improvement will be used by 'perf record' to support unmapping ring buffer for both main evlist and overwrite evlist. Without this patch there's no way to track overwrite evlist from 'struct fdarray'.

[PATCH v6 08/10] perf tools: Check write_backward during evlist config

Before this patch, when using overwritable ring buffer on an old kernel, error message is misleading: # ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a Error: The raw_syscalls:sys_enter event is not supported. This patch output clear error message to tell user his/her kernel is too old:

[PATCH v6 07/10] perf tools: Don't warn about out of order event if write_backward is used

If write_backward attribute is set, records are written into kernel ring buffer from end to beginning, but read from beginning to end. To avoid 'XX out of order events recorded' warning message (timestamps of records is in reverse order when using write_backward), suppress the warning message if

[PATCH v6 05/10] perf record: Toggle overwrite ring buffer for reading

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY ^ ^ | | |___(disallow)___/| ||

[PATCH v6 05/10] perf record: Toggle overwrite ring buffer for reading

overwrite_evt_state is introduced to reflect the state of overwritable ring buffers. It is a state machine with 3 states: RUNNING --(1)--> DATA_PENDING --(2)--> EMPTY ^ ^ | | |___(disallow)___/| ||

[PATCH v6 06/10] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

[PATCH v6 06/10] perf tools: Enable overwrite settings

This patch allows following config terms and option: Globally setting events to overwrite; # perf record --overwrite ... Set specific events to be overwrite or no-overwrite. # perf record --event cycles/overwrite/ ... # perf record --event cycles/no-overwrite/ ... Add missing config terms

[PATCH v6 03/10] perf tests: Add testcase for auxiliary evlist

Improve test backward-ring-buffer, trace both enter and exit event of prctl() syscall, utilize auxiliary evlist to mmap enter and exit event into separated mmaps. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc:

[PATCH v6 03/10] perf tests: Add testcase for auxiliary evlist

Improve test backward-ring-buffer, trace both enter and exit event of prctl() syscall, utilize auxiliary evlist to mmap enter and exit event into separated mmaps. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: He

[PATCH v6 00/10] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

[PATCH v6 00/10] perf tools: Support overwritable ring buffer

This patch set enables daemonized perf recording by utilizing overwritable backward ring buffer. With this feature one can put perf background, and dump ring buffer records by a SIGUSR2 when he/she find something unusual. For example, following command record system calls, schedule events and

[PATCH v6 02/10] perf tools: Choose correct reading direction according to evlist->backward

Now we have evlist->backward to indicate the mmap direction. Make perf_evlist__mmap_read() choose right direction automatically. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu

[PATCH v6 02/10] perf tools: Choose correct reading direction according to evlist->backward

Now we have evlist->backward to indicate the mmap direction. Make perf_evlist__mmap_read() choose right direction automatically. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Zefan Li Cc: He Kuang --- tools/perf/util/evlist.c

Re: [PATCH 08/10] m68k: Add

Philippe De Muyter wrote: > On Wed, May 25, 2016 at 03:34:55AM -0400, George Spelvin wrote: >> Addition chains found by Yevgen Voronenko's Hcub algorithm at >> http://spiral.ece.cmu.edu/mcm/gen.html > Shouldn't you put that reference in the comments of your archhash.h file ? I don't really care

Re: [PATCH 08/10] m68k: Add

Philippe De Muyter wrote: > On Wed, May 25, 2016 at 03:34:55AM -0400, George Spelvin wrote: >> Addition chains found by Yevgen Voronenko's Hcub algorithm at >> http://spiral.ece.cmu.edu/mcm/gen.html > Shouldn't you put that reference in the comments of your archhash.h file ? I don't really care

Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

On Wed, May 25, 2016 at 11:49:12AM +0100, Jose Abreu wrote: > Ok, will do that. I noticed the last I2S patch that you merged > ("ASoC: dwc: Add helper functions to disable/enable irqs") is not > in for-next yet. Should I base my work on 'topic/dwc' branch? We are in the merge window. No new

Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

On Wed, May 25, 2016 at 11:49:12AM +0100, Jose Abreu wrote: > Ok, will do that. I noticed the last I2S patch that you merged > ("ASoC: dwc: Add helper functions to disable/enable irqs") is not > in for-next yet. Should I base my work on 'topic/dwc' branch? We are in the merge window. No new

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