Re: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

On Wed, Jun 22, 2016 at 07:04:28AM +, Appana Durga Kedareswara Rao wrote: > > > > > > > > Can you elobrate what you meant by Multichannel mode? This patch > > > > seems to do two things, one is to add interleaved dma support and > > > > something else. Can you explain the latter part? > > > >

Re: [PATCH 2/4] dmaengine: vdma: Add support for mulit-channel dma mode

On Wed, Jun 22, 2016 at 07:04:28AM +, Appana Durga Kedareswara Rao wrote: > > > > > > > > Can you elobrate what you meant by Multichannel mode? This patch > > > > seems to do two things, one is to add interleaved dma support and > > > > something else. Can you explain the latter part? > > > >

Re: [PATCH 01/21] of: device: Support loading a module with OF based modalias

On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote: > In the case of ULPI devices, we want to be able to load the > driver before registering the device so that we don't get stuck > in a loop waiting for the phy module to appear and failing usb > controller probe. Currently we request the ulpi

Re: [PATCH 01/21] of: device: Support loading a module with OF based modalias

On Sun 26 Jun 00:28 PDT 2016, Stephen Boyd wrote: > In the case of ULPI devices, we want to be able to load the > driver before registering the device so that we don't get stuck > in a loop waiting for the phy module to appear and failing usb > controller probe. Currently we request the ulpi

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

On Mon, 2016-06-27 at 09:04 +0100, David Binderman wrote: > Hello there, > > linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:20]: (warning) %x in format > string (no. 1) requires 'unsigned int' but the argument type is > 'unsigned long'. > [linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:26]: (warning) %x

Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote: > > Ok agree with you for the scenario that I have mentioned above. > > Other simple dma mode feature that I missed to explain is configuring the > Dma descriptors. It provides a register interface for configuring the

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

On Mon, 2016-06-27 at 09:04 +0100, David Binderman wrote: > Hello there, > > linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:20]: (warning) %x in format > string (no. 1) requires 'unsigned int' but the argument type is > 'unsigned long'. > [linux-4.7-rc5/arch/powerpc/xmon/dis-asm.h:26]: (warning) %x

Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote: > > Ok agree with you for the scenario that I have mentioned above. > > Other simple dma mode feature that I missed to explain is configuring the > Dma descriptors. It provides a register interface for configuring the

Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.

On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote: > > On 21/06/16 17:01, Vinod Koul wrote: > > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote: > >> Hi Peter, > >> > >> On 07/06/16 18:38, Peter Griffin wrote: > >>> There is no point calculating the residue if there is > >>>

Re: [PATCH 7/8] dmaengine: tegra20-apb-dma: Only calculate residue if txstate exists.

On Tue, Jun 21, 2016 at 06:19:50PM +0100, Jon Hunter wrote: > > On 21/06/16 17:01, Vinod Koul wrote: > > On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote: > >> Hi Peter, > >> > >> On 07/06/16 18:38, Peter Griffin wrote: > >>> There is no point calculating the residue if there is > >>>

Re: [PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

On Mon, 2016-06-27 at 19:53 -0500, Larry Finger wrote: > On 06/25/2016 05:46 PM, Joe Perches wrote: > > > > This debugging macro can expand to a lot of code. > > Make it a function to reduce code size. > > > > (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig) > > $ size

Re: [PATCH] rtlwifi: Create _rtl_dbg_trace function to reduce RT_TRACE code size

On Mon, 2016-06-27 at 19:53 -0500, Larry Finger wrote: > On 06/25/2016 05:46 PM, Joe Perches wrote: > > > > This debugging macro can expand to a lot of code. > > Make it a function to reduce code size. > > > > (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig) > > $ size

Re: [PATCH 1/8] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

On 06/26/16 02:56, Greg KH wrote: On Thu, Jun 09, 2016 at 08:40:32PM +0530, Bhuvanchandra DV wrote: From: Stefan Agner Currently the tx_empty callback only considers the Transmit Complete Flag (TC). The reference manual is not quite clear if the TC flag covers the TX FIFO

Re: [PATCH 1/8] tty: serial: fsl_lpuart: consider TX FIFO too in tx_empty

On 06/26/16 02:56, Greg KH wrote: On Thu, Jun 09, 2016 at 08:40:32PM +0530, Bhuvanchandra DV wrote: From: Stefan Agner Currently the tx_empty callback only considers the Transmit Complete Flag (TC). The reference manual is not quite clear if the TC flag covers the TX FIFO too. Debug prints

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On Mon, 2016-06-27 at 12:34 +0100, Colin Ian King wrote: > On 27/06/16 12:20, Michael Ellerman wrote: > > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: > > > On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: > > > > On 26/06/16 05:19, Michael Ellerman wrote: > > > > > On Fri,

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On Mon, 2016-06-27 at 12:34 +0100, Colin Ian King wrote: > On 27/06/16 12:20, Michael Ellerman wrote: > > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: > > > On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: > > > > On 26/06/16 05:19, Michael Ellerman wrote: > > > > > On Fri,

Re: [ftrace] kernel panics during my attempt to use ftrace

Hello, On Tue, Jun 21, 2016 at 9:53 PM, Enrico Mioso wrote: > Hello guys. > > First of all - thank you for your great work in ftrace, and in general in > the Linux tracing infrastructure. I am a newbie: so I am not able to use it > at it's full power, still I find it's

Re: [ftrace] kernel panics during my attempt to use ftrace

Hello, On Tue, Jun 21, 2016 at 9:53 PM, Enrico Mioso wrote: > Hello guys. > > First of all - thank you for your great work in ftrace, and in general in > the Linux tracing infrastructure. I am a newbie: so I am not able to use it > at it's full power, still I find it's capabilities impressive. >

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月27日 22:58, Boqun Feng wrote: Hi Xinhui, On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote: This is to fix some holder preemption issues. Spinning at one vcpu which is preempted is meaningless. Kernel need such interfaces, So lets support it. We also should suooprt both

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月27日 22:58, Boqun Feng wrote: Hi Xinhui, On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote: This is to fix some holder preemption issues. Spinning at one vcpu which is preempted is meaningless. Kernel need such interfaces, So lets support it. We also should suooprt both

Re: [PATCH] Decouple CFG and IO in Designware PCIe Driver

On Mon, Jun 27, 2016 at 6:38 PM, dongbo (E) wrote: > Hi, all. > > How about exchanging the assignments of `MEMORYs' and `CFGs/IOs'? > In other words, assign MEMEORYs to iatu0, CFGs and IOs to iatu1. > > Once the iatu0 is initialized to MEMORY accesses, its BASE_ADDR, > LIMIT

Re: [PATCH] Decouple CFG and IO in Designware PCIe Driver

On Mon, Jun 27, 2016 at 6:38 PM, dongbo (E) wrote: > Hi, all. > > How about exchanging the assignments of `MEMORYs' and `CFGs/IOs'? > In other words, assign MEMEORYs to iatu0, CFGs and IOs to iatu1. > > Once the iatu0 is initialized to MEMORY accesses, its BASE_ADDR, > LIMIT and TYPE is fixed.

Re: [PATCH] notifier: Fix soft lockup for notifier_call_chain().

On 2016/6/28 3:50, Cong Wang wrote: > On Fri, Jun 24, 2016 at 7:46 PM, Ding Tianhong > wrote: >> diff --git a/kernel/notifier.c b/kernel/notifier.c >> index fd2c9ac..9c30411 100644 >> --- a/kernel/notifier.c >> +++ b/kernel/notifier.c >> @@ -92,6 +92,8 @@ static int

Re: [PATCH] notifier: Fix soft lockup for notifier_call_chain().

On 2016/6/28 3:50, Cong Wang wrote: > On Fri, Jun 24, 2016 at 7:46 PM, Ding Tianhong > wrote: >> diff --git a/kernel/notifier.c b/kernel/notifier.c >> index fd2c9ac..9c30411 100644 >> --- a/kernel/notifier.c >> +++ b/kernel/notifier.c >> @@ -92,6 +92,8 @@ static int notifier_call_chain(struct

Re: [PATCH 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

On 06/28/16 at 03:25am, Rafael J. Wysocki wrote: > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c > > index 9414f84..6ef3694 100644 > > --- a/arch/x86/kernel/acpi/boot.c > > +++ b/arch/x86/kernel/acpi/boot.c > > @@ -990,21 +992,6 @@ static int __init

Re: [PATCH 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

On 06/28/16 at 03:25am, Rafael J. Wysocki wrote: > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c > > index 9414f84..6ef3694 100644 > > --- a/arch/x86/kernel/acpi/boot.c > > +++ b/arch/x86/kernel/acpi/boot.c > > @@ -990,21 +992,6 @@ static int __init

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月27日 22:17, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote: diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h index 523673d..ae938ee 100644 --- a/arch/powerpc/include/asm/spinlock.h +++

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On 2016年06月27日 22:17, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 01:41:29PM -0400, Pan Xinhui wrote: diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h index 523673d..ae938ee 100644 --- a/arch/powerpc/include/asm/spinlock.h +++

linux-next: manual merge of the audit tree with the security tree

Hi Paul, Today's linux-next merge of the audit tree got conflicts in: arch/s390/kernel/ptrace.c between commit: 0208b9445bc0 ("s390/ptrace: run seccomp after ptrace") from the security tree and commit: da7f750c1ef5 ("s390: ensure that syscall arguments are properly masked on s390")

linux-next: manual merge of the audit tree with the security tree

Hi Paul, Today's linux-next merge of the audit tree got conflicts in: arch/s390/kernel/ptrace.c between commit: 0208b9445bc0 ("s390/ptrace: run seccomp after ptrace") from the security tree and commit: da7f750c1ef5 ("s390: ensure that syscall arguments are properly masked on s390")

[PATCH 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 soc

Make dw8250_set_termios() as the default set_termios callback for 8250 dw uart, correct me if I am wrong. Then add ACPI support for uart on Hisilicon Hip05 soc, be careful that it is not 16500 compatible. Note, the build(no ACPI) depends on https://patchwork.kernel.org/patch/9141207/, which

[PATCH 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 soc

Make dw8250_set_termios() as the default set_termios callback for 8250 dw uart, correct me if I am wrong. Then add ACPI support for uart on Hisilicon Hip05 soc, be careful that it is not 16500 compatible. Note, the build(no ACPI) depends on https://patchwork.kernel.org/patch/9141207/, which

[PATCH 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback

We can safely use dw8250_set_termios() as the default set_termios callback instead of serial8250_do_set_termios(), so do it. Signed-off-by: Kefeng Wang --- drivers/tty/serial/8250/8250_dw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 soc

Add ACPI identifier for UART on Hisilicon Hip05 soc, be careful that it is not 16550 compatibal. Meanwhile, set dw8250_serial_out32 to keep consistent between serial_out and serial_in in ACPI. Signed-off-by: Kefeng Wang --- drivers/tty/serial/8250/8250_dw.c | 8

[PATCH 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback

We can safely use dw8250_set_termios() as the default set_termios callback instead of serial8250_do_set_termios(), so do it. Signed-off-by: Kefeng Wang --- drivers/tty/serial/8250/8250_dw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250_dw.c

[PATCH 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 soc

Add ACPI identifier for UART on Hisilicon Hip05 soc, be careful that it is not 16550 compatibal. Meanwhile, set dw8250_serial_out32 to keep consistent between serial_out and serial_in in ACPI. Signed-off-by: Kefeng Wang --- drivers/tty/serial/8250/8250_dw.c | 8 ++-- 1 file changed, 6

Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Dear Heiko, On 06/25/2016 03:50 AM, Heiko Stuebner wrote: Hi William, Am Dienstag, 21. Juni 2016, 17:11:44 schrieb William Wu: On 06/20/2016 10:44 PM, Heiko Stübner wrote: Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu: On 06/17/2016 07:15 AM, Heiko Stübner wrote: Am Donnerstag, 2.

Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Dear Heiko, On 06/25/2016 03:50 AM, Heiko Stuebner wrote: Hi William, Am Dienstag, 21. Juni 2016, 17:11:44 schrieb William Wu: On 06/20/2016 10:44 PM, Heiko Stübner wrote: Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu: On 06/17/2016 07:15 AM, Heiko Stübner wrote: Am Donnerstag, 2.

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On 2016年06月27日 22:05, Boqun Feng wrote: On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: this supports to fix lock holder preempted issue which run as a guest for kernel users, we could use bool vcpu_is_preempted(int cpu) to detech if one vcpu is preempted or not. The default

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On 2016年06月27日 22:05, Boqun Feng wrote: On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: this supports to fix lock holder preempted issue which run as a guest for kernel users, we could use bool vcpu_is_preempted(int cpu) to detech if one vcpu is preempted or not. The default

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On 2016年06月27日 22:02, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: +++ b/include/linux/sched.h @@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct *p, unsigned int cpu)

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On 2016年06月27日 22:02, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 04:00:43PM +0200, Peter Zijlstra wrote: On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: +++ b/include/linux/sched.h @@ -3293,6 +3293,15 @@ static inline void set_task_cpu(struct task_struct *p, unsigned int cpu)

linux-next: manual merge of the iommu tree with the arm tree

Hi Joerg, Today's linux-next merge of the iommu tree got a conflict in: drivers/iommu/mtk_iommu.c between commit: d267804c8457 ("iommu: convert DT component matching to component_match_add_release()") from the arm tree and commit: 9ca340c98c0d ("iommu/mediatek: move the common struct

linux-next: manual merge of the iommu tree with the arm tree

Hi Joerg, Today's linux-next merge of the iommu tree got a conflict in: drivers/iommu/mtk_iommu.c between commit: d267804c8457 ("iommu: convert DT component matching to component_match_add_release()") from the arm tree and commit: 9ca340c98c0d ("iommu/mediatek: move the common struct

Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support

On Sun, Jun 26, 2016 at 12:28 AM, Stephen Boyd wrote: > The state of USB ChipIdea support on Qualcomm's platforms is not great. > The DT description of these devices requires up to three different nodes > for what amounts to be the same hardware block, when there should

Re: [PATCH 00/21] Support qcom's HSIC USB and rewrite USB2 HS phy support

On Sun, Jun 26, 2016 at 12:28 AM, Stephen Boyd wrote: > The state of USB ChipIdea support on Qualcomm's platforms is not great. > The DT description of these devices requires up to three different nodes > for what amounts to be the same hardware block, when there should really > only be one.

Re: [PATCH] geneve: fix max_mtu setting

On Mon, Jun 27, 2016 at 6:27 PM, 严海双 wrote: > > On Jun 28, 2016, at 12:10 AM, Jesse Gross wrote: > > On Sun, Jun 26, 2016 at 6:13 PM, Haishuang Yan > wrote: > > > On Jun 26, 2016, at 8:35 PM, zhuyj

Re: [PATCH] geneve: fix max_mtu setting

On Mon, Jun 27, 2016 at 6:27 PM, 严海双 wrote: > > On Jun 28, 2016, at 12:10 AM, Jesse Gross wrote: > > On Sun, Jun 26, 2016 at 6:13 PM, Haishuang Yan > wrote: > > > On Jun 26, 2016, at 8:35 PM, zhuyj wrote: > > + if (geneve->remote.sa.sa_family == AF_INET) > + max_mtu -=

[PATCH net-next v2 6/6] r8152: add byte_enable for ocp_read_word function

Add byte_enable for ocp_read_word() to replace reading 4 bytes data with reading the desired 2 bytes data. This is used to avoid the issue which is described in commit b4d99def0938 ("r8152: remove sram_read"). The origin method always reads 4 bytes data, and it may have problem when reading the

[PATCH net-next v2 0/6] r8152: support new chips

v2: Fix the commit message for patch #6. v1: In order to support new chips, adjust some codes. Then, add the settings for the new chips. Hayes Wang (6): r8152: add aldps_enable for rtl_ops r8152: add u1u2_enable for rtl_ops r8152: add power_cut_en for rtl_ops r8152: support the new chip

[PATCH net-next v2 6/6] r8152: add byte_enable for ocp_read_word function

Add byte_enable for ocp_read_word() to replace reading 4 bytes data with reading the desired 2 bytes data. This is used to avoid the issue which is described in commit b4d99def0938 ("r8152: remove sram_read"). The origin method always reads 4 bytes data, and it may have problem when reading the

[PATCH net-next v2 0/6] r8152: support new chips

v2: Fix the commit message for patch #6. v1: In order to support new chips, adjust some codes. Then, add the settings for the new chips. Hayes Wang (6): r8152: add aldps_enable for rtl_ops r8152: add u1u2_enable for rtl_ops r8152: add power_cut_en for rtl_ops r8152: support the new chip

[PATCH net-next v2 4/6] r8152: support the new chip 8050

Support a new chip which has the product ID 0x8050. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index a4f8a01..3ccbff0 100644 ---

[PATCH net-next v2 1/6] r8152: add aldps_enable for rtl_ops

Add aldps_enable() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 11178f9..b253003 100644 ---

[PATCH net-next v2 4/6] r8152: support the new chip 8050

Support a new chip which has the product ID 0x8050. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index a4f8a01..3ccbff0 100644 --- a/drivers/net/usb/r8152.c +++

[PATCH net-next v2 1/6] r8152: add aldps_enable for rtl_ops

Add aldps_enable() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 11178f9..b253003 100644 --- a/drivers/net/usb/r8152.c +++

[PATCH net-next v2 3/6] r8152: add power_cut_en for rtl_ops

Add power_cut_en() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f51d799..a4f8a01 100644 ---

[PATCH net-next v2 2/6] r8152: add u1u2_enable for rtl_ops

Add u1u2_enable() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index b253003..f51d799 100644 ---

[PATCH net-next v2 5/6] r8152: support RTL8153B

Support new chip RTL8153B. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 560 +--- 1 file changed, 533 insertions(+), 27 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index

[PATCH net-next v2 3/6] r8152: add power_cut_en for rtl_ops

Add power_cut_en() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index f51d799..a4f8a01 100644 --- a/drivers/net/usb/r8152.c +++

[PATCH net-next v2 2/6] r8152: add u1u2_enable for rtl_ops

Add u1u2_enable() for rtl_ops. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index b253003..f51d799 100644 --- a/drivers/net/usb/r8152.c +++

[PATCH net-next v2 5/6] r8152: support RTL8153B

Support new chip RTL8153B. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 560 +--- 1 file changed, 533 insertions(+), 27 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 3ccbff0..2fd4944 100644 ---

Re: [PATCH v2 0/5] ARM: dts: imx7d: add i.MX 7Solo and Colibri iMX7S/D dts

On Sun, Jun 26, 2016 at 01:47:50AM -0700, Stefan Agner wrote: > Stefan Agner (5): > ARM: imx: add support for i.MX 7Solo > ARM: dts: imx7d: use imx7s.dtsi as base device tree > ARM: dts: imx7d: recreate imx7d.dtsi with i.MX 7Dual specifics > ARM: dts: imx7d: move input header into base

Re: [PATCH v2 0/5] ARM: dts: imx7d: add i.MX 7Solo and Colibri iMX7S/D dts

On Sun, Jun 26, 2016 at 01:47:50AM -0700, Stefan Agner wrote: > Stefan Agner (5): > ARM: imx: add support for i.MX 7Solo > ARM: dts: imx7d: use imx7s.dtsi as base device tree > ARM: dts: imx7d: recreate imx7d.dtsi with i.MX 7Dual specifics > ARM: dts: imx7d: move input header into base

[PATCH v2 3/5] spi: s3c64xx: do not configure the device twice

At the start of the transfer, the spi_config function is called twice, the first time when the 3c64xx_spi_prepare_message is called and the second time with the s3c64xx_spi_transfer_one, both called from the spi framework. Remove the first call at the prepare message because in that point we

[PATCH v2 3/5] spi: s3c64xx: do not configure the device twice

At the start of the transfer, the spi_config function is called twice, the first time when the 3c64xx_spi_prepare_message is called and the second time with the s3c64xx_spi_transfer_one, both called from the spi framework. Remove the first call at the prepare message because in that point we

[PATCH v2 5/5] spi: s3c64xx: use unsigned type for fifo handling variables

The 'quirks' variable cannot ever be negative, therefore use u8 instead of int. The 8 bit size is given from the fact that currently the quirks variable has very few statuses. The rx_lvl_offset and tx_st_done store shift values, so that u8 is a proper size. fifo_lvl_mask stores a series of

[PATCH v2 1/5] spi: s3c64xx: group the CS signalling writes in a single function

To enable/disable the CS line, the driver performs a writel in the S3C64XX_SPI_SLAVE_SEL registers. Group the register's configuration in a single function. Signed-off-by: Andi Shyti --- drivers/spi/spi-s3c64xx.c | 36 ++-- 1 file changed,

[PATCH v2 0/5] s3c64xx: consider the case of a disconnected CS line and some code rework

Hi, the main goal of the patchset is to support SPI cnnected device without CS line link. The first two patches make the s3c64xx driver to consider the case of a disconnected CS line. This is done by adding a property in the DTS ("no-cs-readback") which informs the device driver the absence of a

[PATCH v2 2/5] spi: s3c64xx: consider the case when the CS line is not connected

When the CS line is not connected, it is not needed to enable or disable the chip selection functionality from the s3c64xx devices in order to perform a transfer. Set the CS controller logically always enabled already during initialization (by writing '0' in the S3C64XX_SPI_SLAVE_SEL register) and

[PATCH v2 5/5] spi: s3c64xx: use unsigned type for fifo handling variables

The 'quirks' variable cannot ever be negative, therefore use u8 instead of int. The 8 bit size is given from the fact that currently the quirks variable has very few statuses. The rx_lvl_offset and tx_st_done store shift values, so that u8 is a proper size. fifo_lvl_mask stores a series of

[PATCH v2 1/5] spi: s3c64xx: group the CS signalling writes in a single function

To enable/disable the CS line, the driver performs a writel in the S3C64XX_SPI_SLAVE_SEL registers. Group the register's configuration in a single function. Signed-off-by: Andi Shyti --- drivers/spi/spi-s3c64xx.c | 36 ++-- 1 file changed, 26 insertions(+), 10

[PATCH v2 0/5] s3c64xx: consider the case of a disconnected CS line and some code rework

Hi, the main goal of the patchset is to support SPI cnnected device without CS line link. The first two patches make the s3c64xx driver to consider the case of a disconnected CS line. This is done by adding a property in the DTS ("no-cs-readback") which informs the device driver the absence of a

[PATCH v2 2/5] spi: s3c64xx: consider the case when the CS line is not connected

When the CS line is not connected, it is not needed to enable or disable the chip selection functionality from the s3c64xx devices in order to perform a transfer. Set the CS controller logically always enabled already during initialization (by writing '0' in the S3C64XX_SPI_SLAVE_SEL register) and

[PATCH v2 4/5] spi: s3c64xx: simplify if statement in prepare_transfer function

The whole function is inside an 'if' statement ("!is_polling(sdd)"). Check the opposite of that statement at the beginning and exit, this way we can have one level less of indentation. Remove the goto paths as they are redundant. Signed-off-by: Andi Shyti ---

[PATCH v2 4/5] spi: s3c64xx: simplify if statement in prepare_transfer function

The whole function is inside an 'if' statement ("!is_polling(sdd)"). Check the opposite of that statement at the beginning and exit, this way we can have one level less of indentation. Remove the goto paths as they are redundant. Signed-off-by: Andi Shyti --- drivers/spi/spi-s3c64xx.c | 50

[PATCH] virtio-blk: Generate uevent after attribute available

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of

[PATCH] virtio-blk: Generate uevent after attribute available

Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. This race condition can be easily reproduced by hot plugging a number of

Re: [PATCH v2 3/3] intel_pstate: Declare pid_params/pstate_funcs/hwp_active __read_mostly

Dear Rafael, On Mon, 27 Jun 2016 10:29:54 -0700 Srinivas Pandruvada wrote: > On Mon, 2016-06-27 at 18:07 +0800, Jisheng Zhang wrote: > > pid_params is written once by copy_pid_params() during > > initialization, > > and thereafter is mostly read by hot path

[lkp] [x86/mm/64] a611d6b7d4: RIP [] pud_offset+0x6/0x5e

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack commit a611d6b7d4bdf3f57cfc792a45eb1ea5f4b776eb ("x86/mm/64: Enable vmapped stacks") on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with 320M memory

Re: [PATCH v2 3/3] intel_pstate: Declare pid_params/pstate_funcs/hwp_active __read_mostly

Dear Rafael, On Mon, 27 Jun 2016 10:29:54 -0700 Srinivas Pandruvada wrote: > On Mon, 2016-06-27 at 18:07 +0800, Jisheng Zhang wrote: > > pid_params is written once by copy_pid_params() during > > initialization, > > and thereafter is mostly read by hot path intel_pstate_update_util(). > > The

[lkp] [x86/mm/64] a611d6b7d4: RIP [] pud_offset+0x6/0x5e

FYI, we noticed the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vmap_stack commit a611d6b7d4bdf3f57cfc792a45eb1ea5f4b776eb ("x86/mm/64: Enable vmapped stacks") on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with 320M memory

Re: [PATCH 0/6] kill off cpu_is_mx*()

On Fri, Jun 24, 2016 at 12:49:55PM +0200, Arnd Bergmann wrote: > I noticed that i.MX still uses the traditional cpu_is_* functions to > tell the difference between various SoC families, but every single > user of those can be replaced with a simpler way, so we can just > remove it all. > > Please

Re: [PATCH v3 5/8] rtc: ac100: Add clk output support

On Tue, Jun 28, 2016 at 3:23 AM, Maxime Ripard wrote: > On Wed, Jun 22, 2016 at 06:11:55PM +0800, Chen-Yu Tsai wrote: >> On Wed, Jun 22, 2016 at 6:02 PM, Maxime Ripard >> wrote: >> > Hi, >> > >> > On Mon, Jun 20, 2016 at

Re: [PATCH 0/6] kill off cpu_is_mx*()

On Fri, Jun 24, 2016 at 12:49:55PM +0200, Arnd Bergmann wrote: > I noticed that i.MX still uses the traditional cpu_is_* functions to > tell the difference between various SoC families, but every single > user of those can be replaced with a simpler way, so we can just > remove it all. > > Please

Re: [PATCH v3 5/8] rtc: ac100: Add clk output support

On Tue, Jun 28, 2016 at 3:23 AM, Maxime Ripard wrote: > On Wed, Jun 22, 2016 at 06:11:55PM +0800, Chen-Yu Tsai wrote: >> On Wed, Jun 22, 2016 at 6:02 PM, Maxime Ripard >> wrote: >> > Hi, >> > >> > On Mon, Jun 20, 2016 at 10:52:15AM +0800, Chen-Yu Tsai wrote: >> >> + /* >> >> + * The

Re: [RFC] Can we bypass the timeout when resetting Synaptics device?

Hi Dmitry, thanks very much for your reply, On Tue, Jun 28, 2016 at 1:05 AM, Dmitry Torokhov wrote: > Hi Yu, > > On Mon, Jun 27, 2016 at 09:04:58PM +0800, Yu Chen wrote: >> Hi All, >> Currently I'm doing some tunings on the speed of suspend/resume, >> it looks like my

Re: [RFC] Can we bypass the timeout when resetting Synaptics device?

Hi Dmitry, thanks very much for your reply, On Tue, Jun 28, 2016 at 1:05 AM, Dmitry Torokhov wrote: > Hi Yu, > > On Mon, Jun 27, 2016 at 09:04:58PM +0800, Yu Chen wrote: >> Hi All, >> Currently I'm doing some tunings on the speed of suspend/resume, >> it looks like my serio driver tooks a 200ms

Re: [PATCH 2/2] GFS2: Add a gfs2-specific prune_icache_sb

On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote: > This patch adds a new prune_icache_sb function for the VFS slab > shrinker to call. Trying to directly free the inodes from memory > might deadlock because it evicts inodes, which calls into DLM > to acquire the glock. The DLM, in

Re: [PATCH 2/2] GFS2: Add a gfs2-specific prune_icache_sb

On Fri, Jun 24, 2016 at 02:50:11PM -0500, Bob Peterson wrote: > This patch adds a new prune_icache_sb function for the VFS slab > shrinker to call. Trying to directly free the inodes from memory > might deadlock because it evicts inodes, which calls into DLM > to acquire the glock. The DLM, in

Re: [PATCH 1/1] usb: dwc2: add printf attribute to cat_printf()

On 6/26/2016 1:12 AM, Nicolas Iooss wrote: > As cat_printf() uses printf format strings in its parameters, adding > __printf attribute allows the compiler to detect at compile-time some > errors related to format strings (with -Wformat warning flag). > > Signed-off-by: Nicolas Iooss

Re: [PATCH 1/1] usb: dwc2: add printf attribute to cat_printf()

On 6/26/2016 1:12 AM, Nicolas Iooss wrote: > As cat_printf() uses printf format strings in its parameters, adding > __printf attribute allows the compiler to detect at compile-time some > errors related to format strings (with -Wformat warning flag). > > Signed-off-by: Nicolas Iooss > --- >

Re: [PATCH] USB: dwc2-usb: add USB_GADGET dependency

On 6/24/2016 12:28 AM, Arnd Bergmann wrote: > The driver selects NOP_USB_XCEIV, which can only be built-in if > USB_GADGET is either disabled or also built-in, so with USB_DWC2_PCI=y > and USB_GADGET=m, NOP_USB_XCEIV is also built-in and we get this link > error: > > drivers/usb/built-in.o: In

Re: [PATCH] USB: dwc2-usb: add USB_GADGET dependency

On 6/24/2016 12:28 AM, Arnd Bergmann wrote: > The driver selects NOP_USB_XCEIV, which can only be built-in if > USB_GADGET is either disabled or also built-in, so with USB_DWC2_PCI=y > and USB_GADGET=m, NOP_USB_XCEIV is also built-in and we get this link > error: > > drivers/usb/built-in.o: In

Re: [PATCH v3] ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board

On Tue, Jun 28, 2016 at 8:45 AM, Florian Fainelli wrote: > Now that we have a proper binding for Ethernet switches hanging off > different buses, and a driver for the BCM53125 switch, add its Device > Tree as a child MDIO node, at MDIO address 30 (Broadcom pseudo-PHY >

Re: [PATCH v3] ARM: dts: sun7i: Add BCM53125 switch nodes to the lamobo-r1 board

On Tue, Jun 28, 2016 at 8:45 AM, Florian Fainelli wrote: > Now that we have a proper binding for Ethernet switches hanging off > different buses, and a driver for the BCM53125 switch, add its Device > Tree as a child MDIO node, at MDIO address 30 (Broadcom pseudo-PHY > address) and describe the

Re: [PATCH 2/2] ARM: dts: imx53: add support for USB armory board

On Tue, Jun 21, 2016 at 04:50:53PM +0200, and...@inversepath.com wrote: > From: Andrej Rosano > > Add support for Inverse Path USB armory board, an open source > flash-drive sized computer based on NXP i.MX53 SoC. > > https://inversepath.com/usbarmory > > Signed-off-by:

Re: [PATCH 2/2] ARM: dts: imx53: add support for USB armory board

On Tue, Jun 21, 2016 at 04:50:53PM +0200, and...@inversepath.com wrote: > From: Andrej Rosano > > Add support for Inverse Path USB armory board, an open source > flash-drive sized computer based on NXP i.MX53 SoC. > > https://inversepath.com/usbarmory > > Signed-off-by: Andrej Rosano > --- >

Re: [PATCH] hwmon: (jc42) Add support for Microchip MCP9808 temperature sensor

On 06/27/2016 05:23 PM, Alison Schofield wrote: MCP9808 is not officially compliant to JC-42, similar to MCP9804, but its registers are compatible to JC-42. Signed-off-by: Alison Schofield Cc: Daniel Baluta Applied to -next. Thanks, Guenter

Re: [PATCH] hwmon: (jc42) Add support for Microchip MCP9808 temperature sensor

On 06/27/2016 05:23 PM, Alison Schofield wrote: MCP9808 is not officially compliant to JC-42, similar to MCP9804, but its registers are compatible to JC-42. Signed-off-by: Alison Schofield Cc: Daniel Baluta Applied to -next. Thanks, Guenter

<    1   2   3   4   5   6   7   8   9   10   >