Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

Vinod, On 09/28/16 06:26, Vinod Koul wrote: > On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v2: >> - Instead of converting to use enum for the of_device_id data parameter the >> two >> patch for edma and ti-dma-crossbar is using pointers to u32

Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

Vinod, On 09/28/16 06:26, Vinod Koul wrote: > On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: >> Hi, >> >> Changes since v2: >> - Instead of converting to use enum for the of_device_id data parameter the >> two >> patch for edma and ti-dma-crossbar is using pointers to u32

RE: ATA failure regression

Hi Can someone please help me to debug this issue? Regards Nehal -Original Message- From: Shah, Nehal-bakulchandra Sent: Monday, September 26, 2016 3:45 PM To: 'Bharat Kumar Gogada' Cc: Deucher, Alexander ;

RE: ATA failure regression

Hi Can someone please help me to debug this issue? Regards Nehal -Original Message- From: Shah, Nehal-bakulchandra Sent: Monday, September 26, 2016 3:45 PM To: 'Bharat Kumar Gogada' Cc: Deucher, Alexander ; linux-...@vger.kernel.org; hol...@ahsoftware.de; t...@kernel.org;

Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()

On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi

Re: [RFC] mm: a question about high-order check in __zone_watermark_ok()

On Mon, Sep 26, 2016 at 01:02:31PM +0200, Michal Hocko wrote: > On Mon 26-09-16 18:17:50, Xishi Qiu wrote: > > On 2016/9/26 17:43, Michal Hocko wrote: > > > > > On Mon 26-09-16 17:16:54, Xishi Qiu wrote: > > >> On 2016/9/26 16:58, Michal Hocko wrote: > > >> > > >>> On Mon 26-09-16 16:47:57, Xishi

RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

Hi, Martin. I think that the patch is correct. UFS spec says "The Data Segment area is empty" for Read Descriptor. I have been using similar code with it and it works. That have been already applied in Android kernel. Reviewed-by: Kiwoong Kim Regards. > -Original

RE: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

Hi, Martin. I think that the patch is correct. UFS spec says "The Data Segment area is empty" for Read Descriptor. I have been using similar code with it and it works. That have been already applied in Android kernel. Reviewed-by: Kiwoong Kim Regards. > -Original Message- > From:

[PATCH] [media] atmel-isc: start dma in some scenario

If a new vb buf is added to vb queue, the queue is empty and steaming, dma should be started. Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH] [media] atmel-isc: start dma in some scenario

If a new vb buf is added to vb queue, the queue is empty and steaming, dma should be started. Signed-off-by: Songjun Wu --- drivers/media/platform/atmel/atmel-isc.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/atmel/atmel-isc.c

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > >>> > void __init

Re: [PATCH v5 3/6] mm/cma: populate ZONE_CMA

On Thu, Sep 22, 2016 at 05:59:46PM +0200, Vlastimil Babka wrote: > On 09/22/2016 08:50 AM, Joonsoo Kim wrote: > >On Thu, Sep 22, 2016 at 02:45:46PM +0900, Joonsoo Kim wrote: > >>> > >>> > /* Free whole pageblock and set its migration type to MIGRATE_CMA. */ > >>> > void __init

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups :-) I will have a look. --

Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

> "Subhash" == subhashj writes: Subhash> Looks good to me. > - /* Data segment length */ > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > - 0, 0, len >> 8, (u8)len); > + /* Data segment length only need for WRITE_DESC */ > +

Re: [PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

> "Subhash" == subhashj writes: Subhash> Looks good to me. > - /* Data segment length */ > - ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD( > - 0, 0, len >> 8, (u8)len); > + /* Data segment length only need for WRITE_DESC */ > + if

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

> "Lee" == Lee Duncan writes: Lee> Yes, that would be great. Thank you. Applied to 4.9/scsi-queue. >> Is it your plan to go through the SCSI tree? Lee> Yes, the iscsi initiator kernel code updates have been going Lee> through the Linux SCSI mailing list and repository

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

> "Lee" == Lee Duncan writes: Lee> Yes, that would be great. Thank you. Applied to 4.9/scsi-queue. >> Is it your plan to go through the SCSI tree? Lee> Yes, the iscsi initiator kernel code updates have been going Lee> through the Linux SCSI mailing list and repository for a while, Lee>

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: > Yes. But *where* is it relative to the cores and socket(s)? And you need that information because... > > If you need to show the package id, you still iterate over the core > > numbers in an increasing order and show '*' for the

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote: > Yes. But *where* is it relative to the cores and socket(s)? And you need that information because... > > If you need to show the package id, you still iterate over the core > > numbers in an increasing order and show '*' for the

Re: [PATCH] scsi: be2iscsi: mark symbols static where possible

> "Baoyou" == Baoyou Xie writes: Baoyou> We get 6 warnings when building kernel with W=1: Baoyou> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_disp' [-Wmissing-prototypes] Baoyou>

Re: [PATCH] scsi: be2iscsi: mark symbols static where possible

> "Baoyou" == Baoyou Xie writes: Baoyou> We get 6 warnings when building kernel with W=1: Baoyou> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous Baoyou> prototype for 'beiscsi_log_enable_disp' [-Wmissing-prototypes] Baoyou> drivers/scsi/be2iscsi/be_main.c:78:1: warning: no

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: > I see now that the issue is not understanding the difference between physical > and soft thread removal. I will write that up and get back to everyone. No need - we understand the issue. What I don't understand is what

Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event

On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: > I see now that the issue is not understanding the difference between physical > and soft thread removal. I will write that up and get back to everyone. No need - we understand the issue. What I don't understand is what

RE: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready

> -Original Message- > From: Stefan Agner [mailto:ste...@agner.ch] > Sent: Monday, September 26, 2016 7:19 PM > To: w...@the-dreams.de > Cc: Leo Li ; linux-...@vger.kernel.org; u.kleine- > koe...@pengutronix.de; linux-kernel@vger.kernel.org; Stefan Agner >

RE: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready

> -Original Message- > From: Stefan Agner [mailto:ste...@agner.ch] > Sent: Monday, September 26, 2016 7:19 PM > To: w...@the-dreams.de > Cc: Leo Li ; linux-...@vger.kernel.org; u.kleine- > koe...@pengutronix.de; linux-kernel@vger.kernel.org; Stefan Agner > > Subject: [PATCH] i2c: imx:

Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

On 2016-09-27 17:48, Neil Armstrong wrote: > Since the I2C sx150x GPIO expander driver uses platform_data to manage > the pins configurations, rewrite the driver as a pinctrl driver using > pinconf to get/set pin configurations from DT or debugfs. > > The pinctrl driver is functionnally

Re: [PATCH v2] pinctrl: Add SX150X GPIO Extender Pinctrl Driver

On 2016-09-27 17:48, Neil Armstrong wrote: > Since the I2C sx150x GPIO expander driver uses platform_data to manage > the pins configurations, rewrite the driver as a pinctrl driver using > pinconf to get/set pin configurations from DT or debugfs. > > The pinctrl driver is functionnally

linux-next: manual merge of the staging tree with the vfs-miklos tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/file.c between commit: 302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()") from the vfs-miklos tree and commits: 5b8a39c53a16 ("staging: lustre: llite:

linux-next: manual merge of the staging tree with the vfs-miklos tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/lustre/lustre/llite/file.c between commit: 302d50e7203e ("switch generic_file_splice_read() to use of ->read_iter()") from the vfs-miklos tree and commits: 5b8a39c53a16 ("staging: lustre: llite:

Re: [PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

On Tue, Sep 27, 2016 at 10:44 PM, Ioan-Adrian Ratiu wrote: > Can you please wait a little until I post v2 later today and test v2 > directly? Because the change in it's current form has no effect on > 0079:0011 (the current quirk is enabled only for 0006). Sure thing! Just drop

Re: [PATCH 2/2] hid: input: add HID_QUIRK_REUSE_AXES and fix dragonrise

On Tue, Sep 27, 2016 at 10:44 PM, Ioan-Adrian Ratiu wrote: > Can you please wait a little until I post v2 later today and test v2 > directly? Because the change in it's current form has no effect on > 0079:0011 (the current quirk is enabled only for 0006). Sure thing! Just drop me a line when

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > locking. This series allows DAX PMDs to participate in the DAX radix tree > > based

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > locking. This series allows DAX PMDs to participate in the DAX radix tree > > based

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 27-09-16, 20:38, Stefan Agner wrote: > The i.MX I2C driver touches the pinctrl in its prepare/unprepare > callbacks. > > So, on a i.MX or Vybrid, the call chain looks like this: > > i2c_generic_gpio_recovery > -> i2c_get_gpios_for_recovery >-> gpio_request_one > ->

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 27-09-16, 20:38, Stefan Agner wrote: > The i.MX I2C driver touches the pinctrl in its prepare/unprepare > callbacks. > > So, on a i.MX or Vybrid, the call chain looks like this: > > i2c_generic_gpio_recovery > -> i2c_get_gpios_for_recovery >-> gpio_request_one > ->

[PATCH] perf tools: Fix building in 32 bit platform

On ARM32 building it report following error: util/data-convert-bt.c: In function 'add_bpf_output_values': util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format] cc1: all warnings being treated as

[PATCH] perf tools: Fix building in 32 bit platform

On ARM32 building it report following error: util/data-convert-bt.c: In function 'add_bpf_output_values': util/data-convert-bt.c:440:3: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'unsigned int' [-Werror=format] cc1: all warnings being treated as

[PATCH 3/3] bindings: add compatible "fsl,ls1043-ucc-hdlc" to bindings

Signed-off-by: Zhao Qiang --- Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt

[PATCH 3/3] bindings: add compatible "fsl,ls1043-ucc-hdlc" to bindings

Signed-off-by: Zhao Qiang --- Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt index

[PATCH v6 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0,

[PATCH 2/3] ls1043ardb: add ds26522 node to dts

add ds26522 node to fsl-ls1043a-rdb.dts Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts

[PATCH v6 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0,

[PATCH 2/3] ls1043ardb: add ds26522 node to dts

add ds26522 node to fsl-ls1043a-rdb.dts Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts

[PATCH 1/3] ls1043ardb: add qe node to ls1043ardb

Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++ 2 files changed, 82 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts

[PATCH 1/3] ls1043ardb: add qe node to ls1043ardb

Signed-off-by: Zhao Qiang --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 66 +++ 2 files changed, 82 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts

[PATCH v6 4/4] irqchip/qeic: remove PPCisms for QEIC

QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v6: - new added drivers/irqchip/irq-qeic.c | 28 +--- include/soc/fsl/qe/qe_ic.h | 12

[PATCH v6 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang --- Changes for v2: - modify the subject and commit msg Changes for v3: - merge .h file to .c, rename it with irq-qeic.c Changes

[PATCH v6 4/4] irqchip/qeic: remove PPCisms for QEIC

QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v6: - new added drivers/irqchip/irq-qeic.c | 28 +--- include/soc/fsl/qe/qe_ic.h | 12 ++-- 2 files

[PATCH v6 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang --- Changes for v2: - modify the subject and commit msg Changes for v3: - merge .h file to .c, rename it with irq-qeic.c Changes for v4: -

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 2016-09-27 19:00, Viresh Kumar wrote: > On 27-09-16, 12:34, Stefan Agner wrote: >> Added Viresh Kumar to the discussion, he implemented the I2C recovery >> functions. >> >> Yes, reordering the pinctrl/gpio_free calls would fix the problem too. >> >> However, I guess there is no explicit rule to

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 2016-09-27 19:00, Viresh Kumar wrote: > On 27-09-16, 12:34, Stefan Agner wrote: >> Added Viresh Kumar to the discussion, he implemented the I2C recovery >> functions. >> >> Yes, reordering the pinctrl/gpio_free calls would fix the problem too. >> >> However, I guess there is no explicit rule to

[PATCH v7] QE: remove PPCisms for QE

QE was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms. so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v2: - na Changes for v3: - add NO_IRQ Changes for v4: - modify spin_event_timeout to opencoded

[PATCH v7] QE: remove PPCisms for QE

QE was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms. so remove PPCisms. Signed-off-by: Zhao Qiang --- Changes for v2: - na Changes for v3: - add NO_IRQ Changes for v4: - modify spin_event_timeout to opencoded timeout loop -

[PATCH v6 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang --- Changes for v2: - modify subject and commit msg

[PATCH v6 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang --- Changes for v2: - modify subject and commit msg - return 0 and add

Re: [PATCH 2/3] DT: EVM: add LEDs

* H. Nikolaus Schaller [160927 13:11]: > > Am 27.09.2016 um 21:49 schrieb Tony Lindgren : > > How about this for defaults: > > > > - heartbeat for led3 > > - cpu0 for led4 > > - cpu1 for led5 > > Good idea. Will try. > > What I don't exactly know is if

Re: [PATCH 2/3] DT: EVM: add LEDs

* H. Nikolaus Schaller [160927 13:11]: > > Am 27.09.2016 um 21:49 schrieb Tony Lindgren : > > How about this for defaults: > > > > - heartbeat for led3 > > - cpu0 for led4 > > - cpu1 for led5 > > Good idea. Will try. > > What I don't exactly know is if these gpios based on an I2C-expander >

[PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from

[PATCH 2/2] mfd: intel-lpss: Avoid resuming runtime-suspended lpss unnecessarily

We have report that the intel_lpss_prepare() takes too much time during suspend, and this is because we first resume the devices from runtime suspend by resume_lpss_device(), to make sure they are in proper state before system suspend, which takes 100ms for each LPSS devices(PCI power state from

[PATCH 0/2] Define positive return value to RPM_SUSPEND for runtime-suspended devices

This patch set is to define the positive value returned by device .prepare() callbacks, which is used to indicate the devices are OK to remain in runtime-suspended during system sleep. A precise return value would make the code more readable. Based on this definition, optimized the suspend

[PATCH 0/2] Define positive return value to RPM_SUSPEND for runtime-suspended devices

This patch set is to define the positive value returned by device .prepare() callbacks, which is used to indicate the devices are OK to remain in runtime-suspended during system sleep. A precise return value would make the code more readable. Based on this definition, optimized the suspend

[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended

Currently if the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. However it would be more convenient to define this positive number then makes it more maintainable. Consider there might be

[PATCH 1/2] PM / sleep: Return RPM_SUSPENDED to keep devices in runtime-suspended

Currently if the ->prepare() callback of a device returns a positive number, the PM core will regard that as an indication that it may leave the device runtime-suspended. However it would be more convenient to define this positive number then makes it more maintainable. Consider there might be

Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Instead of converting to use enum for the of_device_id data parameter the > two > patch for edma and ti-dma-crossbar is using pointers to u32 variables to > make > sure that the code compile (and

Re: [PATCH v3 0/9] dmaengine: ti drivers: enable COMPILE_TESTing

On Wed, Sep 21, 2016 at 03:41:26PM +0300, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Instead of converting to use enum for the of_device_id data parameter the > two > patch for edma and ti-dma-crossbar is using pointers to u32 variables to > make > sure that the code compile (and

[PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")

An "unnecessary" 'else' was removed due to complains from checkpatch.pl as it is preceded by a 'return', however the 'else' branch is necessary as an earlier branch of the 'if' falls through. By removing the 'else', that route now hits the 'break' and the 'while' loop exits prematurely. This

[PATCH] Fixes: 3d44a78f0d8b ("staging: rtl8712: Remove unnecessary 'else'")

An "unnecessary" 'else' was removed due to complains from checkpatch.pl as it is preceded by a 'return', however the 'else' branch is necessary as an earlier branch of the 'if' falls through. By removing the 'else', that route now hits the 'break' and the 'while' loop exits prematurely. This

Re: [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage

On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote: > @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device > *pdev) > > xbar->dmarouter.dev = >dev; > xbar->dmarouter.route_free = ti_dra7_xbar_free; > - xbar->dma_offset = (u32)match->data; > +

Re: [PATCH v3 6/9] dmaengine: ti-dma-crossbar: Fix of_device_id data parameter usage

On Wed, Sep 21, 2016 at 03:41:32PM +0300, Peter Ujfalusi wrote: > @@ -395,7 +403,7 @@ static int ti_dra7_xbar_probe(struct platform_device > *pdev) > > xbar->dmarouter.dev = >dev; > xbar->dmarouter.route_free = ti_dra7_xbar_free; > - xbar->dma_offset = (u32)match->data; > +

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

On 09/26/2016 05:25 PM, Lee Duncan wrote: > Chris Leech and I are taking over as open-iscsi maintainers. > > Changes since v1: > * Updated URL to open-iscsi.com > * Removed git repository, since code in tree > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >

[PATCH V2] checkpatch: Improve the octal permissions tests

The function calls with octal permissions commonly span multiple lines. The current test is line oriented and fails to find some matches. Make the test use the $stat variable instead of the $line variable to span multiple lines. Also add a few functions to the known functions with permissions

Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

On 09/26/2016 05:25 PM, Lee Duncan wrote: > Chris Leech and I are taking over as open-iscsi maintainers. > > Changes since v1: > * Updated URL to open-iscsi.com > * Removed git repository, since code in tree > --- > MAINTAINERS | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > >

[PATCH V2] checkpatch: Improve the octal permissions tests

The function calls with octal permissions commonly span multiple lines. The current test is line oriented and fails to find some matches. Make the test use the $stat variable instead of the $line variable to span multiple lines. Also add a few functions to the known functions with permissions

Re: [PATCH v5] powerpc: Do not make the entire heap executable

On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote: > But this is not really a powerpc patch, and I'm not an ELF expert. So > I'm not comfortable merging it via the powerpc tree. It doesn't look > like we really have a maintainer for binfmt_elf.c, so I'm not sure who > should be

Re: [PATCH v5] powerpc: Do not make the entire heap executable

On Wed, Sep 28, 2016 at 11:42:11AM +1000, Michael Ellerman wrote: > But this is not really a powerpc patch, and I'm not an ELF expert. So > I'm not comfortable merging it via the powerpc tree. It doesn't look > like we really have a maintainer for binfmt_elf.c, so I'm not sure who > should be

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > Can you check if the problem occurs with this patch? In light of the fact that padlock-sha is the correct example to follow, you only need to add one line to the init_tfm fucntion to update the descsize based on that of the

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Tue, Sep 27, 2016 at 04:46:44PM -0300, Marcelo Cerri wrote: > > Can you check if the problem occurs with this patch? In light of the fact that padlock-sha is the correct example to follow, you only need to add one line to the init_tfm fucntion to update the descsize based on that of the

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > > Also, does that mean that padlock_sha has similar problem? > It does not seem to reserve any space for fallback __ctx and it calls > init()/update()/export() with padlock_sha_desc's fallback: > > struct padlock_sha_desc { >

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

On Tue, Sep 27, 2016 at 05:01:03AM -0400, Jan Stancek wrote: > > Also, does that mean that padlock_sha has similar problem? > It does not seem to reserve any space for fallback __ctx and it calls > init()/update()/export() with padlock_sha_desc's fallback: > > struct padlock_sha_desc { >

Re: [PATCH 00/17] clean up readlinks

On Tue, Sep 27, 2016 at 11:38:33AM +0200, Miklos Szeredi wrote: > > I have no problem with "let's get rid of generic_readlink" - not > > that > > it bought us much, but sure, if you want to have decision made based upon > > the combination of flags, let's do it. Just make NULL ->readlink

Re: [PATCH 00/17] clean up readlinks

On Tue, Sep 27, 2016 at 11:38:33AM +0200, Miklos Szeredi wrote: > > I have no problem with "let's get rid of generic_readlink" - not > > that > > it bought us much, but sure, if you want to have decision made based upon > > the combination of flags, let's do it. Just make NULL ->readlink

Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Date: Tue, 27 Sep 2016 09:57:50 -0600 > From: Chris Roth > > From Allan Chou > From: Chris Roth Three From lines, it's actually quite amazing how you were able to achieve this. Please take some time,

Re: [PATCH v3] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Date: Tue, 27 Sep 2016 09:57:50 -0600 > From: Chris Roth > > From Allan Chou > From: Chris Roth Three From lines, it's actually quite amazing how you were able to achieve this. Please take some time, and carefully craft your patch emails but don't send them to the list. Instead,

linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform

linux-next: manual merge of the drm-misc tree with the drm tree

Hi all, Today's linux-next merge of the drm-misc tree got conflicts in: drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c between commits: bdfd36ef8e64 ("drm/sti: Fix sparse warnings") b4bba92dfbe2 ("drm/sti: remove stih415-416 platform

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:41 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Cc: Alexei Starovoitov > Signed-off-by: Shaohua Li

Re: [PATCH trival -resend 1/2] bpf: clean up put_cpu_var usage

From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:41 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Cc: Alexei Starovoitov > Signed-off-by: Shaohua Li Applied.

Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:42 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Signed-off-by: Shaohua Li Applied.

Re: [PATCH trival -resend 2/2] lib: clean up put_cpu_var usage

From: Shaohua Li Date: Tue, 27 Sep 2016 08:42:42 -0700 > put_cpu_var takes the percpu data, not the data returned from > get_cpu_var. > > This doesn't change the behavior. > > Cc: Tejun Heo > Signed-off-by: Shaohua Li Applied.

Re: [PATCH v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On September 27, 2016 11:50:00 AM PDT, Lee Jones wrote: >On Sat, 17 Sep 2016, Ksenija Stanojević wrote: >> On Wed, Aug 31, 2016 at 2:05 PM, Lee Jones >wrote: >> > On Thu, 18 Aug 2016, Ksenija Stanojevic wrote: >> > >> > > Add core files for mxs-lradc

Re: kernel BUG at net/unix/garbage.c:149!"

From: Nikolay Borisov Date: Tue, 27 Sep 2016 17:16:27 +0300 > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Why would I apply a patch that's an RFC, doesn't have a proper commit message, lacks a proper signoff, and also

Re: [PATCH v5 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

On September 27, 2016 11:50:00 AM PDT, Lee Jones wrote: >On Sat, 17 Sep 2016, Ksenija Stanojević wrote: >> On Wed, Aug 31, 2016 at 2:05 PM, Lee Jones >wrote: >> > On Thu, 18 Aug 2016, Ksenija Stanojevic wrote: >> > >> > > Add core files for mxs-lradc MFD driver. >> > > >> > > Note: this patch

Re: kernel BUG at net/unix/garbage.c:149!"

From: Nikolay Borisov Date: Tue, 27 Sep 2016 17:16:27 +0300 > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Why would I apply a patch that's an RFC, doesn't have a proper commit message, lacks a proper signoff, and also lacks ACK's and

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > locking. This series allows DAX PMDs to participate in the DAX radix tree > based locking scheme so that they can be re-enabled. > > Jan and Christoph, can

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > locking. This series allows DAX PMDs to participate in the DAX radix tree > based locking scheme so that they can be re-enabled. > > Jan and Christoph, can

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 27-09-16, 12:34, Stefan Agner wrote: > Added Viresh Kumar to the discussion, he implemented the I2C recovery > functions. > > Yes, reordering the pinctrl/gpio_free calls would fix the problem too. > > However, I guess there is no explicit rule to that ("request/free GPIOs > only when they are

Re: [PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

On 27-09-16, 12:34, Stefan Agner wrote: > Added Viresh Kumar to the discussion, he implemented the I2C recovery > functions. > > Yes, reordering the pinctrl/gpio_free calls would fix the problem too. > > However, I guess there is no explicit rule to that ("request/free GPIOs > only when they are

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/drm_crtc.c between commit: 6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET") from Linus' tree and commit: 43968d7b806d ("drm: Extract drm_plane.[hc]") from the drm tree. I fixed it up (the

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/drm_crtc.c between commit: 6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET") from Linus' tree and commit: 43968d7b806d ("drm: Extract drm_plane.[hc]") from the drm tree. I fixed it up (the

  1   2   3   4   5   6   7   8   9   10   >