Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi, On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote: >> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote: >> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform >>> b/Documentation/ABI/testing/sysfs-bus-platform >>>

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi, On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote: >> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote: >> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform >>> b/Documentation/ABI/testing/sysfs-bus-platform >>>

Re: [PATCH V2 01/30] bitops: add parity functions

在 2016年04月06日 03:04, Sam Ravnborg 写道: On Tue, Apr 05, 2016 at 10:06:21AM +0800, Zeng Zhaoxiu wrote: From: Zhaoxiu Zeng These patches provide generic and architecture-specific odd parity calculations. Hi Zeng. Can you please fix your mail script. I see only 1/30 (sent

Re: [PATCH V2 01/30] bitops: add parity functions

在 2016年04月06日 03:04, Sam Ravnborg 写道: On Tue, Apr 05, 2016 at 10:06:21AM +0800, Zeng Zhaoxiu wrote: From: Zhaoxiu Zeng These patches provide generic and architecture-specific odd parity calculations. Hi Zeng. Can you please fix your mail script. I see only 1/30 (sent to linux-arch) - and

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

On (04/05/16 17:02), Rui Salvaterra wrote: [..] > > For some reason it never got merged, sorry, I don't remember why. > > > > Have you tested this patch? If so, can you resend it with your > > tested-by: line added to it? > > > > thanks, > > > > greg k-h > > Hi, Greg > > > No, I haven't tested

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

On (04/05/16 17:02), Rui Salvaterra wrote: [..] > > For some reason it never got merged, sorry, I don't remember why. > > > > Have you tested this patch? If so, can you resend it with your > > tested-by: line added to it? > > > > thanks, > > > > greg k-h > > Hi, Greg > > > No, I haven't tested

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

On Wed, 30 Mar 2016, Jiri Kosina wrote: > > __module_put_and_exit() is makred noreturn in module.h declaration, but is > > lacking the attribute in the definition, which makes some tools (such as > > sparse) unhappy. Amend the definition with the attribute as well (and > > reformat the

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

On Wed, 30 Mar 2016, Jiri Kosina wrote: > > __module_put_and_exit() is makred noreturn in module.h declaration, but is > > lacking the attribute in the definition, which makes some tools (such as > > sparse) unhappy. Amend the definition with the attribute as well (and > > reformat the

[PATCH 8/9] iio: health: afe4404: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4404.c | 38

[PATCH 8/9] iio: health: afe4404: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4404.c | 38

[PATCH 9/9] iio: gyro: bmg160_core: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/gyro/bmg160_core.c | 86

Re: [RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

Hi, On 04/05/2016 11:44 PM, Brian Norris wrote: > + Mark, Cyrille > > On Tue, Mar 29, 2016 at 11:16:17AM +0530, Vignesh R wrote: >> Certain SPI controllers may provide accelerated hardware interface to >> read from m25p80 type flash devices in order to provide better read >> performance. SPI

[PATCH 9/9] iio: gyro: bmg160_core: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/gyro/bmg160_core.c | 86

Re: [RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

Hi, On 04/05/2016 11:44 PM, Brian Norris wrote: > + Mark, Cyrille > > On Tue, Mar 29, 2016 at 11:16:17AM +0530, Vignesh R wrote: >> Certain SPI controllers may provide accelerated hardware interface to >> read from m25p80 type flash devices in order to provide better read >> performance. SPI

[PATCH 7/9] iio: health: afe4403: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4403.c | 36

[PATCH 7/9] iio: health: afe4403: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4403.c | 36 +---

[PATCH 5/9] iio: accel: mma7455: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/mma7455_core.c | 5 ++--- 1

[PATCH 6/9] iio: accel: mxc4005: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/mxc4005.c | 26

[PATCH 5/9] iio: accel: mma7455: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/mma7455_core.c | 5 ++--- 1 file changed, 2

[PATCH 6/9] iio: accel: mxc4005: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/mxc4005.c | 26 +++--- 1 file

[PATCH 3/9] iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/qcom-spmi-vadc.c | 37

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

On 04/06/2016 12:47 PM, Andy Lutomirski wrote: > On Apr 5, 2016 8:17 PM, "Alex Shi" wrote: >> >> It seems Intel core still share the TLB pool, flush both of threads' TLB >> just cause a extra useless IPI and a extra flush. The extra flush will >> flush out TLB again which

[RESEND PATCH v2 6/6] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

This patch adds support for the AXI Central Direct Memory Access (AXI CDMA) core to the existing vdma driver, AXI CDMA is a soft Xilinx IP core that provides high-bandwidth Direct Memory Access(DMA) between a memory-mapped source address and a memory-mapped destination address. Signed-off-by:

[RESEND PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

This patch updates the device-tree binding doc for adding support for AXI CDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Modified commit message as suggested by Vinod. ---> Moved the patch to forward in the series as suggested by vinod.

[PATCH 2/9] iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/qcom-spmi-iadc.c | 32

[PATCH 3/9] iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/qcom-spmi-vadc.c | 37

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

On 04/06/2016 12:47 PM, Andy Lutomirski wrote: > On Apr 5, 2016 8:17 PM, "Alex Shi" wrote: >> >> It seems Intel core still share the TLB pool, flush both of threads' TLB >> just cause a extra useless IPI and a extra flush. The extra flush will >> flush out TLB again which another thread just

[RESEND PATCH v2 6/6] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

This patch adds support for the AXI Central Direct Memory Access (AXI CDMA) core to the existing vdma driver, AXI CDMA is a soft Xilinx IP core that provides high-bandwidth Direct Memory Access(DMA) between a memory-mapped source address and a memory-mapped destination address. Signed-off-by:

[RESEND PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

This patch updates the device-tree binding doc for adding support for AXI CDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Modified commit message as suggested by Vinod. ---> Moved the patch to forward in the series as suggested by vinod.

[PATCH 2/9] iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/qcom-spmi-iadc.c | 32 +---

[RESEND PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

This patch updates the device-tree binding doc for adding support for AXI DMA. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Modified commit message as suggested by Vinod. ---> Moved the patch to forward in the series as suggested by vinod.

[PATCH 4/9] iio: accel: bmc150: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/bmc150-accel-core.c | 99

[RESEND PATCH v2 4/6] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

This patch adds support for the AXI Direct Memory Access (AXI DMA) core in the existing vdma driver, AXI DMA Core is a soft Xilinx IP core that provides high-bandwidth direct memory access between memory and AXI4-Stream type target peripherals. Signed-off-by: Kedareswara rao Appana

[RESEND PATCH v2 0/6] dmaengine: vdma: AXI DMA's enhancments

This patch series does some enhancments to the VDMA driver which includes --> Adding support for AXI DMA IP. --> Adding support for AXI CDMA IP. --> Fixing checkpatch warnings. Kedareswara rao Appana (6): dmaengine: vdma: Fix checkpatch.pl warnings dmaengine: vdma: Rename xilinx_vdma_ prefix

[RESEND PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

This patch updates the device-tree binding doc for adding support for AXI DMA. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> Modified commit message as suggested by Vinod. ---> Moved the patch to forward in the series as suggested by vinod.

[PATCH 4/9] iio: accel: bmc150: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/accel/bmc150-accel-core.c | 99

[RESEND PATCH v2 4/6] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

This patch adds support for the AXI Direct Memory Access (AXI DMA) core in the existing vdma driver, AXI DMA Core is a soft Xilinx IP core that provides high-bandwidth direct memory access between memory and AXI4-Stream type target peripherals. Signed-off-by: Kedareswara rao Appana --- Changes

[RESEND PATCH v2 0/6] dmaengine: vdma: AXI DMA's enhancments

This patch series does some enhancments to the VDMA driver which includes --> Adding support for AXI DMA IP. --> Adding support for AXI CDMA IP. --> Fixing checkpatch warnings. Kedareswara rao Appana (6): dmaengine: vdma: Fix checkpatch.pl warnings dmaengine: vdma: Rename xilinx_vdma_ prefix

[PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/exynos_adc.c | 18

[RESEND PATCH v2 2/6] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

This patch renames the xilinx_vdma_ prefix to xilinx_dma for the API's and masks that will be shared b/w three DMA IP cores. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> New patch as suggested by Laurent Pinchart. drivers/dma/xilinx/xilinx_vdma.c | 636

[RESEND PATCH v2 1/6] dmaengine: vdma: Fix checkpatch.pl warnings

This patch fixes the below checkpatch.pl warnings. WARNING: void function return statements are not generally useful + return; +} WARNING: void function return statements are not generally useful + return; +} WARNING: Missing a blank line after declarations + u32

[PATCH 0/9] iio: use regmap to retrieve struct device

These drivers include both struct regmap and struct device in their global data. Remove the redundant copy by deleting struct device from the drivers global data and using regmap API to retrieve when needed. This patchset removes all such redundancies in drivers/iio/. Patches created using

[PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield --- drivers/iio/adc/exynos_adc.c | 18 +- 1 file changed, 9

[RESEND PATCH v2 2/6] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

This patch renames the xilinx_vdma_ prefix to xilinx_dma for the API's and masks that will be shared b/w three DMA IP cores. Signed-off-by: Kedareswara rao Appana --- Changes for v2: ---> New patch as suggested by Laurent Pinchart. drivers/dma/xilinx/xilinx_vdma.c | 636

[RESEND PATCH v2 1/6] dmaengine: vdma: Fix checkpatch.pl warnings

This patch fixes the below checkpatch.pl warnings. WARNING: void function return statements are not generally useful + return; +} WARNING: void function return statements are not generally useful + return; +} WARNING: Missing a blank line after declarations + u32

[PATCH 0/9] iio: use regmap to retrieve struct device

These drivers include both struct regmap and struct device in their global data. Remove the redundant copy by deleting struct device from the drivers global data and using regmap API to retrieve when needed. This patchset removes all such redundancies in drivers/iio/. Patches created using

[RESEND PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

When VDMA is configured in Non-sg mode Users can queue descriptors greater than h/w configured frames. Current driver allows the user to queue descriptors upto h/w configured. Which is wrong for non-sg mode configuration. This patch fixes this issue. Signed-off-by: Kedareswara rao Appana

RE: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Wednesday, April 06, 2016 3:23 AM > To: Appana Durga Kedareswara Rao > Cc: dan.j.willi...@intel.com; Michal Simek ; Soren > Brinkmann ;

[RESEND PATCH v3 1/2] dmaengine: vdma: Add 64 bit addressing support to the driver

This VDMA is a soft ip, which can be programmed to support 32 bit addressing or greater than 32 bit addressing. When the VDMA ip is configured for 32 bit address space the buffer address is specified by a single register (0x5C for MM2S and 0xAC for S2MM channel). When the VDMA core is

[RESEND PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

When VDMA is configured in Non-sg mode Users can queue descriptors greater than h/w configured frames. Current driver allows the user to queue descriptors upto h/w configured. Which is wrong for non-sg mode configuration. This patch fixes this issue. Signed-off-by: Kedareswara rao Appana ---

RE: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Wednesday, April 06, 2016 3:23 AM > To: Appana Durga Kedareswara Rao > Cc: dan.j.willi...@intel.com; Michal Simek ; Soren > Brinkmann ; Appana Durga Kedareswara Rao > ; moritz.fisc...@ettus.com; >

[RESEND PATCH v3 1/2] dmaengine: vdma: Add 64 bit addressing support to the driver

This VDMA is a soft ip, which can be programmed to support 32 bit addressing or greater than 32 bit addressing. When the VDMA ip is configured for 32 bit address space the buffer address is specified by a single register (0x5C for MM2S and 0xAC for S2MM channel). When the VDMA core is

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

On 2016-04-04 22:53, Andy Gross wrote: 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:

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

On 2016-04-04 22:53, Andy Gross wrote: 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 4/4] irqchip: bcm2836: Use a more generic memory barrier call

On 04/04/2016 09:44 PM, Eric Anholt wrote: dsb() requires an argument on arm64, so we needed to add "sy". Instead, take this opportunity to switch to the same smp_wmb() call that gic uses for its IPIs. This is a less strong barrier than we were doing before (dmb(ishst) compared to dsb(sy)), but

Re: [PATCH 4/4] irqchip: bcm2836: Use a more generic memory barrier call

On 04/04/2016 09:44 PM, Eric Anholt wrote: dsb() requires an argument on arm64, so we needed to add "sy". Instead, take this opportunity to switch to the same smp_wmb() call that gic uses for its IPIs. This is a less strong barrier than we were doing before (dmb(ishst) compared to dsb(sy)), but

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

On 2016-04-04 22:59, Andy Gross wrote: 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 ---

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

On 2016-04-04 22:59, Andy Gross wrote: 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 ---

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

On Apr 5, 2016 8:17 PM, "Alex Shi" wrote: > > It seems Intel core still share the TLB pool, flush both of threads' TLB > just cause a extra useless IPI and a extra flush. The extra flush will > flush out TLB again which another thread just introduced. > That's double waste.

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

On Apr 5, 2016 8:17 PM, "Alex Shi" wrote: > > It seems Intel core still share the TLB pool, flush both of threads' TLB > just cause a extra useless IPI and a extra flush. The extra flush will > flush out TLB again which another thread just introduced. > That's double waste. Do you have a

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 5 April 2016 at 18:37, Jacek Anaszewski wrote: > Hi Ezequiel, > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devicetree boolean property to mark >> which

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

On 5 April 2016 at 18:37, Jacek Anaszewski wrote: > Hi Ezequiel, > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> It's desirable to specify which LEDs are to be blinked on a kernel >> panic. Therefore, introduce a devicetree boolean property to mark >> which LEDs should be treated this

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

On 5 April 2016 at 18:36, Jacek Anaszewski wrote: > Hi Ezequiel, > > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> Now that we can mark any LED (even those in use by delayed blink >> triggers) to trigger on a kernel panic, let's introduce a nosleep >>

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

On 5 April 2016 at 18:36, Jacek Anaszewski wrote: > Hi Ezequiel, > > > On 04/04/2016 10:22 PM, Ezequiel Garcia wrote: >> >> Now that we can mark any LED (even those in use by delayed blink >> triggers) to trigger on a kernel panic, let's introduce a nosleep >> led_trigger_event API. >> >> This

Re: [PATCH v2] arm: omap2: remove redundant multiplatform checks

On Wednesday 06 April 2016 04:05 AM, Jonas Rabenstein wrote: > The directory arch/arm/mach-omap2 is only selected for compilation if > CONFIG_ARCH_OMAP2PLUS is selected. CONFIG_ARCH_OMAP2PLUS itself is a > silent option and all machines selecting this option are multiplatform > devices. As a

Re: [PATCH v2] arm: omap2: remove redundant multiplatform checks

On Wednesday 06 April 2016 04:05 AM, Jonas Rabenstein wrote: > The directory arch/arm/mach-omap2 is only selected for compilation if > CONFIG_ARCH_OMAP2PLUS is selected. CONFIG_ARCH_OMAP2PLUS itself is a > silent option and all machines selecting this option are multiplatform > devices. As a

linux-next: Tree for Apr 6

Hi all, Changes since 20160405: Non-merge commits (relative to Linus' tree): 2369 2200 files changed, 93285 insertions(+), 58570 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm

linux-next: Tree for Apr 6

Hi all, Changes since 20160405: Non-merge commits (relative to Linus' tree): 2369 2200 files changed, 93285 insertions(+), 58570 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm

Re: [PATCH 01/27] block: bio: introduce 4 helpers for cleanup

On Wed, Apr 6, 2016 at 10:21 AM, Kent Overstreet wrote: > On Wed, Apr 06, 2016 at 10:11:27AM +0800, Ming Lei wrote: >> On Wed, Apr 6, 2016 at 9:46 AM, Kent Overstreet >> wrote: >> > On Wed, Apr 06, 2016 at 09:34:34AM +0800, Ming Lei wrote: >>

Re: [PATCH 01/27] block: bio: introduce 4 helpers for cleanup

On Wed, Apr 6, 2016 at 10:21 AM, Kent Overstreet wrote: > On Wed, Apr 06, 2016 at 10:11:27AM +0800, Ming Lei wrote: >> On Wed, Apr 6, 2016 at 9:46 AM, Kent Overstreet >> wrote: >> > On Wed, Apr 06, 2016 at 09:34:34AM +0800, Ming Lei wrote: >> >> On Wed, Apr 6, 2016 at 8:18 AM, Kent Overstreet >>

[PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

Replace the code that guarantees the device stays in direct mode with iio_device_{claim|release}_direct_mode() which does same. Signed-off-by: Alison Schofield --- Changed in v2: - removed improper application of claim/release from intr handler - updated changelog

[PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

Replace the code that guarantees the device stays in direct mode with iio_device_{claim|release}_direct_mode() which does same. Signed-off-by: Alison Schofield --- Changed in v2: - removed improper application of claim/release from intr handler - updated changelog

[PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

Hi David, Please feel free to squash this patch with yours of the same name (12/12). Just replace the .ima_mok keyring with the .secondary_trusted_keys. Signed-off-by: Mimi Zohar --- include/keys/system_keyring.h| 4 +-- security/integrity/digsig.c | 9

[PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

Hi David, Please feel free to squash this patch with yours of the same name (12/12). Just replace the .ima_mok keyring with the .secondary_trusted_keys. Signed-off-by: Mimi Zohar --- include/keys/system_keyring.h| 4 +-- security/integrity/digsig.c | 9 ++

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

Hi Robert, Not sure I understand, what should the purpose of this patch be? Why do you want to move some function(s) from one file to another? And you aren't even calling the new soc_mbus_build_fmts_xlate() function, and you aren't replacing the currently used analogous

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

Hi Robert, Not sure I understand, what should the purpose of this patch be? Why do you want to move some function(s) from one file to another? And you aren't even calling the new soc_mbus_build_fmts_xlate() function, and you aren't replacing the currently used analogous

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

Hi all, On 2016/4/5 13:59, Kefeng Wang wrote: > 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

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

Hi all, On 2016/4/5 13:59, Kefeng Wang wrote: > 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

Re: [PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

On Wed, Apr 06, 2016 at 11:43:32AM +0800, Ming Lei wrote: > After arbitrary bio size is supported, the incoming bio may > be very big. We have to split the bio into small bios so that > each holds at most BIO_MAX_PAGES bvecs for safety reason, such > as bio_clone(). > > This patch fixes the

Re: [PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

On Wed, Apr 06, 2016 at 11:43:32AM +0800, Ming Lei wrote: > After arbitrary bio size is supported, the incoming bio may > be very big. We have to split the bio into small bios so that > each holds at most BIO_MAX_PAGES bvecs for safety reason, such > as bio_clone(). > > This patch fixes the

[PATCH v2] fs: return EPERM on immutable inode

In most cases, EPERM is returned on immutable inode, and there're only a few places returning EACCES. I noticed this when running LTP on overlayfs, setxattr03 failed due to unexpected EACCES on immutable inode. So converting all EACCES to EPERM on immutable inode. Acked-by: Dave Chinner

[PATCH v2] fs: return EPERM on immutable inode

In most cases, EPERM is returned on immutable inode, and there're only a few places returning EACCES. I noticed this when running LTP on overlayfs, setxattr03 failed due to unexpected EACCES on immutable inode. So converting all EACCES to EPERM on immutable inode. Acked-by: Dave Chinner

[PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

After arbitrary bio size is supported, the incoming bio may be very big. We have to split the bio into small bios so that each holds at most BIO_MAX_PAGES bvecs for safety reason, such as bio_clone(). This patch fixes the following kernel crash: > [ 172.660142] BUG: unable to handle kernel NULL

[PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

After arbitrary bio size is supported, the incoming bio may be very big. We have to split the bio into small bios so that each holds at most BIO_MAX_PAGES bvecs for safety reason, such as bio_clone(). This patch fixes the following kernel crash: > [ 172.660142] BUG: unable to handle kernel NULL

Re: [PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

Radim, On 04/05/2016 09:56 PM, Radim Krčmář wrote: I meant to change the place where we remember that is_running must not be true. Something like svm_vcpu_blocking(struct kvm_vcpu *vcpu): vcpu->is_blocking = true; avic_set_running(vcpu, false); avic_vcpu_load(struct

Re: [PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

Radim, On 04/05/2016 09:56 PM, Radim Krčmář wrote: I meant to change the place where we remember that is_running must not be true. Something like svm_vcpu_blocking(struct kvm_vcpu *vcpu): vcpu->is_blocking = true; avic_set_running(vcpu, false); avic_vcpu_load(struct

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On 2016/4/6 8:00, Gavin Shan wrote: On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote: This patch enables mmapping MSI-X tables if hardware supports interrupt remapping which can ensure that a given pci device can only shoot the MSIs assigned for it. Signed-off-by: Yongji Xie

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On 2016/4/6 8:00, Gavin Shan wrote: On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote: This patch enables mmapping MSI-X tables if hardware supports interrupt remapping which can ensure that a given pci device can only shoot the MSIs assigned for it. Signed-off-by: Yongji Xie ---

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

On 03/30/2016 02:39 PM, Xiao Guangrong wrote: On 03/30/2016 02:36 PM, Paolo Bonzini wrote: On 30/03/2016 03:56, Xiao Guangrong wrote: x86/access.flat is currently using the "other" definition, i.e., PFEC.PK is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can you use it (with

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

On 03/30/2016 02:39 PM, Xiao Guangrong wrote: On 03/30/2016 02:36 PM, Paolo Bonzini wrote: On 30/03/2016 03:56, Xiao Guangrong wrote: x86/access.flat is currently using the "other" definition, i.e., PFEC.PK is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0. Can you use it (with

RE: [PATCH v6 12/12] usb: host: xhci-plat: Add otg device to platform data

Hi, > Sent: Tuesday, April 05, 2016 11:05 PM > > Host controllers that are part of an OTG/dual-role instance > need to somehow pass the OTG controller device information > to the HCD core. > > We use platform data to pass the OTG controller device. > > Signed-off-by: Roger Quadros

RE: [PATCH v6 12/12] usb: host: xhci-plat: Add otg device to platform data

Hi, > Sent: Tuesday, April 05, 2016 11:05 PM > > Host controllers that are part of an OTG/dual-role instance > need to somehow pass the OTG controller device information > to the HCD core. > > We use platform data to pass the OTG controller device. > > Signed-off-by: Roger Quadros > --- >

Re: [RFC v5 6/7] PCI: Add a new bit to pci_bus_flags to indicate interrupt remapping

On 2016/4/6 8:11, Gavin Shan wrote: On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote: I'm trying to find a proper way to indicate the capability of interrupt remapping on PPC64 because we need this to determine whether it is safe to mmap MSI-X table in VFIO driver. There is a

Re: [RFC v5 6/7] PCI: Add a new bit to pci_bus_flags to indicate interrupt remapping

On 2016/4/6 8:11, Gavin Shan wrote: On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote: I'm trying to find a proper way to indicate the capability of interrupt remapping on PPC64 because we need this to determine whether it is safe to mmap MSI-X table in VFIO driver. There is a

[REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

It seems Intel core still share the TLB pool, flush both of threads' TLB just cause a extra useless IPI and a extra flush. The extra flush will flush out TLB again which another thread just introduced. That's double waste. The micro testing show memory access can save about 25% time on my

[REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

It seems Intel core still share the TLB pool, flush both of threads' TLB just cause a extra useless IPI and a extra flush. The extra flush will flush out TLB again which another thread just introduced. That's double waste. The micro testing show memory access can save about 25% time on my

Re: [PATCH net-next 1/3] net: dsa: make the STP state function return void

Hi Andrew, Andrew Lunn writes: >> -- port_stp_update: bridge layer function invoked when a given switch port >> STP >> +- port_stp_state: bridge layer function invoked when a given switch port STP > > port_stp_state_set might be a better name, to make it clear it is > setting

Re: [PATCH net-next 1/3] net: dsa: make the STP state function return void

Hi Andrew, Andrew Lunn writes: >> -- port_stp_update: bridge layer function invoked when a given switch port >> STP >> +- port_stp_state: bridge layer function invoked when a given switch port STP > > port_stp_state_set might be a better name, to make it clear it is > setting the state, not

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

Hi Andrew, Andrew Lunn writes: >> mutex_lock(>smi_mutex); >> -ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state); >> +if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state)) >> +netdev_warn(ds->ports[port], "cannot load

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

Hi Andrew, Andrew Lunn writes: >> mutex_lock(>smi_mutex); >> -ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state); >> +if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state)) >> +netdev_warn(ds->ports[port], "cannot load address\n"); > > In

  1   2   3   4   5   6   7   8   9   10   >