Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 11:00:41PM +0700, Dede Dindin Qudsy wrote:
> 
> 
> On 27/04/18 20:57, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> build and tested on rn4, No dmesg regressions.

What is a "rn4"?  Anyway, thanks for testing and letting me know.

greg k-h

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 11:00:41PM +0700, Dede Dindin Qudsy wrote:
> 
> 
> On 27/04/18 20:57, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> build and tested on rn4, No dmesg regressions.

What is a "rn4"?  Anyway, thanks for testing and letting me know.

greg k-h

Re: [PATCH 4.16 00/81] 4.16.6-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 03:41:14PM -0500, Dan Rue wrote:
> On Fri, Apr 27, 2018 at 03:58:02PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.6 release.
> > There are 81 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:57:21 UTC 2018.
> > Anything received after that time might be too late.
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing these and letting me know.

greg k-h

Re: [PATCH 4.16 00/81] 4.16.6-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 03:41:14PM -0500, Dan Rue wrote:
> On Fri, Apr 27, 2018 at 03:58:02PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.6 release.
> > There are 81 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:57:21 UTC 2018.
> > Anything received after that time might be too late.
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing these and letting me know.

greg k-h

Re: [PATCH 4.14 41/80] Revert "microblaze: fix endian handling"

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 09:25:24AM -0700, Guenter Roeck wrote:
> On Fri, Apr 27, 2018 at 03:58:34PM +0200, Greg Kroah-Hartman wrote:
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Greg Kroah-Hartman 
> > 
> > This reverts commit ac3d021048be9edb825f0794da5b42f04fefecef which is
> > commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
> > 
> > kbuild reports that this causes build regressions in 4.14.y, so drop it.
> > 
> 
> I don't know about kbuild, but with this revert applied all Microblaze
> builds fail. There are endless
> 
> warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN 
> [-Wcpp]
> 
> followed by
> 
> lib/find_bit.c:185:15: error: redefinition of ‘find_next_bit_le’
> 
> I have to revert this revert to get successful builds.

Sorry about that, yes, you are right, it needs to be dropped, and I've
now done so and pushed out a -rc2 with that fixed up.

thanks,

greg k-h

Re: [PATCH 4.14 41/80] Revert "microblaze: fix endian handling"

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 09:25:24AM -0700, Guenter Roeck wrote:
> On Fri, Apr 27, 2018 at 03:58:34PM +0200, Greg Kroah-Hartman wrote:
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Greg Kroah-Hartman 
> > 
> > This reverts commit ac3d021048be9edb825f0794da5b42f04fefecef which is
> > commit 71e7673dadfdae0605d4c1f66ecb4b045c79fe0f upstream.
> > 
> > kbuild reports that this causes build regressions in 4.14.y, so drop it.
> > 
> 
> I don't know about kbuild, but with this revert applied all Microblaze
> builds fail. There are endless
> 
> warning: #warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN 
> [-Wcpp]
> 
> followed by
> 
> lib/find_bit.c:185:15: error: redefinition of ‘find_next_bit_le’
> 
> I have to revert this revert to get successful builds.

Sorry about that, yes, you are right, it needs to be dropped, and I've
now done so and pushed out a -rc2 with that fixed up.

thanks,

greg k-h

[PATCH v2 1/2] arm64: dts: Add msm8998 SoC and MTP board support

[Bjorn Andersson]

From: Joonwoo Park 

Add initial device tree support for the Qualcomm MSM8998 SoC and
MTP8998 evaluation board.

Signed-off-by: Joonwoo Park 
Signed-off-by: Imran Khan 
Signed-off-by: Rajendra Nayak 
[bjorn: Restructured, removed its node and moved to SPDX headers]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Cleaned up interrupts
- Added options to stdout-path

 arch/arm64/boot/dts/qcom/Makefile |   1 +
 arch/arm64/boot/dts/qcom/msm8998-mtp.dts  |  13 ++
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi |  20 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 340 ++
 4 files changed, 374 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index 55ec5ee7f7e8..f658595bb347 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dts
new file mode 100644
index ..f1853e020e57
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+/dts-v1/;
+
+#include "msm8998-mtp.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8998 v1 MTP";
+   compatible = "qcom,msm8998-mtp";
+
+   qcom,board-id = <8 0>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
new file mode 100644
index ..e30c95f63a05
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+#include "msm8998.dtsi"
+
+/ {
+   aliases {
+   serial0 = _uart1;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   serial@c1b {
+   status = "okay";
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
new file mode 100644
index ..d6665e4f801f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8998";
+
+   interrupt-parent = <>;
+
+   qcom,msm-id = <292 0x0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   /* We expect the bootloader to fill in the reg */
+   reg = <0 0 0 0>;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   efficiency = <1024>;
+   next-level-cache = <_0>;
+   L2_0: l2-cache {
+   compatible = "arm,arch-cache";
+   cache-level = <2>;
+   };
+   L1_I_0: l1-icache {
+   compatible = "arm,arch-cache";
+   };
+   L1_D_0: l1-dcache {
+   compatible = "arm,arch-cache";
+   };
+   };
+
+   CPU1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   efficiency = <1024>;
+   next-level-cache = <_0>;
+   L1_I_1: l1-icache {
+   compatible = "arm,arch-cache";
+   };
+   L1_D_1: l1-dcache {
+   compatible = "arm,arch-cache";
+   };
+   };
+
+   CPU2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+

[PATCH v2 1/2] arm64: dts: Add msm8998 SoC and MTP board support

[Bjorn Andersson]

From: Joonwoo Park 

Add initial device tree support for the Qualcomm MSM8998 SoC and
MTP8998 evaluation board.

Signed-off-by: Joonwoo Park 
Signed-off-by: Imran Khan 
Signed-off-by: Rajendra Nayak 
[bjorn: Restructured, removed its node and moved to SPDX headers]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Cleaned up interrupts
- Added options to stdout-path

 arch/arm64/boot/dts/qcom/Makefile |   1 +
 arch/arm64/boot/dts/qcom/msm8998-mtp.dts  |  13 ++
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi |  20 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 340 ++
 4 files changed, 374 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
index 55ec5ee7f7e8..f658595bb347 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8992-bullhead-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)+= msm8996-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= msm8998-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dts
new file mode 100644
index ..f1853e020e57
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+/dts-v1/;
+
+#include "msm8998-mtp.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8998 v1 MTP";
+   compatible = "qcom,msm8998-mtp";
+
+   qcom,board-id = <8 0>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
new file mode 100644
index ..e30c95f63a05
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+#include "msm8998.dtsi"
+
+/ {
+   aliases {
+   serial0 = _uart1;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   serial@c1b {
+   status = "okay";
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
new file mode 100644
index ..d6665e4f801f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2016, The Linux Foundation. All rights reserved. */
+
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8998";
+
+   interrupt-parent = <>;
+
+   qcom,msm-id = <292 0x0>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   chosen { };
+
+   memory {
+   device_type = "memory";
+   /* We expect the bootloader to fill in the reg */
+   reg = <0 0 0 0>;
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   efficiency = <1024>;
+   next-level-cache = <_0>;
+   L2_0: l2-cache {
+   compatible = "arm,arch-cache";
+   cache-level = <2>;
+   };
+   L1_I_0: l1-icache {
+   compatible = "arm,arch-cache";
+   };
+   L1_D_0: l1-dcache {
+   compatible = "arm,arch-cache";
+   };
+   };
+
+   CPU1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   efficiency = <1024>;
+   next-level-cache = <_0>;
+   L1_I_1: l1-icache {
+   compatible = "arm,arch-cache";
+   };
+   L1_D_1: l1-dcache {
+   compatible = "arm,arch-cache";
+   };
+   };
+
+   CPU2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   efficiency = <1024>;
+   next-level-cache = <_0>;
+   L1_I_2: 

[PATCH v2 2/2] arm64: dts: qcom: msm8998: Add rpm and regulators for MTP

[Bjorn Andersson]

This adds the rpm and rpm regulators to the msm8998 platform and mtp.

Signed-off-by: Bjorn Andersson 
---
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 142 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi |  83 +
 2 files changed, 225 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
index e30c95f63a05..4780751b560e 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -18,3 +18,145 @@
status = "okay";
};
 };
+
+_glink {
+   rpm_requests {
+   pm8998-regulators {
+   s2 {
+   regulator-min-microvolt = <1128000>;
+   regulator-max-microvolt = <1128000>;
+   };
+   s3 {
+   regulator-min-microvolt = <1352000>;
+   regulator-max-microvolt = <1352000>;
+   };
+   s4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   s5 {
+   regulator-min-microvolt = <1904000>;
+   regulator-max-microvolt = <204>;
+   };
+   s7 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <1028000>;
+   };
+   s8 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <80>;
+   };
+   l1 {
+   regulator-min-microvolt = <88>;
+   regulator-max-microvolt = <88>;
+   };
+   l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   };
+   l3 {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+   l5 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <80>;
+   };
+   l6 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <1808000>;
+   };
+   l7 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l8 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   };
+   l9 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l10 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l11 {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+   l12 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l13 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l14 {
+   regulator-min-microvolt = <188>;
+   regulator-max-microvolt = <188>;
+   };
+   l15 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l16 {
+   regulator-min-microvolt = <2704000>;
+   regulator-max-microvolt = <2704000>;
+   };
+   l17 {
+   regulator-min-microvolt = <1304000>;
+   regulator-max-microvolt = <1304000>;
+   };
+   l18 {
+ 

[PATCH v2 2/2] arm64: dts: qcom: msm8998: Add rpm and regulators for MTP

[Bjorn Andersson]

This adds the rpm and rpm regulators to the msm8998 platform and mtp.

Signed-off-by: Bjorn Andersson 
---
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 142 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi |  83 +
 2 files changed, 225 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
index e30c95f63a05..4780751b560e 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -18,3 +18,145 @@
status = "okay";
};
 };
+
+_glink {
+   rpm_requests {
+   pm8998-regulators {
+   s2 {
+   regulator-min-microvolt = <1128000>;
+   regulator-max-microvolt = <1128000>;
+   };
+   s3 {
+   regulator-min-microvolt = <1352000>;
+   regulator-max-microvolt = <1352000>;
+   };
+   s4 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   s5 {
+   regulator-min-microvolt = <1904000>;
+   regulator-max-microvolt = <204>;
+   };
+   s7 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <1028000>;
+   };
+   s8 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <80>;
+   };
+   l1 {
+   regulator-min-microvolt = <88>;
+   regulator-max-microvolt = <88>;
+   };
+   l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   };
+   l3 {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+   l5 {
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <80>;
+   };
+   l6 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <1808000>;
+   };
+   l7 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l8 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   };
+   l9 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l10 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l11 {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+   l12 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l13 {
+   regulator-min-microvolt = <1808000>;
+   regulator-max-microvolt = <296>;
+   };
+   l14 {
+   regulator-min-microvolt = <188>;
+   regulator-max-microvolt = <188>;
+   };
+   l15 {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+   l16 {
+   regulator-min-microvolt = <2704000>;
+   regulator-max-microvolt = <2704000>;
+   };
+   l17 {
+   regulator-min-microvolt = <1304000>;
+   regulator-max-microvolt = <1304000>;
+   };
+   l18 {
+   

Re: [PATCH] mm: memory_hotplug: use put_device() if device_register fail

[arvindY]

On Friday 27 April 2018 08:26 PM, Michal Hocko wrote:

On Thu 26-04-18 21:12:09, Arvind Yadav wrote:

if device_register() returned an error. Always use put_device()
to give up the initialized reference and release allocated memory.

Is this patch correct? The docummentation says
  * NOTE: _Never_ directly free @dev after calling this function, even
  * if it returned an error! Always use put_device() to give up your
  * reference instead.

but we do not have _our_ reference in this path AFAICS. Maybe this is
just a documentation issue? How have you tested this change btw.?

The document is correct. Here device_register() will initialize object by
making reference count as 1 and also increment reference count for device.

device_register() {
   device_initialize()->kobject_init()->kref_init() - initialize 
object( reference count = 1).

   device_add()->get_device() - increment reference count for device.
}

If device_register() will fail then we have to release the object by making
reference count 0. So we need to call put_object() which will release the
object and other resources like memory etc. so long as the reference
count is nonzero, the object continue to exist in memory.

I have not tested this peace of code. But I have tested other code which
is using Kboject.

~arvind



Signed-off-by: Arvind Yadav 
---
  drivers/base/memory.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bffe861..f5e5601 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -649,13 +649,19 @@ static const struct attribute_group 
*memory_memblk_attr_groups[] = {
  static
  int register_memory(struct memory_block *memory)
  {
+   int ret;
+
memory->dev.bus = _subsys;
memory->dev.id = memory->start_section_nr / sections_per_block;
memory->dev.release = memory_block_release;
memory->dev.groups = memory_memblk_attr_groups;
memory->dev.offline = memory->state == MEM_OFFLINE;
  
-	return device_register(>dev);

+   ret = device_register(>dev);
+   if (ret)
+   put_device(>dev);
+
+   return ret;
  }
  
  static int init_memory_block(struct memory_block **memory,

--
2.7.4

Re: [PATCH] mm: memory_hotplug: use put_device() if device_register fail

[arvindY]

On Friday 27 April 2018 08:26 PM, Michal Hocko wrote:

On Thu 26-04-18 21:12:09, Arvind Yadav wrote:

if device_register() returned an error. Always use put_device()
to give up the initialized reference and release allocated memory.

Is this patch correct? The docummentation says
  * NOTE: _Never_ directly free @dev after calling this function, even
  * if it returned an error! Always use put_device() to give up your
  * reference instead.

but we do not have _our_ reference in this path AFAICS. Maybe this is
just a documentation issue? How have you tested this change btw.?

The document is correct. Here device_register() will initialize object by
making reference count as 1 and also increment reference count for device.

device_register() {
   device_initialize()->kobject_init()->kref_init() - initialize 
object( reference count = 1).

   device_add()->get_device() - increment reference count for device.
}

If device_register() will fail then we have to release the object by making
reference count 0. So we need to call put_object() which will release the
object and other resources like memory etc. so long as the reference
count is nonzero, the object continue to exist in memory.

I have not tested this peace of code. But I have tested other code which
is using Kboject.

~arvind



Signed-off-by: Arvind Yadav 
---
  drivers/base/memory.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bffe861..f5e5601 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -649,13 +649,19 @@ static const struct attribute_group 
*memory_memblk_attr_groups[] = {
  static
  int register_memory(struct memory_block *memory)
  {
+   int ret;
+
memory->dev.bus = _subsys;
memory->dev.id = memory->start_section_nr / sections_per_block;
memory->dev.release = memory_block_release;
memory->dev.groups = memory_memblk_attr_groups;
memory->dev.offline = memory->state == MEM_OFFLINE;
  
-	return device_register(>dev);

+   ret = device_register(>dev);
+   if (ret)
+   put_device(>dev);
+
+   return ret;
  }
  
  static int init_memory_block(struct memory_block **memory,

--
2.7.4

Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform

[Wang YanQing]

On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
> >> test_verifier(kselftest) report below errors on x86_32:
> >> "
> >> 172/p unpriv: spill/fill of different pointers ldx FAIL
> >> Unexpected error message!
> >> 0: (bf) r6 = r10
> >> 1: (07) r6 += -8
> >> 2: (15) if r1 == 0x0 goto pc+3
> >> R1=ctx(id=0,off=0,imm=0) R6=fp-8,call_-1 R10=fp0,call_-1
> >> 3: (bf) r2 = r10
> >> 4: (07) r2 += -76
> >> 5: (7b) *(u64 *)(r6 +0) = r2
> >> 6: (55) if r1 != 0x0 goto pc+1
> >> R1=ctx(id=0,off=0,imm=0) R2=fp-76,call_-1 R6=fp-8,call_-1 R10=fp0,call_-1 
> >> fp-8=fp
> >> 7: (7b) *(u64 *)(r6 +0) = r1
> >> 8: (79) r1 = *(u64 *)(r6 +0)
> >> 9: (79) r1 = *(u64 *)(r1 +68)
> >> invalid bpf_context access off=68 size=8
> >>
> >> 378/p check bpf_perf_event_data->sample_period byte load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (71) r0 = *(u8 *)(r1 +68)
> >> invalid bpf_context access off=68 size=1
> >>
> >> 379/p check bpf_perf_event_data->sample_period half load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (69) r0 = *(u16 *)(r1 +68)
> >> invalid bpf_context access off=68 size=2
> >>
> >> 380/p check bpf_perf_event_data->sample_period word load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (61) r0 = *(u32 *)(r1 +68)
> >> invalid bpf_context access off=68 size=4
> >>
> >> 381/p check bpf_perf_event_data->sample_period dword load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (79) r0 = *(u64 *)(r1 +68)
> >> invalid bpf_context access off=68 size=8
> >> "
> >>
> >> This patch fix it, the fix isn't only necessary for x86_32, it will fix the
> >> same problem for other platforms too, if their size of bpf_user_pt_regs_t
> >> can't divide exactly into 8.
> >>
> >> Signed-off-by: Wang YanQing 
> >> ---
> >>  Hi all!
> >>  After mainline accept this patch, then we need to submit a sync patch
> >>  to update the tools/include/uapi/linux/bpf_perf_event.h.
> >>
> >>  Thanks.
> >>
> >>  include/uapi/linux/bpf_perf_event.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/uapi/linux/bpf_perf_event.h 
> >> b/include/uapi/linux/bpf_perf_event.h
> >> index eb1b9d2..ff4c092 100644
> >> --- a/include/uapi/linux/bpf_perf_event.h
> >> +++ b/include/uapi/linux/bpf_perf_event.h
> >> @@ -12,7 +12,7 @@
> >>  
> >>  struct bpf_perf_event_data {
> >>bpf_user_pt_regs_t regs;
> >> -  __u64 sample_period;
> >> +  __u64 sample_period __attribute__((aligned(8)));
> > 
> > I don't think this necessary.
> > imo it's a bug in pe_prog_is_valid_access
> > that should have allowed 8-byte access to 4-byte aligned sample_period.
> > The access rewritten by pe_prog_convert_ctx_access anyway,
> > no alignment issues as far as I can see.
> 
> Right, good point. Wang, could you give the below a test run:
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 56ba0f2..95b9142 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -833,8 +833,14 @@ static bool pe_prog_is_valid_access(int off, int size, 
> enum bpf_access_type type
>   return false;
>   if (type != BPF_READ)
>   return false;
> - if (off % size != 0)
> - return false;
> + if (off % size != 0) {
> + if (sizeof(long) != 4)
> + return false;
> + if (size != 8)
> + return false;
> + if (off % size != 4)
> + return false;
> + }
> 
>   switch (off) {
>   case bpf_ctx_range(struct bpf_perf_event_data, sample_period):
Hi all!

I have tested this patch, but test_verifier reports the same errors
for the five testcases.

The reason is they all failed to pass the test of bpf_ctx_narrow_access_ok.

Thanks.

Re: [PATCH] bpf: fix misaligned access for BPF_PROG_TYPE_PERF_EVENT program type on x86_32 platform

[Wang YanQing]

On Sat, Apr 28, 2018 at 01:33:15AM +0200, Daniel Borkmann wrote:
> On 04/28/2018 12:48 AM, Alexei Starovoitov wrote:
> > On Thu, Apr 26, 2018 at 05:57:49PM +0800, Wang YanQing wrote:
> >> All the testcases for BPF_PROG_TYPE_PERF_EVENT program type in
> >> test_verifier(kselftest) report below errors on x86_32:
> >> "
> >> 172/p unpriv: spill/fill of different pointers ldx FAIL
> >> Unexpected error message!
> >> 0: (bf) r6 = r10
> >> 1: (07) r6 += -8
> >> 2: (15) if r1 == 0x0 goto pc+3
> >> R1=ctx(id=0,off=0,imm=0) R6=fp-8,call_-1 R10=fp0,call_-1
> >> 3: (bf) r2 = r10
> >> 4: (07) r2 += -76
> >> 5: (7b) *(u64 *)(r6 +0) = r2
> >> 6: (55) if r1 != 0x0 goto pc+1
> >> R1=ctx(id=0,off=0,imm=0) R2=fp-76,call_-1 R6=fp-8,call_-1 R10=fp0,call_-1 
> >> fp-8=fp
> >> 7: (7b) *(u64 *)(r6 +0) = r1
> >> 8: (79) r1 = *(u64 *)(r6 +0)
> >> 9: (79) r1 = *(u64 *)(r1 +68)
> >> invalid bpf_context access off=68 size=8
> >>
> >> 378/p check bpf_perf_event_data->sample_period byte load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (71) r0 = *(u8 *)(r1 +68)
> >> invalid bpf_context access off=68 size=1
> >>
> >> 379/p check bpf_perf_event_data->sample_period half load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (69) r0 = *(u16 *)(r1 +68)
> >> invalid bpf_context access off=68 size=2
> >>
> >> 380/p check bpf_perf_event_data->sample_period word load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (61) r0 = *(u32 *)(r1 +68)
> >> invalid bpf_context access off=68 size=4
> >>
> >> 381/p check bpf_perf_event_data->sample_period dword load permitted FAIL
> >> Failed to load prog 'Permission denied'!
> >> 0: (b7) r0 = 0
> >> 1: (79) r0 = *(u64 *)(r1 +68)
> >> invalid bpf_context access off=68 size=8
> >> "
> >>
> >> This patch fix it, the fix isn't only necessary for x86_32, it will fix the
> >> same problem for other platforms too, if their size of bpf_user_pt_regs_t
> >> can't divide exactly into 8.
> >>
> >> Signed-off-by: Wang YanQing 
> >> ---
> >>  Hi all!
> >>  After mainline accept this patch, then we need to submit a sync patch
> >>  to update the tools/include/uapi/linux/bpf_perf_event.h.
> >>
> >>  Thanks.
> >>
> >>  include/uapi/linux/bpf_perf_event.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/uapi/linux/bpf_perf_event.h 
> >> b/include/uapi/linux/bpf_perf_event.h
> >> index eb1b9d2..ff4c092 100644
> >> --- a/include/uapi/linux/bpf_perf_event.h
> >> +++ b/include/uapi/linux/bpf_perf_event.h
> >> @@ -12,7 +12,7 @@
> >>  
> >>  struct bpf_perf_event_data {
> >>bpf_user_pt_regs_t regs;
> >> -  __u64 sample_period;
> >> +  __u64 sample_period __attribute__((aligned(8)));
> > 
> > I don't think this necessary.
> > imo it's a bug in pe_prog_is_valid_access
> > that should have allowed 8-byte access to 4-byte aligned sample_period.
> > The access rewritten by pe_prog_convert_ctx_access anyway,
> > no alignment issues as far as I can see.
> 
> Right, good point. Wang, could you give the below a test run:
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 56ba0f2..95b9142 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -833,8 +833,14 @@ static bool pe_prog_is_valid_access(int off, int size, 
> enum bpf_access_type type
>   return false;
>   if (type != BPF_READ)
>   return false;
> - if (off % size != 0)
> - return false;
> + if (off % size != 0) {
> + if (sizeof(long) != 4)
> + return false;
> + if (size != 8)
> + return false;
> + if (off % size != 4)
> + return false;
> + }
> 
>   switch (off) {
>   case bpf_ctx_range(struct bpf_perf_event_data, sample_period):
Hi all!

I have tested this patch, but test_verifier reports the same errors
for the five testcases.

The reason is they all failed to pass the test of bpf_ctx_narrow_access_ok.

Thanks.

Re: copy_file_range and user space tools to do copy fastest

[Steve French]

On Sat, Apr 28, 2018 at 12:18 AM, Andreas Dilger  wrote:
> On Apr 27, 2018, at 5:41 PM, Eric Biggers  wrote:
>>
>> On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote:
>>> On Apr 27, 2018, at 12:25 PM, Steve French  wrote:

 Are there any user space tools (other than our test tools and xfs_io
 etc.) that support copy_file_range?  Looks like at least cp and rsync
 and dd don't.  That syscall which now has been around a couple years,
 and was reminded about at the LSF/MM summit a few days ago, presumably
 is the 'best' way to copy a file fast since it tries all the
 mechanisms (reflink etc.) in order.

 Since copy_file_range syscall can be 100x or more faster for network
 file systems than the alternative, was surprised when I noticed that
 cp and rsync didn't support it.  It doesn't look like rsync even
 supports reflink either(although presumably if you call
 copy_file_range you don't have to worry about that), and reads/writes
 are 8K. See copy_file() in rsync/util.c

 In the cp command it looks like it can call the FICLONE IOCTL (see
 clone_file() in coreutils/src/copy.c) but doesn't call the expected
 "copy_file_range" syscall.

 In the dd command it doesn't call either - see dd_copy in corutils/src/dd.c

 Since it can be 100x or more faster in some cases to call
 copy_file_range than do reads/writes back and forth to do a copy
 (especially if network or clustered backend or cloud), what tools are
 the best to recommend?

 Would rsync or cp be likely to take patches to call the standard
 "copy_file_range" syscall
 (http://man7.org/linux/man-pages/man2/copy_file_range.2.html)?
 Presumably not if it has been two+ years ... but would be interested
 what copy tools to recommend to use instead.
>>>
>>> I would start with submitting a patch to coreutils, if you can figure
>>> out that code enough to do so (I find it quite opaque).  Since it has
>>> been in the kernel for a while already, it should be acceptable to the
>>> upstream coreutils maintainers to use this interface.  Doubly so if you
>>> include some benchmarks with CIFS/NFS clients avoiding network overhead
>>> during the copy.
>>>
>>
>> For cp (coreutils), apparently there was a concern that copy_file_range()
>> expands holes; see the thread at
>> https://lists.gnu.org/archive/html/bug-coreutils/2016-09/msg00020.html.
>> Though, I'd think it could just be used on non-holes only.  And I don't think
>> the size_t type of 'len' is a problem either, since it's the copy length, not
>> the file size.  You just call it multiple times if the file is larger.
>
> I think cp is already using SEEK_HOLE/SEEK_DATA and/or FIEMAP to determine
> the mapped and sparse segments of the file, so it should be practical to
> use copy_file_range() in conjunction with these to copy only the allocated
> parts of the file.

For the case where clone/reflink or copy_file_range is supported - is
there any reason to
not sent the request to copy the whole file? Presumably long
timeout/errors might be a concern, but
that could happen with ranges too.  In any case, if sent the whole
file copy request,
the server file system can figure out the  holes and copy more efficiently.

In the case where it is copying local to remote or remote to local -
figuring out whether it is
sparse and optimizing makes a lot of sense - but I didn't think cp did
that (at least the
sections of code I was looking at).



-- 
Thanks,

Steve

Re: copy_file_range and user space tools to do copy fastest

[Steve French]

On Sat, Apr 28, 2018 at 12:18 AM, Andreas Dilger  wrote:
> On Apr 27, 2018, at 5:41 PM, Eric Biggers  wrote:
>>
>> On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote:
>>> On Apr 27, 2018, at 12:25 PM, Steve French  wrote:

 Are there any user space tools (other than our test tools and xfs_io
 etc.) that support copy_file_range?  Looks like at least cp and rsync
 and dd don't.  That syscall which now has been around a couple years,
 and was reminded about at the LSF/MM summit a few days ago, presumably
 is the 'best' way to copy a file fast since it tries all the
 mechanisms (reflink etc.) in order.

 Since copy_file_range syscall can be 100x or more faster for network
 file systems than the alternative, was surprised when I noticed that
 cp and rsync didn't support it.  It doesn't look like rsync even
 supports reflink either(although presumably if you call
 copy_file_range you don't have to worry about that), and reads/writes
 are 8K. See copy_file() in rsync/util.c

 In the cp command it looks like it can call the FICLONE IOCTL (see
 clone_file() in coreutils/src/copy.c) but doesn't call the expected
 "copy_file_range" syscall.

 In the dd command it doesn't call either - see dd_copy in corutils/src/dd.c

 Since it can be 100x or more faster in some cases to call
 copy_file_range than do reads/writes back and forth to do a copy
 (especially if network or clustered backend or cloud), what tools are
 the best to recommend?

 Would rsync or cp be likely to take patches to call the standard
 "copy_file_range" syscall
 (http://man7.org/linux/man-pages/man2/copy_file_range.2.html)?
 Presumably not if it has been two+ years ... but would be interested
 what copy tools to recommend to use instead.
>>>
>>> I would start with submitting a patch to coreutils, if you can figure
>>> out that code enough to do so (I find it quite opaque).  Since it has
>>> been in the kernel for a while already, it should be acceptable to the
>>> upstream coreutils maintainers to use this interface.  Doubly so if you
>>> include some benchmarks with CIFS/NFS clients avoiding network overhead
>>> during the copy.
>>>
>>
>> For cp (coreutils), apparently there was a concern that copy_file_range()
>> expands holes; see the thread at
>> https://lists.gnu.org/archive/html/bug-coreutils/2016-09/msg00020.html.
>> Though, I'd think it could just be used on non-holes only.  And I don't think
>> the size_t type of 'len' is a problem either, since it's the copy length, not
>> the file size.  You just call it multiple times if the file is larger.
>
> I think cp is already using SEEK_HOLE/SEEK_DATA and/or FIEMAP to determine
> the mapped and sparse segments of the file, so it should be practical to
> use copy_file_range() in conjunction with these to copy only the allocated
> parts of the file.

For the case where clone/reflink or copy_file_range is supported - is
there any reason to
not sent the request to copy the whole file? Presumably long
timeout/errors might be a concern, but
that could happen with ranges too.  In any case, if sent the whole
file copy request,
the server file system can figure out the  holes and copy more efficiently.

In the case where it is copying local to remote or remote to local -
figuring out whether it is
sparse and optimizing makes a lot of sense - but I didn't think cp did
that (at least the
sections of code I was looking at).



-- 
Thanks,

Steve

Re: WARNING in perf_trace_buf_alloc (2)

[Alexei Starovoitov]

On Sat, Apr 21, 2018 at 12:37:01PM -0700, Eric Biggers wrote:
> [+bpf maintainers and netdev]
> 
> On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote:
> > Hello,
> > 
> > syzkaller hit the following crash on
> > 5cb0512c02ecd7e6214e912e4c150f4219ac78e0
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> > 
> > 
> > [ cut here ]
> > WARNING: CPU: 0 PID: 3008 at kernel/trace/trace_event_perf.c:274
> > perf_trace_buf_alloc+0x12d/0x160 kernel/trace/trace_event_perf.c:273
> > Kernel panic - not syncing: panic_on_warn set ...
> > 
> > CPU: 0 PID: 3008 Comm: syzkaller609027 Not tainted 4.14.0-rc7+ #159
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:17 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >  panic+0x1e4/0x417 kernel/panic.c:181
> >  __warn+0x1c4/0x1d9 kernel/panic.c:542
> >  report_bug+0x211/0x2d0 lib/bug.c:184
> >  fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> >  do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> >  do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> >  do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> >  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> >  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:906
> > RIP: 0010:perf_trace_buf_alloc+0x12d/0x160
> > kernel/trace/trace_event_perf.c:273
> > RSP: 0018:8801c0fdf760 EFLAGS: 00010286
> > RAX: 001c RBX: 1100381fbefe RCX: 
> > RDX: 001c RSI: 1100381fbeac RDI: ed00381fbee0
> > RBP: 8801c0fdf780 R08: 0001 R09: 
> > R10: 8801c0fdf7a0 R11:  R12: 082c
> > R13: 8801c0fdf810 R14: 8801c0fdf890 R15: 8801d8b34b40
> >  perf_trace_bpf_map_keyval+0x260/0xbd0 include/trace/events/bpf.h:228
> >  trace_bpf_map_update_elem include/trace/events/bpf.h:274 [inline]
> >  map_update_elem kernel/bpf/syscall.c:597 [inline]
> >  SYSC_bpf kernel/bpf/syscall.c:1478 [inline]
> >  SyS_bpf+0x33eb/0x46a0 kernel/bpf/syscall.c:1453
> >  entry_SYSCALL_64_fastpath+0x1f/0xbe
> > RIP: 0033:0x445c29
> > RSP: 002b:007eff68 EFLAGS: 0246 ORIG_RAX: 0141
> > RAX: ffda RBX: 7ffe66adb340 RCX: 00445c29
> > RDX: 0020 RSI: 2053dfe0 RDI: 0002
> > RBP: 0082 R08:  R09: 
> > R10:  R11: 0246 R12: 00403280
> > R13: 00403310 R14:  R15: 
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
> > 
> > 
> > ---
> > This bug is generated by a dumb bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for details.
> > Direct all questions to syzkal...@googlegroups.com.
> > Please credit me with: Reported-by: syzbot 
> > 
> > syzbot will keep track of this bug report.
> > Once a fix for this bug is committed, please reply to this email with:
> > #syz fix: exact-commit-title
> > To mark this as a duplicate of another syzbot report, please reply with:
> > #syz dup: exact-subject-of-another-report
> > If it's a one-off invalid bug report, please reply with:
> > #syz invalid
> > Note: if the crash happens again, it will cause creation of a new bug
> > report.
> > Note: all commands must start from beginning of the line.
> 
> This still happens on Linus' tree.  It seems one of the BPF tracepoints is
> trying to pass a buffer that is too long.  Here's a simplified reproducer that

right. this is easily reproducible.
looks like tracepoints in bpf core rot quite a bit.
will send a patch to address that soon.

> works on Linus' tree (commit 5e7c7806111ade5).  Note: it's not 100% reliable 
> for
> some reason; you may have to run it a couple times.  Daniel or Alexei, can one
> of you please look into this more?  Thanks!
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main()
> {
> int tracepoint_id;
> FILE *f;
> 
> f = 
> fopen("/sys/kernel/debug/tracing/events/bpf/bpf_map_update_elem/id",
>   "r");
> fscanf(f, "%d", _id);
> 
> struct perf_event_attr perf_attr = {
> .type = PERF_TYPE_TRACEPOINT,
> .size = sizeof(perf_attr),
> .config = tracepoint_id,
> };
> syscall(__NR_perf_event_open, _attr, 0, 0, -1, 0);
> 
> for (;;) {
> union bpf_attr create_attr = {
> .map_type = BPF_MAP_TYPE_HASH,
> .key_size = 4,
> .value_size = 2048,
> 

Re: WARNING in perf_trace_buf_alloc (2)

[Alexei Starovoitov]

On Sat, Apr 21, 2018 at 12:37:01PM -0700, Eric Biggers wrote:
> [+bpf maintainers and netdev]
> 
> On Mon, Nov 06, 2017 at 03:56:01AM -0800, syzbot wrote:
> > Hello,
> > 
> > syzkaller hit the following crash on
> > 5cb0512c02ecd7e6214e912e4c150f4219ac78e0
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> > 
> > 
> > [ cut here ]
> > WARNING: CPU: 0 PID: 3008 at kernel/trace/trace_event_perf.c:274
> > perf_trace_buf_alloc+0x12d/0x160 kernel/trace/trace_event_perf.c:273
> > Kernel panic - not syncing: panic_on_warn set ...
> > 
> > CPU: 0 PID: 3008 Comm: syzkaller609027 Not tainted 4.14.0-rc7+ #159
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:17 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >  panic+0x1e4/0x417 kernel/panic.c:181
> >  __warn+0x1c4/0x1d9 kernel/panic.c:542
> >  report_bug+0x211/0x2d0 lib/bug.c:184
> >  fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
> >  do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
> >  do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
> >  do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
> >  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
> >  invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:906
> > RIP: 0010:perf_trace_buf_alloc+0x12d/0x160
> > kernel/trace/trace_event_perf.c:273
> > RSP: 0018:8801c0fdf760 EFLAGS: 00010286
> > RAX: 001c RBX: 1100381fbefe RCX: 
> > RDX: 001c RSI: 1100381fbeac RDI: ed00381fbee0
> > RBP: 8801c0fdf780 R08: 0001 R09: 
> > R10: 8801c0fdf7a0 R11:  R12: 082c
> > R13: 8801c0fdf810 R14: 8801c0fdf890 R15: 8801d8b34b40
> >  perf_trace_bpf_map_keyval+0x260/0xbd0 include/trace/events/bpf.h:228
> >  trace_bpf_map_update_elem include/trace/events/bpf.h:274 [inline]
> >  map_update_elem kernel/bpf/syscall.c:597 [inline]
> >  SYSC_bpf kernel/bpf/syscall.c:1478 [inline]
> >  SyS_bpf+0x33eb/0x46a0 kernel/bpf/syscall.c:1453
> >  entry_SYSCALL_64_fastpath+0x1f/0xbe
> > RIP: 0033:0x445c29
> > RSP: 002b:007eff68 EFLAGS: 0246 ORIG_RAX: 0141
> > RAX: ffda RBX: 7ffe66adb340 RCX: 00445c29
> > RDX: 0020 RSI: 2053dfe0 RDI: 0002
> > RBP: 0082 R08:  R09: 
> > R10:  R11: 0246 R12: 00403280
> > R13: 00403310 R14:  R15: 
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
> > 
> > 
> > ---
> > This bug is generated by a dumb bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for details.
> > Direct all questions to syzkal...@googlegroups.com.
> > Please credit me with: Reported-by: syzbot 
> > 
> > syzbot will keep track of this bug report.
> > Once a fix for this bug is committed, please reply to this email with:
> > #syz fix: exact-commit-title
> > To mark this as a duplicate of another syzbot report, please reply with:
> > #syz dup: exact-subject-of-another-report
> > If it's a one-off invalid bug report, please reply with:
> > #syz invalid
> > Note: if the crash happens again, it will cause creation of a new bug
> > report.
> > Note: all commands must start from beginning of the line.
> 
> This still happens on Linus' tree.  It seems one of the BPF tracepoints is
> trying to pass a buffer that is too long.  Here's a simplified reproducer that

right. this is easily reproducible.
looks like tracepoints in bpf core rot quite a bit.
will send a patch to address that soon.

> works on Linus' tree (commit 5e7c7806111ade5).  Note: it's not 100% reliable 
> for
> some reason; you may have to run it a couple times.  Daniel or Alexei, can one
> of you please look into this more?  Thanks!
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main()
> {
> int tracepoint_id;
> FILE *f;
> 
> f = 
> fopen("/sys/kernel/debug/tracing/events/bpf/bpf_map_update_elem/id",
>   "r");
> fscanf(f, "%d", _id);
> 
> struct perf_event_attr perf_attr = {
> .type = PERF_TYPE_TRACEPOINT,
> .size = sizeof(perf_attr),
> .config = tracepoint_id,
> };
> syscall(__NR_perf_event_open, _attr, 0, 0, -1, 0);
> 
> for (;;) {
> union bpf_attr create_attr = {
> .map_type = BPF_MAP_TYPE_HASH,
> .key_size = 4,
> .value_size = 2048,
> 

Re: copy_file_range and user space tools to do copy fastest

[Andreas Dilger]

On Apr 27, 2018, at 5:41 PM, Eric Biggers  wrote:
> 
> On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote:
>> On Apr 27, 2018, at 12:25 PM, Steve French  wrote:
>>> 
>>> Are there any user space tools (other than our test tools and xfs_io
>>> etc.) that support copy_file_range?  Looks like at least cp and rsync
>>> and dd don't.  That syscall which now has been around a couple years,
>>> and was reminded about at the LSF/MM summit a few days ago, presumably
>>> is the 'best' way to copy a file fast since it tries all the
>>> mechanisms (reflink etc.) in order.
>>> 
>>> Since copy_file_range syscall can be 100x or more faster for network
>>> file systems than the alternative, was surprised when I noticed that
>>> cp and rsync didn't support it.  It doesn't look like rsync even
>>> supports reflink either(although presumably if you call
>>> copy_file_range you don't have to worry about that), and reads/writes
>>> are 8K. See copy_file() in rsync/util.c
>>> 
>>> In the cp command it looks like it can call the FICLONE IOCTL (see
>>> clone_file() in coreutils/src/copy.c) but doesn't call the expected
>>> "copy_file_range" syscall.
>>> 
>>> In the dd command it doesn't call either - see dd_copy in corutils/src/dd.c
>>> 
>>> Since it can be 100x or more faster in some cases to call
>>> copy_file_range than do reads/writes back and forth to do a copy
>>> (especially if network or clustered backend or cloud), what tools are
>>> the best to recommend?
>>> 
>>> Would rsync or cp be likely to take patches to call the standard
>>> "copy_file_range" syscall
>>> (http://man7.org/linux/man-pages/man2/copy_file_range.2.html)?
>>> Presumably not if it has been two+ years ... but would be interested
>>> what copy tools to recommend to use instead.
>> 
>> I would start with submitting a patch to coreutils, if you can figure
>> out that code enough to do so (I find it quite opaque).  Since it has
>> been in the kernel for a while already, it should be acceptable to the
>> upstream coreutils maintainers to use this interface.  Doubly so if you
>> include some benchmarks with CIFS/NFS clients avoiding network overhead
>> during the copy.
>> 
> 
> For cp (coreutils), apparently there was a concern that copy_file_range()
> expands holes; see the thread at
> https://lists.gnu.org/archive/html/bug-coreutils/2016-09/msg00020.html.
> Though, I'd think it could just be used on non-holes only.  And I don't think
> the size_t type of 'len' is a problem either, since it's the copy length, not
> the file size.  You just call it multiple times if the file is larger.

I think cp is already using SEEK_HOLE/SEEK_DATA and/or FIEMAP to determine
the mapped and sparse segments of the file, so it should be practical to
use copy_file_range() in conjunction with these to copy only the allocated
parts of the file.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

Re: copy_file_range and user space tools to do copy fastest

[Andreas Dilger]

On Apr 27, 2018, at 5:41 PM, Eric Biggers  wrote:
> 
> On Fri, Apr 27, 2018 at 01:45:40PM -0600, Andreas Dilger wrote:
>> On Apr 27, 2018, at 12:25 PM, Steve French  wrote:
>>> 
>>> Are there any user space tools (other than our test tools and xfs_io
>>> etc.) that support copy_file_range?  Looks like at least cp and rsync
>>> and dd don't.  That syscall which now has been around a couple years,
>>> and was reminded about at the LSF/MM summit a few days ago, presumably
>>> is the 'best' way to copy a file fast since it tries all the
>>> mechanisms (reflink etc.) in order.
>>> 
>>> Since copy_file_range syscall can be 100x or more faster for network
>>> file systems than the alternative, was surprised when I noticed that
>>> cp and rsync didn't support it.  It doesn't look like rsync even
>>> supports reflink either(although presumably if you call
>>> copy_file_range you don't have to worry about that), and reads/writes
>>> are 8K. See copy_file() in rsync/util.c
>>> 
>>> In the cp command it looks like it can call the FICLONE IOCTL (see
>>> clone_file() in coreutils/src/copy.c) but doesn't call the expected
>>> "copy_file_range" syscall.
>>> 
>>> In the dd command it doesn't call either - see dd_copy in corutils/src/dd.c
>>> 
>>> Since it can be 100x or more faster in some cases to call
>>> copy_file_range than do reads/writes back and forth to do a copy
>>> (especially if network or clustered backend or cloud), what tools are
>>> the best to recommend?
>>> 
>>> Would rsync or cp be likely to take patches to call the standard
>>> "copy_file_range" syscall
>>> (http://man7.org/linux/man-pages/man2/copy_file_range.2.html)?
>>> Presumably not if it has been two+ years ... but would be interested
>>> what copy tools to recommend to use instead.
>> 
>> I would start with submitting a patch to coreutils, if you can figure
>> out that code enough to do so (I find it quite opaque).  Since it has
>> been in the kernel for a while already, it should be acceptable to the
>> upstream coreutils maintainers to use this interface.  Doubly so if you
>> include some benchmarks with CIFS/NFS clients avoiding network overhead
>> during the copy.
>> 
> 
> For cp (coreutils), apparently there was a concern that copy_file_range()
> expands holes; see the thread at
> https://lists.gnu.org/archive/html/bug-coreutils/2016-09/msg00020.html.
> Though, I'd think it could just be used on non-holes only.  And I don't think
> the size_t type of 'len' is a problem either, since it's the copy length, not
> the file size.  You just call it multiple times if the file is larger.

I think cp is already using SEEK_HOLE/SEEK_DATA and/or FIEMAP to determine
the mapped and sparse segments of the file, so it should be practical to
use copy_file_range() in conjunction with these to copy only the allocated
parts of the file.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

Re: [PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959


coccinelle warnings: (new ones prefixed by >>)

>> drivers/bus/mhi/devices/mhi_uci.c:556:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v1 4/4] mhi_bus: dev: uci: add user space interface driver

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959


coccinelle warnings: (new ones prefixed by >>)

>> drivers/bus/mhi/devices/mhi_uci.c:556:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] mhi_bus: dev: uci: fix semicolon.cocci warnings

[kbuild test robot]

From: Fengguang Wu 

drivers/bus/mhi/devices/mhi_uci.c:556:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 2064c7ebc5cb ("mhi_bus: dev: uci: add user space interface driver")
CC: Sujeev Dias 
Signed-off-by: Fengguang Wu 
---

 mhi_uci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/bus/mhi/devices/mhi_uci.c
+++ b/drivers/bus/mhi/devices/mhi_uci.c
@@ -553,7 +553,7 @@ static int mhi_uci_probe(struct mhi_devi
spin_lock_init(_chan->lock);
init_waitqueue_head(_chan->wq);
INIT_LIST_HEAD(_chan->pending);
-   };
+   }
 
uci_dev->mtu = id->driver_data;
mhi_device_set_devdata(mhi_dev, uci_dev);

[PATCH] mhi_bus: dev: uci: fix semicolon.cocci warnings

[kbuild test robot]

From: Fengguang Wu 

drivers/bus/mhi/devices/mhi_uci.c:556:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Fixes: 2064c7ebc5cb ("mhi_bus: dev: uci: add user space interface driver")
CC: Sujeev Dias 
Signed-off-by: Fengguang Wu 
---

 mhi_uci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/bus/mhi/devices/mhi_uci.c
+++ b/drivers/bus/mhi/devices/mhi_uci.c
@@ -553,7 +553,7 @@ static int mhi_uci_probe(struct mhi_devi
spin_lock_init(_chan->lock);
init_waitqueue_head(_chan->wq);
INIT_LIST_HEAD(_chan->pending);
-   };
+   }
 
uci_dev->mtu = id->driver_data;
mhi_device_set_devdata(mhi_dev, uci_dev);

Re: [PATCH 4.14 00/80] 4.14.38-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 12:33:27PM -0700, Nathan Chancellor wrote:
> On Fri, Apr 27, 2018 at 03:57:53PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.38 release.
> > There are 80 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:57:13 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.38-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Merged, compiled, and installed on my Raspberry Pi 3.
> 
> No initial issues noticed in dmesg or general usage.

Thanks for testing this, and 4.4, and letting me know.

greg k-h

Re: [PATCH] dmaengine: stm32-mdma: fix spelling mistake: "avalaible" -> "available"

[Vinod Koul]

On Fri, Apr 27, 2018 at 08:24:31PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in dev_err error message text

Applied, thanks

-- 
~Vinod

Re: [PATCH 4.14 00/80] 4.14.38-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 12:33:27PM -0700, Nathan Chancellor wrote:
> On Fri, Apr 27, 2018 at 03:57:53PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.38 release.
> > There are 80 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:57:13 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.38-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Merged, compiled, and installed on my Raspberry Pi 3.
> 
> No initial issues noticed in dmesg or general usage.

Thanks for testing this, and 4.4, and letting me know.

greg k-h

Re: [PATCH] dmaengine: stm32-mdma: fix spelling mistake: "avalaible" -> "available"

[Vinod Koul]

On Fri, Apr 27, 2018 at 08:24:31PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in dev_err error message text

Applied, thanks

-- 
~Vinod

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Vinod Koul]

On Fri, Apr 27, 2018 at 05:18:29PM +0200, Lars-Peter Clausen wrote:
> On 04/27/2018 05:15 PM, Moritz Fischer wrote:
> > Hi Vinod,
> > 
> > On Fri, Apr 27, 2018 at 12:08 AM, Vinod Koul  wrote:
> >> On Fri, Apr 27, 2018 at 08:53:39AM +0200, Lars-Peter Clausen wrote:
> >>> On 04/27/2018 07:11 AM, Vinod Koul wrote:
>  On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
> > Request IRQ with IRQF_SHARED flag. This works since the interrupt
> > handler already checks if there is an actual IRQ pending and returns
> > IRQ_NONE otherwise.
> 
>  hmmm what are we trying to fix here? Is your device on a shared line or 
>  not?
> >>>
> >>> IRQF_SHARED does not mean that the IRQ is on a shared line. It means that
> >>> the driver can handle it if the IRQ is on a shared line. Since the driver
> >>> can handle it setting the flag is a good idea since this enables usecases
> >>> where the line is shared.
> >>
> >> Yes that is correct indeed, but what is the motivation for the change.
> >>
> >> If you never expect this to be in shared environment why to do this?
> >> Sorry but "it works" is not a good enough reason for this change, to enable
> >> usecases where the line is shared is a good reason :)
> > 
> > Remember, this is an FPGA soft core. I happen to have a design [1] where it
> > is hooked up with multiple of them on one IRQ line, so to make this work,
> > I need this change.
> 
> I think what Vinod is asking for is a change to the commit message saying
> that "this change enables the driver to be used with devices where the
> interrupt line is shared".

Correct, changelog need to reflect why a change was made, down the line
people need to know the reasons, sometimes it might be even you..

-- 
~Vinod

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Vinod Koul]

On Fri, Apr 27, 2018 at 05:18:29PM +0200, Lars-Peter Clausen wrote:
> On 04/27/2018 05:15 PM, Moritz Fischer wrote:
> > Hi Vinod,
> > 
> > On Fri, Apr 27, 2018 at 12:08 AM, Vinod Koul  wrote:
> >> On Fri, Apr 27, 2018 at 08:53:39AM +0200, Lars-Peter Clausen wrote:
> >>> On 04/27/2018 07:11 AM, Vinod Koul wrote:
>  On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
> > Request IRQ with IRQF_SHARED flag. This works since the interrupt
> > handler already checks if there is an actual IRQ pending and returns
> > IRQ_NONE otherwise.
> 
>  hmmm what are we trying to fix here? Is your device on a shared line or 
>  not?
> >>>
> >>> IRQF_SHARED does not mean that the IRQ is on a shared line. It means that
> >>> the driver can handle it if the IRQ is on a shared line. Since the driver
> >>> can handle it setting the flag is a good idea since this enables usecases
> >>> where the line is shared.
> >>
> >> Yes that is correct indeed, but what is the motivation for the change.
> >>
> >> If you never expect this to be in shared environment why to do this?
> >> Sorry but "it works" is not a good enough reason for this change, to enable
> >> usecases where the line is shared is a good reason :)
> > 
> > Remember, this is an FPGA soft core. I happen to have a design [1] where it
> > is hooked up with multiple of them on one IRQ line, so to make this work,
> > I need this change.
> 
> I think what Vinod is asking for is a change to the commit message saying
> that "this change enables the driver to be used with devices where the
> interrupt line is shared".

Correct, changelog need to reflect why a change was made, down the line
people need to know the reasons, sometimes it might be even you..

-- 
~Vinod

Re: [PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

[Greg KH]

On Fri, Apr 27, 2018 at 05:15:26PM -0700, Luis R. Rodriguez wrote:
> Some architectures do not define PAGE_KERNEL_RO, best we can do
> for them is to provide a fallback onto PAGE_KERNEL. Remove the
> hack from the firmware loader and move it onto the asm-generic
> header, and document while at it the affected architectures
> which do not have a PAGE_KERNEL_RO:
> 
>   o alpha
>   o ia64
>   o m68k
>   o mips
>   o sparc64
>   o sparc
> 
> Blessed-by: 0-day

New tag?  :)

Re: [PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

[Greg KH]

On Fri, Apr 27, 2018 at 05:15:26PM -0700, Luis R. Rodriguez wrote:
> Some architectures do not define PAGE_KERNEL_RO, best we can do
> for them is to provide a fallback onto PAGE_KERNEL. Remove the
> hack from the firmware loader and move it onto the asm-generic
> header, and document while at it the affected architectures
> which do not have a PAGE_KERNEL_RO:
> 
>   o alpha
>   o ia64
>   o m68k
>   o mips
>   o sparc64
>   o sparc
> 
> Blessed-by: 0-day

New tag?  :)

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 12:12:32PM -0600, Shuah Khan wrote:
> On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 03:03:04AM +0530, Harsh Shandilya wrote:
> On 27 April 2018 7:27:35 PM IST, Greg Kroah-Hartman 
>  wrote:
> >This is the start of the stable review cycle for the 3.18.107 release.
> >There are 24 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> >or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >linux-3.18.y
> >and the diffstat can be found below.
> No issues on the OnePlus 3, usage seems fine so far. Thanks!

Wonderful, thanks for testing and letting me know.

greg k-h

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 03:03:04AM +0530, Harsh Shandilya wrote:
> On 27 April 2018 7:27:35 PM IST, Greg Kroah-Hartman 
>  wrote:
> >This is the start of the stable review cycle for the 3.18.107 release.
> >There are 24 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> >or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >linux-3.18.y
> >and the diffstat can be found below.
> No issues on the OnePlus 3, usage seems fine so far. Thanks!

Wonderful, thanks for testing and letting me know.

greg k-h

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 12:12:32PM -0600, Shuah Khan wrote:
> On 04/27/2018 07:57 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:56:20 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.107-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: kernel-4.9.94 compile error: 'KMOD_DECOMP_LEN' undeclared

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 10:28:27AM -0700, Randy Dunlap wrote:
> [adding some Cc:]
> 
> On 04/14/2018 02:41 AM, Teck Choon Giam wrote:
> > Hi,
> > 
> > Compile linux-4.9.94 will have error related to KMOD_DECOMP_LEN
> > undeclared.  Searching string related to KMOD_DECOMP_LEN in
> > linux-4.9.94 and linux-4.15.17 sources as below:
> > 
> > sh-4.2# grep -r KMOD_DECOMP_LEN ./linux-4.15.17
> > ./linux-4.15.17/tools/perf/tests/code-reading.c: char
> > decomp_name[KMOD_DECOMP_LEN];
> > ./linux-4.15.17/tools/perf/util/dso.h:#define KMOD_DECOMP_LEN
> > sizeof(KMOD_DECOMP_NAME)
> > ./linux-4.15.17/tools/perf/util/annotate.c: char tmp[KMOD_DECOMP_LEN];
> > ./linux-4.15.17/tools/perf/util/dso.c: char newpath[KMOD_DECOMP_LEN];
> > sh-4.2# grep -r KMOD_DECOMP_LEN ./linux-4.9.94
> > ./linux-4.9.94/tools/perf/tests/code-reading.c: char
> > decomp_name[KMOD_DECOMP_LEN];
> > ./linux-4.9.94/tools/perf/util/dso.c: char newpath[KMOD_DECOMP_LEN];
> > 
> > So I guess for linux-4.9.94 has not define KMOD_DECOMP_LEN in
> > tools/perf/util/dso.h?
> 
> 
> 4.9.9[456] lack:
> #define KMOD_DECOMP_NAME  "/tmp/perf-kmod-XX"
> #define KMOD_DECOMP_LEN   sizeof(KMOD_DECOMP_NAME)
> 
> 
> However, the commit that added those macros does not apply cleanly to 4.9.96.
> 
> commit 42b3fa670825983fc8bd0ac7b80cc84ae3abb75b
> Author: Namhyung Kim 
> Date:   Thu Jun 8 16:31:03 2017 +0900
> 
> perf tools: Introduce dso__decompress_kmodule_{fd,path}

This should now be fixed in the latest 4.9.y -rc release, right?

If not, please let me know as I though I resolved this problem there...

thanks,

greg k-h

Re: kernel-4.9.94 compile error: 'KMOD_DECOMP_LEN' undeclared

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 10:28:27AM -0700, Randy Dunlap wrote:
> [adding some Cc:]
> 
> On 04/14/2018 02:41 AM, Teck Choon Giam wrote:
> > Hi,
> > 
> > Compile linux-4.9.94 will have error related to KMOD_DECOMP_LEN
> > undeclared.  Searching string related to KMOD_DECOMP_LEN in
> > linux-4.9.94 and linux-4.15.17 sources as below:
> > 
> > sh-4.2# grep -r KMOD_DECOMP_LEN ./linux-4.15.17
> > ./linux-4.15.17/tools/perf/tests/code-reading.c: char
> > decomp_name[KMOD_DECOMP_LEN];
> > ./linux-4.15.17/tools/perf/util/dso.h:#define KMOD_DECOMP_LEN
> > sizeof(KMOD_DECOMP_NAME)
> > ./linux-4.15.17/tools/perf/util/annotate.c: char tmp[KMOD_DECOMP_LEN];
> > ./linux-4.15.17/tools/perf/util/dso.c: char newpath[KMOD_DECOMP_LEN];
> > sh-4.2# grep -r KMOD_DECOMP_LEN ./linux-4.9.94
> > ./linux-4.9.94/tools/perf/tests/code-reading.c: char
> > decomp_name[KMOD_DECOMP_LEN];
> > ./linux-4.9.94/tools/perf/util/dso.c: char newpath[KMOD_DECOMP_LEN];
> > 
> > So I guess for linux-4.9.94 has not define KMOD_DECOMP_LEN in
> > tools/perf/util/dso.h?
> 
> 
> 4.9.9[456] lack:
> #define KMOD_DECOMP_NAME  "/tmp/perf-kmod-XX"
> #define KMOD_DECOMP_LEN   sizeof(KMOD_DECOMP_NAME)
> 
> 
> However, the commit that added those macros does not apply cleanly to 4.9.96.
> 
> commit 42b3fa670825983fc8bd0ac7b80cc84ae3abb75b
> Author: Namhyung Kim 
> Date:   Thu Jun 8 16:31:03 2017 +0900
> 
> perf tools: Introduce dso__decompress_kmodule_{fd,path}

This should now be fixed in the latest 4.9.y -rc release, right?

If not, please let me know as I though I resolved this problem there...

thanks,

greg k-h

Re: [PATCH v6 02/24] soc: qcom: Add APR bus driver

[Bjorn Andersson]

On Thu 26 Apr 02:45 PDT 2018, Srinivas Kandagatla wrote:
> diff --git a/drivers/soc/qcom/apr.c b/drivers/soc/qcom/apr.c
[..]
> +int apr_send_pkt(struct apr_device *adev, void *buf)

Sorry, but I think we have discussed this before?

"buf" isn't some random buffer to be sent, it is a apr_hdr followed by
some data. As such I think you should make this type struct apr_hdr *,
or if you think that doesn't imply there's payload make a type apr_pkt
that has a payload[] at the end.

It will make it obvious for both future readers and the compiler what
kind of data we're passing here.


This comment also applies to functions calling functions that calls
apr_send_pkt() as they too lug around a void *.

> +{
> + struct apr *apr = dev_get_drvdata(adev->dev.parent);
> + struct apr_hdr *hdr;
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + hdr = (struct apr_hdr *)buf;
> + hdr->src_domain = APR_DOMAIN_APPS;
> + hdr->src_svc = adev->svc_id;
> + hdr->dest_domain = adev->domain_id;
> + hdr->dest_svc = adev->svc_id;
> +
> + ret = rpmsg_trysend(apr->ch, buf, hdr->pkt_size);
> + if (ret) {
> + dev_err(>dev, "Unable to send APR pkt %d\n",
> + hdr->pkt_size);

Afaict all callers of this function will print an error message,
sometimes on more than one level in the stack. And if some code path
does retry sending you will get a printout for each attempt, even though
the caller is fine with it.

I would recommend unlocking the spinlock and then do:

return ret ? : hdr->pkt_size;

> + } else {
> + ret = hdr->pkt_size;
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(apr_send_pkt);
> +
> +static void apr_dev_release(struct device *dev)
> +{
> + struct apr_device *adev = to_apr_device(dev);
> +
> + kfree(adev);
> +}
> +
> +static int apr_callback(struct rpmsg_device *rpdev, void *buf,
> +   int len, void *priv, u32 addr)
> +{
> + struct apr *apr = dev_get_drvdata(>dev);
> + struct apr_client_message data;
> + struct apr_device *p, *c_svc = NULL;
> + struct apr_driver *adrv = NULL;
> + struct apr_hdr *hdr;
> + unsigned long flags;
> + uint16_t hdr_size;
> + uint16_t msg_type;
> + uint16_t ver;
> + uint16_t svc;
> +
> + if (len <= APR_HDR_SIZE) {
> + dev_err(apr->dev, "APR: Improper apr pkt received:%p %d\n",
> + buf, len);
> + return -EINVAL;
> + }
> +
> + hdr = buf;
> + ver = APR_HDR_FIELD_VER(hdr->hdr_field);
> + if (ver > APR_PKT_VER + 1)
> + return -EINVAL;
> +
> + hdr_size = APR_HDR_FIELD_SIZE_BYTES(hdr->hdr_field);
> + if (hdr_size < APR_HDR_SIZE) {
> + dev_err(apr->dev, "APR: Wrong hdr size:%d\n", hdr_size);
> + return -EINVAL;
> + }
> +
> + if (hdr->pkt_size < APR_HDR_SIZE) {

I think it would be nice to make sure that hdr->pkt_size is < len as
well, to reject messages that larger than the incoming buffer.

The pkt_size should be in the ballpark of len, could this check be
changed to hdr->pkt_size != len?

> + dev_err(apr->dev, "APR: Wrong paket size\n");
> + return -EINVAL;
> + }
> +
> + msg_type = APR_HDR_FIELD_MT(hdr->hdr_field);
> + if (msg_type >= APR_MSG_TYPE_MAX && msg_type != APR_BASIC_RSP_RESULT) {
> + dev_err(apr->dev, "APR: Wrong message type: %d\n", msg_type);
> + return -EINVAL;
> + }
> +
> + if (hdr->src_domain >= APR_DOMAIN_MAX ||
> + hdr->dest_domain >= APR_DOMAIN_MAX ||
> + hdr->src_svc >= APR_SVC_MAX ||
> + hdr->dest_svc >= APR_SVC_MAX) {
> + dev_err(apr->dev, "APR: Wrong APR header\n");
> + return -EINVAL;
> + }
> +
> + svc = hdr->dest_svc;
> + spin_lock_irqsave(>svcs_lock, flags);
> + list_for_each_entry(p, >svcs, node) {

Rather than doing a O(n) search for the svc with svc_id you could use a
idr or a radix_tree to keep the id -> svc mapping.

> + if (svc == p->svc_id) {
> + c_svc = p;
> + if (c_svc->dev.driver)
> + adrv = to_apr_driver(c_svc->dev.driver);
> + break;
> + }
> + }
> + spin_unlock_irqrestore(>svcs_lock, flags);
> +
> + if (!adrv) {
> + dev_err(apr->dev, "APR: service is not registered\n");
> + return -EINVAL;
> + }
> +
> + data.payload_size = hdr->pkt_size - hdr_size;
> + data.opcode = hdr->opcode;
> + data.src_port = hdr->src_port;
> + data.dest_port = hdr->dest_port;
> + data.token = hdr->token;
> + data.msg_type = msg_type;
> +
> + if (data.payload_size > 0)
> + data.payload = buf + hdr_size;
> +

Making a verbatim copy of parts of the hdr and then 

Re: [PATCH v6 02/24] soc: qcom: Add APR bus driver

[Bjorn Andersson]

On Thu 26 Apr 02:45 PDT 2018, Srinivas Kandagatla wrote:
> diff --git a/drivers/soc/qcom/apr.c b/drivers/soc/qcom/apr.c
[..]
> +int apr_send_pkt(struct apr_device *adev, void *buf)

Sorry, but I think we have discussed this before?

"buf" isn't some random buffer to be sent, it is a apr_hdr followed by
some data. As such I think you should make this type struct apr_hdr *,
or if you think that doesn't imply there's payload make a type apr_pkt
that has a payload[] at the end.

It will make it obvious for both future readers and the compiler what
kind of data we're passing here.


This comment also applies to functions calling functions that calls
apr_send_pkt() as they too lug around a void *.

> +{
> + struct apr *apr = dev_get_drvdata(adev->dev.parent);
> + struct apr_hdr *hdr;
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + hdr = (struct apr_hdr *)buf;
> + hdr->src_domain = APR_DOMAIN_APPS;
> + hdr->src_svc = adev->svc_id;
> + hdr->dest_domain = adev->domain_id;
> + hdr->dest_svc = adev->svc_id;
> +
> + ret = rpmsg_trysend(apr->ch, buf, hdr->pkt_size);
> + if (ret) {
> + dev_err(>dev, "Unable to send APR pkt %d\n",
> + hdr->pkt_size);

Afaict all callers of this function will print an error message,
sometimes on more than one level in the stack. And if some code path
does retry sending you will get a printout for each attempt, even though
the caller is fine with it.

I would recommend unlocking the spinlock and then do:

return ret ? : hdr->pkt_size;

> + } else {
> + ret = hdr->pkt_size;
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(apr_send_pkt);
> +
> +static void apr_dev_release(struct device *dev)
> +{
> + struct apr_device *adev = to_apr_device(dev);
> +
> + kfree(adev);
> +}
> +
> +static int apr_callback(struct rpmsg_device *rpdev, void *buf,
> +   int len, void *priv, u32 addr)
> +{
> + struct apr *apr = dev_get_drvdata(>dev);
> + struct apr_client_message data;
> + struct apr_device *p, *c_svc = NULL;
> + struct apr_driver *adrv = NULL;
> + struct apr_hdr *hdr;
> + unsigned long flags;
> + uint16_t hdr_size;
> + uint16_t msg_type;
> + uint16_t ver;
> + uint16_t svc;
> +
> + if (len <= APR_HDR_SIZE) {
> + dev_err(apr->dev, "APR: Improper apr pkt received:%p %d\n",
> + buf, len);
> + return -EINVAL;
> + }
> +
> + hdr = buf;
> + ver = APR_HDR_FIELD_VER(hdr->hdr_field);
> + if (ver > APR_PKT_VER + 1)
> + return -EINVAL;
> +
> + hdr_size = APR_HDR_FIELD_SIZE_BYTES(hdr->hdr_field);
> + if (hdr_size < APR_HDR_SIZE) {
> + dev_err(apr->dev, "APR: Wrong hdr size:%d\n", hdr_size);
> + return -EINVAL;
> + }
> +
> + if (hdr->pkt_size < APR_HDR_SIZE) {

I think it would be nice to make sure that hdr->pkt_size is < len as
well, to reject messages that larger than the incoming buffer.

The pkt_size should be in the ballpark of len, could this check be
changed to hdr->pkt_size != len?

> + dev_err(apr->dev, "APR: Wrong paket size\n");
> + return -EINVAL;
> + }
> +
> + msg_type = APR_HDR_FIELD_MT(hdr->hdr_field);
> + if (msg_type >= APR_MSG_TYPE_MAX && msg_type != APR_BASIC_RSP_RESULT) {
> + dev_err(apr->dev, "APR: Wrong message type: %d\n", msg_type);
> + return -EINVAL;
> + }
> +
> + if (hdr->src_domain >= APR_DOMAIN_MAX ||
> + hdr->dest_domain >= APR_DOMAIN_MAX ||
> + hdr->src_svc >= APR_SVC_MAX ||
> + hdr->dest_svc >= APR_SVC_MAX) {
> + dev_err(apr->dev, "APR: Wrong APR header\n");
> + return -EINVAL;
> + }
> +
> + svc = hdr->dest_svc;
> + spin_lock_irqsave(>svcs_lock, flags);
> + list_for_each_entry(p, >svcs, node) {

Rather than doing a O(n) search for the svc with svc_id you could use a
idr or a radix_tree to keep the id -> svc mapping.

> + if (svc == p->svc_id) {
> + c_svc = p;
> + if (c_svc->dev.driver)
> + adrv = to_apr_driver(c_svc->dev.driver);
> + break;
> + }
> + }
> + spin_unlock_irqrestore(>svcs_lock, flags);
> +
> + if (!adrv) {
> + dev_err(apr->dev, "APR: service is not registered\n");
> + return -EINVAL;
> + }
> +
> + data.payload_size = hdr->pkt_size - hdr_size;
> + data.opcode = hdr->opcode;
> + data.src_port = hdr->src_port;
> + data.dest_port = hdr->dest_port;
> + data.token = hdr->token;
> + data.msg_type = msg_type;
> +
> + if (data.payload_size > 0)
> + data.payload = buf + hdr_size;
> +

Making a verbatim copy of parts of the hdr and then 

Re: [PATCH v3 4/7] kprobes: Replace %p with other pointer types

[Masami Hiramatsu]

On Sat, 28 Apr 2018 00:42:02 +0900
Masami Hiramatsu  wrote:

> > > +/* Caller must NOT call this in usual path. This is only for critical 
> > > case */
> > >  void dump_kprobe(struct kprobe *kp)
> > >  {
> > > - printk(KERN_WARNING "Dumping kprobe:\n");
> > > - printk(KERN_WARNING "Name: %s\nAddress: %p\nOffset: %x\n",
> > > -kp->symbol_name, kp->addr, kp->offset);
> > > + pr_err("Dumping kprobe:\n");
> > > + pr_err("Name: %s\nOffset: %x\nAddress: %pS\n",
> > > +kp->symbol_name, kp->offset, kp->addr);
> > 
> > No, this function should just go away and be replaced by a WARN() in 
> > reenter_kprobe().
> 
> Would you consider to use pr_err() here? If so, I'll move this
> dump as you suggested.

So, this is actually called right before BUG(), which means we found
a non-recoverable error while recovering from reentrant kprobes.
Since the BUG() dumps all registers and stack as same as WARN(),
I think we should keep it.
(I would like to dump all kprobes fields like flags, etc. so that
 we can find it is broken or not.)

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH v3 4/7] kprobes: Replace %p with other pointer types

[Masami Hiramatsu]

On Sat, 28 Apr 2018 00:42:02 +0900
Masami Hiramatsu  wrote:

> > > +/* Caller must NOT call this in usual path. This is only for critical 
> > > case */
> > >  void dump_kprobe(struct kprobe *kp)
> > >  {
> > > - printk(KERN_WARNING "Dumping kprobe:\n");
> > > - printk(KERN_WARNING "Name: %s\nAddress: %p\nOffset: %x\n",
> > > -kp->symbol_name, kp->addr, kp->offset);
> > > + pr_err("Dumping kprobe:\n");
> > > + pr_err("Name: %s\nOffset: %x\nAddress: %pS\n",
> > > +kp->symbol_name, kp->offset, kp->addr);
> > 
> > No, this function should just go away and be replaced by a WARN() in 
> > reenter_kprobe().
> 
> Would you consider to use pr_err() here? If so, I'll move this
> dump as you suggested.

So, this is actually called right before BUG(), which means we found
a non-recoverable error while recovering from reentrant kprobes.
Since the BUG() dumps all registers and stack as same as WARN(),
I think we should keep it.
(I would like to dump all kprobes fields like flags, etc. so that
 we can find it is broken or not.)

Thank you,

-- 
Masami Hiramatsu 

[PATCH] kselftests: fix grammar and non-ASCII space

[Randy Dunlap]

From: Randy Dunlap 

This is a small cleanup to kselftest.rst:

- Fix some language typos in the usage instructions.
- Change one non-ASCII space to an ASCII space.

Signed-off-by: Randy Dunlap 
---
 Documentation/dev-tools/kselftest.rst |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-next-20180426.orig/Documentation/dev-tools/kselftest.rst
+++ linux-next-20180426/Documentation/dev-tools/kselftest.rst
@@ -9,7 +9,7 @@ and booting a kernel.
 
 On some systems, hot-plug tests could hang forever waiting for cpu and
 memory to be ready to be offlined. A special hot-plug target is created
-to run full range of hot-plug tests. In default mode, hot-plug tests run
+to run the full range of hot-plug tests. In default mode, hot-plug tests run
 in safe mode with a limited scope. In limited mode, cpu-hotplug test is
 run on a single cpu as opposed to all hotplug capable cpus, and memory
 hotplug test is run on 2% of hotplug capable memory instead of 10%.
@@ -89,9 +89,9 @@ Note that some tests will require root p
 Install selftests
 =
 
-You can use kselftest_install.sh tool installs selftests in default
-location which is tools/testing/selftests/kselftest or a user specified
-location.
+You can use the kselftest_install.sh tool to install selftests in the
+default location, which is tools/testing/selftests/kselftest, or in a
+user specified location.
 
 To install selftests in default location::
 
@@ -109,7 +109,7 @@ Running installed selftests
 Kselftest install as well as the Kselftest tarball provide a script
 named "run_kselftest.sh" to run the tests.
 
-You can simply do the following to run the installed Kselftests. Please
+You can simply do the following to run the installed Kselftests. Please
 note some tests will require root privileges::
 
$ cd kselftest
@@ -139,7 +139,7 @@ Contributing new tests (details)
default.
 
TEST_CUSTOM_PROGS should be used by tests that require custom build
-   rule and prevent common build rule use.
+   rules and prevent common build rule use.
 
TEST_PROGS are for test shell scripts. Please ensure shell script has
its exec bit set. Otherwise, lib.mk run_tests will generate a warning.

[PATCH] kselftests: fix grammar and non-ASCII space

[Randy Dunlap]

From: Randy Dunlap 

This is a small cleanup to kselftest.rst:

- Fix some language typos in the usage instructions.
- Change one non-ASCII space to an ASCII space.

Signed-off-by: Randy Dunlap 
---
 Documentation/dev-tools/kselftest.rst |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-next-20180426.orig/Documentation/dev-tools/kselftest.rst
+++ linux-next-20180426/Documentation/dev-tools/kselftest.rst
@@ -9,7 +9,7 @@ and booting a kernel.
 
 On some systems, hot-plug tests could hang forever waiting for cpu and
 memory to be ready to be offlined. A special hot-plug target is created
-to run full range of hot-plug tests. In default mode, hot-plug tests run
+to run the full range of hot-plug tests. In default mode, hot-plug tests run
 in safe mode with a limited scope. In limited mode, cpu-hotplug test is
 run on a single cpu as opposed to all hotplug capable cpus, and memory
 hotplug test is run on 2% of hotplug capable memory instead of 10%.
@@ -89,9 +89,9 @@ Note that some tests will require root p
 Install selftests
 =
 
-You can use kselftest_install.sh tool installs selftests in default
-location which is tools/testing/selftests/kselftest or a user specified
-location.
+You can use the kselftest_install.sh tool to install selftests in the
+default location, which is tools/testing/selftests/kselftest, or in a
+user specified location.
 
 To install selftests in default location::
 
@@ -109,7 +109,7 @@ Running installed selftests
 Kselftest install as well as the Kselftest tarball provide a script
 named "run_kselftest.sh" to run the tests.
 
-You can simply do the following to run the installed Kselftests. Please
+You can simply do the following to run the installed Kselftests. Please
 note some tests will require root privileges::
 
$ cd kselftest
@@ -139,7 +139,7 @@ Contributing new tests (details)
default.
 
TEST_CUSTOM_PROGS should be used by tests that require custom build
-   rule and prevent common build rule use.
+   rules and prevent common build rule use.
 
TEST_PROGS are for test shell scripts. Please ensure shell script has
its exec bit set. Otherwise, lib.mk run_tests will generate a warning.

[PATCH net-next] libcxgb,cxgb4: use __skb_put_zero to simplfy code

[YueHaibing]

use helper __skb_put_zero to replace the pattern of __skb_put() && memset()

Signed-off-by: YueHaibing 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c |  3 +--
 drivers/net/ethernet/chelsio/cxgb4/srq.c  |  3 +--
 drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h | 15 +--
 3 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index db92f18..aae9802 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -64,8 +64,7 @@ static int set_tcb_field(struct adapter *adap, struct 
filter_entry *f,
if (!skb)
return -ENOMEM;
 
-   req = (struct cpl_set_tcb_field *)__skb_put(skb, sizeof(*req));
-   memset(req, 0, sizeof(*req));
+   req = (struct cpl_set_tcb_field *)__skb_put_zero(skb, sizeof(*req));
INIT_TP_WR_CPL(req, CPL_SET_TCB_FIELD, ftid);
req->reply_ctrl = htons(REPLY_CHAN_V(0) |
QUEUENO_V(adap->sge.fw_evtq.abs_id) |
diff --git a/drivers/net/ethernet/chelsio/cxgb4/srq.c 
b/drivers/net/ethernet/chelsio/cxgb4/srq.c
index 6228a57..82b70a5 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/srq.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/srq.c
@@ -84,8 +84,7 @@ int cxgb4_get_srq_entry(struct net_device *dev,
if (!skb)
return -ENOMEM;
req = (struct cpl_srq_table_req *)
-   __skb_put(skb, sizeof(*req));
-   memset(req, 0, sizeof(*req));
+   __skb_put_zero(skb, sizeof(*req));
INIT_TP_WR(req, 0);
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_SRQ_TABLE_REQ,
  TID_TID_V(srq_idx) |
diff --git a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h 
b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
index 4b5aacc..240ba9d 100644
--- a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
+++ b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
@@ -90,8 +90,7 @@ cxgb_mk_tid_release(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan)
 {
struct cpl_tid_release *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_TID_RELEASE, tid));
@@ -104,8 +103,7 @@ cxgb_mk_close_con_req(struct sk_buff *skb, u32 len, u32 
tid, u16 chan,
 {
struct cpl_close_con_req *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_CLOSE_CON_REQ, tid));
@@ -119,8 +117,7 @@ cxgb_mk_abort_req(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan,
 {
struct cpl_abort_req *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_REQ, tid));
@@ -134,8 +131,7 @@ cxgb_mk_abort_rpl(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan)
 {
struct cpl_abort_rpl *rpl;
 
-   rpl = __skb_put(skb, len);
-   memset(rpl, 0, len);
+   rpl = __skb_put_zero(skb, len);
 
INIT_TP_WR(rpl, tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, tid));
@@ -149,8 +145,7 @@ cxgb_mk_rx_data_ack(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan,
 {
struct cpl_rx_data_ack *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_RX_DATA_ACK, tid));
-- 
2.7.0

[PATCH net-next] libcxgb,cxgb4: use __skb_put_zero to simplfy code

[YueHaibing]

use helper __skb_put_zero to replace the pattern of __skb_put() && memset()

Signed-off-by: YueHaibing 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c |  3 +--
 drivers/net/ethernet/chelsio/cxgb4/srq.c  |  3 +--
 drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h | 15 +--
 3 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
index db92f18..aae9802 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c
@@ -64,8 +64,7 @@ static int set_tcb_field(struct adapter *adap, struct 
filter_entry *f,
if (!skb)
return -ENOMEM;
 
-   req = (struct cpl_set_tcb_field *)__skb_put(skb, sizeof(*req));
-   memset(req, 0, sizeof(*req));
+   req = (struct cpl_set_tcb_field *)__skb_put_zero(skb, sizeof(*req));
INIT_TP_WR_CPL(req, CPL_SET_TCB_FIELD, ftid);
req->reply_ctrl = htons(REPLY_CHAN_V(0) |
QUEUENO_V(adap->sge.fw_evtq.abs_id) |
diff --git a/drivers/net/ethernet/chelsio/cxgb4/srq.c 
b/drivers/net/ethernet/chelsio/cxgb4/srq.c
index 6228a57..82b70a5 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/srq.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/srq.c
@@ -84,8 +84,7 @@ int cxgb4_get_srq_entry(struct net_device *dev,
if (!skb)
return -ENOMEM;
req = (struct cpl_srq_table_req *)
-   __skb_put(skb, sizeof(*req));
-   memset(req, 0, sizeof(*req));
+   __skb_put_zero(skb, sizeof(*req));
INIT_TP_WR(req, 0);
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_SRQ_TABLE_REQ,
  TID_TID_V(srq_idx) |
diff --git a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h 
b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
index 4b5aacc..240ba9d 100644
--- a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
+++ b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.h
@@ -90,8 +90,7 @@ cxgb_mk_tid_release(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan)
 {
struct cpl_tid_release *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_TID_RELEASE, tid));
@@ -104,8 +103,7 @@ cxgb_mk_close_con_req(struct sk_buff *skb, u32 len, u32 
tid, u16 chan,
 {
struct cpl_close_con_req *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_CLOSE_CON_REQ, tid));
@@ -119,8 +117,7 @@ cxgb_mk_abort_req(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan,
 {
struct cpl_abort_req *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_REQ, tid));
@@ -134,8 +131,7 @@ cxgb_mk_abort_rpl(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan)
 {
struct cpl_abort_rpl *rpl;
 
-   rpl = __skb_put(skb, len);
-   memset(rpl, 0, len);
+   rpl = __skb_put_zero(skb, len);
 
INIT_TP_WR(rpl, tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, tid));
@@ -149,8 +145,7 @@ cxgb_mk_rx_data_ack(struct sk_buff *skb, u32 len, u32 tid, 
u16 chan,
 {
struct cpl_rx_data_ack *req;
 
-   req = __skb_put(skb, len);
-   memset(req, 0, len);
+   req = __skb_put_zero(skb, len);
 
INIT_TP_WR(req, tid);
OPCODE_TID(req) = cpu_to_be32(MK_OPCODE_TID(CPL_RX_DATA_ACK, tid));
-- 
2.7.0

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 03:41:28PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> 
> The kernel.org page currently lists 3.18 as EOL.  I assume we released
> an update for Spectre/Meltdown after we declared it end of life, but I
> was surprised to see that there was going to be a 3.18.107.

There are no patches for Spectre/Meltdown in the 3.18.y kernel tree that
I know of.

> Should we change how 3.18 is listed on kernel.org?  Or should we just
> keep peeople wondering whether will be updates after 3.18.107?  :-)

Keep people wondering.

As I have stated before, I'm keeping it alive as there are still a few
tens of millions of devices out there using this kernel, including one
of my personal phones.  I might get tired of keeping it semi-up-to-date
and then will stop releasing updates, and reserve the right to do so at
any point in time :)

thanks,

greg k-h

Re: [PATCH 3.18 00/24] 3.18.107-stable review

[Greg Kroah-Hartman]

On Fri, Apr 27, 2018 at 03:41:28PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.107 release.
> 
> The kernel.org page currently lists 3.18 as EOL.  I assume we released
> an update for Spectre/Meltdown after we declared it end of life, but I
> was surprised to see that there was going to be a 3.18.107.

There are no patches for Spectre/Meltdown in the 3.18.y kernel tree that
I know of.

> Should we change how 3.18 is listed on kernel.org?  Or should we just
> keep peeople wondering whether will be updates after 3.18.107?  :-)

Keep people wondering.

As I have stated before, I'm keeping it alive as there are still a few
tens of millions of devices out there using this kernel, including one
of my personal phones.  I might get tired of keeping it semi-up-to-date
and then will stop releasing updates, and reserve the right to do so at
any point in time :)

thanks,

greg k-h

[PATCH v2] staging: greybus: Use gpio_is_valid()

[Arvind Yadav]

Replace the manual validity checks for the GPIO with the
gpio_is_valid().

Signed-off-by: Arvind Yadav 
---
chnage in v2 :
 Returning invalid gpio as error instead of -ENODEV.

 drivers/staging/greybus/arche-platform.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 83254a7..c3a7da5 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -448,7 +448,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
"svc,reset-gpio",
0);
-   if (arche_pdata->svc_reset_gpio < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_reset_gpio)) {
dev_err(dev, "failed to get reset-gpio\n");
return arche_pdata->svc_reset_gpio;
}
@@ -468,7 +468,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
  "svc,sysboot-gpio",
  0);
-   if (arche_pdata->svc_sysboot_gpio < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_sysboot_gpio)) {
dev_err(dev, "failed to get sysboot gpio\n");
return arche_pdata->svc_sysboot_gpio;
}
@@ -487,7 +487,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_refclk_req = of_get_named_gpio(np,
"svc,refclk-req-gpio",
0);
-   if (arche_pdata->svc_refclk_req < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_refclk_req)) {
dev_err(dev, "failed to get svc clock-req gpio\n");
return arche_pdata->svc_refclk_req;
}
-- 
2.7.4

[PATCH v2] staging: greybus: Use gpio_is_valid()

[Arvind Yadav]

Replace the manual validity checks for the GPIO with the
gpio_is_valid().

Signed-off-by: Arvind Yadav 
---
chnage in v2 :
 Returning invalid gpio as error instead of -ENODEV.

 drivers/staging/greybus/arche-platform.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 83254a7..c3a7da5 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -448,7 +448,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
"svc,reset-gpio",
0);
-   if (arche_pdata->svc_reset_gpio < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_reset_gpio)) {
dev_err(dev, "failed to get reset-gpio\n");
return arche_pdata->svc_reset_gpio;
}
@@ -468,7 +468,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
  "svc,sysboot-gpio",
  0);
-   if (arche_pdata->svc_sysboot_gpio < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_sysboot_gpio)) {
dev_err(dev, "failed to get sysboot gpio\n");
return arche_pdata->svc_sysboot_gpio;
}
@@ -487,7 +487,7 @@ static int arche_platform_probe(struct platform_device 
*pdev)
arche_pdata->svc_refclk_req = of_get_named_gpio(np,
"svc,refclk-req-gpio",
0);
-   if (arche_pdata->svc_refclk_req < 0) {
+   if (!gpio_is_valid(arche_pdata->svc_refclk_req)) {
dev_err(dev, "failed to get svc clock-req gpio\n");
return arche_pdata->svc_refclk_req;
}
-- 
2.7.4

Re: [greybus-dev] [PATCH] staging: greybus: Use gpio_is_valid()

[arvindY]

On Friday 27 April 2018 06:32 PM, Alex Elder wrote:

On 04/27/2018 07:50 AM, Arvind Yadav wrote:


On Friday 27 April 2018 05:47 PM, Alex Elder wrote:

On 04/27/2018 05:52 AM, Arvind Yadav wrote:

Replace the manual validity checks for the GPIO with the
gpio_is_valid().

I haven't looked through the code paths very closely, but I
think that get_named_gpio() might return -EPROBE_DEFER, which
would be something we want to pass to the caller.

Yes of_get_name_gpio() can return other error value apart from
-EPROBE_DEFER.

So rather than returning -ENODEV and hiding the reason the
call to of_get_named_gpio() failed, you should continue
returning the errno it supplies (if not a valid gpio number).

 -Alex

I have return -ENODEV because invalid gpio pin can be positive.
static inline bool gpio_is_valid(int number)
{
 return number >= 0 && number < ARCH_NR_GPIOS;
}
Here if number > ARCH_NR_GPIOS then it's invalid but return value
will be positive.

Your reasoning is good.  However in all three of these cases,
the GPIO number you're checking is the value returned from
of_get_named_gpio().  The return value is a "GPIO number to
use with Linux generic GPIO API, or one of the errno value."

So unless the API of of_get_named_gpio() changes, you can be
sure that if the value returned is invalid, it is a negative
errno.  (And if the API did change, the person making that
change would be responsible for fixing all callers to ensure
the change didn't break them.)

This distinction may be why the code you're changing was only
testing for negative, rather than using gpio_is_valid() (you'll
see it's used elsewhere in the Greybus code--even in the same
source files.)

Anyway, changing the code to use gpio_is_valid() is fine.  But
you should avoid obscuring the reason for the error that the
return value from of_get_named_gpio() provides.

-Alex


Yes, It'll be fine to return a invalid gpio as error instead of
-ENODEV. I will send an updated patch.

~arvind



We can return like this
 " return (gpio > 0) ? -ENODEV: gpio;"

But not sure this is worth to handle this.

~arvind

Signed-off-by: Arvind Yadav 
---
   drivers/staging/greybus/arche-platform.c | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 83254a7..fc6bf60 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -448,9 +448,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
   "svc,reset-gpio",
   0);
-if (arche_pdata->svc_reset_gpio < 0) {
+if (!gpio_is_valid(arche_pdata->svc_reset_gpio)) {
   dev_err(dev, "failed to get reset-gpio\n");
-return arche_pdata->svc_reset_gpio;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_reset_gpio, "svc-reset");
   if (ret) {
@@ -468,9 +468,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
 "svc,sysboot-gpio",
 0);
-if (arche_pdata->svc_sysboot_gpio < 0) {
+if (!gpio_is_valid(arche_pdata->svc_sysboot_gpio)) {
   dev_err(dev, "failed to get sysboot gpio\n");
-return arche_pdata->svc_sysboot_gpio;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_sysboot_gpio, "sysboot0");
   if (ret) {
@@ -487,9 +487,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_refclk_req = of_get_named_gpio(np,
   "svc,refclk-req-gpio",
   0);
-if (arche_pdata->svc_refclk_req < 0) {
+if (!gpio_is_valid(arche_pdata->svc_refclk_req)) {
   dev_err(dev, "failed to get svc clock-req gpio\n");
-return arche_pdata->svc_refclk_req;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_refclk_req,
   "svc-clk-req");

Re: [greybus-dev] [PATCH] staging: greybus: Use gpio_is_valid()

[arvindY]

On Friday 27 April 2018 06:32 PM, Alex Elder wrote:

On 04/27/2018 07:50 AM, Arvind Yadav wrote:


On Friday 27 April 2018 05:47 PM, Alex Elder wrote:

On 04/27/2018 05:52 AM, Arvind Yadav wrote:

Replace the manual validity checks for the GPIO with the
gpio_is_valid().

I haven't looked through the code paths very closely, but I
think that get_named_gpio() might return -EPROBE_DEFER, which
would be something we want to pass to the caller.

Yes of_get_name_gpio() can return other error value apart from
-EPROBE_DEFER.

So rather than returning -ENODEV and hiding the reason the
call to of_get_named_gpio() failed, you should continue
returning the errno it supplies (if not a valid gpio number).

 -Alex

I have return -ENODEV because invalid gpio pin can be positive.
static inline bool gpio_is_valid(int number)
{
 return number >= 0 && number < ARCH_NR_GPIOS;
}
Here if number > ARCH_NR_GPIOS then it's invalid but return value
will be positive.

Your reasoning is good.  However in all three of these cases,
the GPIO number you're checking is the value returned from
of_get_named_gpio().  The return value is a "GPIO number to
use with Linux generic GPIO API, or one of the errno value."

So unless the API of of_get_named_gpio() changes, you can be
sure that if the value returned is invalid, it is a negative
errno.  (And if the API did change, the person making that
change would be responsible for fixing all callers to ensure
the change didn't break them.)

This distinction may be why the code you're changing was only
testing for negative, rather than using gpio_is_valid() (you'll
see it's used elsewhere in the Greybus code--even in the same
source files.)

Anyway, changing the code to use gpio_is_valid() is fine.  But
you should avoid obscuring the reason for the error that the
return value from of_get_named_gpio() provides.

-Alex


Yes, It'll be fine to return a invalid gpio as error instead of
-ENODEV. I will send an updated patch.

~arvind



We can return like this
 " return (gpio > 0) ? -ENODEV: gpio;"

But not sure this is worth to handle this.

~arvind

Signed-off-by: Arvind Yadav 
---
   drivers/staging/greybus/arche-platform.c | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index 83254a7..fc6bf60 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -448,9 +448,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
   "svc,reset-gpio",
   0);
-if (arche_pdata->svc_reset_gpio < 0) {
+if (!gpio_is_valid(arche_pdata->svc_reset_gpio)) {
   dev_err(dev, "failed to get reset-gpio\n");
-return arche_pdata->svc_reset_gpio;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_reset_gpio, "svc-reset");
   if (ret) {
@@ -468,9 +468,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
 "svc,sysboot-gpio",
 0);
-if (arche_pdata->svc_sysboot_gpio < 0) {
+if (!gpio_is_valid(arche_pdata->svc_sysboot_gpio)) {
   dev_err(dev, "failed to get sysboot gpio\n");
-return arche_pdata->svc_sysboot_gpio;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_sysboot_gpio, "sysboot0");
   if (ret) {
@@ -487,9 +487,9 @@ static int arche_platform_probe(struct platform_device 
*pdev)
   arche_pdata->svc_refclk_req = of_get_named_gpio(np,
   "svc,refclk-req-gpio",
   0);
-if (arche_pdata->svc_refclk_req < 0) {
+if (!gpio_is_valid(arche_pdata->svc_refclk_req)) {
   dev_err(dev, "failed to get svc clock-req gpio\n");
-return arche_pdata->svc_refclk_req;
+return -ENODEV;
   }
   ret = devm_gpio_request(dev, arche_pdata->svc_refclk_req,
   "svc-clk-req");

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

[Darren Hart]

On Fri, Apr 27, 2018 at 02:57:21PM -0700, Randy Dunlap wrote:
> On 04/27/2018 11:01 AM, mario.limoncie...@dell.com wrote:
...
> DELL_SMBIOS depends on ACPI_WMI so when ACPI_WMI=m, DELL_SMBIOS should never 
> =y.
> Your DELL_LAPTOP Kconfig patch does fix this, I believe, because when 
> DELL_LAPTOP=y,
> its select DELL_SMBIOS incorrectly makes DELL_SMBIOS=y.
> 
> 
> so if we can get your patch merged, we can see if any more breakage 
> happens... :)

Sorry, comms fail on my part. This will be merged to for-next by tomorrow.

-- 
Darren Hart
VMware Open Source Technology Center

Re: drivers/platform/x86/dell-smbios-wmi.c:66: undefined reference to `wmidev_evaluate_method'

[Darren Hart]

On Fri, Apr 27, 2018 at 02:57:21PM -0700, Randy Dunlap wrote:
> On 04/27/2018 11:01 AM, mario.limoncie...@dell.com wrote:
...
> DELL_SMBIOS depends on ACPI_WMI so when ACPI_WMI=m, DELL_SMBIOS should never 
> =y.
> Your DELL_LAPTOP Kconfig patch does fix this, I believe, because when 
> DELL_LAPTOP=y,
> its select DELL_SMBIOS incorrectly makes DELL_SMBIOS=y.
> 
> 
> so if we can get your patch merged, we can see if any more breakage 
> happens... :)

Sorry, comms fail on my part. This will be merged to for-next by tomorrow.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

[Vivek Unune]

On Fri, Apr 27, 2018 at 10:05 AM, Vivek Unune  wrote:
> On Wed, Apr 25, 2018 at 11:02:04AM +0200, Rafał Miłecki wrote:
>>
>> The easiest solution: ignore all these "error -74 (ECC error) while
>> reading" errors (they may last for few minutes!). I believe UBI should
>> simply recreate all pages it couldn't access and once you wait long
>> enough, all your NAND flash will be using BCH8.
>
> Let me build the firmware with BCH-8 and wait it out. I'll report back my
> results.

I can confirm that BCH-8 indeed works after letting it run through those
ECC errors.

Thanks!

Vivek

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

[Vivek Unune]

On Fri, Apr 27, 2018 at 10:05 AM, Vivek Unune  wrote:
> On Wed, Apr 25, 2018 at 11:02:04AM +0200, Rafał Miłecki wrote:
>>
>> The easiest solution: ignore all these "error -74 (ECC error) while
>> reading" errors (they may last for few minutes!). I believe UBI should
>> simply recreate all pages it couldn't access and once you wait long
>> enough, all your NAND flash will be using BCH8.
>
> Let me build the firmware with BCH-8 and wait it out. I'll report back my
> results.

I can confirm that BCH-8 indeed works after letting it run through those
ECC errors.

Thanks!

Vivek

[Cubieboard-2] Booting up stuck at runlevel-2

[Ajay Garg]

Hi All.

After a lot of hit-and-trials, I have managed to get some bootup.
Unfortunately, not able to get a login-prompt.

Following have been done :


== u-boot ==

u-boot has been compiled using bleeding-edge mainline
(ec5c4a8fd64a178a4d159917cda0aa176e5a9be5), via :

* make Cubieboard2_defconfig
* make ARCH=arm CROSS_COMPILE=/home/ajay/arm-toolchain-6.2/arm-linux-gnueabihf-

This gives us u-boot-sunxi-with-spl.bin


== kernel ==

kernel also has been compiled using bleeding-edge mainline
(6d08b06e67cd117f6992c46611dfb4ce267cd71e) via :

* make clean
* make ARCH=arm sunxi_defconfig
* make -j$(nproc) ARCH=arm
CROSS_COMPILE=arm-toolchain-6.2/arm-linux-gnueabihf- zImage
* make -j$(nproc) ARCH=arm
CROSS_COMPILE=arm-toolchain-6.2/arm-linux-gnueabihf-
sun7i-a20-cubieboard2.dtb

This gives us zImage and sun7i-a20-cubieboard2.dtb.


== integration, and starting up ==

Followed the steps as per
https://github.com/maronai/cubieboard/wiki/3.1.-Compiling-mainline-kernel-for-CubieBoard2-and-CubieTruck,
but with following differences :

a)
Used u-boot-sunxi-with-spl.bin, zImage, sun7i-a20-cubieboard2.dtb from
above steps.

b)
Used (and compiled to boot.scr) the following boot.cmd :

fatload mmc 0 0x4600 zImage
fatload mmc 0 0x4900 sun7i-a20-cubieboard2.dtb
setenv bootargs console=ttyS0,115200 rw root=/dev/mmcblk0p2
bootz 0x4600 - 0x4900

c)
Extracted debian-wheezy-7.5-armhf.com-20140603.tar to the rootfs
partition on the sd-card.

d)
Finally, inserted the sdcard in cubieboard2, and upon bootup,
following is seen :


U-Boot SPL 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48 +0530)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48 +0530)
Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
245 bytes read in 13 ms (17.6 KiB/s)
## Executing script at 4310
3961944 bytes read in 241 ms (15.7 MiB/s)
26147 bytes read in 23 ms (1.1 MiB/s)
## Flattened Device Tree blob at 4900
   Booting using the fdt blob at 0x4900
   Loading Device Tree to 49ff6000, end 49fff622 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.17.0-rc2 (ajay@latitude-3480) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #6 SMP Sat Apr 28
08:36:46 8
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt: Machine model: Cubietech Cubieboard2
[0.00] Memory policy: Data cache writealloc
[0.00] cma: Reserved 16 MiB at 0x7f00
[0.00] psci: probing for conduit method from DT.
[0.00] psci: Using PSCI v0.1 Function IDs from DT
[0.00] random: get_random_bytes called from
start_kernel+0xa0/0x3fc with crng_init=0
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s33804 r8192
d23540 u65536
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[0.00] Kernel command line: console=ttyS0,115200 rw root=/dev/mmcblk0p2
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1013080K/1048576K available (6144K kernel code,
420K rwdata, 1492K rodata, 1024K init, 241K bss, 19112K reserved,
16384)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (7136 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 421 kB)
[0.00].bss : 

[Cubieboard-2] Booting up stuck at runlevel-2

[Ajay Garg]

Hi All.

After a lot of hit-and-trials, I have managed to get some bootup.
Unfortunately, not able to get a login-prompt.

Following have been done :


== u-boot ==

u-boot has been compiled using bleeding-edge mainline
(ec5c4a8fd64a178a4d159917cda0aa176e5a9be5), via :

* make Cubieboard2_defconfig
* make ARCH=arm CROSS_COMPILE=/home/ajay/arm-toolchain-6.2/arm-linux-gnueabihf-

This gives us u-boot-sunxi-with-spl.bin


== kernel ==

kernel also has been compiled using bleeding-edge mainline
(6d08b06e67cd117f6992c46611dfb4ce267cd71e) via :

* make clean
* make ARCH=arm sunxi_defconfig
* make -j$(nproc) ARCH=arm
CROSS_COMPILE=arm-toolchain-6.2/arm-linux-gnueabihf- zImage
* make -j$(nproc) ARCH=arm
CROSS_COMPILE=arm-toolchain-6.2/arm-linux-gnueabihf-
sun7i-a20-cubieboard2.dtb

This gives us zImage and sun7i-a20-cubieboard2.dtb.


== integration, and starting up ==

Followed the steps as per
https://github.com/maronai/cubieboard/wiki/3.1.-Compiling-mainline-kernel-for-CubieBoard2-and-CubieTruck,
but with following differences :

a)
Used u-boot-sunxi-with-spl.bin, zImage, sun7i-a20-cubieboard2.dtb from
above steps.

b)
Used (and compiled to boot.scr) the following boot.cmd :

fatload mmc 0 0x4600 zImage
fatload mmc 0 0x4900 sun7i-a20-cubieboard2.dtb
setenv bootargs console=ttyS0,115200 rw root=/dev/mmcblk0p2
bootz 0x4600 - 0x4900

c)
Extracted debian-wheezy-7.5-armhf.com-20140603.tar to the rootfs
partition on the sd-card.

d)
Finally, inserted the sdcard in cubieboard2, and upon bootup,
following is seen :


U-Boot SPL 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48 +0530)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2018.05-rc2-00118-gec5c4a8 (Apr 28 2018 - 08:40:48 +0530)
Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
In:serial
Out:   serial
Err:   serial
SCSI:  SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   eth0: ethernet@01c5
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
245 bytes read in 13 ms (17.6 KiB/s)
## Executing script at 4310
3961944 bytes read in 241 ms (15.7 MiB/s)
26147 bytes read in 23 ms (1.1 MiB/s)
## Flattened Device Tree blob at 4900
   Booting using the fdt blob at 0x4900
   Loading Device Tree to 49ff6000, end 49fff622 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.17.0-rc2 (ajay@latitude-3480) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #6 SMP Sat Apr 28
08:36:46 8
[0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt: Machine model: Cubietech Cubieboard2
[0.00] Memory policy: Data cache writealloc
[0.00] cma: Reserved 16 MiB at 0x7f00
[0.00] psci: probing for conduit method from DT.
[0.00] psci: Using PSCI v0.1 Function IDs from DT
[0.00] random: get_random_bytes called from
start_kernel+0xa0/0x3fc with crng_init=0
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s33804 r8192
d23540 u65536
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[0.00] Kernel command line: console=ttyS0,115200 rw root=/dev/mmcblk0p2
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1013080K/1048576K available (6144K kernel code,
420K rwdata, 1492K rodata, 1024K init, 241K bss, 19112K reserved,
16384)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (7136 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 421 kB)
[0.00].bss : 

Re: [PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

[Matthew Wilcox]

On Fri, Apr 27, 2018 at 05:15:26PM -0700, Luis R. Rodriguez wrote:
> Some architectures do not define PAGE_KERNEL_RO, best we can do
> for them is to provide a fallback onto PAGE_KERNEL. Remove the
> hack from the firmware loader and move it onto the asm-generic
> header, and document while at it the affected architectures
> which do not have a PAGE_KERNEL_RO:
> 
>   o alpha
>   o ia64
>   o m68k
>   o mips
>   o sparc64
>   o sparc

ia64 doesn't have it?

*fx: riffles through architecture book*

That seems like an oversight of the Linux port.  Tony, Fenghua, any thoughts?

(also, Luis, maybe move the PAGE_KERNEL_EXEC fallback the same way you
moved the PAGE_KERNEL_RO fallback?)

--- >8 ---

ia64: Add PAGE_KERNEL_RO and PAGE_KERNEL_EXEC

The rest of the kernel was falling back to simple PAGE_KERNEL pages; using
PAGE_KERNEL_RO and PAGE_KERNEL_EXEC provide better protection against
unintended writes.

Signed-off-by: Matthew Wilcox 

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 165827774bea..041a32a7960d 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -23,7 +23,7 @@
 
 /*
  * First, define the various bits in a PTE.  Note that the PTE format
- * matches the VHPT short format, the firt doubleword of the VHPD long
+ * matches the VHPT short format, the first doubleword of the VHPD long
  * format, and the first doubleword of the TLB insertion format.
  */
 #define _PAGE_P_BIT0
@@ -142,9 +142,11 @@
 #define PAGE_COPY_EXEC __pgprot(__ACCESS_BITS | _PAGE_PL_3 | _PAGE_AR_RX)
 #define PAGE_GATE  __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_X_RX)
 #define PAGE_KERNEL__pgprot(__DIRTY_BITS  | _PAGE_PL_0 | _PAGE_AR_RWX)
-#define PAGE_KERNELRX  __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_RX)
+#define PAGE_KERNEL_RO __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_R)
+#define PAGE_KERNEL_RX __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_RX)
 #define PAGE_KERNEL_UC __pgprot(__DIRTY_BITS  | _PAGE_PL_0 | _PAGE_AR_RWX | \
 _PAGE_MA_UC)
+#define PAGE_KERNEL_EXEC   PAGE_KERNEL_RX
 
 # ifndef __ASSEMBLY__
 

Re: [PATCH] mm: provide a fallback for PAGE_KERNEL_RO for architectures

[Matthew Wilcox]

On Fri, Apr 27, 2018 at 05:15:26PM -0700, Luis R. Rodriguez wrote:
> Some architectures do not define PAGE_KERNEL_RO, best we can do
> for them is to provide a fallback onto PAGE_KERNEL. Remove the
> hack from the firmware loader and move it onto the asm-generic
> header, and document while at it the affected architectures
> which do not have a PAGE_KERNEL_RO:
> 
>   o alpha
>   o ia64
>   o m68k
>   o mips
>   o sparc64
>   o sparc

ia64 doesn't have it?

*fx: riffles through architecture book*

That seems like an oversight of the Linux port.  Tony, Fenghua, any thoughts?

(also, Luis, maybe move the PAGE_KERNEL_EXEC fallback the same way you
moved the PAGE_KERNEL_RO fallback?)

--- >8 ---

ia64: Add PAGE_KERNEL_RO and PAGE_KERNEL_EXEC

The rest of the kernel was falling back to simple PAGE_KERNEL pages; using
PAGE_KERNEL_RO and PAGE_KERNEL_EXEC provide better protection against
unintended writes.

Signed-off-by: Matthew Wilcox 

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 165827774bea..041a32a7960d 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -23,7 +23,7 @@
 
 /*
  * First, define the various bits in a PTE.  Note that the PTE format
- * matches the VHPT short format, the firt doubleword of the VHPD long
+ * matches the VHPT short format, the first doubleword of the VHPD long
  * format, and the first doubleword of the TLB insertion format.
  */
 #define _PAGE_P_BIT0
@@ -142,9 +142,11 @@
 #define PAGE_COPY_EXEC __pgprot(__ACCESS_BITS | _PAGE_PL_3 | _PAGE_AR_RX)
 #define PAGE_GATE  __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_X_RX)
 #define PAGE_KERNEL__pgprot(__DIRTY_BITS  | _PAGE_PL_0 | _PAGE_AR_RWX)
-#define PAGE_KERNELRX  __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_RX)
+#define PAGE_KERNEL_RO __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_R)
+#define PAGE_KERNEL_RX __pgprot(__ACCESS_BITS | _PAGE_PL_0 | _PAGE_AR_RX)
 #define PAGE_KERNEL_UC __pgprot(__DIRTY_BITS  | _PAGE_PL_0 | _PAGE_AR_RWX | \
 _PAGE_MA_UC)
+#define PAGE_KERNEL_EXEC   PAGE_KERNEL_RX
 
 # ifndef __ASSEMBLY__
 

[PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

[Zumeng Chen]

Reading hw_stats will get the actual data after a sucessfull tg3_reset_hw,
which actually after tg3_timer_start, so tg->hw_stats_flag is introduced to
tell tg3_get_stats64 when hw_stats is ready to read, and it will be false
after having done memset(tp->hw_stats, 0) in tg3_halt. Plus tg3_get_stats64
and tg3_halt are protected by tp->lock in all scope.

Meanwhile, this patch is also to fix a kernel BUG_ON(in_interrupt) crash when
tg3_free_consistent is stuck in tp->lock, which might get a lot of in_softirq
counts(512 or so), and BUG_ON when vunmap to unmap hw->stats.

[ cut here ]
kernel BUG at /kernel-source//mm/vmalloc.c:1621!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
task: ffc87431 task.stack: ffc8742bc000
PC is at vunmap+0x48/0x50
LR is at __dma_free+0x98/0xa0
pc : [] lr : [] pstate: 0145
sp : ffc8742bfad0
x29: ffc8742bfad0 x28: ffc87431
x27: ffc878931200 x26: ffc87453
x25: 0003 x24: ff800b3aa000
x23: 700bb000 x22: 
x21:  x20: ffc87aafd0a0
x19: ff800b3aa000 x18: 0020
x17: 007f9e191e10 x16: ff8008eb0d28
x15: 000a x14: 00070cc8
x13: ff8008c65000 x12: 
x11: 000a x10: ffbf21d0e220
x9 : 0004 x8 : ff8008c65000
x7 : 3ff0 x6 : 
x5 : ff8008097f20 x4 : 
x3 : ff8008fd4fff x2 : ffc87b361788
x1 : ff800b3aafff x0 : 0201
Process connmand (pid: 785, stack limit = 0xffc8742bc000)
Stack: (0xffc8742bfad0 to 0xffc8742c)
fac0:   ffc8742bfaf0 ff8008097fb8
fae0: 1000 ff80 ffc8742bfb30 ff8000b717d4
fb00: ffc87aafd0a0 ff8008a38000 ff800b3aa000 ffc874530904
fb20: ffc874530900 700bb000 ffc8742bfb80 ff8000b80324
fb40: 0001 ffc874530900 0100 0200
fb60: 9003 ffc87453 0003 ffc87453
fb80: ffc8742bfbd0 ff8000b8aa5c ffc874530900 ffc87453
fba0: 0001  9003 ffc878931210
fbc0: 9002 ffc87453 ffc8742bfc00 ff80088bf44c
fbe0: ffc87453 ffc8742bfc50 0001 ffc87431
fc00: ffc8742bfc30 ff80088bf5e4 ffc87453 9002
fc20: ffc8742bfc40 ffc87453 ffc8742bfc60 ff80088c9d58
fc40: ffc87453 ff80088c9d34 ffc874530080 ffc874530080
fc60: ffc8742bfca0 ff80088c9e4c ffc87453 9003
fc80: 8914  007ffd94ba10 ffc8742bfd38
fca0: ffc8742bfcd0 ff80089509f8  ff9d
fcc0: 8914  ffc8742bfd60 ff8008953088
fce0: 8914 ffc874b49b80 007ffd94ba10 ff8008e9b400
fd00: 0004 007ffd94ba10 0124 001d
fd20: ff8008a32000 ff8008e9b400 0004 34687465
fd40:  9002  
fd60: ffc8742bfd90 ff80088a1720 ffc874b49b80 8914
fd80: 007ffd94ba10  ffc8742bfdc0 ff80088a2648
fda0: 8914 007ffd94ba10 ff8008e9b400 ffc878a73c00
fdc0: ffc8742bfe00 ff800822e9e0 8914 007ffd94ba10
fde0: ffc874b49bb0 ffc8747e5800 ffc8742bfe50 ff800823cd58
fe00: ffc8742bfe80 ff800822f0ec  ffc878a73c00
fe20: ffc878a73c00 0004 8914 0008
fe40: ffc8742bfe80 ff800822f0b0  ffc878a73c00
fe60: ffc878a73c00 0004 8914 ff8008083730
fe80:  ff8008083730  0048771fb000
fea0:  007f9e191e1c  0015
fec0: 0004 8914 007ffd94ba10 
fee0: 002f 0004 0010 
ff00: 001d 000f 0101010101010101 
ff20: 6532336338646634 00656c6261635f38 007f9e46a220 007f9e45f318
ff40: 004c1a58 007f9e191e10 06df 
ff60: 0004 004c6470 004c3c40 00512d20
ff80: 0001   
ffa0:  007ffd94b9f0 00463dec 007ffd94b9f0
ffc0: 007f9e191e1c  0004 001d
ffe0:    
Call trace:
Exception stack(0xffc8742bf900 to 0xffc8742bfa30)
f900: ff800b3aa000 0080 ffc8742bfad0 ff80081eb420
f920: ff80 ff80081a58ec ffc8742bf940 ff80081c3ea8
f940: ffc8742bf990 

[PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

[Zumeng Chen]

Reading hw_stats will get the actual data after a sucessfull tg3_reset_hw,
which actually after tg3_timer_start, so tg->hw_stats_flag is introduced to
tell tg3_get_stats64 when hw_stats is ready to read, and it will be false
after having done memset(tp->hw_stats, 0) in tg3_halt. Plus tg3_get_stats64
and tg3_halt are protected by tp->lock in all scope.

Meanwhile, this patch is also to fix a kernel BUG_ON(in_interrupt) crash when
tg3_free_consistent is stuck in tp->lock, which might get a lot of in_softirq
counts(512 or so), and BUG_ON when vunmap to unmap hw->stats.

[ cut here ]
kernel BUG at /kernel-source//mm/vmalloc.c:1621!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
task: ffc87431 task.stack: ffc8742bc000
PC is at vunmap+0x48/0x50
LR is at __dma_free+0x98/0xa0
pc : [] lr : [] pstate: 0145
sp : ffc8742bfad0
x29: ffc8742bfad0 x28: ffc87431
x27: ffc878931200 x26: ffc87453
x25: 0003 x24: ff800b3aa000
x23: 700bb000 x22: 
x21:  x20: ffc87aafd0a0
x19: ff800b3aa000 x18: 0020
x17: 007f9e191e10 x16: ff8008eb0d28
x15: 000a x14: 00070cc8
x13: ff8008c65000 x12: 
x11: 000a x10: ffbf21d0e220
x9 : 0004 x8 : ff8008c65000
x7 : 3ff0 x6 : 
x5 : ff8008097f20 x4 : 
x3 : ff8008fd4fff x2 : ffc87b361788
x1 : ff800b3aafff x0 : 0201
Process connmand (pid: 785, stack limit = 0xffc8742bc000)
Stack: (0xffc8742bfad0 to 0xffc8742c)
fac0:   ffc8742bfaf0 ff8008097fb8
fae0: 1000 ff80 ffc8742bfb30 ff8000b717d4
fb00: ffc87aafd0a0 ff8008a38000 ff800b3aa000 ffc874530904
fb20: ffc874530900 700bb000 ffc8742bfb80 ff8000b80324
fb40: 0001 ffc874530900 0100 0200
fb60: 9003 ffc87453 0003 ffc87453
fb80: ffc8742bfbd0 ff8000b8aa5c ffc874530900 ffc87453
fba0: 0001  9003 ffc878931210
fbc0: 9002 ffc87453 ffc8742bfc00 ff80088bf44c
fbe0: ffc87453 ffc8742bfc50 0001 ffc87431
fc00: ffc8742bfc30 ff80088bf5e4 ffc87453 9002
fc20: ffc8742bfc40 ffc87453 ffc8742bfc60 ff80088c9d58
fc40: ffc87453 ff80088c9d34 ffc874530080 ffc874530080
fc60: ffc8742bfca0 ff80088c9e4c ffc87453 9003
fc80: 8914  007ffd94ba10 ffc8742bfd38
fca0: ffc8742bfcd0 ff80089509f8  ff9d
fcc0: 8914  ffc8742bfd60 ff8008953088
fce0: 8914 ffc874b49b80 007ffd94ba10 ff8008e9b400
fd00: 0004 007ffd94ba10 0124 001d
fd20: ff8008a32000 ff8008e9b400 0004 34687465
fd40:  9002  
fd60: ffc8742bfd90 ff80088a1720 ffc874b49b80 8914
fd80: 007ffd94ba10  ffc8742bfdc0 ff80088a2648
fda0: 8914 007ffd94ba10 ff8008e9b400 ffc878a73c00
fdc0: ffc8742bfe00 ff800822e9e0 8914 007ffd94ba10
fde0: ffc874b49bb0 ffc8747e5800 ffc8742bfe50 ff800823cd58
fe00: ffc8742bfe80 ff800822f0ec  ffc878a73c00
fe20: ffc878a73c00 0004 8914 0008
fe40: ffc8742bfe80 ff800822f0b0  ffc878a73c00
fe60: ffc878a73c00 0004 8914 ff8008083730
fe80:  ff8008083730  0048771fb000
fea0:  007f9e191e1c  0015
fec0: 0004 8914 007ffd94ba10 
fee0: 002f 0004 0010 
ff00: 001d 000f 0101010101010101 
ff20: 6532336338646634 00656c6261635f38 007f9e46a220 007f9e45f318
ff40: 004c1a58 007f9e191e10 06df 
ff60: 0004 004c6470 004c3c40 00512d20
ff80: 0001   
ffa0:  007ffd94b9f0 00463dec 007ffd94b9f0
ffc0: 007f9e191e1c  0004 001d
ffe0:    
Call trace:
Exception stack(0xffc8742bf900 to 0xffc8742bfa30)
f900: ff800b3aa000 0080 ffc8742bfad0 ff80081eb420
f920: ff80 ff80081a58ec ffc8742bf940 ff80081c3ea8
f940: ffc8742bf990 

Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from drivers/bus/mhi/controllers/mhi_qcom.c:25:0:
   include/linux/mhi.h:658:15: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int'
static inlint int mhi_force_rddm_mode(struct mhi_controller *mhi_cntrl)
  ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_deinit_pci_dev':
>> drivers/bus/mhi/controllers/mhi_qcom.c:46:2: error: implicit declaration of 
>> function 'pci_free_irq_vectors' [-Werror=implicit-function-declaration]
 pci_free_irq_vectors(pci_dev);
 ^~~~
>> drivers/bus/mhi/controllers/mhi_qcom.c:51:2: error: implicit declaration of 
>> function 'pci_clear_master' [-Werror=implicit-function-declaration]
 pci_clear_master(pci_dev);
 ^~~~
>> drivers/bus/mhi/controllers/mhi_qcom.c:52:2: error: implicit declaration of 
>> function 'pci_release_region' [-Werror=implicit-function-declaration]
 pci_release_region(pci_dev, mhi_dev->resn);
 ^~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_init_pci_dev':
>> drivers/bus/mhi/controllers/mhi_qcom.c:77:8: error: implicit declaration of 
>> function 'pci_request_region' [-Werror=implicit-function-declaration]
 ret = pci_request_region(pci_dev, mhi_dev->resn, "mhi");
   ^~
>> drivers/bus/mhi/controllers/mhi_qcom.c:93:8: error: implicit declaration of 
>> function 'pci_alloc_irq_vectors' [-Werror=implicit-function-declaration]
 ret = pci_alloc_irq_vectors(pci_dev, mhi_cntrl->msi_required,
   ^
>> drivers/bus/mhi/controllers/mhi_qcom.c:94:34: error: 'PCI_IRQ_MSI' 
>> undeclared (first use in this function)
mhi_cntrl->msi_required, PCI_IRQ_MSI);
 ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c:94:34: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/bus/mhi/controllers/mhi_qcom.c:109:23: error: implicit declaration 
>> of function 'pci_irq_vector' [-Werror=implicit-function-declaration]
  mhi_cntrl->irq[i] = pci_irq_vector(pci_dev, i);
  ^~
   At top level:
   drivers/bus/mhi/controllers/mhi_qcom.c:238:12: warning: 'mhi_system_resume' 
defined but not used [-Wunused-function]
static int mhi_system_resume(struct device *dev)
   ^
   drivers/bus/mhi/controllers/mhi_qcom.c:186:12: warning: 'mhi_runtime_idle' 
defined but not used [-Wunused-function]
static int mhi_runtime_idle(struct device *dev)
   ^~~~
   cc1: some warnings being treated as errors

vim +/pci_free_irq_vectors +46 drivers/bus/mhi/controllers/mhi_qcom.c

  > 25  #include 
26  #include "mhi_qcom.h"
27  
28  static struct pci_device_id mhi_pcie_device_id[] = {
29  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0300)},
30  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0301)},
31  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0302)},
32  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0303)},
33  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0304)},
34  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0305)},
35  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, MHI_PCIE_DEBUG_ID)},
36  {0},
37  };
38  
39  static struct pci_driver mhi_pcie_driver;
40  
41  void mhi_deinit_pci_dev(struct mhi_controller *mhi_cntrl)
42  {
43  struct mhi_dev *mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
44  struct pci_dev *pci_dev = mhi_dev->pci_dev;
45  
  > 46  pci_free_irq_vectors(pci_dev);
47  kfree(mhi_cntrl->irq);
48  mhi_cntrl->irq = NULL;
49  iounmap(mhi_cntrl->regs);
50  mhi_cntrl->regs = NULL;
  > 51  pci_clear_master(pci_dev);
  > 52  pci_release_region(pci_dev, mhi_dev->resn);
53  pci_disable_device(pci_dev);
54  }
55  
56  static int mhi_init_pci_dev(struct mhi_controller *mhi_cntrl)
57  {
58  struct mhi_dev *mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
59  struct pci_dev *pci_dev = mhi_dev->pci_dev;
60  int ret;
61  

Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from drivers/bus/mhi/controllers/mhi_qcom.c:25:0:
   include/linux/mhi.h:658:15: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int'
static inlint int mhi_force_rddm_mode(struct mhi_controller *mhi_cntrl)
  ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_deinit_pci_dev':
>> drivers/bus/mhi/controllers/mhi_qcom.c:46:2: error: implicit declaration of 
>> function 'pci_free_irq_vectors' [-Werror=implicit-function-declaration]
 pci_free_irq_vectors(pci_dev);
 ^~~~
>> drivers/bus/mhi/controllers/mhi_qcom.c:51:2: error: implicit declaration of 
>> function 'pci_clear_master' [-Werror=implicit-function-declaration]
 pci_clear_master(pci_dev);
 ^~~~
>> drivers/bus/mhi/controllers/mhi_qcom.c:52:2: error: implicit declaration of 
>> function 'pci_release_region' [-Werror=implicit-function-declaration]
 pci_release_region(pci_dev, mhi_dev->resn);
 ^~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_init_pci_dev':
>> drivers/bus/mhi/controllers/mhi_qcom.c:77:8: error: implicit declaration of 
>> function 'pci_request_region' [-Werror=implicit-function-declaration]
 ret = pci_request_region(pci_dev, mhi_dev->resn, "mhi");
   ^~
>> drivers/bus/mhi/controllers/mhi_qcom.c:93:8: error: implicit declaration of 
>> function 'pci_alloc_irq_vectors' [-Werror=implicit-function-declaration]
 ret = pci_alloc_irq_vectors(pci_dev, mhi_cntrl->msi_required,
   ^
>> drivers/bus/mhi/controllers/mhi_qcom.c:94:34: error: 'PCI_IRQ_MSI' 
>> undeclared (first use in this function)
mhi_cntrl->msi_required, PCI_IRQ_MSI);
 ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c:94:34: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/bus/mhi/controllers/mhi_qcom.c:109:23: error: implicit declaration 
>> of function 'pci_irq_vector' [-Werror=implicit-function-declaration]
  mhi_cntrl->irq[i] = pci_irq_vector(pci_dev, i);
  ^~
   At top level:
   drivers/bus/mhi/controllers/mhi_qcom.c:238:12: warning: 'mhi_system_resume' 
defined but not used [-Wunused-function]
static int mhi_system_resume(struct device *dev)
   ^
   drivers/bus/mhi/controllers/mhi_qcom.c:186:12: warning: 'mhi_runtime_idle' 
defined but not used [-Wunused-function]
static int mhi_runtime_idle(struct device *dev)
   ^~~~
   cc1: some warnings being treated as errors

vim +/pci_free_irq_vectors +46 drivers/bus/mhi/controllers/mhi_qcom.c

  > 25  #include 
26  #include "mhi_qcom.h"
27  
28  static struct pci_device_id mhi_pcie_device_id[] = {
29  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0300)},
30  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0301)},
31  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0302)},
32  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0303)},
33  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0304)},
34  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, 0x0305)},
35  {PCI_DEVICE(MHI_PCIE_VENDOR_ID, MHI_PCIE_DEBUG_ID)},
36  {0},
37  };
38  
39  static struct pci_driver mhi_pcie_driver;
40  
41  void mhi_deinit_pci_dev(struct mhi_controller *mhi_cntrl)
42  {
43  struct mhi_dev *mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
44  struct pci_dev *pci_dev = mhi_dev->pci_dev;
45  
  > 46  pci_free_irq_vectors(pci_dev);
47  kfree(mhi_cntrl->irq);
48  mhi_cntrl->irq = NULL;
49  iounmap(mhi_cntrl->regs);
50  mhi_cntrl->regs = NULL;
  > 51  pci_clear_master(pci_dev);
  > 52  pci_release_region(pci_dev, mhi_dev->resn);
53  pci_disable_device(pci_dev);
54  }
55  
56  static int mhi_init_pci_dev(struct mhi_controller *mhi_cntrl)
57  {
58  struct mhi_dev *mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
59  struct pci_dev *pci_dev = mhi_dev->pci_dev;
60  int ret;
61  

Re: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series

[Shawn Guo]

On Fri, Apr 27, 2018 at 03:24:41PM +0200, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
> 
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
> 
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
> 
> Signed-off-by: Jan Tuerk 
> ---
> Changes for v4:
>   - re-arrange the Patch-series to match the DT-submitting-patches
>   - Additional patch for the Documentation of the new DT-bindings
>   - alphabetically sort the DT
>   - moved duplicated Avari baseboard code into separate common file.
> 
>  arch/arm/boot/dts/Makefile |   2 +
>  arch/arm/boot/dts/imx6dl-emcon-avari.dts   |  17 +
>  arch/arm/boot/dts/imx6dl-emcon.dtsi|  28 +
>  arch/arm/boot/dts/imx6q-emcon-avari.dts|  17 +
>  arch/arm/boot/dts/imx6q-emcon.dtsi |  28 +
>  arch/arm/boot/dts/imx6qdl-emcon-avari.dtsi | 208 
>  arch/arm/boot/dts/imx6qdl-emcon.dtsi   | 826 
> +
>  7 files changed, 1126 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon-avari.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e2424957809..05b930da3fda 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -381,6 +381,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-cubox-i-emmc-som-v15.dtb \
>   imx6dl-cubox-i-som-v15.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
> + imx6dl-emcon-avari.dtb \
>   imx6dl-gw51xx.dtb \
>   imx6dl-gw52xx.dtb \
>   imx6dl-gw53xx.dtb \
> @@ -442,6 +443,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6q-display5-tianma-tm070-1280x768.dtb \
>   imx6q-dmo-edmqmx6.dtb \
>   imx6q-dms-ba16.dtb \
> + imx6q-emcon-avari.dtb \
>   imx6q-evi.dtb \
>   imx6q-gk802.dtb \
>   imx6q-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
> b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> new file mode 100644
> index ..464c82a53da3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: (GPL-2.0 or MIT)
> +/*
> + * Copyright (C) 2018 emtrion GmbH
> + * Author: Jan Tuerk  
> + */
> +
> +/dts-v1/;
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-emcon.dtsi"
> +/*Include camera2 pinmux*/
> +#include "imx6dl-emcon.dtsi"
> +#include "imx6qdl-emcon-avari.dtsi"
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
> + compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
> +};
> diff --git a/arch/arm/boot/dts/imx6dl-emcon.dtsi 
> b/arch/arm/boot/dts/imx6dl-emcon.dtsi
> new file mode 100644
> index ..0d86e0ecdb4d
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-emcon.dtsi
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 or MIT)
> +/*
> + * Copyright (C) 2018 emtrion GmbH
> + * Author: Jan Tuerk  
> + */
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Solo/DualLite";
> + compatible = "emtrion,emcon-mx6", "fsl,imx6dl";
> +};
> +
> + {
> + pinctrl_cpi2: csi1grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__IPU1_CSI1_PIXCLK0x0b0b1
> + MX6QDL_PAD_EIM_EB3__IPU1_CSI1_HSYNC 0x1b0b1
> + MX6QDL_PAD_EIM_D29__IPU1_CSI1_VSYNC 0x1b0b1
> + MX6QDL_PAD_EIM_A17__IPU1_CSI1_DATA120x1b0b1
> + MX6QDL_PAD_EIM_D27__IPU1_CSI1_DATA130x1b0b1
> + MX6QDL_PAD_EIM_D26__IPU1_CSI1_DATA140x1b0b1
> + MX6QDL_PAD_EIM_D20__IPU1_CSI1_DATA150x1b0b1
> + MX6QDL_PAD_EIM_D19__IPU1_CSI1_DATA160x1b0b1
> + MX6QDL_PAD_EIM_D18__IPU1_CSI1_DATA170x1b0b1
> + MX6QDL_PAD_EIM_D16__IPU1_CSI1_DATA180x1b0b1
> + MX6QDL_PAD_EIM_EB2__IPU1_CSI1_DATA190x1b0b1
> + >;
> + };
> +};

I'm uncomfortable with maintain two more dtsi files only for a single
pinctrl entry.  Instead, I would suggest you put CSI node and its
pinctrl entry into imx6q/dl-emcon-avari.dts, and have CSI node refer to
its pinctrl entry 

Re: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series

[Shawn Guo]

On Fri, Apr 27, 2018 at 03:24:41PM +0200, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
> 
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
> 
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
> 
> Signed-off-by: Jan Tuerk 
> ---
> Changes for v4:
>   - re-arrange the Patch-series to match the DT-submitting-patches
>   - Additional patch for the Documentation of the new DT-bindings
>   - alphabetically sort the DT
>   - moved duplicated Avari baseboard code into separate common file.
> 
>  arch/arm/boot/dts/Makefile |   2 +
>  arch/arm/boot/dts/imx6dl-emcon-avari.dts   |  17 +
>  arch/arm/boot/dts/imx6dl-emcon.dtsi|  28 +
>  arch/arm/boot/dts/imx6q-emcon-avari.dts|  17 +
>  arch/arm/boot/dts/imx6q-emcon.dtsi |  28 +
>  arch/arm/boot/dts/imx6qdl-emcon-avari.dtsi | 208 
>  arch/arm/boot/dts/imx6qdl-emcon.dtsi   | 826 
> +
>  7 files changed, 1126 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon-avari.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e2424957809..05b930da3fda 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -381,6 +381,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-cubox-i-emmc-som-v15.dtb \
>   imx6dl-cubox-i-som-v15.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
> + imx6dl-emcon-avari.dtb \
>   imx6dl-gw51xx.dtb \
>   imx6dl-gw52xx.dtb \
>   imx6dl-gw53xx.dtb \
> @@ -442,6 +443,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6q-display5-tianma-tm070-1280x768.dtb \
>   imx6q-dmo-edmqmx6.dtb \
>   imx6q-dms-ba16.dtb \
> + imx6q-emcon-avari.dtb \
>   imx6q-evi.dtb \
>   imx6q-gk802.dtb \
>   imx6q-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
> b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> new file mode 100644
> index ..464c82a53da3
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: (GPL-2.0 or MIT)
> +/*
> + * Copyright (C) 2018 emtrion GmbH
> + * Author: Jan Tuerk  
> + */
> +
> +/dts-v1/;
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-emcon.dtsi"
> +/*Include camera2 pinmux*/
> +#include "imx6dl-emcon.dtsi"
> +#include "imx6qdl-emcon-avari.dtsi"
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
> + compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
> +};
> diff --git a/arch/arm/boot/dts/imx6dl-emcon.dtsi 
> b/arch/arm/boot/dts/imx6dl-emcon.dtsi
> new file mode 100644
> index ..0d86e0ecdb4d
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-emcon.dtsi
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 or MIT)
> +/*
> + * Copyright (C) 2018 emtrion GmbH
> + * Author: Jan Tuerk  
> + */
> +
> +/ {
> + model = "emtrion SoM emCON-MX6 Solo/DualLite";
> + compatible = "emtrion,emcon-mx6", "fsl,imx6dl";
> +};
> +
> + {
> + pinctrl_cpi2: csi1grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_D17__IPU1_CSI1_PIXCLK0x0b0b1
> + MX6QDL_PAD_EIM_EB3__IPU1_CSI1_HSYNC 0x1b0b1
> + MX6QDL_PAD_EIM_D29__IPU1_CSI1_VSYNC 0x1b0b1
> + MX6QDL_PAD_EIM_A17__IPU1_CSI1_DATA120x1b0b1
> + MX6QDL_PAD_EIM_D27__IPU1_CSI1_DATA130x1b0b1
> + MX6QDL_PAD_EIM_D26__IPU1_CSI1_DATA140x1b0b1
> + MX6QDL_PAD_EIM_D20__IPU1_CSI1_DATA150x1b0b1
> + MX6QDL_PAD_EIM_D19__IPU1_CSI1_DATA160x1b0b1
> + MX6QDL_PAD_EIM_D18__IPU1_CSI1_DATA170x1b0b1
> + MX6QDL_PAD_EIM_D16__IPU1_CSI1_DATA180x1b0b1
> + MX6QDL_PAD_EIM_EB2__IPU1_CSI1_DATA190x1b0b1
> + >;
> + };
> +};

I'm uncomfortable with maintain two more dtsi files only for a single
pinctrl entry.  Instead, I would suggest you put CSI node and its
pinctrl entry into imx6q/dl-emcon-avari.dts, and have CSI node refer to
its pinctrl entry rather than having the pinctrl in hog group.

> diff --git 

Re: [PATCH v2] init: Fix false positives in W+X checking

[Kees Cook]

On Fri, Apr 27, 2018 at 2:55 PM, Jeffrey Hugo  wrote:
> load_module() creates W+X mappings via __vmalloc_node_range() (from
> layout_and_allocate()->move_module()->module_alloc()) by using
> PAGE_KERNEL_EXEC.  These mappings are later cleaned up via
> "call_rcu_sched(>rcu, do_free_init)" from do_init_module().
>
> This is a problem because call_rcu_sched() queues work, which can be run
> after debug_checkwx() is run, resulting in a race condition.  If hit, the
> race results in a nasty splat about insecure W+X mappings, which results
> in a poor user experience as these are not the mappings that
> debug_checkwx() is intended to catch.
>
> This issue is observed on multiple arm64 platforms, and has been
> artificially triggered on an x86 platform.
>
> Address the race by flushing the queued work before running the
> arch-defined mark_rodata_ro() which then calls debug_checkwx().
>
> Reported-by: Timur Tabi 
> Reported-by: Jan Glauber 
> Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings")
> Signed-off-by: Jeffrey Hugo 

Acked-by: Kees Cook 

-Kees

> ---
>
> v1:
> -was "arm64: mm: Fix false positives in W+X checking" (see [1])
> -moved to common code based on review and confirmation of issue on x86
>
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573776.html
>
>  init/main.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index b795aa3..499d957 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1034,6 +1034,13 @@ static int __init set_debug_rodata(char *str)
>  static void mark_readonly(void)
>  {
> if (rodata_enabled) {
> +   /*
> +* load_module() results in W+X mappings, which are cleaned up
> +* with call_rcu_sched().  Let's make sure that queued work is
> +* flushed so that we don't hit false positives looking for
> +* insecure pages which are W+X.
> +*/
> +   rcu_barrier_sched();
> mark_rodata_ro();
> rodata_test();
> } else
> --
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
> Inc.
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
>



-- 
Kees Cook
Pixel Security

Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   In file included from drivers/bus/mhi/controllers/mhi_qcom.c:25:0:
   include/linux/mhi.h:658:15: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int'
static inlint int mhi_force_rddm_mode(struct mhi_controller *mhi_cntrl)
  ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_platform_probe':
>> drivers/bus/mhi/controllers/mhi_qcom.c:587:17: error: implicit declaration 
>> of function 'memblock_start_of_DRAM'; did you mean 'memblock_alloc'? 
>> [-Werror=implicit-function-declaration]
  addr_win[0] = memblock_start_of_DRAM();
^~
memblock_alloc
>> drivers/bus/mhi/controllers/mhi_qcom.c:588:17: error: implicit declaration 
>> of function 'memblock_end_of_DRAM'; did you mean 'memblock_alloc'? 
>> [-Werror=implicit-function-declaration]
  addr_win[1] = memblock_end_of_DRAM();
^~~~
memblock_alloc
   At top level:
   drivers/bus/mhi/controllers/mhi_qcom.c:238:12: warning: 'mhi_system_resume' 
defined but not used [-Wunused-function]
static int mhi_system_resume(struct device *dev)
   ^
   drivers/bus/mhi/controllers/mhi_qcom.c:186:12: warning: 'mhi_runtime_idle' 
defined but not used [-Wunused-function]
static int mhi_runtime_idle(struct device *dev)
   ^~~~
   cc1: some warnings being treated as errors

vim +587 drivers/bus/mhi/controllers/mhi_qcom.c

   533  
   534  static int mhi_platform_probe(struct platform_device *pdev)
   535  {
   536  struct mhi_controller *mhi_cntrl;
   537  struct mhi_dev *mhi_dev;
   538  struct device_node *of_node = pdev->dev.of_node;
   539  u64 addr_win[2];
   540  int ret;
   541  
   542  if (!of_node)
   543  return -ENODEV;
   544  
   545  mhi_cntrl = mhi_alloc_controller(sizeof(*mhi_dev));
   546  if (!mhi_cntrl)
   547  return -ENOMEM;
   548  
   549  mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
   550  
   551  /* get pci bus topology for this node */
   552  ret = of_property_read_u32(of_node, "qcom,pci-dev-id",
   553 _cntrl->dev_id);
   554  if (ret)
   555  mhi_cntrl->dev_id = PCI_ANY_ID;
   556  
   557  ret = of_property_read_u32(of_node, "qcom,pci-domain",
   558 _cntrl->domain);
   559  if (ret)
   560  goto error_probe;
   561  
   562  ret = of_property_read_u32(of_node, "qcom,pci-bus", 
_cntrl->bus);
   563  if (ret)
   564  goto error_probe;
   565  
   566  ret = of_property_read_u32(of_node, "qcom,pci-slot", 
_cntrl->slot);
   567  if (ret)
   568  goto error_probe;
   569  
   570  ret = of_property_read_u32(of_node, "qcom,smmu-cfg",
   571 _dev->smmu_cfg);
   572  if (ret)
   573  goto error_probe;
   574  
   575  /* if s1 translation enabled pull iova addr from dt */
   576  if (mhi_dev->smmu_cfg & MHI_SMMU_ATTACH &&
   577  !(mhi_dev->smmu_cfg & MHI_SMMU_S1_BYPASS)) {
   578  ret = of_property_count_elems_of_size(of_node, 
"qcom,addr-win",
   579sizeof(addr_win));
   580  if (ret != 1)
   581  goto error_probe;
   582  ret = of_property_read_u64_array(of_node, 
"qcom,addr-win",
   583   addr_win, 2);
   584  if (ret)
   585  goto error_probe;
   586  } else {
 > 587  addr_win[0] = memblock_start_of_DRAM();
 > 588  addr_win[1] = memblock_end_of_DRAM();
   589  }
   590  
   591  mhi_dev->iova_start = addr_win[0];
   592  mhi_dev->iova_stop = addr_win[1];
   593  
   594  /*
   595   * if S1 is enabled, set MHI_CTRL start address to 0 so we can 
use low
   596   * 

Re: [PATCH v2] init: Fix false positives in W+X checking

[Kees Cook]

On Fri, Apr 27, 2018 at 2:55 PM, Jeffrey Hugo  wrote:
> load_module() creates W+X mappings via __vmalloc_node_range() (from
> layout_and_allocate()->move_module()->module_alloc()) by using
> PAGE_KERNEL_EXEC.  These mappings are later cleaned up via
> "call_rcu_sched(>rcu, do_free_init)" from do_init_module().
>
> This is a problem because call_rcu_sched() queues work, which can be run
> after debug_checkwx() is run, resulting in a race condition.  If hit, the
> race results in a nasty splat about insecure W+X mappings, which results
> in a poor user experience as these are not the mappings that
> debug_checkwx() is intended to catch.
>
> This issue is observed on multiple arm64 platforms, and has been
> artificially triggered on an x86 platform.
>
> Address the race by flushing the queued work before running the
> arch-defined mark_rodata_ro() which then calls debug_checkwx().
>
> Reported-by: Timur Tabi 
> Reported-by: Jan Glauber 
> Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings")
> Signed-off-by: Jeffrey Hugo 

Acked-by: Kees Cook 

-Kees

> ---
>
> v1:
> -was "arm64: mm: Fix false positives in W+X checking" (see [1])
> -moved to common code based on review and confirmation of issue on x86
>
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573776.html
>
>  init/main.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index b795aa3..499d957 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1034,6 +1034,13 @@ static int __init set_debug_rodata(char *str)
>  static void mark_readonly(void)
>  {
> if (rodata_enabled) {
> +   /*
> +* load_module() results in W+X mappings, which are cleaned up
> +* with call_rcu_sched().  Let's make sure that queued work is
> +* flushed so that we don't hit false positives looking for
> +* insecure pages which are W+X.
> +*/
> +   rcu_barrier_sched();
> mark_rodata_ro();
> rodata_test();
> } else
> --
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
> Inc.
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
>



-- 
Kees Cook
Pixel Security

Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   In file included from drivers/bus/mhi/controllers/mhi_qcom.c:25:0:
   include/linux/mhi.h:658:15: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int'
static inlint int mhi_force_rddm_mode(struct mhi_controller *mhi_cntrl)
  ^~~
   drivers/bus/mhi/controllers/mhi_qcom.c: In function 'mhi_platform_probe':
>> drivers/bus/mhi/controllers/mhi_qcom.c:587:17: error: implicit declaration 
>> of function 'memblock_start_of_DRAM'; did you mean 'memblock_alloc'? 
>> [-Werror=implicit-function-declaration]
  addr_win[0] = memblock_start_of_DRAM();
^~
memblock_alloc
>> drivers/bus/mhi/controllers/mhi_qcom.c:588:17: error: implicit declaration 
>> of function 'memblock_end_of_DRAM'; did you mean 'memblock_alloc'? 
>> [-Werror=implicit-function-declaration]
  addr_win[1] = memblock_end_of_DRAM();
^~~~
memblock_alloc
   At top level:
   drivers/bus/mhi/controllers/mhi_qcom.c:238:12: warning: 'mhi_system_resume' 
defined but not used [-Wunused-function]
static int mhi_system_resume(struct device *dev)
   ^
   drivers/bus/mhi/controllers/mhi_qcom.c:186:12: warning: 'mhi_runtime_idle' 
defined but not used [-Wunused-function]
static int mhi_runtime_idle(struct device *dev)
   ^~~~
   cc1: some warnings being treated as errors

vim +587 drivers/bus/mhi/controllers/mhi_qcom.c

   533  
   534  static int mhi_platform_probe(struct platform_device *pdev)
   535  {
   536  struct mhi_controller *mhi_cntrl;
   537  struct mhi_dev *mhi_dev;
   538  struct device_node *of_node = pdev->dev.of_node;
   539  u64 addr_win[2];
   540  int ret;
   541  
   542  if (!of_node)
   543  return -ENODEV;
   544  
   545  mhi_cntrl = mhi_alloc_controller(sizeof(*mhi_dev));
   546  if (!mhi_cntrl)
   547  return -ENOMEM;
   548  
   549  mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
   550  
   551  /* get pci bus topology for this node */
   552  ret = of_property_read_u32(of_node, "qcom,pci-dev-id",
   553 _cntrl->dev_id);
   554  if (ret)
   555  mhi_cntrl->dev_id = PCI_ANY_ID;
   556  
   557  ret = of_property_read_u32(of_node, "qcom,pci-domain",
   558 _cntrl->domain);
   559  if (ret)
   560  goto error_probe;
   561  
   562  ret = of_property_read_u32(of_node, "qcom,pci-bus", 
_cntrl->bus);
   563  if (ret)
   564  goto error_probe;
   565  
   566  ret = of_property_read_u32(of_node, "qcom,pci-slot", 
_cntrl->slot);
   567  if (ret)
   568  goto error_probe;
   569  
   570  ret = of_property_read_u32(of_node, "qcom,smmu-cfg",
   571 _dev->smmu_cfg);
   572  if (ret)
   573  goto error_probe;
   574  
   575  /* if s1 translation enabled pull iova addr from dt */
   576  if (mhi_dev->smmu_cfg & MHI_SMMU_ATTACH &&
   577  !(mhi_dev->smmu_cfg & MHI_SMMU_S1_BYPASS)) {
   578  ret = of_property_count_elems_of_size(of_node, 
"qcom,addr-win",
   579sizeof(addr_win));
   580  if (ret != 1)
   581  goto error_probe;
   582  ret = of_property_read_u64_array(of_node, 
"qcom,addr-win",
   583   addr_win, 2);
   584  if (ret)
   585  goto error_probe;
   586  } else {
 > 587  addr_win[0] = memblock_start_of_DRAM();
 > 588  addr_win[1] = memblock_end_of_DRAM();
   589  }
   590  
   591  mhi_dev->iova_start = addr_win[0];
   592  mhi_dev->iova_stop = addr_win[1];
   593  
   594  /*
   595   * if S1 is enabled, set MHI_CTRL start address to 0 so we can 
use low
   596   * 

Re: kselftest archives etc.

[Daniel Díaz Rodríguez]

Hello!


On 27 April 2018 at 19:17, Randy Dunlap  wrote:
[...]
> so I looked for an archive of linux-kselft...@vger.kernel.org.
> http://vger.kernel.org/vger-lists.html lists all mailing lists and
> (some of) their archives, but none for linux-kselftest.

For what it's worth, as of last November Linaro is also hosting a
mirror of this mailing list:
  https://lists.linaro.org/pipermail/linux-kselftest-mirror/

Greetings!

Daniel Díaz
daniel.d...@linaro.org

Re: kselftest archives etc.

[Daniel Díaz Rodríguez]

Hello!


On 27 April 2018 at 19:17, Randy Dunlap  wrote:
[...]
> so I looked for an archive of linux-kselft...@vger.kernel.org.
> http://vger.kernel.org/vger-lists.html lists all mailing lists and
> (some of) their archives, but none for linux-kselftest.

For what it's worth, as of last November Linaro is also hosting a
mirror of this mailing list:
  https://lists.linaro.org/pipermail/linux-kselftest-mirror/

Greetings!

Daniel Díaz
daniel.d...@linaro.org

[PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nipun Gupta 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Bjorn Helgaas   # PCI parts
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

Changes in v3:
  - Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
  - Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c  |  4 
 drivers/base/dma-mapping.c  | 31 ---
 drivers/base/platform.c | 17 +
 drivers/gpu/host1x/bus.c|  8 
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/platform_device.h |  2 ++
 7 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
 /*
  * Primecells are part of the Advanced Microcontroller Bus Architecture,
  * so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
  */
 struct bus_type amba_bustype = {
.name   = "amba",
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index d82566d..f831a58 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -329,36 +329,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
  */
-#include 
-
 int dma_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
-   enum dev_dma_attr attr;
-   int ret = 0;
-
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
-   if (attr != DEV_DMA_NOT_SUPPORTED)
-   ret = acpi_dma_configure(dev, attr);
-   }
-
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
-   return ret;
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+   return 0;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 8075ddc..638d42e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+int platform_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ 

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All error/warnings (new ones prefixed by >>):

   drivers/bus/mhi/core/mhi_dtr.c: In function 'mhi_ioctl':
>> drivers/bus/mhi/core/mhi_dtr.c:108:9: error: implicit declaration of 
>> function 'get_user'; did you mean 'get_super'? 
>> [-Werror=implicit-function-declaration]
  ret = get_user(tiocm, (u32 *)arg);
^~~~
get_super
>> drivers/bus/mhi/core/mhi_dtr.c:108:7: warning: 'tiocm' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  ret = get_user(tiocm, (u32 *)arg);
  ^
   cc1: some warnings being treated as errors

vim +108 drivers/bus/mhi/core/mhi_dtr.c

90  
91  long mhi_ioctl(struct mhi_device *mhi_dev, unsigned int cmd, unsigned 
long arg)
92  {
93  struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
94  struct mhi_chan *mhi_chan = mhi_dev->ul_chan;
95  int ret;
96  
97  /* ioctl not supported by this controller */
98  if (!mhi_cntrl->dtr_dev)
99  return -EIO;
   100  
   101  switch (cmd) {
   102  case TIOCMGET:
   103  return mhi_chan->tiocm;
   104  case TIOCMSET:
   105  {
   106  u32 tiocm;
   107  
 > 108  ret = get_user(tiocm, (u32 *)arg);
   109  if (ret)
   110  return ret;
   111  
   112  return mhi_dtr_tiocmset(mhi_cntrl, mhi_chan, tiocm);
   113  }
   114  default:
   115  break;
   116  }
   117  
   118  return -EINVAL;
   119  }
   120  EXPORT_SYMBOL(mhi_ioctl);
   121  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

[Nipun Gupta]

It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.

The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.

This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.

Suggested-by: Christoph Hellwig 
Signed-off-by: Nipun Gupta 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Bjorn Helgaas   # PCI parts
---
 - The patches are based on the comments on:
   https://patchwork.kernel.org/patch/10259087/

Changes in v2:
  - Do not have dma_deconfigure callback
  - Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
  - Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
  - Updated commit message
  - Updated pci_dma_configure API with changes suggested by Robin

Changes in v3:
  - Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
  - Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c  |  4 
 drivers/base/dma-mapping.c  | 31 ---
 drivers/base/platform.c | 17 +
 drivers/gpu/host1x/bus.c|  8 
 drivers/pci/pci-driver.c| 32 
 include/linux/device.h  |  4 
 include/linux/platform_device.h |  2 ++
 7 files changed, 71 insertions(+), 27 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
 /*
  * Primecells are part of the Advanced Microcontroller Bus Architecture,
  * so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
  */
 struct bus_type amba_bustype = {
.name   = "amba",
.dev_groups = amba_dev_groups,
.match  = amba_match,
.uevent = amba_uevent,
+   .dma_configure  = platform_dma_configure,
.pm = _pm,
.force_dma  = true,
 };
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index d82566d..f831a58 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -329,36 +329,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
 #endif
 
 /*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
  */
-#include 
-
 int dma_configure(struct device *dev)
 {
-   struct device *bridge = NULL, *dma_dev = dev;
-   enum dev_dma_attr attr;
-   int ret = 0;
-
-   if (dev_is_pci(dev)) {
-   bridge = pci_get_host_bridge_device(to_pci_dev(dev));
-   dma_dev = bridge;
-   if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
-   dma_dev->parent->of_node)
-   dma_dev = dma_dev->parent;
-   }
-
-   if (dma_dev->of_node) {
-   ret = of_dma_configure(dev, dma_dev->of_node);
-   } else if (has_acpi_companion(dma_dev)) {
-   attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
-   if (attr != DEV_DMA_NOT_SUPPORTED)
-   ret = acpi_dma_configure(dev, attr);
-   }
-
-   if (bridge)
-   pci_put_host_bridge_device(bridge);
-
-   return ret;
+   if (dev->bus->dma_configure)
+   return dev->bus->dma_configure(dev);
+   return 0;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 8075ddc..638d42e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
 
 #endif /* CONFIG_HIBERNATE_CALLBACKS */
 
+int platform_dma_configure(struct device *dev)
+{
+   enum dev_dma_attr attr;
+   int ret = 0;
+
+   if (dev->of_node) {
+   ret = of_dma_configure(dev, dev->of_node);
+   } else if (has_acpi_companion(dev)) {
+   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+   if (attr != DEV_DMA_NOT_SUPPORTED)
+   ret = acpi_dma_configure(dev, attr);
+   }
+
+   return ret;
+}
+
 static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1157,7 @@ struct bus_type platform_bus_type = {
.dev_groups = 

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

[kbuild test robot]

Hi Sujeev,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sujeev-Dias/mhi_bus-core-Add-support-for-MHI-host-interface/20180428-065959
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All error/warnings (new ones prefixed by >>):

   drivers/bus/mhi/core/mhi_dtr.c: In function 'mhi_ioctl':
>> drivers/bus/mhi/core/mhi_dtr.c:108:9: error: implicit declaration of 
>> function 'get_user'; did you mean 'get_super'? 
>> [-Werror=implicit-function-declaration]
  ret = get_user(tiocm, (u32 *)arg);
^~~~
get_super
>> drivers/bus/mhi/core/mhi_dtr.c:108:7: warning: 'tiocm' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
  ret = get_user(tiocm, (u32 *)arg);
  ^
   cc1: some warnings being treated as errors

vim +108 drivers/bus/mhi/core/mhi_dtr.c

90  
91  long mhi_ioctl(struct mhi_device *mhi_dev, unsigned int cmd, unsigned 
long arg)
92  {
93  struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
94  struct mhi_chan *mhi_chan = mhi_dev->ul_chan;
95  int ret;
96  
97  /* ioctl not supported by this controller */
98  if (!mhi_cntrl->dtr_dev)
99  return -EIO;
   100  
   101  switch (cmd) {
   102  case TIOCMGET:
   103  return mhi_chan->tiocm;
   104  case TIOCMSET:
   105  {
   106  u32 tiocm;
   107  
 > 108  ret = get_user(tiocm, (u32 *)arg);
   109  if (ret)
   110  return ret;
   111  
   112  return mhi_dtr_tiocmset(mhi_cntrl, mhi_chan, tiocm);
   113  }
   114  default:
   115  break;
   116  }
   117  
   118  return -EINVAL;
   119  }
   120  EXPORT_SYMBOL(mhi_ioctl);
   121  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v4 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta 
Acked-by: Bjorn Helgaas   # PCI parts
---
Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

Changes in v3:
  - Rebase and changes corresponding to the changes in patch 1/2

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c| 1 -
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/of_device.h | 8 ++--
 10 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = platform_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 638d42e..c0ff1e7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
return 0;
 }
 
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = _bus_type;
device->dev.parent = host1x->dev;
 
-   of_dma_configure(>dev, host1x->dev->of_node);
+   of_dma_configure(>dev, host1x->dev->of_node, true);
 
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
  * of_dma_configure - Setup DMA configuration
  * @dev:   Device to apply DMA configuration
  * @np:Pointer to OF node having DMA configuration
+ * @force_dma:  Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described 

[PATCH v4 2/2] drivers: remove force dma flag from buses

[Nipun Gupta]

With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.

Signed-off-by: Nipun Gupta 
Acked-by: Bjorn Helgaas   # PCI parts
---
Changes in v2:
  - This is a new change suggested by Robin and Christoph
and is added to the series.

Changes in v3:
  - Rebase and changes corresponding to the changes in patch 1/2

Changes in v4:
  - Rebased on top of 4.17-rc2

 drivers/amba/bus.c| 1 -
 drivers/base/platform.c   | 3 +--
 drivers/bcma/main.c   | 2 +-
 drivers/dma/qcom/hidma_mgmt.c | 2 +-
 drivers/gpu/host1x/bus.c  | 5 ++---
 drivers/of/device.c   | 6 --
 drivers/of/of_reserved_mem.c  | 2 +-
 drivers/pci/pci-driver.c  | 3 +--
 include/linux/device.h| 4 
 include/linux/of_device.h | 8 ++--
 10 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure  = platform_dma_configure,
.pm = _pm,
-   .force_dma  = true,
 };
 
 static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 638d42e..c0ff1e7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
 
if (dev->of_node) {
-   ret = of_dma_configure(dev, dev->of_node);
+   ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure  = platform_dma_configure,
.pm = _dev_pm_ops,
-   .force_dma  = true,
 };
 EXPORT_SYMBOL_GPL(platform_bus_type);
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
 
core->irq = bcma_of_get_irq(parent, core, 0);
 
-   of_dma_configure(>dev, node);
+   of_dma_configure(>dev, node, false);
 }
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
-   of_dma_configure(_pdev->dev, child);
+   of_dma_configure(_pdev->dev, child, true);
/*
 * It is assumed that calling of_msi_configure is safe on
 * platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
device_driver *drv)
 static int host1x_dma_configure(struct device *dev)
 {
if (dev->of_node)
-   return of_dma_configure(dev, dev->of_node);
+   return of_dma_configure(dev, dev->of_node, true);
return 0;
 }
 
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure  = host1x_dma_configure,
.pm = _device_pm_ops,
-   .force_dma = true,
 };
 
 static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = _bus_type;
device->dev.parent = host1x->dev;
 
-   of_dma_configure(>dev, host1x->dev->of_node);
+   of_dma_configure(>dev, host1x->dev->of_node, true);
 
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
  * of_dma_configure - Setup DMA configuration
  * @dev:   Device to apply DMA configuration
  * @np:Pointer to OF node having DMA configuration
+ * @force_dma:  Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not explicitly described by firmware.
  *
  * Try to get devices's 

Re: [RFC v3 0/5] virtio: support packed ring

[Jason Wang]

On 2018年04月27日 17:12, Tiwei Bie wrote:

On Fri, Apr 27, 2018 at 02:17:51PM +0800, Jason Wang wrote:

On 2018年04月27日 12:18, Michael S. Tsirkin wrote:

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:

On 2018年04月25日 13:15, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support in virtio driver.

Some simple functional tests have been done with Jason's
packed ring implementation in vhost:

https://lkml.org/lkml/2018/4/23/12

Both of ping and netperf worked as expected (with EVENT_IDX
disabled). But there are below known issues:

1. Reloading the guest driver will break the Tx/Rx;

Will have a look at this issue.


2. Zeroing the flags when detaching a used desc will
  break the guest -> host path.

I still think zeroing flags is unnecessary or even a bug. At host, I track
last observed avail wrap counter and detect avail like (what is suggested in
the example code in the spec):

static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
{
     bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);

     return avail == vq->avail_wrap_counter;
}

So zeroing wrap can not work with this obviously.

Thanks

I agree. I think what one should do is flip the available bit.


But is this flipping a must?

Thanks

Yeah, that's my question too. It seems to be a requirement
for driver that, the only change to the desc status that a
driver can do during running is to mark the desc as avail,
and any other changes to the desc status are not allowed.
Similarly, the device can only mark the desc as used, and
any other changes to the desc status are also not allowed.
So the question is, are there such requirements?


Looks not, but I think we need clarify this in the spec.

Thanks



Based on below contents in the spec:

"""
Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different
for an available descriptor and equal for a used descriptor.

Note that this observation is mostly useful for sanity-checking
as these are necessary but not sufficient conditions
"""

It seems that, it's necessary for devices to check whether
the AVAIL bit and USED bit are different.

Best regards,
Tiwei Bie

Re: [RFC v3 0/5] virtio: support packed ring

[Jason Wang]

On 2018年04月27日 17:12, Tiwei Bie wrote:

On Fri, Apr 27, 2018 at 02:17:51PM +0800, Jason Wang wrote:

On 2018年04月27日 12:18, Michael S. Tsirkin wrote:

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:

On 2018年04月25日 13:15, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support in virtio driver.

Some simple functional tests have been done with Jason's
packed ring implementation in vhost:

https://lkml.org/lkml/2018/4/23/12

Both of ping and netperf worked as expected (with EVENT_IDX
disabled). But there are below known issues:

1. Reloading the guest driver will break the Tx/Rx;

Will have a look at this issue.


2. Zeroing the flags when detaching a used desc will
  break the guest -> host path.

I still think zeroing flags is unnecessary or even a bug. At host, I track
last observed avail wrap counter and detect avail like (what is suggested in
the example code in the spec):

static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
{
     bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);

     return avail == vq->avail_wrap_counter;
}

So zeroing wrap can not work with this obviously.

Thanks

I agree. I think what one should do is flip the available bit.


But is this flipping a must?

Thanks

Yeah, that's my question too. It seems to be a requirement
for driver that, the only change to the desc status that a
driver can do during running is to mark the desc as avail,
and any other changes to the desc status are not allowed.
Similarly, the device can only mark the desc as used, and
any other changes to the desc status are also not allowed.
So the question is, are there such requirements?


Looks not, but I think we need clarify this in the spec.

Thanks



Based on below contents in the spec:

"""
Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different
for an available descriptor and equal for a used descriptor.

Note that this observation is mostly useful for sanity-checking
as these are necessary but not sufficient conditions
"""

It seems that, it's necessary for devices to check whether
the AVAIL bit and USED bit are different.

Best regards,
Tiwei Bie

Re: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

Hi Martin,


2018-04-24 2:44 GMT+09:00 Martin Blumenstingl
:
> Hello,
>
> On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
>  wrote:
>> Historically, the clocks and resets are handled on the glue layer
>> side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
>> takes care of arbitrary number of clocks and resets.  The DT node
>> structure typically looks like as follows:
>>
>>   dwc3-glue {
>>   compatible = "foo,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>
>>   dwc3 {
>>   compatible = "snps,dwc3";
>>   ...
>>   };
>>   }
>>
>> By supporting the clocks and the reset in the dwc3/core.c, it will
>> be turned into a single node:
>>
>>   dwc3 {
>>   compatible = "foo,dwc3", "snps,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>   }
>>
>> This commit adds the binding of clocks and resets specific to this IP.
>> The number of clocks should generally be the same across SoCs, it is
>> just some SoCs either tie clocks together or do not provide software
>> control of some of the clocks.
>>
>> I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
>> "bus_early" (bus_clk_early), and "suspend" (suspend_clk).
> looking at the code: this could mean that dwc3-exynos.c can be removed
> mid-term (assuming the PHY and regulator handling can be
> moved/removed/changed)
>
> does the datasheet state anything about the clock speeds? from
> Documentation/devicetree/bindings/usb/dwc3-xilinx.txt:
> "bus_clk" Master/Core clock, have to be >= 125 MHz for SS operation
> and >= 60MHz for HS operation
>
>> I found only one reset line in the datasheet, hence the reset-names
>> property is omitted.
> does the datasheet state whether this is a level or a pulsed reset line?
> on Amlogic Meson GXL, GXM and AXG SoCs we use a pulsed (and shared)
> reset line (see ff0a632f08759e "usb: dwc3: of-simple: add support for
> shared and pulsed reset lines") because the reset line is shared
> between various components (USB2 PHY, USB3 PHY, dwc3 controller, ...)
> your current approach (having a vendor-specific "foo,dwc3" binding
> along with the generic "snps,dwc3") would allow having
> per-"of_device_id" settings which could indicate whether the reset
> lines are level or pulsed reset if these are "implementation specific"

Let me ask a question about your reset controller.
(drivers/reset/reset-meson.c)

All reset ID supports .reset, .assert, .deassert
Is this correct?


I believe you and I use the same DWC3 core IP.


I suspect the difference is in the reset controller side.

In my case, the reset line is asserted by default.
(that is, all FFs in the RTL are put into the initial state
on power-on)
That's why only reset_deassert() will work for me, I think.

What about your case?  Is the reset line in deassert state on power-on?
Then, the reset must be explicitly pulsed to put FFs into
the initial state.  Is this correct?




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

Hi Martin,


2018-04-24 2:44 GMT+09:00 Martin Blumenstingl
:
> Hello,
>
> On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
>  wrote:
>> Historically, the clocks and resets are handled on the glue layer
>> side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
>> takes care of arbitrary number of clocks and resets.  The DT node
>> structure typically looks like as follows:
>>
>>   dwc3-glue {
>>   compatible = "foo,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>
>>   dwc3 {
>>   compatible = "snps,dwc3";
>>   ...
>>   };
>>   }
>>
>> By supporting the clocks and the reset in the dwc3/core.c, it will
>> be turned into a single node:
>>
>>   dwc3 {
>>   compatible = "foo,dwc3", "snps,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>   }
>>
>> This commit adds the binding of clocks and resets specific to this IP.
>> The number of clocks should generally be the same across SoCs, it is
>> just some SoCs either tie clocks together or do not provide software
>> control of some of the clocks.
>>
>> I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
>> "bus_early" (bus_clk_early), and "suspend" (suspend_clk).
> looking at the code: this could mean that dwc3-exynos.c can be removed
> mid-term (assuming the PHY and regulator handling can be
> moved/removed/changed)
>
> does the datasheet state anything about the clock speeds? from
> Documentation/devicetree/bindings/usb/dwc3-xilinx.txt:
> "bus_clk" Master/Core clock, have to be >= 125 MHz for SS operation
> and >= 60MHz for HS operation
>
>> I found only one reset line in the datasheet, hence the reset-names
>> property is omitted.
> does the datasheet state whether this is a level or a pulsed reset line?
> on Amlogic Meson GXL, GXM and AXG SoCs we use a pulsed (and shared)
> reset line (see ff0a632f08759e "usb: dwc3: of-simple: add support for
> shared and pulsed reset lines") because the reset line is shared
> between various components (USB2 PHY, USB3 PHY, dwc3 controller, ...)
> your current approach (having a vendor-specific "foo,dwc3" binding
> along with the generic "snps,dwc3") would allow having
> per-"of_device_id" settings which could indicate whether the reset
> lines are level or pulsed reset if these are "implementation specific"

Let me ask a question about your reset controller.
(drivers/reset/reset-meson.c)

All reset ID supports .reset, .assert, .deassert
Is this correct?


I believe you and I use the same DWC3 core IP.


I suspect the difference is in the reset controller side.

In my case, the reset line is asserted by default.
(that is, all FFs in the RTL are put into the initial state
on power-on)
That's why only reset_deassert() will work for me, I think.

What about your case?  Is the reset line in deassert state on power-on?
Then, the reset must be explicitly pulsed to put FFs into
the initial state.  Is this correct?




-- 
Best Regards
Masahiro Yamada

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

[Tian, Kevin]

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, April 28, 2018 2:08 AM
> 
> [...]
> >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should
> >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it
> >> different from GRANU_DOMAIN then?
> > QI_GRAN_ALL_ALL maps to VT-d spec 6.5.2.4, which invalidates all ext
> > TLB cache within a domain. It could reuse GRANU_DOMAIN but I was
> > also trying to match the naming convention in the spec.
> 
> Sorry I don't quite understand the difference between TLB and ext TLB
> invalidation. Can an ext TLB invalidation do everything a TLB can do
> plus some additional parameters (introduced in more recent version of
> the spec), or do they have distinct purposes? I'm trying to understand
> why it needs to be user-visible

distinct purpose though some overlapped effect:

IOTLB invalidate is more for 2nd-level cache on granularity (global/
domain/PSI), with side effect on 1st-level and nested caches (global/
domain).

Extended IOTLB invalidate is specifically for 1st-level and nested
caches on granularity (per-domain: all PASIDs/per PASID/PSI). 

Thanks
Kevin

RE: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

[Tian, Kevin]

> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, April 28, 2018 2:08 AM
> 
> [...]
> >> If this corresponds to QI_GRAN_ALL_ALL in patch 9, the comment should
> >> be "Cache of all PASIDs"? Or maybe "all entries for all PASIDs"? Is it
> >> different from GRANU_DOMAIN then?
> > QI_GRAN_ALL_ALL maps to VT-d spec 6.5.2.4, which invalidates all ext
> > TLB cache within a domain. It could reuse GRANU_DOMAIN but I was
> > also trying to match the naming convention in the spec.
> 
> Sorry I don't quite understand the difference between TLB and ext TLB
> invalidation. Can an ext TLB invalidation do everything a TLB can do
> plus some additional parameters (introduced in more recent version of
> the spec), or do they have distinct purposes? I'm trying to understand
> why it needs to be user-visible

distinct purpose though some overlapped effect:

IOTLB invalidate is more for 2nd-level cache on granularity (global/
domain/PSI), with side effect on 1st-level and nested caches (global/
domain).

Extended IOTLB invalidate is specifically for 1st-level and nested
caches on granularity (per-domain: all PASIDs/per PASID/PSI). 

Thanks
Kevin

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/27 10:04, Chao Yu wrote:
> > On 2018/4/27 0:03, Jaegeuk Kim wrote:
> >> On 04/24, Chao Yu wrote:
> >>> Thread A  Thread BThread C
> >>> - f2fs_remount
> >>>  - stop_gc_thread
> >>>   - f2fs_sbi_store
> >>>   - issue_discard_thread
> >>>sbi->gc_thread = NULL;
> >>> sbi->gc_thread->gc_wake = 1
> >>> access 
> >>> sbi->gc_thread->gc_urgent
> >>>
> >>> Previously, we allocate memory for sbi->gc_thread based on background
> >>> gc thread mount option, the memory can be released if we turn off
> >>> that mount option, but still there are several places access gc_thread
> >>> pointer without considering race condition, result in NULL point
> >>> dereference.
> >>
> >> Do we just need to check >s_umount in f2fs_sbi_store() and
> > 
> > Better,
> > 
> >> issue_discard_thread?
> > 
> > There is more cases can be called from different scenarios:
> > - select_policy()
> > - need_SSR()
> 
> BTW, do you agree with introducing {init,destroy}_gc_context as the patch 
> does?

I don't think so. The issue only requires mutex() in sysfs/discard_thread.

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >>>
> >>> In order to fix this issue, keep gc_thread structure valid in sbi all
> >>> the time instead of alloc/free it dynamically.
> >>>
> >>> In addition, add a rw semaphore to exclude rw operation in fields of
> >>> gc_thread.
> >>>
> >>> Signed-off-by: Chao Yu 
> >>> ---
> >>> v2:
> >>> - add a rw semaphore to exclude rw operation suggested by Jaegeuk.
> >>>  fs/f2fs/debug.c   |  3 +--
> >>>  fs/f2fs/f2fs.h|  9 ++-
> >>>  fs/f2fs/gc.c  | 78 
> >>> ---
> >>>  fs/f2fs/gc.h  |  1 +
> >>>  fs/f2fs/segment.c | 10 +--
> >>>  fs/f2fs/super.c   | 26 +--
> >>>  fs/f2fs/sysfs.c   | 26 ++-
> >>>  7 files changed, 107 insertions(+), 46 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >>> index a66107b5cfff..0fbd674c66fb 100644
> >>> --- a/fs/f2fs/debug.c
> >>> +++ b/fs/f2fs/debug.c
> >>> @@ -221,8 +221,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> >>>   si->cache_mem = 0;
> >>>  
> >>>   /* build gc */
> >>> - if (sbi->gc_thread)
> >>> - si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>> + si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>>  
> >>>   /* build merge flush thread */
> >>>   if (SM_I(sbi)->fcc_info)
> >>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>> index 8f3ad9662d13..75d3b4875429 100644
> >>> --- a/fs/f2fs/f2fs.h
> >>> +++ b/fs/f2fs/f2fs.h
> >>> @@ -1412,6 +1412,11 @@ static inline struct sit_info *SIT_I(struct 
> >>> f2fs_sb_info *sbi)
> >>>   return (struct sit_info *)(SM_I(sbi)->sit_info);
> >>>  }
> >>>  
> >>> +static inline struct f2fs_gc_kthread *GC_I(struct f2fs_sb_info *sbi)
> >>> +{
> >>> + return (struct f2fs_gc_kthread *)(sbi->gc_thread);
> >>> +}
> >>> +
> >>>  static inline struct free_segmap_info *FREE_I(struct f2fs_sb_info *sbi)
> >>>  {
> >>>   return (struct free_segmap_info *)(SM_I(sbi)->free_info);
> >>> @@ -2954,8 +2959,10 @@ bool f2fs_overwrite_io(struct inode *inode, loff_t 
> >>> pos, size_t len);
> >>>  /*
> >>>   * gc.c
> >>>   */
> >>> +int init_gc_context(struct f2fs_sb_info *sbi);
> >>> +void destroy_gc_context(struct f2fs_sb_info * sbi);
> >>>  int start_gc_thread(struct f2fs_sb_info *sbi);
> >>> -void stop_gc_thread(struct f2fs_sb_info *sbi);
> >>> +bool stop_gc_thread(struct f2fs_sb_info *sbi);
> >>>  block_t start_bidx_of_node(unsigned int node_ofs, struct inode *inode);
> >>>  int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, bool background,
> >>>   unsigned int segno);
> >>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> >>> index 70418b34c5f6..2febb84b2fd6 100644
> >>> --- a/fs/f2fs/gc.c
> >>> +++ b/fs/f2fs/gc.c
> >>> @@ -26,8 +26,8 @@
> >>>  static int gc_thread_func(void *data)
> >>>  {
> >>>   struct f2fs_sb_info *sbi = data;
> >>> - struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
> >>> - wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
> >>> + struct f2fs_gc_kthread *gc_th = GC_I(sbi);
> >>> + wait_queue_head_t *wq = _th->gc_wait_queue_head;
> >>>   unsigned int wait_ms;
> >>>  
> >>>   wait_ms = gc_th->min_sleep_time;
> >>> @@ -114,17 +114,15 @@ static int gc_thread_func(void *data)
> >>>   return 0;
> >>>  }
> >>>  
> >>> -int start_gc_thread(struct f2fs_sb_info *sbi)
> >>> +int init_gc_context(struct f2fs_sb_info *sbi)
> >>>  {
> >>>   struct f2fs_gc_kthread *gc_th;
> >>> - dev_t dev = sbi->sb->s_bdev->bd_dev;
> >>> - int err = 0;
> >>>  
> >>>   gc_th = f2fs_kmalloc(sbi, sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
> >>> - if (!gc_th) {
> >>> - err = -ENOMEM;
> >>> - goto out;
> >>> - }
> >>> + if (!gc_th)
> >>> + return -ENOMEM;
> 

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/27 10:04, Chao Yu wrote:
> > On 2018/4/27 0:03, Jaegeuk Kim wrote:
> >> On 04/24, Chao Yu wrote:
> >>> Thread A  Thread BThread C
> >>> - f2fs_remount
> >>>  - stop_gc_thread
> >>>   - f2fs_sbi_store
> >>>   - issue_discard_thread
> >>>sbi->gc_thread = NULL;
> >>> sbi->gc_thread->gc_wake = 1
> >>> access 
> >>> sbi->gc_thread->gc_urgent
> >>>
> >>> Previously, we allocate memory for sbi->gc_thread based on background
> >>> gc thread mount option, the memory can be released if we turn off
> >>> that mount option, but still there are several places access gc_thread
> >>> pointer without considering race condition, result in NULL point
> >>> dereference.
> >>
> >> Do we just need to check >s_umount in f2fs_sbi_store() and
> > 
> > Better,
> > 
> >> issue_discard_thread?
> > 
> > There is more cases can be called from different scenarios:
> > - select_policy()
> > - need_SSR()
> 
> BTW, do you agree with introducing {init,destroy}_gc_context as the patch 
> does?

I don't think so. The issue only requires mutex() in sysfs/discard_thread.

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >>>
> >>> In order to fix this issue, keep gc_thread structure valid in sbi all
> >>> the time instead of alloc/free it dynamically.
> >>>
> >>> In addition, add a rw semaphore to exclude rw operation in fields of
> >>> gc_thread.
> >>>
> >>> Signed-off-by: Chao Yu 
> >>> ---
> >>> v2:
> >>> - add a rw semaphore to exclude rw operation suggested by Jaegeuk.
> >>>  fs/f2fs/debug.c   |  3 +--
> >>>  fs/f2fs/f2fs.h|  9 ++-
> >>>  fs/f2fs/gc.c  | 78 
> >>> ---
> >>>  fs/f2fs/gc.h  |  1 +
> >>>  fs/f2fs/segment.c | 10 +--
> >>>  fs/f2fs/super.c   | 26 +--
> >>>  fs/f2fs/sysfs.c   | 26 ++-
> >>>  7 files changed, 107 insertions(+), 46 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >>> index a66107b5cfff..0fbd674c66fb 100644
> >>> --- a/fs/f2fs/debug.c
> >>> +++ b/fs/f2fs/debug.c
> >>> @@ -221,8 +221,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> >>>   si->cache_mem = 0;
> >>>  
> >>>   /* build gc */
> >>> - if (sbi->gc_thread)
> >>> - si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>> + si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>>  
> >>>   /* build merge flush thread */
> >>>   if (SM_I(sbi)->fcc_info)
> >>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>> index 8f3ad9662d13..75d3b4875429 100644
> >>> --- a/fs/f2fs/f2fs.h
> >>> +++ b/fs/f2fs/f2fs.h
> >>> @@ -1412,6 +1412,11 @@ static inline struct sit_info *SIT_I(struct 
> >>> f2fs_sb_info *sbi)
> >>>   return (struct sit_info *)(SM_I(sbi)->sit_info);
> >>>  }
> >>>  
> >>> +static inline struct f2fs_gc_kthread *GC_I(struct f2fs_sb_info *sbi)
> >>> +{
> >>> + return (struct f2fs_gc_kthread *)(sbi->gc_thread);
> >>> +}
> >>> +
> >>>  static inline struct free_segmap_info *FREE_I(struct f2fs_sb_info *sbi)
> >>>  {
> >>>   return (struct free_segmap_info *)(SM_I(sbi)->free_info);
> >>> @@ -2954,8 +2959,10 @@ bool f2fs_overwrite_io(struct inode *inode, loff_t 
> >>> pos, size_t len);
> >>>  /*
> >>>   * gc.c
> >>>   */
> >>> +int init_gc_context(struct f2fs_sb_info *sbi);
> >>> +void destroy_gc_context(struct f2fs_sb_info * sbi);
> >>>  int start_gc_thread(struct f2fs_sb_info *sbi);
> >>> -void stop_gc_thread(struct f2fs_sb_info *sbi);
> >>> +bool stop_gc_thread(struct f2fs_sb_info *sbi);
> >>>  block_t start_bidx_of_node(unsigned int node_ofs, struct inode *inode);
> >>>  int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, bool background,
> >>>   unsigned int segno);
> >>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> >>> index 70418b34c5f6..2febb84b2fd6 100644
> >>> --- a/fs/f2fs/gc.c
> >>> +++ b/fs/f2fs/gc.c
> >>> @@ -26,8 +26,8 @@
> >>>  static int gc_thread_func(void *data)
> >>>  {
> >>>   struct f2fs_sb_info *sbi = data;
> >>> - struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
> >>> - wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
> >>> + struct f2fs_gc_kthread *gc_th = GC_I(sbi);
> >>> + wait_queue_head_t *wq = _th->gc_wait_queue_head;
> >>>   unsigned int wait_ms;
> >>>  
> >>>   wait_ms = gc_th->min_sleep_time;
> >>> @@ -114,17 +114,15 @@ static int gc_thread_func(void *data)
> >>>   return 0;
> >>>  }
> >>>  
> >>> -int start_gc_thread(struct f2fs_sb_info *sbi)
> >>> +int init_gc_context(struct f2fs_sb_info *sbi)
> >>>  {
> >>>   struct f2fs_gc_kthread *gc_th;
> >>> - dev_t dev = sbi->sb->s_bdev->bd_dev;
> >>> - int err = 0;
> >>>  
> >>>   gc_th = f2fs_kmalloc(sbi, sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
> >>> - if (!gc_th) {
> >>> - err = -ENOMEM;
> >>> - goto out;
> >>> - }
> >>> + if (!gc_th)
> >>> + return -ENOMEM;
> >>> +
> >>> + 

Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

[Tetsuo Handa]

OK. Patch was sent to linux.git as 6c1e851c4edc13a4.

#syz fix: random: fix possible sleeping allocation from irq context

Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

[Tetsuo Handa]

OK. Patch was sent to linux.git as 6c1e851c4edc13a4.

#syz fix: random: fix possible sleeping allocation from irq context

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/27 0:03, Jaegeuk Kim wrote:
> > On 04/24, Chao Yu wrote:
> >> Thread A   Thread BThread C
> >> - f2fs_remount
> >>  - stop_gc_thread
> >>- f2fs_sbi_store
> >>- issue_discard_thread
> >>sbi->gc_thread = NULL;
> >>  sbi->gc_thread->gc_wake = 1
> >>  access 
> >> sbi->gc_thread->gc_urgent
> >>
> >> Previously, we allocate memory for sbi->gc_thread based on background
> >> gc thread mount option, the memory can be released if we turn off
> >> that mount option, but still there are several places access gc_thread
> >> pointer without considering race condition, result in NULL point
> >> dereference.
> > 
> > Do we just need to check >s_umount in f2fs_sbi_store() and
> 
> Better,
> 
> > issue_discard_thread?
> 
> There is more cases can be called from different scenarios:
> - select_policy()
> - need_SSR()

No? They should be blocked by remount(2).

> 
> Thanks,
> 
> > 
> >>
> >> In order to fix this issue, keep gc_thread structure valid in sbi all
> >> the time instead of alloc/free it dynamically.
> >>
> >> In addition, add a rw semaphore to exclude rw operation in fields of
> >> gc_thread.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >> v2:
> >> - add a rw semaphore to exclude rw operation suggested by Jaegeuk.
> >>  fs/f2fs/debug.c   |  3 +--
> >>  fs/f2fs/f2fs.h|  9 ++-
> >>  fs/f2fs/gc.c  | 78 
> >> ---
> >>  fs/f2fs/gc.h  |  1 +
> >>  fs/f2fs/segment.c | 10 +--
> >>  fs/f2fs/super.c   | 26 +--
> >>  fs/f2fs/sysfs.c   | 26 ++-
> >>  7 files changed, 107 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >> index a66107b5cfff..0fbd674c66fb 100644
> >> --- a/fs/f2fs/debug.c
> >> +++ b/fs/f2fs/debug.c
> >> @@ -221,8 +221,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> >>si->cache_mem = 0;
> >>  
> >>/* build gc */
> >> -  if (sbi->gc_thread)
> >> -  si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >> +  si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>  
> >>/* build merge flush thread */
> >>if (SM_I(sbi)->fcc_info)
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 8f3ad9662d13..75d3b4875429 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -1412,6 +1412,11 @@ static inline struct sit_info *SIT_I(struct 
> >> f2fs_sb_info *sbi)
> >>return (struct sit_info *)(SM_I(sbi)->sit_info);
> >>  }
> >>  
> >> +static inline struct f2fs_gc_kthread *GC_I(struct f2fs_sb_info *sbi)
> >> +{
> >> +  return (struct f2fs_gc_kthread *)(sbi->gc_thread);
> >> +}
> >> +
> >>  static inline struct free_segmap_info *FREE_I(struct f2fs_sb_info *sbi)
> >>  {
> >>return (struct free_segmap_info *)(SM_I(sbi)->free_info);
> >> @@ -2954,8 +2959,10 @@ bool f2fs_overwrite_io(struct inode *inode, loff_t 
> >> pos, size_t len);
> >>  /*
> >>   * gc.c
> >>   */
> >> +int init_gc_context(struct f2fs_sb_info *sbi);
> >> +void destroy_gc_context(struct f2fs_sb_info * sbi);
> >>  int start_gc_thread(struct f2fs_sb_info *sbi);
> >> -void stop_gc_thread(struct f2fs_sb_info *sbi);
> >> +bool stop_gc_thread(struct f2fs_sb_info *sbi);
> >>  block_t start_bidx_of_node(unsigned int node_ofs, struct inode *inode);
> >>  int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, bool background,
> >>unsigned int segno);
> >> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> >> index 70418b34c5f6..2febb84b2fd6 100644
> >> --- a/fs/f2fs/gc.c
> >> +++ b/fs/f2fs/gc.c
> >> @@ -26,8 +26,8 @@
> >>  static int gc_thread_func(void *data)
> >>  {
> >>struct f2fs_sb_info *sbi = data;
> >> -  struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
> >> -  wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
> >> +  struct f2fs_gc_kthread *gc_th = GC_I(sbi);
> >> +  wait_queue_head_t *wq = _th->gc_wait_queue_head;
> >>unsigned int wait_ms;
> >>  
> >>wait_ms = gc_th->min_sleep_time;
> >> @@ -114,17 +114,15 @@ static int gc_thread_func(void *data)
> >>return 0;
> >>  }
> >>  
> >> -int start_gc_thread(struct f2fs_sb_info *sbi)
> >> +int init_gc_context(struct f2fs_sb_info *sbi)
> >>  {
> >>struct f2fs_gc_kthread *gc_th;
> >> -  dev_t dev = sbi->sb->s_bdev->bd_dev;
> >> -  int err = 0;
> >>  
> >>gc_th = f2fs_kmalloc(sbi, sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
> >> -  if (!gc_th) {
> >> -  err = -ENOMEM;
> >> -  goto out;
> >> -  }
> >> +  if (!gc_th)
> >> +  return -ENOMEM;
> >> +
> >> +  gc_th->f2fs_gc_task = NULL;
> >>  
> >>gc_th->urgent_sleep_time = DEF_GC_THREAD_URGENT_SLEEP_TIME;
> >>gc_th->min_sleep_time = DEF_GC_THREAD_MIN_SLEEP_TIME;
> >> @@ -135,35 +133,59 @@ int start_gc_thread(struct f2fs_sb_info *sbi)
> >>gc_th->gc_urgent = 0;

Re: [PATCH v2] f2fs: fix to avoid race during access gc_thread pointer

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/27 0:03, Jaegeuk Kim wrote:
> > On 04/24, Chao Yu wrote:
> >> Thread A   Thread BThread C
> >> - f2fs_remount
> >>  - stop_gc_thread
> >>- f2fs_sbi_store
> >>- issue_discard_thread
> >>sbi->gc_thread = NULL;
> >>  sbi->gc_thread->gc_wake = 1
> >>  access 
> >> sbi->gc_thread->gc_urgent
> >>
> >> Previously, we allocate memory for sbi->gc_thread based on background
> >> gc thread mount option, the memory can be released if we turn off
> >> that mount option, but still there are several places access gc_thread
> >> pointer without considering race condition, result in NULL point
> >> dereference.
> > 
> > Do we just need to check >s_umount in f2fs_sbi_store() and
> 
> Better,
> 
> > issue_discard_thread?
> 
> There is more cases can be called from different scenarios:
> - select_policy()
> - need_SSR()

No? They should be blocked by remount(2).

> 
> Thanks,
> 
> > 
> >>
> >> In order to fix this issue, keep gc_thread structure valid in sbi all
> >> the time instead of alloc/free it dynamically.
> >>
> >> In addition, add a rw semaphore to exclude rw operation in fields of
> >> gc_thread.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >> v2:
> >> - add a rw semaphore to exclude rw operation suggested by Jaegeuk.
> >>  fs/f2fs/debug.c   |  3 +--
> >>  fs/f2fs/f2fs.h|  9 ++-
> >>  fs/f2fs/gc.c  | 78 
> >> ---
> >>  fs/f2fs/gc.h  |  1 +
> >>  fs/f2fs/segment.c | 10 +--
> >>  fs/f2fs/super.c   | 26 +--
> >>  fs/f2fs/sysfs.c   | 26 ++-
> >>  7 files changed, 107 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >> index a66107b5cfff..0fbd674c66fb 100644
> >> --- a/fs/f2fs/debug.c
> >> +++ b/fs/f2fs/debug.c
> >> @@ -221,8 +221,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> >>si->cache_mem = 0;
> >>  
> >>/* build gc */
> >> -  if (sbi->gc_thread)
> >> -  si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >> +  si->cache_mem += sizeof(struct f2fs_gc_kthread);
> >>  
> >>/* build merge flush thread */
> >>if (SM_I(sbi)->fcc_info)
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 8f3ad9662d13..75d3b4875429 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -1412,6 +1412,11 @@ static inline struct sit_info *SIT_I(struct 
> >> f2fs_sb_info *sbi)
> >>return (struct sit_info *)(SM_I(sbi)->sit_info);
> >>  }
> >>  
> >> +static inline struct f2fs_gc_kthread *GC_I(struct f2fs_sb_info *sbi)
> >> +{
> >> +  return (struct f2fs_gc_kthread *)(sbi->gc_thread);
> >> +}
> >> +
> >>  static inline struct free_segmap_info *FREE_I(struct f2fs_sb_info *sbi)
> >>  {
> >>return (struct free_segmap_info *)(SM_I(sbi)->free_info);
> >> @@ -2954,8 +2959,10 @@ bool f2fs_overwrite_io(struct inode *inode, loff_t 
> >> pos, size_t len);
> >>  /*
> >>   * gc.c
> >>   */
> >> +int init_gc_context(struct f2fs_sb_info *sbi);
> >> +void destroy_gc_context(struct f2fs_sb_info * sbi);
> >>  int start_gc_thread(struct f2fs_sb_info *sbi);
> >> -void stop_gc_thread(struct f2fs_sb_info *sbi);
> >> +bool stop_gc_thread(struct f2fs_sb_info *sbi);
> >>  block_t start_bidx_of_node(unsigned int node_ofs, struct inode *inode);
> >>  int f2fs_gc(struct f2fs_sb_info *sbi, bool sync, bool background,
> >>unsigned int segno);
> >> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> >> index 70418b34c5f6..2febb84b2fd6 100644
> >> --- a/fs/f2fs/gc.c
> >> +++ b/fs/f2fs/gc.c
> >> @@ -26,8 +26,8 @@
> >>  static int gc_thread_func(void *data)
> >>  {
> >>struct f2fs_sb_info *sbi = data;
> >> -  struct f2fs_gc_kthread *gc_th = sbi->gc_thread;
> >> -  wait_queue_head_t *wq = >gc_thread->gc_wait_queue_head;
> >> +  struct f2fs_gc_kthread *gc_th = GC_I(sbi);
> >> +  wait_queue_head_t *wq = _th->gc_wait_queue_head;
> >>unsigned int wait_ms;
> >>  
> >>wait_ms = gc_th->min_sleep_time;
> >> @@ -114,17 +114,15 @@ static int gc_thread_func(void *data)
> >>return 0;
> >>  }
> >>  
> >> -int start_gc_thread(struct f2fs_sb_info *sbi)
> >> +int init_gc_context(struct f2fs_sb_info *sbi)
> >>  {
> >>struct f2fs_gc_kthread *gc_th;
> >> -  dev_t dev = sbi->sb->s_bdev->bd_dev;
> >> -  int err = 0;
> >>  
> >>gc_th = f2fs_kmalloc(sbi, sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
> >> -  if (!gc_th) {
> >> -  err = -ENOMEM;
> >> -  goto out;
> >> -  }
> >> +  if (!gc_th)
> >> +  return -ENOMEM;
> >> +
> >> +  gc_th->f2fs_gc_task = NULL;
> >>  
> >>gc_th->urgent_sleep_time = DEF_GC_THREAD_URGENT_SLEEP_TIME;
> >>gc_th->min_sleep_time = DEF_GC_THREAD_MIN_SLEEP_TIME;
> >> @@ -135,35 +133,59 @@ int start_gc_thread(struct f2fs_sb_info *sbi)
> >>gc_th->gc_urgent = 0;
> >>

Re: [PATCH v4 0/7] Add basic support for emtrion emCON-MX6 modules

[Shawn Guo]

On Fri, Apr 27, 2018 at 03:24:35PM +0200, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> Changes for v4:
>   - re-arrange the Patch-series to match the DT-submitting-patches
>   - Additional patch for the Documentation of the new DT-bindings
> 
> [PATCH v4 1/7] dt-bindings: display: Document the EDT et* displays in one 
> file.
>   - no change (re-arranged 3/6 => 1/7)
> 
> [PATCH v4 2/7] drm/panel: Add support for the EDT ETM0700G0BDH6
>   - no change (re-arranged 1/6 => 2/7)
> 
> [PATCH v4 3/7] drm/panel: Add support for the EDT ETM0700G0EDH6
>   - no change (re-arranged 2/6 => 3/7)

Please split the series into two, DRM driver (above) and platform part
(below), to avoid posting one part over and over again with zero
changes, but only because the other part needs update.

Shawn

> 
> [PATCH v4 4/7] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
>   - no change
> 
> [PATCH v4 5/7] dt-bindings: arm: Document emtrion emCON-MX6 bindings
>   - separate patch for the emtrion emCON-MX6 DT-bindings
> 
> [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series
>   - alphabetically sort the DT
>   - moved duplicated Avari baseboard code into separate file.
> 
> [PATCH v4 7/7] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
>   - unchaged

Re: [PATCH v4 0/7] Add basic support for emtrion emCON-MX6 modules

[Shawn Guo]

On Fri, Apr 27, 2018 at 03:24:35PM +0200, jan.tu...@emtrion.com wrote:
> From: Jan Tuerk 
> 
> Changes for v4:
>   - re-arrange the Patch-series to match the DT-submitting-patches
>   - Additional patch for the Documentation of the new DT-bindings
> 
> [PATCH v4 1/7] dt-bindings: display: Document the EDT et* displays in one 
> file.
>   - no change (re-arranged 3/6 => 1/7)
> 
> [PATCH v4 2/7] drm/panel: Add support for the EDT ETM0700G0BDH6
>   - no change (re-arranged 1/6 => 2/7)
> 
> [PATCH v4 3/7] drm/panel: Add support for the EDT ETM0700G0EDH6
>   - no change (re-arranged 2/6 => 3/7)

Please split the series into two, DRM driver (above) and platform part
(below), to avoid posting one part over and over again with zero
changes, but only because the other part needs update.

Shawn

> 
> [PATCH v4 4/7] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
>   - no change
> 
> [PATCH v4 5/7] dt-bindings: arm: Document emtrion emCON-MX6 bindings
>   - separate patch for the emtrion emCON-MX6 DT-bindings
> 
> [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series
>   - alphabetically sort the DT
>   - moved duplicated Avari baseboard code into separate file.
> 
> [PATCH v4 7/7] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
>   - unchaged

Re: [PATCH v2] f2fs: avoid stucking GC due to atomic write

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/26 23:54, Jaegeuk Kim wrote:
> > On 04/24, Chao Yu wrote:
> >> f2fs doesn't allow abuse on atomic write class interface, so except
> >> limiting in-mem pages' total memory usage capacity, we need to limit
> >> atomic-write usage as well when filesystem is seriously fragmented,
> >> otherwise we may run into infinite loop during foreground GC because
> >> target blocks in victim segment are belong to atomic opened file for
> >> long time.
> > 
> > How about using fi->i_gc_failure likewise pin_file?
> 
> OK, how about changing it to array fi->i_gc_failure[MAX_GC_FAILURE], and 
> change
> the type to unsigned long long to avoid overflow?

It'd be enough to share i_gc_failure between the types, IMO.

> 
> enum {
>   GC_FAILURE_PIN,
>   GC_FAILURE_ATOMIC,
>   MAX_GC_FAILURE
> }
> 
> Thanks,
> 
> > 
> >>
> >> Now, we will detect failure due to atomic write in foreground GC, if
> >> the count exceeds threshold, we will drop all atomic written data in
> >> cache, by this, I expect it can keep our system running safely to
> >> prevent Dos attack.
> >>
> >> In addition, his patch adds to show GC skip information in debugfs,
> >> now it just shows count of skipped caused by atomic write.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >> v2:
> >> - add to show skip info in debugfs.
> >>  fs/f2fs/debug.c   |  8 
> >>  fs/f2fs/f2fs.h|  2 ++
> >>  fs/f2fs/file.c|  5 +
> >>  fs/f2fs/gc.c  | 29 +
> >>  fs/f2fs/gc.h  |  3 +++
> >>  fs/f2fs/segment.c |  1 +
> >>  fs/f2fs/segment.h |  2 ++
> >>  7 files changed, 46 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >> index 0fbd674c66fb..607b258a9b61 100644
> >> --- a/fs/f2fs/debug.c
> >> +++ b/fs/f2fs/debug.c
> >> @@ -104,6 +104,10 @@ static void update_general_status(struct f2fs_sb_info 
> >> *sbi)
> >>si->avail_nids = NM_I(sbi)->available_nids;
> >>si->alloc_nids = NM_I(sbi)->nid_cnt[PREALLOC_NID];
> >>si->bg_gc = sbi->bg_gc;
> >> +  si->skipped_atomic_files[BG_GC] =
> >> +  sbi->gc_thread->skipped_atomic_files[BG_GC];
> >> +  si->skipped_atomic_files[FG_GC] =
> >> +  sbi->gc_thread->skipped_atomic_files[FG_GC];
> >>si->util_free = (int)(free_user_blocks(sbi) >> sbi->log_blocks_per_seg)
> >>* 100 / (int)(sbi->user_block_count >> sbi->log_blocks_per_seg)
> >>/ 2;
> >> @@ -341,6 +345,10 @@ static int stat_show(struct seq_file *s, void *v)
> >>si->bg_data_blks);
> >>seq_printf(s, "  - node blocks : %d (%d)\n", si->node_blks,
> >>si->bg_node_blks);
> >> +  seq_printf(s, "Skipped : atomic write %llu (%llu)\n",
> >> +  si->skipped_atomic_files[BG_GC] +
> >> +  si->skipped_atomic_files[FG_GC],
> >> +  si->skipped_atomic_files[BG_GC]);
> >>seq_puts(s, "\nExtent Cache:\n");
> >>seq_printf(s, "  - Hit Count: L1-1:%llu L1-2:%llu L2:%llu\n",
> >>si->hit_largest, si->hit_cached,
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 75d3b4875429..c2b92cb377c6 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -2254,6 +2254,7 @@ enum {
> >>FI_EXTRA_ATTR,  /* indicate file has extra attribute */
> >>FI_PROJ_INHERIT,/* indicate file inherits projectid */
> >>FI_PIN_FILE,/* indicate file should not be gced */
> >> +  FI_ATOMIC_REVOKE_REQUEST,/* indicate atomic committed data has been 
> >> dropped */
> >>  };
> >>  
> >>  static inline void __mark_inode_dirty_flag(struct inode *inode,
> >> @@ -3010,6 +3011,7 @@ struct f2fs_stat_info {
> >>int bg_node_segs, bg_data_segs;
> >>int tot_blks, data_blks, node_blks;
> >>int bg_data_blks, bg_node_blks;
> >> +  unsigned long long skipped_atomic_files[2];
> >>int curseg[NR_CURSEG_TYPE];
> >>int cursec[NR_CURSEG_TYPE];
> >>int curzone[NR_CURSEG_TYPE];
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index a352804af244..0cfa65c21d3f 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -1702,6 +1702,7 @@ static int f2fs_ioc_start_atomic_write(struct file 
> >> *filp)
> >>  skip_flush:
> >>set_inode_flag(inode, FI_HOT_DATA);
> >>set_inode_flag(inode, FI_ATOMIC_FILE);
> >> +  clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> >>f2fs_update_time(F2FS_I_SB(inode), REQ_TIME);
> >>  
> >>F2FS_I(inode)->inmem_task = current;
> >> @@ -1750,6 +1751,10 @@ static int f2fs_ioc_commit_atomic_write(struct file 
> >> *filp)
> >>ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 1, false);
> >>}
> >>  err_out:
> >> +  if (is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST)) {
> >> +  clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> >> +  ret = -EINVAL;
> >> +  }
> >>

Re: [PATCH v2] f2fs: avoid stucking GC due to atomic write

[Jaegeuk Kim]

On 04/27, Chao Yu wrote:
> On 2018/4/26 23:54, Jaegeuk Kim wrote:
> > On 04/24, Chao Yu wrote:
> >> f2fs doesn't allow abuse on atomic write class interface, so except
> >> limiting in-mem pages' total memory usage capacity, we need to limit
> >> atomic-write usage as well when filesystem is seriously fragmented,
> >> otherwise we may run into infinite loop during foreground GC because
> >> target blocks in victim segment are belong to atomic opened file for
> >> long time.
> > 
> > How about using fi->i_gc_failure likewise pin_file?
> 
> OK, how about changing it to array fi->i_gc_failure[MAX_GC_FAILURE], and 
> change
> the type to unsigned long long to avoid overflow?

It'd be enough to share i_gc_failure between the types, IMO.

> 
> enum {
>   GC_FAILURE_PIN,
>   GC_FAILURE_ATOMIC,
>   MAX_GC_FAILURE
> }
> 
> Thanks,
> 
> > 
> >>
> >> Now, we will detect failure due to atomic write in foreground GC, if
> >> the count exceeds threshold, we will drop all atomic written data in
> >> cache, by this, I expect it can keep our system running safely to
> >> prevent Dos attack.
> >>
> >> In addition, his patch adds to show GC skip information in debugfs,
> >> now it just shows count of skipped caused by atomic write.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >> v2:
> >> - add to show skip info in debugfs.
> >>  fs/f2fs/debug.c   |  8 
> >>  fs/f2fs/f2fs.h|  2 ++
> >>  fs/f2fs/file.c|  5 +
> >>  fs/f2fs/gc.c  | 29 +
> >>  fs/f2fs/gc.h  |  3 +++
> >>  fs/f2fs/segment.c |  1 +
> >>  fs/f2fs/segment.h |  2 ++
> >>  7 files changed, 46 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> >> index 0fbd674c66fb..607b258a9b61 100644
> >> --- a/fs/f2fs/debug.c
> >> +++ b/fs/f2fs/debug.c
> >> @@ -104,6 +104,10 @@ static void update_general_status(struct f2fs_sb_info 
> >> *sbi)
> >>si->avail_nids = NM_I(sbi)->available_nids;
> >>si->alloc_nids = NM_I(sbi)->nid_cnt[PREALLOC_NID];
> >>si->bg_gc = sbi->bg_gc;
> >> +  si->skipped_atomic_files[BG_GC] =
> >> +  sbi->gc_thread->skipped_atomic_files[BG_GC];
> >> +  si->skipped_atomic_files[FG_GC] =
> >> +  sbi->gc_thread->skipped_atomic_files[FG_GC];
> >>si->util_free = (int)(free_user_blocks(sbi) >> sbi->log_blocks_per_seg)
> >>* 100 / (int)(sbi->user_block_count >> sbi->log_blocks_per_seg)
> >>/ 2;
> >> @@ -341,6 +345,10 @@ static int stat_show(struct seq_file *s, void *v)
> >>si->bg_data_blks);
> >>seq_printf(s, "  - node blocks : %d (%d)\n", si->node_blks,
> >>si->bg_node_blks);
> >> +  seq_printf(s, "Skipped : atomic write %llu (%llu)\n",
> >> +  si->skipped_atomic_files[BG_GC] +
> >> +  si->skipped_atomic_files[FG_GC],
> >> +  si->skipped_atomic_files[BG_GC]);
> >>seq_puts(s, "\nExtent Cache:\n");
> >>seq_printf(s, "  - Hit Count: L1-1:%llu L1-2:%llu L2:%llu\n",
> >>si->hit_largest, si->hit_cached,
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 75d3b4875429..c2b92cb377c6 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -2254,6 +2254,7 @@ enum {
> >>FI_EXTRA_ATTR,  /* indicate file has extra attribute */
> >>FI_PROJ_INHERIT,/* indicate file inherits projectid */
> >>FI_PIN_FILE,/* indicate file should not be gced */
> >> +  FI_ATOMIC_REVOKE_REQUEST,/* indicate atomic committed data has been 
> >> dropped */
> >>  };
> >>  
> >>  static inline void __mark_inode_dirty_flag(struct inode *inode,
> >> @@ -3010,6 +3011,7 @@ struct f2fs_stat_info {
> >>int bg_node_segs, bg_data_segs;
> >>int tot_blks, data_blks, node_blks;
> >>int bg_data_blks, bg_node_blks;
> >> +  unsigned long long skipped_atomic_files[2];
> >>int curseg[NR_CURSEG_TYPE];
> >>int cursec[NR_CURSEG_TYPE];
> >>int curzone[NR_CURSEG_TYPE];
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index a352804af244..0cfa65c21d3f 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -1702,6 +1702,7 @@ static int f2fs_ioc_start_atomic_write(struct file 
> >> *filp)
> >>  skip_flush:
> >>set_inode_flag(inode, FI_HOT_DATA);
> >>set_inode_flag(inode, FI_ATOMIC_FILE);
> >> +  clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> >>f2fs_update_time(F2FS_I_SB(inode), REQ_TIME);
> >>  
> >>F2FS_I(inode)->inmem_task = current;
> >> @@ -1750,6 +1751,10 @@ static int f2fs_ioc_commit_atomic_write(struct file 
> >> *filp)
> >>ret = f2fs_do_sync_file(filp, 0, LLONG_MAX, 1, false);
> >>}
> >>  err_out:
> >> +  if (is_inode_flag_set(inode, FI_ATOMIC_REVOKE_REQUEST)) {
> >> +  clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
> >> +  ret = -EINVAL;
> >> +  }
> >>up_write(_I(inode)->dio_rwsem[WRITE]);
> >> 

Re: general protection fault in fuse_ctl_remove_conn

[Tetsuo Handa]

>From 9f41081f8bd6762a6f629e5e23e6d07a62bba69c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Sat, 28 Apr 2018 11:24:09 +0900
Subject: [PATCH] fuse: don't keep inode-less dentry at fuse_ctl_add_dentry().

syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1].
Since fc->ctl_ndents is incremented by fuse_ctl_add_conn() when new_inode()
failed, fuse_ctl_remove_conn() reaches an inode-less dentry and tries to
clear d_inode(dentry)->i_private field. Fix this by calling dput() rather
than incrementing fc->ctl_ndents when new_inode() failed.

[1] 
https://syzkaller.appspot.com/bug?id=f396d863067238959c91c0b7cfc10b163638cac6

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Fixes: bafa96541b250a70 ("fuse: add control filesystem")
Cc: Miklos Szeredi 
---
 fs/fuse/control.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/control.c b/fs/fuse/control.c
index b9ea99c..a651f8e 100644
--- a/fs/fuse/control.c
+++ b/fs/fuse/control.c
@@ -211,10 +211,12 @@ static struct dentry *fuse_ctl_add_dentry(struct dentry 
*parent,
if (!dentry)
return NULL;
 
-   fc->ctl_dentry[fc->ctl_ndents++] = dentry;
inode = new_inode(fuse_control_sb);
-   if (!inode)
+   if (!inode) {
+   dput(dentry);
return NULL;
+   }
+   fc->ctl_dentry[fc->ctl_ndents++] = dentry;
 
inode->i_ino = get_next_ino();
inode->i_mode = mode;
-- 
1.8.3.1

Re: general protection fault in fuse_ctl_remove_conn

[Tetsuo Handa]

>From 9f41081f8bd6762a6f629e5e23e6d07a62bba69c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Sat, 28 Apr 2018 11:24:09 +0900
Subject: [PATCH] fuse: don't keep inode-less dentry at fuse_ctl_add_dentry().

syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1].
Since fc->ctl_ndents is incremented by fuse_ctl_add_conn() when new_inode()
failed, fuse_ctl_remove_conn() reaches an inode-less dentry and tries to
clear d_inode(dentry)->i_private field. Fix this by calling dput() rather
than incrementing fc->ctl_ndents when new_inode() failed.

[1] 
https://syzkaller.appspot.com/bug?id=f396d863067238959c91c0b7cfc10b163638cac6

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Fixes: bafa96541b250a70 ("fuse: add control filesystem")
Cc: Miklos Szeredi 
---
 fs/fuse/control.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/fuse/control.c b/fs/fuse/control.c
index b9ea99c..a651f8e 100644
--- a/fs/fuse/control.c
+++ b/fs/fuse/control.c
@@ -211,10 +211,12 @@ static struct dentry *fuse_ctl_add_dentry(struct dentry 
*parent,
if (!dentry)
return NULL;
 
-   fc->ctl_dentry[fc->ctl_ndents++] = dentry;
inode = new_inode(fuse_control_sb);
-   if (!inode)
+   if (!inode) {
+   dput(dentry);
return NULL;
+   }
+   fc->ctl_dentry[fc->ctl_ndents++] = dentry;
 
inode->i_ino = get_next_ino();
inode->i_mode = mode;
-- 
1.8.3.1

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

[Jason Wang]

On 2018年04月28日 09:51, Kevin Easton wrote:

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote:

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote:

On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:

The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.

Signed-off-by: Kevin Easton 
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com

Does it help if a patch naming the padding is applied,
and then we init just the relevant field?
Just curious.

No, I don't believe that is sufficient to fix the problem.

Scratch that, somehow I missed the "..and then we init just the
relevant field" part, sorry.

There's still the padding after the vhost_iotlb_msg to consider.  It's
named in the union but I don't think that's guaranteed to be initialised
when the iotlb member of the union is used to initialise things.


I didn't name the padding in my original patch because I wasn't sure
if the padding actually exists on 32 bit architectures?

This might still be a conce


Yes.

print &((struct vhost_msg *)0)->iotlb
$3 = (struct vhost_iotlb_msg *) 0x4




At the end of the day, zeroing 96 bytes (the full size of vhost_msg_node)
is pretty quick.

 - Kevin


Right, and even if it may be used heavily in the data-path, zeroing is 
not the main delay in that path.


Thanks

Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node

[Jason Wang]

On 2018年04月28日 09:51, Kevin Easton wrote:

On Fri, Apr 27, 2018 at 09:07:56PM -0400, Kevin Easton wrote:

On Fri, Apr 27, 2018 at 07:05:45PM +0300, Michael S. Tsirkin wrote:

On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:

The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.

Signed-off-by: Kevin Easton 
Reported-by: syzbot+87cfa083e727a2247...@syzkaller.appspotmail.com

Does it help if a patch naming the padding is applied,
and then we init just the relevant field?
Just curious.

No, I don't believe that is sufficient to fix the problem.

Scratch that, somehow I missed the "..and then we init just the
relevant field" part, sorry.

There's still the padding after the vhost_iotlb_msg to consider.  It's
named in the union but I don't think that's guaranteed to be initialised
when the iotlb member of the union is used to initialise things.


I didn't name the padding in my original patch because I wasn't sure
if the padding actually exists on 32 bit architectures?

This might still be a conce


Yes.

print &((struct vhost_msg *)0)->iotlb
$3 = (struct vhost_iotlb_msg *) 0x4




At the end of the day, zeroing 96 bytes (the full size of vhost_msg_node)
is pretty quick.

 - Kevin


Right, and even if it may be used heavily in the data-path, zeroing is 
not the main delay in that path.


Thanks

[PATCH v2 0/2] net: stmmac: dwmac-meson: 100M phy mode support for AXG SoC

[Yixun Lan]

Due to the dwmac glue layer register changed, we need to 
introduce a new compatible name for the Meson-AXG SoC
to support for the RMII 100M ethernet PHY.

Change since v1 at [1]:
  - implement set_phy_mode() for each SoC

[1] https://lkml.kernel.org/r/20180426160508.29380-1-yixun@amlogic.com

Yixun Lan (2):
  dt-bindings: net: meson-dwmac: new compatible name for AXG SoC
  net: stmmac: dwmac-meson: extend phy mode setting

 .../devicetree/bindings/net/meson-dwmac.txt   |   1 +
 .../ethernet/stmicro/stmmac/dwmac-meson8b.c   | 120 +++---
 2 files changed, 105 insertions(+), 16 deletions(-)

-- 
2.17.0

[PATCH v2 1/2] dt-bindings: net: meson-dwmac: new compatible name for AXG SoC

[Yixun Lan]

We need to introduce a new compatible name for the Meson-AXG SoC
in order to support the RMII 100M ethernet PHY, since the PRG_ETH0
register of the dwmac glue layer is changed from previous old SoC.

Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/net/meson-dwmac.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt 
b/Documentation/devicetree/bindings/net/meson-dwmac.txt
index 61cada22ae6c..1321bb194ed9 100644
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -11,6 +11,7 @@ Required properties on all platforms:
- "amlogic,meson8b-dwmac"
- "amlogic,meson8m2-dwmac"
- "amlogic,meson-gxbb-dwmac"
+   - "amlogic,meson-axg-dwmac"
Additionally "snps,dwmac" and any applicable more
detailed version number described in net/stmmac.txt
should be used.
-- 
2.17.0