[PATCH V2 net-next 05/11] net: hns3: refactor interrupt coalescing init function

From: Fuyun Liang In the hardware, the coalesce configurable registers include GL0, GL1, GL2. In the driver, the TX queues use the register GL1 and the RX queues use the register GL0. This function initializes the configuration of the interrupt coalescing, but does not

[PATCH V2 net-next 06/11] net: hns3: refactor GL update function

From: Fuyun Liang The GL update function uses the max GL value between tx_int_gl and rx_int_gl to set both new tx_int_gl and new rx_int_gl. Therefore, User can not enable TX GL self-adaptive or RX GL self-adaptive individually. This patch refactors the code to update the

[PATCH V2 net-next 05/11] net: hns3: refactor interrupt coalescing init function

From: Fuyun Liang In the hardware, the coalesce configurable registers include GL0, GL1, GL2. In the driver, the TX queues use the register GL1 and the RX queues use the register GL0. This function initializes the configuration of the interrupt coalescing, but does not distinguish between the TX

[PATCH V2 net-next 06/11] net: hns3: refactor GL update function

From: Fuyun Liang The GL update function uses the max GL value between tx_int_gl and rx_int_gl to set both new tx_int_gl and new rx_int_gl. Therefore, User can not enable TX GL self-adaptive or RX GL self-adaptive individually. This patch refactors the code to update the TX GL and the RX GL

RE: 答复: [f2fs-dev] [PATCH] f2fs: prevent newly created inode from being dirtied incorrectly

Hi Zhikang, We dropped vfs caches periodically to reproduce the kernel panic using drop cache command. I mean you have to trigger a checkpoint right after f2fs_mark_inode_dirty_sync() for a new inode. We don't have any special test cases for that and we just triggered to drop caches

RE: 答复: [f2fs-dev] [PATCH] f2fs: prevent newly created inode from being dirtied incorrectly

Hi Zhikang, We dropped vfs caches periodically to reproduce the kernel panic using drop cache command. I mean you have to trigger a checkpoint right after f2fs_mark_inode_dirty_sync() for a new inode. We don't have any special test cases for that and we just triggered to drop caches

[PATCH V2 net-next 09/11] net: hns3: add int_gl_idx setup for TX and RX queues

From: Fuyun Liang If the int_gl_idx does not be set, the default interrupt coalesce index is 0. The TX queues and the RX queues will both use the GL0 as the interrupt coalesce GL switch. But it should be GL1 for TX queues and GL0 for RX queues. This patch adds the

[PATCH V2 net-next 00/11] add some new features and fix some bugs

This patchset adds 3 ethtool features: get_channels, get_coalesce and get_coalesce, and fix some bugs. [patch 1/11] adds ethtool_ops.get_channels (ethtool -l) support for VF. [patch 2/11] removes TSO config command from VF driver, as only main PF can config TSO MSS length according to hardware.

[PATCH V2 net-next 09/11] net: hns3: add int_gl_idx setup for TX and RX queues

From: Fuyun Liang If the int_gl_idx does not be set, the default interrupt coalesce index is 0. The TX queues and the RX queues will both use the GL0 as the interrupt coalesce GL switch. But it should be GL1 for TX queues and GL0 for RX queues. This patch adds the int_gl_idx setup for TX queues

[PATCH V2 net-next 00/11] add some new features and fix some bugs

This patchset adds 3 ethtool features: get_channels, get_coalesce and get_coalesce, and fix some bugs. [patch 1/11] adds ethtool_ops.get_channels (ethtool -l) support for VF. [patch 2/11] removes TSO config command from VF driver, as only main PF can config TSO MSS length according to hardware.

[PATCH V2 net-next 03/11] net: hns3: add ethtool_ops.get_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.get_coalesce support to PF. Whilst our hardware supports per queue values, external interfaces support only a single shared value. As such we use the values for queue 0. Signed-off-by: Fuyun Liang

[PATCH V2 net-next 03/11] net: hns3: add ethtool_ops.get_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.get_coalesce support to PF. Whilst our hardware supports per queue values, external interfaces support only a single shared value. As such we use the values for queue 0. Signed-off-by: Fuyun Liang Signed-off-by: Peng Li ---

[PATCH V2 net-next 04/11] net: hns3: add ethtool_ops.set_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.set_coalesce support to PF. Signed-off-by: Fuyun Liang Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 34 -

[PATCH V2 net-next 04/11] net: hns3: add ethtool_ops.set_coalesce support to PF

From: Fuyun Liang This patch adds ethtool_ops.set_coalesce support to PF. Signed-off-by: Fuyun Liang Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 34 - drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 17 +++

[PATCH] drm/nouveau/core/client: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/gpu/drm/nouveau/nvif/client.c: In function 'nvif_client_init': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] We need to use strlcpy() to make

[PATCH] drm/nouveau/core/client: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/gpu/drm/nouveau/nvif/client.c: In function 'nvif_client_init': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] We need to use strlcpy() to make sure the dest string is

[PATCH V2 net-next 11/11] net: hns3: check for NULL function pointer in hns3_nic_set_features

From: Jian Shen It's necessary to check hook whether being defined before calling, improve the reliability. Signed-off-by: Jian Shen Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 -- 1

[PATCH V2 net-next 11/11] net: hns3: check for NULL function pointer in hns3_nic_set_features

From: Jian Shen It's necessary to check hook whether being defined before calling, improve the reliability. Signed-off-by: Jian Shen Signed-off-by: Peng Li --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum

This patch adds one more generic PHY mode to the phy_mode enum, to allow configuring generic PHYs to the 2.5G SGMII mode by using the set_mode callback. Signed-off-by: Antoine Tenart --- include/linux/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum

This patch adds one more generic PHY mode to the phy_mode enum, to allow configuring generic PHYs to the 2.5G SGMII mode by using the set_mode callback. Signed-off-by: Antoine Tenart --- include/linux/phy/phy.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/phy/phy.h

RE: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to support preallocated region

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:59 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN

RE: [PATCH v2 05/16] remoteproc: modify rproc_handle_carveout to support preallocated region

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:59 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org >

[PATCH net-next v5 4/4] net: mvpp2: 2500baseX support

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses nearly the same code path. Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn ---

[PATCH net-next v5 3/4] net: mvpp2: 1000baseX support

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2 driver. 1000Base-X is quite close the SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/net/ethernet/marvell/mvpp2.c | 45

[PATCH net-next v5 4/4] net: mvpp2: 2500baseX support

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2 driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses nearly the same code path. Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn --- drivers/net/ethernet/marvell/mvpp2.c | 49

[PATCH net-next v5 3/4] net: mvpp2: 1000baseX support

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2 driver. 1000Base-X is quite close the SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/net/ethernet/marvell/mvpp2.c | 45 1 file changed, 35 insertions(+),

[PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode

This patch allow the CP100 comphy to configure some lanes in the 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++--- 1

[PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode

This patch allow the CP100 comphy to configure some lanes in the 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the same code path. Signed-off-by: Antoine Tenart --- drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++--- 1 file changed, 14 insertions(+), 3

[PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi all, This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 driver. In order to use it, the 2.5 SGMII mode is added in the Marvell common PHY driver (cp110-comphy). This was tested on a mcbin. All patches should probably go through net-next as patch 4/4 depends on patch 1/4 to

[PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi all, This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2 driver. In order to use it, the 2.5 SGMII mode is added in the Marvell common PHY driver (cp110-comphy). This was tested on a mcbin. All patches should probably go through net-next as patch 4/4 depends on patch 1/4 to

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 05:32:15PM -0800, Ashok Raj wrote: > - Remove including microcode.h, and use native macros from asm/msr.h > - added license header for spec_ctrl.c Worst changlog ever :( Why are you touching spec_ctrl.c in this patch? How does it belong here in this series? Come on, you

[PATCH V2 net-next 08/11] net: hns3: change the unit of GL value macro

From: Fuyun Liang Previously, driver used 2us as the GL unit. The time unit ethtool command "-c" and "-C" use is 1us, so now the GL unit driver uses actually is 1us. This patch changes the unit of GL value macro from 2us to 1us. Signed-off-by: Fuyun Liang

[PATCH V2 net-next 08/11] net: hns3: change the unit of GL value macro

From: Fuyun Liang Previously, driver used 2us as the GL unit. The time unit ethtool command "-c" and "-C" use is 1us, so now the GL unit driver uses actually is 1us. This patch changes the unit of GL value macro from 2us to 1us. Signed-off-by: Fuyun Liang Signed-off-by: Peng Li ---

Re: [PATCH 1/5] x86/ibrs: Introduce native_rdmsrl, and native_wrmsrl

On Thu, Jan 11, 2018 at 05:32:15PM -0800, Ashok Raj wrote: > - Remove including microcode.h, and use native macros from asm/msr.h > - added license header for spec_ctrl.c Worst changlog ever :( Why are you touching spec_ctrl.c in this patch? How does it belong here in this series? Come on, you

[PATCH V2 net-next 02/11] net: hns3: remove TSO config command from VF driver

Only main PF can config TSO MSS length according to hardware. This patch removes TSO config command from VF driver. Signed-off-by: Peng Li --- .../net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 8 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c| 20

[PATCH V2 net-next 02/11] net: hns3: remove TSO config command from VF driver

Only main PF can config TSO MSS length according to hardware. This patch removes TSO config command from VF driver. Signed-off-by: Peng Li --- .../net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 8 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c| 20 2

Re: [PATCH v4] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

On 2018/1/11 22:17, Adrian Hunter wrote: >> (e.g., via 'perf inject --itrace'), are also not supported >> >> - technically both cs-etm and spe can be used simultaneously, however >> disabled for simplicity in this release >> >> Signed-off-by: Kim Phillips > For what is

Re: [PATCH v4] perf tools: Add ARM Statistical Profiling Extensions (SPE) support

On 2018/1/11 22:17, Adrian Hunter wrote: >> (e.g., via 'perf inject --itrace'), are also not supported >> >> - technically both cs-etm and spe can be used simultaneously, however >> disabled for simplicity in this release >> >> Signed-off-by: Kim Phillips > For what is there now, it looks

[PATCH] IB/cma: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/infiniband/core/cma_configfs.c: In function 'make_cma_dev': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 64 equals destination size [-Wstringop-truncation] We need to use strlcpy() to make

[PATCH] IB/cma: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/infiniband/core/cma_configfs.c: In function 'make_cma_dev': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 64 equals destination size [-Wstringop-truncation] We need to use strlcpy() to make sure the string is

RE: [PATCH v2 04/16] remoteproc: introduce rproc_find_carveout_by_da

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:46 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN

RE: [PATCH v2 04/16] remoteproc: introduce rproc_find_carveout_by_da

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:46 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org >

RE: [PATCH v2 03/16] remoteproc: introduce rproc_add_carveout function

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:37 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN

RE: [PATCH v2 03/16] remoteproc: introduce rproc_add_carveout function

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:37 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org >

Re: [PATCH v2] KVM: arm/arm64: vgic-its: Fix vgicv4 init

Hi Christoffer On 11/01/18 19:55, Christoffer Dall wrote: > On Mon, Jan 08, 2018 at 10:52:54AM +0100, Eric Auger wrote: >> Commit 3d1ad640f8c94 ("KVM: arm/arm64: Fix GICv4 ITS initialization >> issues") moved the vgic_supports_direct_msis() check in vgic_v4_init(). >> However when vgic_v4_init is

Re: [PATCH v2] KVM: arm/arm64: vgic-its: Fix vgicv4 init

Hi Christoffer On 11/01/18 19:55, Christoffer Dall wrote: > On Mon, Jan 08, 2018 at 10:52:54AM +0100, Eric Auger wrote: >> Commit 3d1ad640f8c94 ("KVM: arm/arm64: Fix GICv4 ITS initialization >> issues") moved the vgic_supports_direct_msis() check in vgic_v4_init(). >> However when vgic_v4_init is

Re: [PATCH] input: multi-touch fix for ALPS touchpads ("SS4 plus" variant)

On Fri, Jan 12, 2018 at 01:02:55AM +, Masaki Ota wrote: > Hi, Nir, > > Wow, thank you for fixing the bug. > Your code is correct! Great, I am putting you down as "Reviewed-by" then. Thanks! > > Best Regards, > Masaki Ota > -Original Message- > From: Nir Perry

Re: [PATCH] input: multi-touch fix for ALPS touchpads ("SS4 plus" variant)

On Fri, Jan 12, 2018 at 01:02:55AM +, Masaki Ota wrote: > Hi, Nir, > > Wow, thank you for fixing the bug. > Your code is correct! Great, I am putting you down as "Reviewed-by" then. Thanks! > > Best Regards, > Masaki Ota > -Original Message- > From: Nir Perry

RE: [PATCH v2 02/16] remoteproc: add release ops in rproc_mem_entry struct

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:34 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN

RE: [PATCH v2 01/16] remoteproc: add rproc_va_to_pa function

Hi Bjorn, Thanks for the review of this series. > -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:31 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- >

RE: [PATCH v2 02/16] remoteproc: add release ops in rproc_mem_entry struct

> -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:34 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org; Arnaud POULIQUEN ; > benjamin.gaign...@linaro.org >

RE: [PATCH v2 01/16] remoteproc: add rproc_va_to_pa function

Hi Bjorn, Thanks for the review of this series. > -Original Message- > From: Bjorn Andersson [mailto:bjorn.anders...@linaro.org] > Sent: Thursday, December 14, 2017 1:31 AM > To: Loic PALLARDY > Cc: o...@wizery.com; linux-remotep...@vger.kernel.org; linux- > ker...@vger.kernel.org;

[PATCH] iio: accel: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/iio/accel/st_accel_i2c.c: In function 'st_accel_i2c_probe': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 20 equals destination size [-Wstringop-truncation] The compiler require that the length

[PATCH] iio: accel: use strlcpy() instead of strncpy()

From: Xiongfeng Wang gcc-8 reports drivers/iio/accel/st_accel_i2c.c: In function 'st_accel_i2c_probe': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 20 equals destination size [-Wstringop-truncation] The compiler require that the length of the dest string is

Re: [PATCH] selftests/x86: Add test_vsyscall

On Thu, Jan 11, 2018 at 05:16:51PM -0800, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling, >

Re: [PATCH] selftests/x86: Add test_vsyscall

On Thu, Jan 11, 2018 at 05:16:51PM -0800, Andy Lutomirski wrote: > This tests that the vsyscall entries do what they're expected to do. > It also confirms that attempts to read the vsyscall page behave as > expected. > > If changes are made to the vsyscall code or its memory map handling, >

Re: [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi David, On Thu, Jan 11, 2018 at 11:32:03AM -0500, David Miller wrote: > > Actually, this introduced build warnings, I'm reverting. Please fix this > and repost. The warning points a real issue. I'm sorry about that, seems like I forgot to test this one after the last change... I'll send a

Re: [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

Hi David, On Thu, Jan 11, 2018 at 11:32:03AM -0500, David Miller wrote: > > Actually, this introduced build warnings, I'm reverting. Please fix this > and repost. The warning points a real issue. I'm sorry about that, seems like I forgot to test this one after the last change... I'll send a

Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 02:15:12PM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 1:03 AM, Greg KH wrote: > > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote: > >> Static analysis reports that 'handle' may be a user controlled value > >> that is used

Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 02:15:12PM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 1:03 AM, Greg KH wrote: > > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote: > >> Static analysis reports that 'handle' may be a user controlled value > >> that is used as a data dependency to read

Re: [PATCH 4/5] x86/svm: Direct access to MSR_IA32_SPEC_CTRL

On Thu, 2018-01-11 at 17:32 -0800, Ashok Raj wrote: > > @@ -4910,6 +4935,14 @@ static void svm_vcpu_run(struct kvm_vcpu > *vcpu) >   > clgi(); >   > +   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > +   /* > +    * FIXME: lockdep_assert_irqs_disabled(); > +  

Re: [PATCH 4/5] x86/svm: Direct access to MSR_IA32_SPEC_CTRL

On Thu, 2018-01-11 at 17:32 -0800, Ashok Raj wrote: > > @@ -4910,6 +4935,14 @@ static void svm_vcpu_run(struct kvm_vcpu > *vcpu) >   > clgi(); >   > +   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL)) { > +   /* > +    * FIXME: lockdep_assert_irqs_disabled(); > +  

Re: [PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree

On 11.01.2018 23:56, Rob Herring wrote: On Mon, Jan 08, 2018 at 06:54:37AM +0200, Mikko Perttunen wrote: Add the chip-level device tree, including binding headers, for the NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices are initially available, enough to boot to UART

Re: [PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree

On 11.01.2018 23:56, Rob Herring wrote: On Mon, Jan 08, 2018 at 06:54:37AM +0200, Mikko Perttunen wrote: Add the chip-level device tree, including binding headers, for the NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices are initially available, enough to boot to UART

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 12, 2018 at 12:03:10AM +0100, Thomas Gleixner wrote: > On Thu, 11 Jan 2018, Thomas Gleixner wrote: > > On Thu, 11 Jan 2018, Thomas Gleixner wrote: > > > On Thu, 11 Jan 2018, Linus Torvalds wrote: > > > > > > > On Thu, Jan 11, 2018 at 12:37 PM, Thomas Gleixner > >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 12, 2018 at 12:03:10AM +0100, Thomas Gleixner wrote: > On Thu, 11 Jan 2018, Thomas Gleixner wrote: > > On Thu, 11 Jan 2018, Thomas Gleixner wrote: > > > On Thu, 11 Jan 2018, Linus Torvalds wrote: > > > > > > > On Thu, Jan 11, 2018 at 12:37 PM, Thomas Gleixner > > > > wrote: > > > >

[PATCH] cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin

Some OpenPOWER boxes can have same pstate values for nominal and pmin pstates. In these boxes the current code will not initialize 'powernv_pstate_info.min' variable and result in erroneous CPU frequency reporting. This patch fixes this problem. Fixes: 09ca4c9b5958 ("cpufreq: powernv: Replacing

Re: [PATCH 2/6] crypto: engine - Permit to enqueue all async requests

On Wed, Jan 03, 2018 at 09:11:05PM +0100, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe > --- >

Re: [PATCH 2/6] crypto: engine - Permit to enqueue all async requests

On Wed, Jan 03, 2018 at 09:11:05PM +0100, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue any type of crypto_async_request. > > Signed-off-by: Corentin Labbe > --- > crypto/crypto_engine.c | 230 >

[PATCH] cpufreq: powernv: Dont assume distinct pstate values for nominal and pmin

Some OpenPOWER boxes can have same pstate values for nominal and pmin pstates. In these boxes the current code will not initialize 'powernv_pstate_info.min' variable and result in erroneous CPU frequency reporting. This patch fixes this problem. Fixes: 09ca4c9b5958 ("cpufreq: powernv: Replacing

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

On 11.01.2018 14:51, Philippe CORNU wrote: > Hi Brian & All *DSI DRM experts*, > > 1) Re-reading this patch, I realize that the returned value of > dw_mipi_dsi_host_transfer() is not correct: we should return the number > of transfered/received bytes... > > so I think there are two solutions:

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

On 11.01.2018 14:51, Philippe CORNU wrote: > Hi Brian & All *DSI DRM experts*, > > 1) Re-reading this patch, I realize that the returned value of > dw_mipi_dsi_host_transfer() is not correct: we should return the number > of transfered/received bytes... > > so I think there are two solutions:

[PATCH v2] arm64: allwinner: a64: a64-olinuxino: add usb otg

Add usb otg support for a64-olinuxino board, - USB0-ID connected with PH9 - USB0-VBUSDET connected with PH6 - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC Signed-off-by: Jagan Teki --- Changes for v2: - rebase on master - tested otg host mode.

[PATCH v2] arm64: allwinner: a64: a64-olinuxino: add usb otg

Add usb otg support for a64-olinuxino board, - USB0-ID connected with PH9 - USB0-VBUSDET connected with PH6 - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC Signed-off-by: Jagan Teki --- Changes for v2: - rebase on master - tested otg host mode.

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Donnerstag, 11. Januar 2018, 20:56:56 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 >

Re: [PATCH 1/2] crypto: Implement a generic crypto statistics

Am Donnerstag, 11. Januar 2018, 20:56:56 CET schrieb Corentin Labbe: Hi Corentin, > This patch implement a generic way to get statistics about all crypto > usages. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 11 > crypto/ablkcipher.c | 9

Re: [PATCH v4 1/9] dt-bindings: media: Add Renesas CEU bindings

On Fri, Jan 12, 2018 at 12:50:41AM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Tuesday, 9 January 2018 18:25:23 EET Jacopo Mondi wrote: > > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > > > Signed-off-by: Jacopo Mondi

Re: [PATCH v4 1/9] dt-bindings: media: Add Renesas CEU bindings

On Fri, Jan 12, 2018 at 12:50:41AM +0200, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Tuesday, 9 January 2018 18:25:23 EET Jacopo Mondi wrote: > > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > > > Signed-off-by: Jacopo Mondi > >

[PATCH] kconfig: Warn if there is more than one help text

Avoids mistakes like in the following real-world example, where only the final help string ("Say Y...") was used. This particular example was fixed in commit 561b29e4ec8d ("media: fix media Kconfig help syntax issues"). config DVB_NETUP_UNIDVB ... select DVB_CXD2841ER if

[PATCH] kconfig: Warn if there is more than one help text

Avoids mistakes like in the following real-world example, where only the final help string ("Say Y...") was used. This particular example was fixed in commit 561b29e4ec8d ("media: fix media Kconfig help syntax issues"). config DVB_NETUP_UNIDVB ... select DVB_CXD2841ER if

[PATCH] Input: trackpoint - force 3 buttons if 0 button is reported

Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands. Some of these sticks with 3 buttons always return 0 when reading extended button info, set it as 3 buttons to enable middle button. Cc: sta...@vger.kernel.org Signed-off-by: Aaron Ma ---

[PATCH] Input: trackpoint - force 3 buttons if 0 button is reported

Lenovo introduced trackpoint compatible sticks with minimum PS/2 commands. Some of these sticks with 3 buttons always return 0 when reading extended button info, set it as 3 buttons to enable middle button. Cc: sta...@vger.kernel.org Signed-off-by: Aaron Ma --- drivers/input/mouse/trackpoint.c

Crypto Fixes for 4.15

Hi Linus: This push fixes a NULL pointer dereference in crypto_remove_spawns that can be triggered through af_alg. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Eric Biggers (1): crypto: algapi - fix NULL dereference in

Crypto Fixes for 4.15

Hi Linus: This push fixes a NULL pointer dereference in crypto_remove_spawns that can be triggered through af_alg. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Eric Biggers (1): crypto: algapi - fix NULL dereference in

Re: [x86-tip] RSDP changes converted i4790 box SMP -> UP

On 12/01/18 05:25, Mike Galbraith wrote: > Hi Juergen, > > Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but > discovered instead that my box had turned into a complete slug, not due > to incredible RETPOLINE overhead, rather because box had forgotten that > it had more than

Re: [x86-tip] RSDP changes converted i4790 box SMP -> UP

On 12/01/18 05:25, Mike Galbraith wrote: > Hi Juergen, > > Yesterday I wanted to test the RETPOLINE stuff in tip and tip-rt, but > discovered instead that my box had turned into a complete slug, not due > to incredible RETPOLINE overhead, rather because box had forgotten that > it had more than

[PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

Add usb otg support for bananapi-m64 board, - USB-ID connected with PH9 - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC Signed-off-by: Jagan Teki --- Changes for v4: - rebase on master - tested otg host mode. Changes for v3: - Move the position of reg_drivevbus as

[PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

Add usb otg support for bananapi-m64 board, - USB-ID connected with PH9 - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC Signed-off-by: Jagan Teki --- Changes for v4: - rebase on master - tested otg host mode. Changes for v3: - Move the position of reg_drivevbus as per binding documentation.

[PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

Add reg_drivevbus regualtor for boards which are using external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Signed-off-by: Jagan Teki --- Changes for v4: - rebase on master Changes for v3: - none arch/arm64/boot/dts/allwinner/axp803.dtsi | 5 + 1

[PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

Like axp221, axp223, axp813 the axp803 is also supporting external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Add support for it. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v4: - rebase on master Changes for

[PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

Add reg_drivevbus regualtor for boards which are using external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Signed-off-by: Jagan Teki --- Changes for v4: - rebase on master Changes for v3: - none arch/arm64/boot/dts/allwinner/axp803.dtsi | 5 + 1 file changed, 5

[PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

Like axp221, axp223, axp813 the axp803 is also supporting external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Add support for it. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Changes for v4: - rebase on master Changes for v3: - Update drivevbus in table of regulators

Re: [RESEND PATCH 0/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

On 01/11/18 at 01:05pm, Eric W. Biederman wrote: > Baoquan He writes: > > > Hi all, > > > > PING! > > > > (Add Fenghua and Eric to this thread) > > > > On 01/05/18 at 11:42am, Baoquan He wrote: > >> On kvm guest, the latest kernel will always print warning during kdump > >>

Re: [RESEND PATCH 0/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

On 01/11/18 at 01:05pm, Eric W. Biederman wrote: > Baoquan He writes: > > > Hi all, > > > > PING! > > > > (Add Fenghua and Eric to this thread) > > > > On 01/05/18 at 11:42am, Baoquan He wrote: > >> On kvm guest, the latest kernel will always print warning during kdump > >> kernel boots > >> as

Re: [RFC PATCH 2/2] softirq: Per vector thread deferment

On Fri, Jan 12, 2018 at 06:35:54AM +0100, Frederic Weisbecker wrote: > Some softirq vectors can be more CPU hungry than others. Especially > networking may sometimes deal with packet storm and need more CPU than > IRQ tail can offer without inducing scheduler latencies. In this case > the current

Re: [RFC PATCH 2/2] softirq: Per vector thread deferment

On Fri, Jan 12, 2018 at 06:35:54AM +0100, Frederic Weisbecker wrote: > Some softirq vectors can be more CPU hungry than others. Especially > networking may sometimes deal with packet storm and need more CPU than > IRQ tail can offer without inducing scheduler latencies. In this case > the current

Re: [PATCH v4 10/16] phy: qcom-qmp: Move register offsets to header file

Hi Manu, On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam wrote: > New revision (v3) of QMP PHY uses different offsets > for almost all of the registers. Hence, move these > definitions to header file so that updated offsets > can be added for QMP v3. > > Signed-off-by: Manu

Re: [PATCH v4 10/16] phy: qcom-qmp: Move register offsets to header file

Hi Manu, On Wed, Jan 3, 2018 at 4:58 PM, Manu Gautam wrote: > New revision (v3) of QMP PHY uses different offsets > for almost all of the registers. Hence, move these > definitions to header file so that updated offsets > can be added for QMP v3. > > Signed-off-by: Manu Gautam > --- >

Re: [PATCH v7 7/8] dt-bindings: can: m_can: Document new can transceiver binding

Hi Rob, On Friday 12 January 2018 01:50 AM, Rob Herring wrote: > On Wed, Jan 10, 2018 at 4:55 AM, Faiz Abbas wrote: >> From: Franklin S Cooper Jr >> >> Add information regarding can-transceiver binding. This is especially >> important for MCAN since the IP

Re: [PATCH v7 7/8] dt-bindings: can: m_can: Document new can transceiver binding

Hi Rob, On Friday 12 January 2018 01:50 AM, Rob Herring wrote: > On Wed, Jan 10, 2018 at 4:55 AM, Faiz Abbas wrote: >> From: Franklin S Cooper Jr >> >> Add information regarding can-transceiver binding. This is especially >> important for MCAN since the IP allows CAN FD mode to run

  1   2   3   4   5   6   7   8   9   10   >