[PATCH v3 05/14] metag: use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Acked-by: James Hogan Cc: James Hogan Signed-off-by: Kefeng Wang ---

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > This adds the regulator nodes to DK04 device tree to support > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > Signed-off-by: Sreedhar Sambangi > --- >

[PATCH v3 05/14] metag: use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Acked-by: James Hogan Cc: James Hogan Signed-off-by: Kefeng Wang --- arch/metag/kernel/setup.c | 3 +-- 1 file changed, 1 insertion(+), 2

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote: > This adds the regulator nodes to DK04 device tree to support > > Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa > Signed-off-by: Sreedhar Sambangi > --- > .../bindings/regulator/ipq4019-regulator.txt | 19 >

[PATCH v3 07/14] nios2: use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Cc: Ley Foon Tan Signed-off-by: Kefeng Wang --- arch/nios2/platform/platform.c | 3 +-- 1 file

[PATCH v3 07/14] nios2: use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Cc: Ley Foon Tan Signed-off-by: Kefeng Wang --- arch/nios2/platform/platform.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[PATCH v3 00/14] use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Then it is possible for driver code build as a module, and no need to export of_default_bus_match_table anymore. This patchset is based on Linux

[PATCH v3 00/14] use of_platform_default_populate() to populate default bus

Use helper of_platform_default_populate() in linux/of_platform when possible, instead of calling of_platform_populate() with the default match table. Then it is possible for driver code build as a module, and no need to export of_default_bus_match_table anymore. This patchset is based on Linux

RE: [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular

> -Original Message- > From: rcoch...@linutronix.de [mailto:rcoch...@linutronix.de] > Sent: Tuesday, April 05, 2016 12:30 AM > To: Brown, Len > Cc: Gortmaker, Paul (Wind River); linux-kernel@vger.kernel.org; Len Brown; > linux...@vger.kernel.org > Subject: Re: [PATCH] drivers/idle: make

Re: [PATCH 2/2] qcom: ipq4019: Add LDO regulator driver for SDHC controller

On Mon, Apr 04, 2016 at 02:08:24PM -0700, Sreedhar Sambangi wrote: > From: Kirthik Srinivasan > > Add LDO regulator driver to enable SD /MMC card to > switch between 3.0 volts and 1.8 volts > > Change-Id: I66f770878570b1f5b1db044ba626e0f6989acc3f > Signed-off-by:

RE: [PATCH] drivers/idle: make intel_idle.c driver more explicitly non-modular

> -Original Message- > From: rcoch...@linutronix.de [mailto:rcoch...@linutronix.de] > Sent: Tuesday, April 05, 2016 12:30 AM > To: Brown, Len > Cc: Gortmaker, Paul (Wind River); linux-kernel@vger.kernel.org; Len Brown; > linux...@vger.kernel.org > Subject: Re: [PATCH] drivers/idle: make

Re: [PATCH 2/2] qcom: ipq4019: Add LDO regulator driver for SDHC controller

On Mon, Apr 04, 2016 at 02:08:24PM -0700, Sreedhar Sambangi wrote: > From: Kirthik Srinivasan > > Add LDO regulator driver to enable SD /MMC card to > switch between 3.0 volts and 1.8 volts > > Change-Id: I66f770878570b1f5b1db044ba626e0f6989acc3f > Signed-off-by: Kirthik Srinivasan >

[PATCH v4] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()

Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code duplicate with new dw8250_check_lcr()") introduce a wrong logic when write val to LCR reg. When CONFIG_64BIT enabled, __raw_writeq is used unconditionally. The __raw_readq/__raw_writeq is introduced by commit bca2092d7897 ("serial:

[PATCH v4] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()

Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code duplicate with new dw8250_check_lcr()") introduce a wrong logic when write val to LCR reg. When CONFIG_64BIT enabled, __raw_writeq is used unconditionally. The __raw_readq/__raw_writeq is introduced by commit bca2092d7897 ("serial:

RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

Hi Eric, Thanks for the comments. > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM > To: Wei-Ning Huang > Cc: Kalle Valo; Linux Wireless; LKML; Amitkumar Karwar; Nishant > Sarmukadam; Sameer Nanda; net...@vger.kernel.org; Sonny Rao; Douglas > Anderson

RE: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

Hi Eric, Thanks for the comments. > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM > To: Wei-Ning Huang > Cc: Kalle Valo; Linux Wireless; LKML; Amitkumar Karwar; Nishant > Sarmukadam; Sameer Nanda; net...@vger.kernel.org; Sonny Rao; Douglas > Anderson

Re: [PATCHv2 6/7] ARM: socfpga: Enable Arria10 OCRAM ECC on startup

On Tue, Apr 05, 2016 at 12:25:33AM -0500, Thor Thayer wrote: > I realize that I'm not calling iounmap(ecc_block_base) and I'll fix that in > the next revision with a goto. I'm assuming nothing else changes. Because I've applied 1-4 already. Yes, no? If no, then please send only an updated

Re: [PATCHv2 6/7] ARM: socfpga: Enable Arria10 OCRAM ECC on startup

On Tue, Apr 05, 2016 at 12:25:33AM -0500, Thor Thayer wrote: > I realize that I'm not calling iounmap(ecc_block_base) and I'll fix that in > the next revision with a goto. I'm assuming nothing else changes. Because I've applied 1-4 already. Yes, no? If no, then please send only an updated

[PATCH v3 3/9] drm/fsl-dcu: disable clock on initialization failure and remove

Fix error handling during probe by reordering initialization and adding a error path which disables clock again. Also disable the clock on remove. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 44 +++ 1 file changed, 21

[PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

The Vybrid DCU variant has two independent clock inputs, one for the registers (IPG bus clock) and one for the pixel clock. Support this distinction in the DCU DRM driver while staying backward compatible for old device trees. Signed-off-by: Stefan Agner ---

[PATCH v3 4/9] drm/fsl-dcu: add extra clock for pixel clock

The Vybrid DCU variant has two independent clock inputs, one for the registers (IPG bus clock) and one for the pixel clock. Support this distinction in the DCU DRM driver while staying backward compatible for old device trees. Signed-off-by: Stefan Agner ---

[PATCH v3 3/9] drm/fsl-dcu: disable clock on initialization failure and remove

Fix error handling during probe by reordering initialization and adding a error path which disables clock again. Also disable the clock on remove. Signed-off-by: Stefan Agner --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 44 +++ 1 file changed, 21 insertions(+), 23

[PATCH v3 6/9] drm/fsl-dcu: add TCON driver

Add driver for the TCON (timing controller) module. The TCON module is a separate module attached after the DCU (display controller unit). Each DCU instance has its own, directly connected TCON instance. The DCU's RGB and timing signals are passing through the TCON module. TCON can provide timing

[PATCH v3 8/9] ARM: dts: vf610-colibri: enable display controller

Enable dcu node which is used by the DCU DRM driver. Assign the 5.7" EDT panel with VGA resolution which Toradex sells often with the evaluation board. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 16 +++

[PATCH v3 5/9] drm/fsl-dcu: use common clock framework for pixel clock divider

Use the common clock framework to calculate the pixel clock dividier. The previous implementation rounded down the calculated factor. Thanks to the CLK_DIVIDER_ROUND_CLOSEST flag using the common clock framework divider implementation improves the pixel clock accuracy in some cases. Ontop of that

[PATCH v3 6/9] drm/fsl-dcu: add TCON driver

Add driver for the TCON (timing controller) module. The TCON module is a separate module attached after the DCU (display controller unit). Each DCU instance has its own, directly connected TCON instance. The DCU's RGB and timing signals are passing through the TCON module. TCON can provide timing

[PATCH v3 8/9] ARM: dts: vf610-colibri: enable display controller

Enable dcu node which is used by the DCU DRM driver. Assign the 5.7" EDT panel with VGA resolution which Toradex sells often with the evaluation board. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 16 +++ arch/arm/boot/dts/vf-colibri.dtsi | 33

[PATCH v3 5/9] drm/fsl-dcu: use common clock framework for pixel clock divider

Use the common clock framework to calculate the pixel clock dividier. The previous implementation rounded down the calculated factor. Thanks to the CLK_DIVIDER_ROUND_CLOSEST flag using the common clock framework divider implementation improves the pixel clock accuracy in some cases. Ontop of that

[PATCH v3 9/9] ARM: dts: ls1021a: add pix clock to DCU dts node

The DCU IP has distinct clock inputs for register access and the pixel clocks, at least in some implementations. LS1021a seems to use the same clock, therefore specify the same clock for "dcu" and "pix". Signed-off-by: Stefan Agner --- arch/arm/boot/dts/ls1021a.dtsi | 5 +++--

[PATCH v3 7/9] ARM: dts: vf610: add display nodes

Add the dcu and tcon nodes to enable the Display Controller Unit and Timing Controller in Vybrid's SoC level device-tree file. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vfxxx.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git

[PATCH v3 9/9] ARM: dts: ls1021a: add pix clock to DCU dts node

The DCU IP has distinct clock inputs for register access and the pixel clocks, at least in some implementations. LS1021a seems to use the same clock, therefore specify the same clock for "dcu" and "pix". Signed-off-by: Stefan Agner --- arch/arm/boot/dts/ls1021a.dtsi | 5 +++-- 1 file changed, 3

[PATCH v3 7/9] ARM: dts: vf610: add display nodes

Add the dcu and tcon nodes to enable the Display Controller Unit and Timing Controller in Vybrid's SoC level device-tree file. Signed-off-by: Stefan Agner --- arch/arm/boot/dts/vfxxx.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/boot/dts/vfxxx.dtsi

[PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy mixes the bus clock with the display controllers pixel clock. Tests have shown that the gates in CCM_CCGR3/9 registers do not control the DCU pixel clock, but only the register access clock (bus clock). Fix this by defining the

[PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy mixes the bus clock with the display controllers pixel clock. Tests have shown that the gates in CCM_CCGR3/9 registers do not control the DCU pixel clock, but only the register access clock (bus clock). Fix this by defining the

[PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

I think this bug needs to be fixed, this way or another. The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for

[PATCH v3 0/9] add TCON and Vybrid support

This patchset adds the missing pieces to make the Freescale DCU DRM driver work on Freescale Vybrid. Foremost, it adds support for the timing controller (TCON) module. The module is between the Display Controller and the actual output pins. It allows to alter the timings for RAW TFT displays, but

[PATCH v3 2/9] ARM: imx: clk-vf610: add TCON ipg clock

Add the ipg (bus) clock for the TCON modules (Timing Controller). This module is required by the new DCU DRM driver, since the display signals pass through TCON. Signed-off-by: Stefan Agner --- drivers/clk/imx/clk-vf610.c | 3 +++

[PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

I think this bug needs to be fixed, this way or another. The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for

[PATCH v3 0/9] add TCON and Vybrid support

This patchset adds the missing pieces to make the Freescale DCU DRM driver work on Freescale Vybrid. Foremost, it adds support for the timing controller (TCON) module. The module is between the Display Controller and the actual output pins. It allows to alter the timings for RAW TFT displays, but

[PATCH v3 2/9] ARM: imx: clk-vf610: add TCON ipg clock

Add the ipg (bus) clock for the TCON modules (Timing Controller). This module is required by the new DCU DRM driver, since the display signals pass through TCON. Signed-off-by: Stefan Agner --- drivers/clk/imx/clk-vf610.c | 3 +++ include/dt-bindings/clock/vf610-clock.h | 4 +++- 2

Re: [PATCH v2] parport: register driver later

On Mon, Mar 07, 2016 at 10:32:55AM -0700, Ross Zwisler wrote: > On Sun, Mar 06, 2016 at 08:40:10PM +0530, Sudip Mukherjee wrote: > > If the parport bus is not yet registered and any device using parallel > > port tries to register with the bus we get a stackdump with a message > > of Kernel bug. >

Re: [PATCH v2] parport: register driver later

On Mon, Mar 07, 2016 at 10:32:55AM -0700, Ross Zwisler wrote: > On Sun, Mar 06, 2016 at 08:40:10PM +0530, Sudip Mukherjee wrote: > > If the parport bus is not yet registered and any device using parallel > > port tries to register with the bus we get a stackdump with a message > > of Kernel bug. >

Re: [PATCH] perf config: Fix build with older toolchain.

Hi, On 04/05/2016 07:07 AM, Vinson Lee wrote: Fix build error on Ubuntu 12.04.5 with GCC 4.6.3. CC util/config.o util/config.c: In function ‘perf_buildid_config’: util/config.c:384:15: error: declaration of ‘dirname’ shadows a global declaration [-Werror=shadow] I'm sorry, lately I

Re: [PATCH] perf config: Fix build with older toolchain.

Hi, On 04/05/2016 07:07 AM, Vinson Lee wrote: Fix build error on Ubuntu 12.04.5 with GCC 4.6.3. CC util/config.o util/config.c: In function ‘perf_buildid_config’: util/config.c:384:15: error: declaration of ‘dirname’ shadows a global declaration [-Werror=shadow] I'm sorry, lately I

Re: [PATCH] usb: dwc3: keystone: drop dma_mask configuration

Hi, Grygorii Strashko writes: > On 04/04/2016 02:45 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> The Keystone 2 supports DT-boot only, as result dma_mask will be >>> always configured properly from DT - >>>

Re: [PATCH] usb: dwc3: keystone: drop dma_mask configuration

Hi, Grygorii Strashko writes: > On 04/04/2016 02:45 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> The Keystone 2 supports DT-boot only, as result dma_mask will be >>> always configured properly from DT - >>> of_platform_device_create_pdata()->of_dma_configure(). More

Re: [PATCHv2 6/7] ARM: socfpga: Enable Arria10 OCRAM ECC on startup

Hi, On 03/31/2016 01:48 PM, ttha...@opensource.altera.com wrote: From: Thor Thayer Enable ECC for Arria10 On-Chip RAM on machine startup. The ECC has to be enabled and memory initialized before data is stored in memory otherwise the ECC will fail on reads.

Re: [PATCHv2 6/7] ARM: socfpga: Enable Arria10 OCRAM ECC on startup

Hi, On 03/31/2016 01:48 PM, ttha...@opensource.altera.com wrote: From: Thor Thayer Enable ECC for Arria10 On-Chip RAM on machine startup. The ECC has to be enabled and memory initialized before data is stored in memory otherwise the ECC will fail on reads. Signed-off-by: Thor Thayer --- v2:

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

santosh shilimkar writes: > On 4/3/2016 11:28 PM, Felipe Balbi wrote: >> santosh shilimkar writes: >>> +Arnd, RMK, >>> >>> On 4/1/2016 4:57 AM, Felipe Balbi wrote: Hi, Grygorii Strashko

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

santosh shilimkar writes: > On 4/3/2016 11:28 PM, Felipe Balbi wrote: >> santosh shilimkar writes: >>> +Arnd, RMK, >>> >>> On 4/1/2016 4:57 AM, Felipe Balbi wrote: Hi, Grygorii Strashko writes: > On 04/01/2016 01:20 PM, Felipe Balbi wrote: >>> >>> [...] >>> > commit

Re: [PATCH v10 1/2] printk: Make printk() completely async

Hello Andrew, On (04/04/16 15:51), Andrew Morton wrote: [..] > The whole idea remains worrisome. It is definitely making printk() > less reliable in the vast majority of cases: what happens if the > scheduler is busted or random memory has been scribbled on, etc. yes. well, printk, in some

Re: [PATCH v10 1/2] printk: Make printk() completely async

Hello Andrew, On (04/04/16 15:51), Andrew Morton wrote: [..] > The whole idea remains worrisome. It is definitely making printk() > less reliable in the vast majority of cases: what happens if the > scheduler is busted or random memory has been scribbled on, etc. yes. well, printk, in some

[PATCH v4 1/6] xen: sync xen header

Import the actual version of include/xen/interface/sched.h from Xen. Signed-off-by: Juergen Gross --- include/xen/interface/sched.h | 100 ++ 1 file changed, 82 insertions(+), 18 deletions(-) diff --git a/include/xen/interface/sched.h

[PATCH v4 5/6] dcdbas: make use of smp_call_on_cpu()

Use smp_call_on_cpu() to raise SMI on cpu 0. Make call secure by adding get_online_cpus() to avoid e.g. suspend resume cycles in between. Signed-off-by: Juergen Gross --- V4: add call to get_online_cpus() --- drivers/firmware/dcdbas.c | 51

[PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu

On some hardware models (e.g. Dell Studio 1555 laptop) some hardware related functions (e.g. SMIs) are to be executed on physical cpu 0 only. Instead of open coding such a functionality multiple times in the kernel add a service function for this purpose. This will enable the possibility to take

[PATCH v4 1/6] xen: sync xen header

Import the actual version of include/xen/interface/sched.h from Xen. Signed-off-by: Juergen Gross --- include/xen/interface/sched.h | 100 ++ 1 file changed, 82 insertions(+), 18 deletions(-) diff --git a/include/xen/interface/sched.h

[PATCH v4 5/6] dcdbas: make use of smp_call_on_cpu()

Use smp_call_on_cpu() to raise SMI on cpu 0. Make call secure by adding get_online_cpus() to avoid e.g. suspend resume cycles in between. Signed-off-by: Juergen Gross --- V4: add call to get_online_cpus() --- drivers/firmware/dcdbas.c | 51 --- 1 file

[PATCH v4 3/6] smp: add function to execute a function synchronously on a cpu

On some hardware models (e.g. Dell Studio 1555 laptop) some hardware related functions (e.g. SMIs) are to be executed on physical cpu 0 only. Instead of open coding such a functionality multiple times in the kernel add a service function for this purpose. This will enable the possibility to take

[PATCH v4 2/6] virt, sched: add generic vcpu pinning support

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Signed-off-by: Juergen Gross

[PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

Use the smp_call_on_cpu() function to call system management mode on cpu 0. Make call secure by adding get_online_cpus() to avoid e.g. suspend resume cycles in between. Signed-off-by: Juergen Gross --- V4: add call to get_online_cpus() --- drivers/hwmon/dell-smm-hwmon.c | 35

[PATCH v4 2/6] virt, sched: add generic vcpu pinning support

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Signed-off-by: Juergen Gross

[PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

Use the smp_call_on_cpu() function to call system management mode on cpu 0. Make call secure by adding get_online_cpus() to avoid e.g. suspend resume cycles in between. Signed-off-by: Juergen Gross --- V4: add call to get_online_cpus() --- drivers/hwmon/dell-smm-hwmon.c | 35

[PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu

Some hardware models (e.g. Dell Studio 1555 laptops) require calls to the firmware to be issued on cpu 0 only. As Dom0 might have to use these calls, add xen_pin_vcpu() to achieve this functionality. In case either the domain doesn't have the privilege to make the related hypercall or the

[PATCH v4 0/6] Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This

[PATCH v4 4/6] xen: add xen_pin_vcpu() to support calling functions on a dedicated pcpu

Some hardware models (e.g. Dell Studio 1555 laptops) require calls to the firmware to be issued on cpu 0 only. As Dom0 might have to use these calls, add xen_pin_vcpu() to achieve this functionality. In case either the domain doesn't have the privilege to make the related hypercall or the

[PATCH v4 0/6] Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to be called on physical cpu 0 in order to avoid occasional hangs. When running as dom0 under Xen this could be achieved only via special boot parameters (vcpu pinning) limiting the hypervisor in it's scheduling decisions. This

Re: [PATCH char-misc-linus] misc: mic: Fix randconfig build error

On Mon, 2016-04-04 at 21:41 -0700, Greg Kroah-Hartman wrote: > On Mon, Apr 04, 2016 at 09:32:30PM -0700, Sudeep Dutt wrote: > > Fixes randconfig build error reported at > > https://lkml.org/lkml/2016/4/3/135 by ensuring that > > the VOP driver selects VIRTIO. > > > > Reported-by: Fengguang Wu

Re: [PATCH char-misc-linus] misc: mic: Fix randconfig build error

On Mon, 2016-04-04 at 21:41 -0700, Greg Kroah-Hartman wrote: > On Mon, Apr 04, 2016 at 09:32:30PM -0700, Sudeep Dutt wrote: > > Fixes randconfig build error reported at > > https://lkml.org/lkml/2016/4/3/135 by ensuring that > > the VOP driver selects VIRTIO. > > > > Reported-by: Fengguang Wu >

[GIT PULL] extcon fixes for 4.6-rc3

Dear Greg, This is extcon fixes pull request for v4.6-rc3. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03

[GIT PULL] extcon fixes for 4.6-rc3

Dear Greg, This is extcon fixes pull request for v4.6-rc3. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03

[PATCH net-next 4/8] bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs

needs two wrapper functions to fetch 'struct pt_regs *' to convert tracepoint bpf context into kprobe bpf context to reuse existing helper functions Signed-off-by: Alexei Starovoitov --- include/linux/bpf.h | 1 + kernel/bpf/stackmap.c| 2 +- kernel/trace/bpf_trace.c

[PATCH net-next 4/8] bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs

needs two wrapper functions to fetch 'struct pt_regs *' to convert tracepoint bpf context into kprobe bpf context to reuse existing helper functions Signed-off-by: Alexei Starovoitov --- include/linux/bpf.h | 1 + kernel/bpf/stackmap.c| 2 +- kernel/trace/bpf_trace.c | 42

Re: [PATCH v3] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()

On 2016/4/5 12:02, Greg Kroah-Hartman wrote: > On Tue, Apr 05, 2016 at 11:32:46AM +0800, Kefeng Wang wrote: >> Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code duplicate >> with new dw8250_check_lcr()") introduce a wrong logic when write val to >> LCR reg. When CONFIG_64BIT enabled,

[PATCH net-next 3/8] bpf: register BPF_PROG_TYPE_TRACEPOINT program type

register tracepoint bpf program type and let it call the same set of helper functions as BPF_PROG_TYPE_KPROBE Signed-off-by: Alexei Starovoitov --- kernel/trace/bpf_trace.c | 45 +++-- 1 file changed, 43 insertions(+), 2 deletions(-)

[PATCH net-next 7/8] samples/bpf: tracepoint example

modify offwaketime to work with sched/sched_switch tracepoint instead of kprobe into finish_task_switch Signed-off-by: Alexei Starovoitov --- samples/bpf/offwaketime_kern.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

[PATCH net-next 3/8] bpf: register BPF_PROG_TYPE_TRACEPOINT program type

register tracepoint bpf program type and let it call the same set of helper functions as BPF_PROG_TYPE_KPROBE Signed-off-by: Alexei Starovoitov --- kernel/trace/bpf_trace.c | 45 +++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git

[PATCH net-next 7/8] samples/bpf: tracepoint example

modify offwaketime to work with sched/sched_switch tracepoint instead of kprobe into finish_task_switch Signed-off-by: Alexei Starovoitov --- samples/bpf/offwaketime_kern.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

Re: [PATCH v3] serial: 8250_dw: fix wrong logic in dw8250_check_lcr()

On 2016/4/5 12:02, Greg Kroah-Hartman wrote: > On Tue, Apr 05, 2016 at 11:32:46AM +0800, Kefeng Wang wrote: >> Commit cdcea058e510 ("serial: 8250_dw: Avoid serial_outx code duplicate >> with new dw8250_check_lcr()") introduce a wrong logic when write val to >> LCR reg. When CONFIG_64BIT enabled,

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

On Fri, Apr 1, 2016 at 8:31 AM, kbuild test robot wrote: > Hi Vivek, > > [auto build test ERROR on rockchip/for-next] > [also build test ERROR on v4.6-rc1 next-20160401] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > >

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

On Fri, Apr 1, 2016 at 8:31 AM, kbuild test robot wrote: > Hi Vivek, > > [auto build test ERROR on rockchip/for-next] > [also build test ERROR on v4.6-rc1 next-20160401] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: >

[PATCH net-next 0/8] allow bpf attach to tracepoints

Hi Steven, Peter, last time we discussed bpf+tracepoints it was a year ago [1] and the reason we didn't proceed with that approach was that bpf would make arguments arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf program and that was considered unnecessary extension of abi. Back then

[PATCH net-next 5/8] bpf: sanitize bpf tracepoint access

during bpf program loading remember the last byte of ctx access and at the time of attaching the program to tracepoint check that the program doesn't access bytes beyond defined in tracepoint fields This also disallows access to __dynamic_array fields, but can be relaxed in the future.

[PATCH net-next 0/8] allow bpf attach to tracepoints

Hi Steven, Peter, last time we discussed bpf+tracepoints it was a year ago [1] and the reason we didn't proceed with that approach was that bpf would make arguments arg1, arg2 to trace_xx(arg1, arg2) call to be exposed to bpf program and that was considered unnecessary extension of abi. Back then

[PATCH net-next 5/8] bpf: sanitize bpf tracepoint access

during bpf program loading remember the last byte of ctx access and at the time of attaching the program to tracepoint check that the program doesn't access bytes beyond defined in tracepoint fields This also disallows access to __dynamic_array fields, but can be relaxed in the future.

[PATCH net-next 6/8] samples/bpf: add tracepoint support to bpf loader

Recognize "tracepoint/" section name prefix and attach the program to that tracepoint. Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/samples/bpf/bpf_load.c

[PATCH net-next 1/8] perf: optimize perf_fetch_caller_regs

avoid memset in perf_fetch_caller_regs, since it's the critical path of all tracepoints. It's called from perf_sw_event_sched, perf_event_task_sched_in and all of perf_trace_##call with this_cpu_ptr(&__perf_regs[..]) which are zero initialized by perpcu_alloc and subsequent call to

[PATCH net-next 6/8] samples/bpf: add tracepoint support to bpf loader

Recognize "tracepoint/" section name prefix and attach the program to that tracepoint. Signed-off-by: Alexei Starovoitov --- samples/bpf/bpf_load.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c

[PATCH net-next 1/8] perf: optimize perf_fetch_caller_regs

avoid memset in perf_fetch_caller_regs, since it's the critical path of all tracepoints. It's called from perf_sw_event_sched, perf_event_task_sched_in and all of perf_trace_##call with this_cpu_ptr(&__perf_regs[..]) which are zero initialized by perpcu_alloc and subsequent call to

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

On 2016/04/04 at 22:58, Michael Holzheu wrote: > Hello Xunlei, > > On Sat, 2 Apr 2016 09:23:50 +0800 > Xunlei Pang wrote: > >> On 2016/04/02 at 01:41, Michael Holzheu wrote: >>> Hello Xunlei again, >>> >>> Some initial comments below... >>> >>> On Wed, 30 Mar 2016 19:47:21 +0800

Re: [PATCH] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()

On 2016/04/04 at 22:58, Michael Holzheu wrote: > Hello Xunlei, > > On Sat, 2 Apr 2016 09:23:50 +0800 > Xunlei Pang wrote: > >> On 2016/04/02 at 01:41, Michael Holzheu wrote: >>> Hello Xunlei again, >>> >>> Some initial comments below... >>> >>> On Wed, 30 Mar 2016 19:47:21 +0800 >>> Xunlei Pang

[PATCH net-next 8/8] samples/bpf: add tracepoint vs kprobe performance tests

the first microbenchmark does fd=open("/proc/self/comm"); for() { write(fd, "test"); } and on 4 cpus in parallel: writes per sec base (no tracepoints, no kprobes) 930k with kprobe at __set_task_comm() 420k with tracepoint at task:task_rename

[PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached to tracepoints. The tracepoint will copy the arguments in the per-cpu buffer and pass it to the bpf program as its first argument. The layout of the fields can be discovered by doing 'cat

[PATCH net-next 8/8] samples/bpf: add tracepoint vs kprobe performance tests

the first microbenchmark does fd=open("/proc/self/comm"); for() { write(fd, "test"); } and on 4 cpus in parallel: writes per sec base (no tracepoints, no kprobes) 930k with kprobe at __set_task_comm() 420k with tracepoint at task:task_rename

[PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be attached to tracepoints. The tracepoint will copy the arguments in the per-cpu buffer and pass it to the bpf program as its first argument. The layout of the fields can be discovered by doing 'cat

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi Krzysztof, On Sat, Apr 2, 2016 at 11:05 PM, Krzysztof Kozlowski wrote: > On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote: >> Adding vendor specific directories in phy to group >> phy drivers under their respective vendor umbrella. >> >> Signed-off-by:

Re: [PATCH 1/2] phy: Group vendor specific phy drivers

Hi Krzysztof, On Sat, Apr 2, 2016 at 11:05 PM, Krzysztof Kozlowski wrote: > On Fri, Apr 01, 2016 at 04:59:15PM +0530, Vivek Gautam wrote: >> Adding vendor specific directories in phy to group >> phy drivers under their respective vendor umbrella. >> >> Signed-off-by: Vivek Gautam >> --- >> >>

linux-next: Tree for Apr 5

Hi all, Changes since 20160404: The btrfs-kdave tree gained conflicts Linus' tree. The ceph tree gained conflicts Linus' tree. The staging tree gained conflicts against the staging.current and Linus' trees. Non-merge commits (relative to Linus' tree): 2132 2023 files changed, 82827

linux-next: Tree for Apr 5

Hi all, Changes since 20160404: The btrfs-kdave tree gained conflicts Linus' tree. The ceph tree gained conflicts Linus' tree. The staging tree gained conflicts against the staging.current and Linus' trees. Non-merge commits (relative to Linus' tree): 2132 2023 files changed, 82827

Re: linux-next: manual merge of the staging tree with the staging.current tree

On Tue, Apr 05, 2016 at 01:03:26PM +1000, Stephen Rothwell wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/iio/gyro/bmg160_core.c > > between commit: > > b475c59b113d ("iio: gyro: bmg160: fix buffer read values") > > from the

Re: linux-next: manual merge of the staging tree with the staging.current tree

On Tue, Apr 05, 2016 at 01:03:26PM +1000, Stephen Rothwell wrote: > Hi Greg, > > Today's linux-next merge of the staging tree got a conflict in: > > drivers/iio/gyro/bmg160_core.c > > between commit: > > b475c59b113d ("iio: gyro: bmg160: fix buffer read values") > > from the

  1   2   3   4   5   6   7   8   9   10   >