[PATCH] perf lock: subcommands should include common options

[changbin . du]

From: Changbin Du 

When I use -i option for report subcommand, it doesn't accept it.
We need add common options using OPT_PARENT macro.

perf lock report -i lock_perf.data
  Error: unknown switch `i'

  Usage: perf lock report []

-f, --force   don't complain, do it
-k, --key   key for sorting ...

Signed-off-by: Changbin Du 
---
 tools/perf/builtin-lock.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index ce3bfb4..710c551 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -947,27 +947,30 @@ static int __cmd_record(int argc, const char **argv)
 
 int cmd_lock(int argc, const char **argv, const char *prefix __maybe_unused)
 {
+   const struct option lock_options[] = {
+   OPT_STRING('i', "input", _name, "file", "input file name"),
+   OPT_INCR('v', "verbose", , "be more verbose (show symbol 
address, etc)"),
+   OPT_BOOLEAN('D', "dump-raw-trace", _trace, "dump raw trace in 
ASCII"),
+   OPT_END()
+   };
+
const struct option info_options[] = {
OPT_BOOLEAN('t', "threads", _threads,
"dump thread list in perf.data"),
OPT_BOOLEAN('m', "map", _map,
"map of lock instances (address:name table)"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
-   OPT_END()
-   };
-   const struct option lock_options[] = {
-   OPT_STRING('i', "input", _name, "file", "input file name"),
-   OPT_INCR('v', "verbose", , "be more verbose (show symbol 
address, etc)"),
-   OPT_BOOLEAN('D', "dump-raw-trace", _trace, "dump raw trace in 
ASCII"),
-   OPT_END()
+   OPT_PARENT(lock_options)
};
+
const struct option report_options[] = {
OPT_STRING('k', "key", _key, "acquired",
"key for sorting (acquired / contended / avg_wait / 
wait_total / wait_max / wait_min)"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
/* TODO: type */
-   OPT_END()
+   OPT_PARENT(lock_options)
};
+
const char * const info_usage[] = {
"perf lock info []",
NULL
-- 
2.7.4

[PATCH] perf lock: subcommands should include common options

[changbin . du]

From: Changbin Du 

When I use -i option for report subcommand, it doesn't accept it.
We need add common options using OPT_PARENT macro.

perf lock report -i lock_perf.data
  Error: unknown switch `i'

  Usage: perf lock report []

-f, --force   don't complain, do it
-k, --key   key for sorting ...

Signed-off-by: Changbin Du 
---
 tools/perf/builtin-lock.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index ce3bfb4..710c551 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -947,27 +947,30 @@ static int __cmd_record(int argc, const char **argv)
 
 int cmd_lock(int argc, const char **argv, const char *prefix __maybe_unused)
 {
+   const struct option lock_options[] = {
+   OPT_STRING('i', "input", _name, "file", "input file name"),
+   OPT_INCR('v', "verbose", , "be more verbose (show symbol 
address, etc)"),
+   OPT_BOOLEAN('D', "dump-raw-trace", _trace, "dump raw trace in 
ASCII"),
+   OPT_END()
+   };
+
const struct option info_options[] = {
OPT_BOOLEAN('t', "threads", _threads,
"dump thread list in perf.data"),
OPT_BOOLEAN('m', "map", _map,
"map of lock instances (address:name table)"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
-   OPT_END()
-   };
-   const struct option lock_options[] = {
-   OPT_STRING('i', "input", _name, "file", "input file name"),
-   OPT_INCR('v', "verbose", , "be more verbose (show symbol 
address, etc)"),
-   OPT_BOOLEAN('D', "dump-raw-trace", _trace, "dump raw trace in 
ASCII"),
-   OPT_END()
+   OPT_PARENT(lock_options)
};
+
const struct option report_options[] = {
OPT_STRING('k', "key", _key, "acquired",
"key for sorting (acquired / contended / avg_wait / 
wait_total / wait_max / wait_min)"),
OPT_BOOLEAN('f', "force", , "don't complain, do it"),
/* TODO: type */
-   OPT_END()
+   OPT_PARENT(lock_options)
};
+
const char * const info_usage[] = {
"perf lock info []",
NULL
-- 
2.7.4

[PATCH V4 2/4] dt-bindings: arm: Add bindings for SP9860G

[Chunyan Zhang]

Added bindings for Spreadtrum SP9860G board and SC9860 SoC.
This patch also revised bindings of SC9836 to make the format
more clear.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/arm/sprd.txt | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sprd.txt 
b/Documentation/devicetree/bindings/arm/sprd.txt
index 31a629d..3df034b 100644
--- a/Documentation/devicetree/bindings/arm/sprd.txt
+++ b/Documentation/devicetree/bindings/arm/sprd.txt
@@ -1,11 +1,14 @@
 Spreadtrum SoC Platforms Device Tree Bindings
 
 
-Sharkl64 is a Spreadtrum's SoC Platform which is based
-on ARM 64-bit processor.
+SC9836 openphone Board
+Required root node properties:
+   - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
 
-SC9836 openphone board with SC9836 SoC based on the
-Sharkl64 Platform shall have the following properties.
+SC9860 SoC
+Required root node properties:
+   - compatible = "sprd,sc9860"
 
+SP9860G 3GFHD Board
 Required root node properties:
-- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+   - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
-- 
2.7.4

[PATCH V4 4/4] serial: sprd: adjust TIMEOUT to a big value

[Chunyan Zhang]

From: Wei Qiao 

SPRD_TIMEOUT was 256, which is too small to wait until the status
switched to workable in a while loop, so that the earlycon could
not work correctly.

Signed-off-by: Wei Qiao 
Signed-off-by: Chunyan Zhang 
---
 drivers/tty/serial/sprd_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index d98e3dc..90996ad 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -36,7 +36,7 @@
 #define SPRD_FIFO_SIZE 128
 #define SPRD_DEF_RATE  2600
 #define SPRD_BAUD_IO_LIMIT 300
-#define SPRD_TIMEOUT   256
+#define SPRD_TIMEOUT   256000
 
 /* the offset of serial registers and BITs for them */
 /* data registers */
-- 
2.7.4

[PATCH V4 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
Reviewed-by: Mathieu Poirier 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 569 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
 4 files changed, 698 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..cf72728
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+ 

[PATCH V4 0/4] Add Spreadtrum SP9860G support

[Chunyan Zhang]

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided
into 4 Big cores and 4 little cores.

This patch-set provides a basic configuration for SC9860 in device tree
to make it run to console.  After this we will continue to submit other
device drivers step by step, which are using on most of Spreadtrum's SoCs.

Changes from v3:
* Rebased v4.11-rc2;
* Added Reviewed-by of Mathieu;
* Addressed Rob's comments:
  - Documented sprd serial competible according to Rob's suggestion
  - Revised serial node name to match its offset;
* Added STM device node in dt.

Changes from v2:
* Addressed comments from Mathieu:
  - Removed CoreSight devices' lables from DT;
  - Added another level of imbrication for ETFs which have more than one port;
* Addressed comments from Rob:
  - Switched to use SPDX-License-Identifier tag instead;
  - Moved the 26m fixed clock node to top level in DT;
  - Splited the patch into two, since they were revising two dt-bindings;
  - Removed redundant space from sprd-usrt.txt;
  - Removed useless property from the sprd_uart example of DT configuration.

Changes from v1:
* Removed useless idle-state node 'deep_sleep' from DT
* Removed useless property 'sc-id' from DT
* Removed 'clock-frequency' property from the node 'timer'
* Added another compatible string '"arm,cortex-a53-pmu"' and property
  'interrupt-affinity' for pmu
* Kept using the existed compatible string of sprd_serial driver, and added
  a new one for sc9860 in DT.

Thanks,
Chunyan

Chunyan Zhang (2):
  dt-bindings: arm: Add bindings for SP9860G
  dt-bindings: serial: add a new compatible string for SC9860

Orson Zhai (1):
  arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Wei Qiao (1):
  serial: sprd: adjust TIMEOUT to a big value

 Documentation/devicetree/bindings/arm/sprd.txt |  13 +-
 .../devicetree/bindings/serial/sprd-uart.txt   |  14 +-
 arch/arm64/boot/dts/sprd/Makefile  |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   | 569 +
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts  |  56 ++
 arch/arm64/boot/dts/sprd/whale2.dtsi   |  71 +++
 drivers/tty/serial/sprd_serial.c   |   2 +-
 7 files changed, 720 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

-- 
2.7.4

[PATCH V4 2/4] dt-bindings: arm: Add bindings for SP9860G

[Chunyan Zhang]

Added bindings for Spreadtrum SP9860G board and SC9860 SoC.
This patch also revised bindings of SC9836 to make the format
more clear.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/arm/sprd.txt | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sprd.txt 
b/Documentation/devicetree/bindings/arm/sprd.txt
index 31a629d..3df034b 100644
--- a/Documentation/devicetree/bindings/arm/sprd.txt
+++ b/Documentation/devicetree/bindings/arm/sprd.txt
@@ -1,11 +1,14 @@
 Spreadtrum SoC Platforms Device Tree Bindings
 
 
-Sharkl64 is a Spreadtrum's SoC Platform which is based
-on ARM 64-bit processor.
+SC9836 openphone Board
+Required root node properties:
+   - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
 
-SC9836 openphone board with SC9836 SoC based on the
-Sharkl64 Platform shall have the following properties.
+SC9860 SoC
+Required root node properties:
+   - compatible = "sprd,sc9860"
 
+SP9860G 3GFHD Board
 Required root node properties:
-- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+   - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
-- 
2.7.4

[PATCH V4 4/4] serial: sprd: adjust TIMEOUT to a big value

[Chunyan Zhang]

From: Wei Qiao 

SPRD_TIMEOUT was 256, which is too small to wait until the status
switched to workable in a while loop, so that the earlycon could
not work correctly.

Signed-off-by: Wei Qiao 
Signed-off-by: Chunyan Zhang 
---
 drivers/tty/serial/sprd_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index d98e3dc..90996ad 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -36,7 +36,7 @@
 #define SPRD_FIFO_SIZE 128
 #define SPRD_DEF_RATE  2600
 #define SPRD_BAUD_IO_LIMIT 300
-#define SPRD_TIMEOUT   256
+#define SPRD_TIMEOUT   256000
 
 /* the offset of serial registers and BITs for them */
 /* data registers */
-- 
2.7.4

[PATCH V4 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
Reviewed-by: Mathieu Poirier 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 569 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
 4 files changed, 698 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..cf72728
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530102>;

[PATCH V4 0/4] Add Spreadtrum SP9860G support

[Chunyan Zhang]

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided
into 4 Big cores and 4 little cores.

This patch-set provides a basic configuration for SC9860 in device tree
to make it run to console.  After this we will continue to submit other
device drivers step by step, which are using on most of Spreadtrum's SoCs.

Changes from v3:
* Rebased v4.11-rc2;
* Added Reviewed-by of Mathieu;
* Addressed Rob's comments:
  - Documented sprd serial competible according to Rob's suggestion
  - Revised serial node name to match its offset;
* Added STM device node in dt.

Changes from v2:
* Addressed comments from Mathieu:
  - Removed CoreSight devices' lables from DT;
  - Added another level of imbrication for ETFs which have more than one port;
* Addressed comments from Rob:
  - Switched to use SPDX-License-Identifier tag instead;
  - Moved the 26m fixed clock node to top level in DT;
  - Splited the patch into two, since they were revising two dt-bindings;
  - Removed redundant space from sprd-usrt.txt;
  - Removed useless property from the sprd_uart example of DT configuration.

Changes from v1:
* Removed useless idle-state node 'deep_sleep' from DT
* Removed useless property 'sc-id' from DT
* Removed 'clock-frequency' property from the node 'timer'
* Added another compatible string '"arm,cortex-a53-pmu"' and property
  'interrupt-affinity' for pmu
* Kept using the existed compatible string of sprd_serial driver, and added
  a new one for sc9860 in DT.

Thanks,
Chunyan

Chunyan Zhang (2):
  dt-bindings: arm: Add bindings for SP9860G
  dt-bindings: serial: add a new compatible string for SC9860

Orson Zhai (1):
  arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Wei Qiao (1):
  serial: sprd: adjust TIMEOUT to a big value

 Documentation/devicetree/bindings/arm/sprd.txt |  13 +-
 .../devicetree/bindings/serial/sprd-uart.txt   |  14 +-
 arch/arm64/boot/dts/sprd/Makefile  |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   | 569 +
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts  |  56 ++
 arch/arm64/boot/dts/sprd/whale2.dtsi   |  71 +++
 drivers/tty/serial/sprd_serial.c   |   2 +-
 7 files changed, 720 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

-- 
2.7.4

[PATCH V4 3/4] dt-bindings: serial: add a new compatible string for SC9860

[Chunyan Zhang]

SC9860 use the same serial device which SC9836 uses, so added a new
compatible string to support SC9860 as well, also added an example
of how to describe this serial device in DT.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/serial/sprd-uart.txt | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index 2aff0f2..1db5d6f 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -1,7 +1,19 @@
 * Spreadtrum serial UART
 
 Required properties:
-- compatible: must be "sprd,sc9836-uart"
+- compatible: must be one of:
+  * "sprd,sc9836-uart"
+  * "sprd,sc9860-uart", "sprd,sc9836-uart"
+
 - reg: offset and length of the register set for the device
 - interrupts: exactly one interrupt specifier
 - clocks: phandles to input clocks.
+
+Example:
+   uart0: serial@00 {
+   compatible = "sprd,sc9860-uart",
+"sprd,sc9836-uart";
+   reg = <0x00 0x100>;
+   interrupts = ;
+   clocks = <_26m>;
+   };
-- 
2.7.4

[PATCH V4 3/4] dt-bindings: serial: add a new compatible string for SC9860

[Chunyan Zhang]

SC9860 use the same serial device which SC9836 uses, so added a new
compatible string to support SC9860 as well, also added an example
of how to describe this serial device in DT.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/serial/sprd-uart.txt | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index 2aff0f2..1db5d6f 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -1,7 +1,19 @@
 * Spreadtrum serial UART
 
 Required properties:
-- compatible: must be "sprd,sc9836-uart"
+- compatible: must be one of:
+  * "sprd,sc9836-uart"
+  * "sprd,sc9860-uart", "sprd,sc9836-uart"
+
 - reg: offset and length of the register set for the device
 - interrupts: exactly one interrupt specifier
 - clocks: phandles to input clocks.
+
+Example:
+   uart0: serial@00 {
+   compatible = "sprd,sc9860-uart",
+"sprd,sc9836-uart";
+   reg = <0x00 0x100>;
+   interrupts = ;
+   clocks = <_26m>;
+   };
-- 
2.7.4

[PATCH] PM / Domain: remove conditional from error case

[Viresh Kumar]

There is no point running the conditional 'if' statement if the genpd
isn't present.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 202effbebfd1..03dd7a61f08a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1789,12 +1789,12 @@ int of_genpd_add_provider_simple(struct device_node *np,
 
mutex_lock(_list_lock);
 
-   if (pm_genpd_present(genpd))
+   if (pm_genpd_present(genpd)) {
ret = genpd_add_provider(np, genpd_xlate_simple, genpd);
-
-   if (!ret) {
-   genpd->provider = >fwnode;
-   genpd->has_provider = true;
+   if (!ret) {
+   genpd->provider = >fwnode;
+   genpd->has_provider = true;
+   }
}
 
mutex_unlock(_list_lock);
-- 
2.12.0.432.g71c3a4f4ba37

[PATCH] PM / Domain: remove conditional from error case

[Viresh Kumar]

There is no point running the conditional 'if' statement if the genpd
isn't present.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 202effbebfd1..03dd7a61f08a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1789,12 +1789,12 @@ int of_genpd_add_provider_simple(struct device_node *np,
 
mutex_lock(_list_lock);
 
-   if (pm_genpd_present(genpd))
+   if (pm_genpd_present(genpd)) {
ret = genpd_add_provider(np, genpd_xlate_simple, genpd);
-
-   if (!ret) {
-   genpd->provider = >fwnode;
-   genpd->has_provider = true;
+   if (!ret) {
+   genpd->provider = >fwnode;
+   genpd->has_provider = true;
+   }
}
 
mutex_unlock(_list_lock);
-- 
2.12.0.432.g71c3a4f4ba37

Re: [PATCH] ext4: Add statx support

[Eric Biggers]

Hi David,

On Thu, Mar 16, 2017 at 11:35:33AM +, David Howells wrote:
> +
> + ext4_get_inode_flags(ei);
> + flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
> + if (flags & EXT4_APPEND_FL)
> + stat->attributes |= STATX_ATTR_APPEND;
> + if (flags & EXT4_COMPR_FL)
> + stat->attributes |= STATX_ATTR_COMPRESSED;
> + if (flags & EXT4_ENCRYPT_FL)
> + stat->attributes |= STATX_ATTR_ENCRYPTED;
> + if (flags & EXT4_IMMUTABLE_FL)
> + stat->attributes |= STATX_ATTR_IMMUTABLE;
> + if (flags & EXT4_NODUMP_FL)
> + stat->attributes |= STATX_ATTR_NODUMP;
>  
> - inode = d_inode(path->dentry);
>   generic_fillattr(inode, stat);
> + return 0;
> +}

I think it's the wrong approach to be calling ext4_get_inode_flags() here to
sync the generic inode flags (inode->i_flags) to the ext4-specific inode flags
(ei->i_flags).  I know the GETFLAGS and FSGETXATTR ioctls do it too, but I think
it's a mistake --- at least, when done so without holding the inode lock.  The
issue is that flag syncs can occur in both directions concurrently and cause an
update to be lost.  For example, with thread 1 doing a stat() and thread 2 doing
the SETFLAGS ioctl to set the APPEND flag:

Thread 1, in ext4_get_inode_flags() Thread 2, in 
ext4_ioctl_setflags()
---
---

Read inode->i_flags; S_APPEND is clear  
Set EXT4_APPEND_FL in 
ei->i_flags
Clear EXT4_APPEND_FL in ei->i_flags
Read ei->i_flags; 
EXT4_APPEND_FL is clear
Clear S_APPEND in inode->i_flags

So the flag set by SETFLAGS gets lost.  This bug probably hasn't really been
noticable with GETFLAGS and FSGETXATTR since they're rarely used, but stat() on
the other hand is very common, and I'm worried that with this change people
would start seeing this race more often.

Ultimately this needs to be addressed in ext4 more fully, but how about for
->getattr() just skipping the call to ext4_get_inode_flags() and instead
populating the generic attributes like STATX_ATTR_APPEND and
STATX_ATTR_IMMUTABLE from the generic inode flags, rather than from the
ext4-specific flags?  Actually, it could even be done in generic_fillattr(), so
that all filesystems benefit.

> diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
> index 73b184d161fc..4c6b23a0603e 100644
> --- a/fs/ext4/symlink.c
> +++ b/fs/ext4/symlink.c
> @@ -91,11 +91,13 @@ const struct inode_operations 
> ext4_encrypted_symlink_inode_operations = {
>  const struct inode_operations ext4_symlink_inode_operations = {
>   .get_link   = page_get_link,
>   .setattr= ext4_setattr,
> + .getattr= ext4_getattr,
>   .listxattr  = ext4_listxattr,
>  };
>  
>  const struct inode_operations ext4_fast_symlink_inode_operations = {
>   .get_link   = simple_get_link,
>   .setattr= ext4_setattr,
> + .getattr= ext4_getattr,
>   .listxattr  = ext4_listxattr,
>  };
> 

getattr needs to be added to ext4_encrypted_symlink_inode_operations too.

- Eric

Re: [PATCH] ext4: Add statx support

[Eric Biggers]

Hi David,

On Thu, Mar 16, 2017 at 11:35:33AM +, David Howells wrote:
> +
> + ext4_get_inode_flags(ei);
> + flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
> + if (flags & EXT4_APPEND_FL)
> + stat->attributes |= STATX_ATTR_APPEND;
> + if (flags & EXT4_COMPR_FL)
> + stat->attributes |= STATX_ATTR_COMPRESSED;
> + if (flags & EXT4_ENCRYPT_FL)
> + stat->attributes |= STATX_ATTR_ENCRYPTED;
> + if (flags & EXT4_IMMUTABLE_FL)
> + stat->attributes |= STATX_ATTR_IMMUTABLE;
> + if (flags & EXT4_NODUMP_FL)
> + stat->attributes |= STATX_ATTR_NODUMP;
>  
> - inode = d_inode(path->dentry);
>   generic_fillattr(inode, stat);
> + return 0;
> +}

I think it's the wrong approach to be calling ext4_get_inode_flags() here to
sync the generic inode flags (inode->i_flags) to the ext4-specific inode flags
(ei->i_flags).  I know the GETFLAGS and FSGETXATTR ioctls do it too, but I think
it's a mistake --- at least, when done so without holding the inode lock.  The
issue is that flag syncs can occur in both directions concurrently and cause an
update to be lost.  For example, with thread 1 doing a stat() and thread 2 doing
the SETFLAGS ioctl to set the APPEND flag:

Thread 1, in ext4_get_inode_flags() Thread 2, in 
ext4_ioctl_setflags()
---
---

Read inode->i_flags; S_APPEND is clear  
Set EXT4_APPEND_FL in 
ei->i_flags
Clear EXT4_APPEND_FL in ei->i_flags
Read ei->i_flags; 
EXT4_APPEND_FL is clear
Clear S_APPEND in inode->i_flags

So the flag set by SETFLAGS gets lost.  This bug probably hasn't really been
noticable with GETFLAGS and FSGETXATTR since they're rarely used, but stat() on
the other hand is very common, and I'm worried that with this change people
would start seeing this race more often.

Ultimately this needs to be addressed in ext4 more fully, but how about for
->getattr() just skipping the call to ext4_get_inode_flags() and instead
populating the generic attributes like STATX_ATTR_APPEND and
STATX_ATTR_IMMUTABLE from the generic inode flags, rather than from the
ext4-specific flags?  Actually, it could even be done in generic_fillattr(), so
that all filesystems benefit.

> diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c
> index 73b184d161fc..4c6b23a0603e 100644
> --- a/fs/ext4/symlink.c
> +++ b/fs/ext4/symlink.c
> @@ -91,11 +91,13 @@ const struct inode_operations 
> ext4_encrypted_symlink_inode_operations = {
>  const struct inode_operations ext4_symlink_inode_operations = {
>   .get_link   = page_get_link,
>   .setattr= ext4_setattr,
> + .getattr= ext4_getattr,
>   .listxattr  = ext4_listxattr,
>  };
>  
>  const struct inode_operations ext4_fast_symlink_inode_operations = {
>   .get_link   = simple_get_link,
>   .setattr= ext4_setattr,
> + .getattr= ext4_getattr,
>   .listxattr  = ext4_listxattr,
>  };
> 

getattr needs to be added to ext4_encrypted_symlink_inode_operations too.

- Eric

Re: [rtc] 4cd8adb100: WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 kobject_put

[Logan Gunthorpe]

Hey,

I think I see the issue here: in a couple of error conditions, the RTC
code will not initialize and ask for the cdev. However, my change will
always call cdev_add and cdev_del even though the rtc code did not call
cdev_init. I'll have to add a guard around dev->devt in the new
cdev_device functions. I'll prepare another patch tomorrow.

I also noticed that I neglected to remove the prototypes for the two RTC
function I removed. I'll fix that too.

Thanks,

Logan

On 16/03/17 10:57 PM, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
> char-misc-testing
> 
> commit 4cd8adb100107dc44e63615040ca2bde43de6167
> Author: Logan Gunthorpe 
> AuthorDate: Mon Mar 6 00:04:30 2017 -0700
> Commit: Greg Kroah-Hartman 
> CommitDate: Fri Mar 17 09:20:18 2017 +0900
> 
> rtc: utilize new cdev_device_add helper function
> 
> Mostly straightforward, but we had to remove the rtc_dev_add/del_device
> functions as they split up the cdev_add and the device_add.
> 
> Doing this also revealed that there was likely another subtle bug:
> seeing cdev_add was done after device_register, the cdev probably
> was not ready before device_add when the uevent occurs. This would
> race with userspace, if it tried to use the device directly after
> the uevent. This is fixed just by using the new helper function.
> 
> Signed-off-by: Logan Gunthorpe 
> Acked-by: Alexandre Belloni 
> Signed-off-by: Greg Kroah-Hartman 
> 
> c65bbfc122  rapidio: utilize new cdev_device_add helper function
> 4cd8adb100  rtc: utilize new cdev_device_add helper function
> 64d77f61c0  auxdisplay: Add HD44780 Character LCD support
> +-++++
> | | c65bbfc122 | 
> 4cd8adb100 | 64d77f61c0 |
> +-++++
> | boot_successes  | 4  | 0
>   | 0  |
> | boot_failures   | 55 | 26   
>   | 30 |
> | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 55 | 22   
>   | 24 |
> | WARNING:at_lib/kobject.c:#kobject_put   | 0  | 26   
>   | 30 |
> | WARNING:at_lib/refcount.c:#refcount_sub_and_test| 0  | 26   
>   | 30 |
> +-++++
> 
> [1.261325] input: AT Translated Set 2 keyboard as 
> /devices/platform/i8042/serio0/input/input1
> [1.263029] wistron_btns: System unknown
> [1.263411] usbcore: registered new interface driver yealink
> [1.264581] rtc-test rtc-test.0: rtc core: registered test as rtc0
> [1.265355] [ cut here ]
> [1.265798] WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 
> kobject_put+0x39/0x60
> [1.266539] kobject: '(null)' (cea81ab4): is not initialized, yet 
> kobject_put() is being called.
> [1.267291] Modules linked in:
> [1.267562] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.11.0-rc2-00049-g4cd8adb #834
> [1.268236] Call Trace:
> [1.268453]  dump_stack+0x76/0xa9
> [1.268740]  __warn+0xdb/0x100
> [1.269005]  ? kobject_put+0x39/0x60
> [1.269318]  warn_slowpath_fmt+0x36/0x40
> [1.269653]  kobject_put+0x39/0x60
> [1.269948]  cdev_del+0x1d/0x20
> [1.270224]  cdev_device_del+0x14/0x20
> [1.270548]  rtc_device_unregister+0x2a/0x50
> [1.270913]  devm_rtc_device_release+0xa/0x10
> [1.271291]  release_nodes+0x1e4/0x210
> [1.271613]  devres_release_all+0x51/0x60
> [1.271962]  driver_probe_device+0x237/0x480
> [1.272332]  ? klist_next+0x1b/0xc0
> [1.272633]  ? acpi_driver_match_device+0x49/0x62
> [1.273034]  __device_attach_driver+0xe8/0x110
> [1.273418]  ? klist_next+0x9d/0xc0
> [1.273718]  ? __driver_attach+0xf0/0xf0
> [1.274053]  bus_for_each_drv+0x44/0x80
> [1.274389]  __device_attach+0x9d/0x140
> [1.274718]  ? __driver_attach+0xf0/0xf0
> [1.275054]  device_initial_probe+0xd/0x10
> [1.275409]  bus_probe_device+0x25/0x80
> [1.275738]  device_add+0x3fc/0x5c0
> [1.276038]  ? kobject_set_name_vargs+0x7f/0xa0
> [1.276428]  platform_device_add+0x1d9/0x250
> [1.276793]  test_init+0x52/0xa6
> [1.277085]  ? stk17ta8_rtc_driver_init+0x11/0x11
> [1.277504]  do_one_initcall+0x92/0x160
> [1.277844]  ? parameq+0x13/0x70
> [1.278138]  ? repair_env_string+0x12/0x51
> [1.278500]  ? parse_args+0x325/0x470
> [1.278826]  ? __usermodehelper_set_disable_depth+0x3e/0x50
> [

Re: [rtc] 4cd8adb100: WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 kobject_put

[Logan Gunthorpe]

Hey,

I think I see the issue here: in a couple of error conditions, the RTC
code will not initialize and ask for the cdev. However, my change will
always call cdev_add and cdev_del even though the rtc code did not call
cdev_init. I'll have to add a guard around dev->devt in the new
cdev_device functions. I'll prepare another patch tomorrow.

I also noticed that I neglected to remove the prototypes for the two RTC
function I removed. I'll fix that too.

Thanks,

Logan

On 16/03/17 10:57 PM, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
> char-misc-testing
> 
> commit 4cd8adb100107dc44e63615040ca2bde43de6167
> Author: Logan Gunthorpe 
> AuthorDate: Mon Mar 6 00:04:30 2017 -0700
> Commit: Greg Kroah-Hartman 
> CommitDate: Fri Mar 17 09:20:18 2017 +0900
> 
> rtc: utilize new cdev_device_add helper function
> 
> Mostly straightforward, but we had to remove the rtc_dev_add/del_device
> functions as they split up the cdev_add and the device_add.
> 
> Doing this also revealed that there was likely another subtle bug:
> seeing cdev_add was done after device_register, the cdev probably
> was not ready before device_add when the uevent occurs. This would
> race with userspace, if it tried to use the device directly after
> the uevent. This is fixed just by using the new helper function.
> 
> Signed-off-by: Logan Gunthorpe 
> Acked-by: Alexandre Belloni 
> Signed-off-by: Greg Kroah-Hartman 
> 
> c65bbfc122  rapidio: utilize new cdev_device_add helper function
> 4cd8adb100  rtc: utilize new cdev_device_add helper function
> 64d77f61c0  auxdisplay: Add HD44780 Character LCD support
> +-++++
> | | c65bbfc122 | 
> 4cd8adb100 | 64d77f61c0 |
> +-++++
> | boot_successes  | 4  | 0
>   | 0  |
> | boot_failures   | 55 | 26   
>   | 30 |
> | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 55 | 22   
>   | 24 |
> | WARNING:at_lib/kobject.c:#kobject_put   | 0  | 26   
>   | 30 |
> | WARNING:at_lib/refcount.c:#refcount_sub_and_test| 0  | 26   
>   | 30 |
> +-++++
> 
> [1.261325] input: AT Translated Set 2 keyboard as 
> /devices/platform/i8042/serio0/input/input1
> [1.263029] wistron_btns: System unknown
> [1.263411] usbcore: registered new interface driver yealink
> [1.264581] rtc-test rtc-test.0: rtc core: registered test as rtc0
> [1.265355] [ cut here ]
> [1.265798] WARNING: CPU: 0 PID: 1 at lib/kobject.c:690 
> kobject_put+0x39/0x60
> [1.266539] kobject: '(null)' (cea81ab4): is not initialized, yet 
> kobject_put() is being called.
> [1.267291] Modules linked in:
> [1.267562] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.11.0-rc2-00049-g4cd8adb #834
> [1.268236] Call Trace:
> [1.268453]  dump_stack+0x76/0xa9
> [1.268740]  __warn+0xdb/0x100
> [1.269005]  ? kobject_put+0x39/0x60
> [1.269318]  warn_slowpath_fmt+0x36/0x40
> [1.269653]  kobject_put+0x39/0x60
> [1.269948]  cdev_del+0x1d/0x20
> [1.270224]  cdev_device_del+0x14/0x20
> [1.270548]  rtc_device_unregister+0x2a/0x50
> [1.270913]  devm_rtc_device_release+0xa/0x10
> [1.271291]  release_nodes+0x1e4/0x210
> [1.271613]  devres_release_all+0x51/0x60
> [1.271962]  driver_probe_device+0x237/0x480
> [1.272332]  ? klist_next+0x1b/0xc0
> [1.272633]  ? acpi_driver_match_device+0x49/0x62
> [1.273034]  __device_attach_driver+0xe8/0x110
> [1.273418]  ? klist_next+0x9d/0xc0
> [1.273718]  ? __driver_attach+0xf0/0xf0
> [1.274053]  bus_for_each_drv+0x44/0x80
> [1.274389]  __device_attach+0x9d/0x140
> [1.274718]  ? __driver_attach+0xf0/0xf0
> [1.275054]  device_initial_probe+0xd/0x10
> [1.275409]  bus_probe_device+0x25/0x80
> [1.275738]  device_add+0x3fc/0x5c0
> [1.276038]  ? kobject_set_name_vargs+0x7f/0xa0
> [1.276428]  platform_device_add+0x1d9/0x250
> [1.276793]  test_init+0x52/0xa6
> [1.277085]  ? stk17ta8_rtc_driver_init+0x11/0x11
> [1.277504]  do_one_initcall+0x92/0x160
> [1.277844]  ? parameq+0x13/0x70
> [1.278138]  ? repair_env_string+0x12/0x51
> [1.278500]  ? parse_args+0x325/0x470
> [1.278826]  ? __usermodehelper_set_disable_depth+0x3e/0x50
> [1.279318]  kernel_init_freeable+0xfb/0x19a
> [1.279696]  ? do_early_param+0x7a/0x7a
> [1.280036]  ? rest_init+0x130/0x130
> [   

Re: [PATCH] powerpc/pseries: Don't give a warning when HPT resizing isn't available

[Michael Ellerman]

David Gibson  writes:

> As of 438cc81a41 "powerpc/pseries: Automatically resize HPT for memory hot
> add/remove" when running on the pseries platform, we always attempt to
> use the PAPR extension to resize the hashed page table (HPT) when we add
> or remove memory.
>
> This is fine, but when the extension is available we'll give a harmless,
> but scary warning.  This patch suppresses the warning in this case.  It
> will still warn if the feature is supposed to be available, but didn't
> work.
>
> Signed-off-by: David Gibson 
> ---
>  arch/powerpc/mm/hash_utils_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Kind of cosmetic, but getting an error message on every memory hot
> plug/unplug attempt if your host doesn't support HPT resizing is
> pretty ugly.  So I think this is a candidate for quick inclusion.

Yeah thanks, I forgot I was going to send a patch for it.

I was thinking of doing the following instead, or maybe we can do both?

diff --git a/arch/powerpc/platforms/pseries/lpar.c 
b/arch/powerpc/platforms/pseries/lpar.c
index 251060cf1713..8b1fe895daa3 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -751,7 +751,9 @@ void __init hpte_init_pseries(void)
mmu_hash_ops.flush_hash_range= pSeries_lpar_flush_hash_range;
mmu_hash_ops.hpte_clear_all  = pseries_hpte_clear_all;
mmu_hash_ops.hugepage_invalidate = pSeries_lpar_hugepage_invalidate;
-   mmu_hash_ops.resize_hpt  = pseries_lpar_resize_hpt;
+
+   if (firmware_has_feature(FW_FEATURE_HPT_RESIZE))
+   mmu_hash_ops.resize_hpt = pseries_lpar_resize_hpt;
 }
 
 void radix_init_pseries(void)


cheers

Re: [PATCH] powerpc/pseries: Don't give a warning when HPT resizing isn't available

[Michael Ellerman]

David Gibson  writes:

> As of 438cc81a41 "powerpc/pseries: Automatically resize HPT for memory hot
> add/remove" when running on the pseries platform, we always attempt to
> use the PAPR extension to resize the hashed page table (HPT) when we add
> or remove memory.
>
> This is fine, but when the extension is available we'll give a harmless,
> but scary warning.  This patch suppresses the warning in this case.  It
> will still warn if the feature is supposed to be available, but didn't
> work.
>
> Signed-off-by: David Gibson 
> ---
>  arch/powerpc/mm/hash_utils_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Kind of cosmetic, but getting an error message on every memory hot
> plug/unplug attempt if your host doesn't support HPT resizing is
> pretty ugly.  So I think this is a candidate for quick inclusion.

Yeah thanks, I forgot I was going to send a patch for it.

I was thinking of doing the following instead, or maybe we can do both?

diff --git a/arch/powerpc/platforms/pseries/lpar.c 
b/arch/powerpc/platforms/pseries/lpar.c
index 251060cf1713..8b1fe895daa3 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -751,7 +751,9 @@ void __init hpte_init_pseries(void)
mmu_hash_ops.flush_hash_range= pSeries_lpar_flush_hash_range;
mmu_hash_ops.hpte_clear_all  = pseries_hpte_clear_all;
mmu_hash_ops.hugepage_invalidate = pSeries_lpar_hugepage_invalidate;
-   mmu_hash_ops.resize_hpt  = pseries_lpar_resize_hpt;
+
+   if (firmware_has_feature(FW_FEATURE_HPT_RESIZE))
+   mmu_hash_ops.resize_hpt = pseries_lpar_resize_hpt;
 }
 
 void radix_init_pseries(void)


cheers

Re: [PATCH] tty: hvc: don't allocate a buffer for console print on stack

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:42:45PM +0300, Jan Dakinevich wrote:
> The buffer is used by virtio console driver as DMA buffer. Since v4.9
> (if VMAP_STACK is enabled) we shouldn't use the stack for DMA.

You shouldn't use 'static' data either, that's not always guaranteed to
be DMA-able, right?

> 
> Signed-off-by: Jan Dakinevich 
> ---
>  drivers/tty/hvc/hvc_console.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 9b5c0fb..1ce6aaf 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -143,10 +143,15 @@ static struct hvc_struct *hvc_get_by_index(int index)
>  static void hvc_console_print(struct console *co, const char *b,
> unsigned count)
>  {
> - char c[N_OUTBUF] __ALIGNED__;
>   unsigned i = 0, n = 0;
>   int r, donecr = 0, index = co->index;
>  
> + /*
> +  * Access to the buffer is serialized by console_sem in caller code from
> +  * kernel/printk/printk.c
> +  */
> + static char c[N_OUTBUF] __ALIGNED__;

What about allocating it dynamically?  That's the correct thing to do.

thanks,

greg k-h

Re: [PATCH] tty: hvc: don't allocate a buffer for console print on stack

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:42:45PM +0300, Jan Dakinevich wrote:
> The buffer is used by virtio console driver as DMA buffer. Since v4.9
> (if VMAP_STACK is enabled) we shouldn't use the stack for DMA.

You shouldn't use 'static' data either, that's not always guaranteed to
be DMA-able, right?

> 
> Signed-off-by: Jan Dakinevich 
> ---
>  drivers/tty/hvc/hvc_console.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
> index 9b5c0fb..1ce6aaf 100644
> --- a/drivers/tty/hvc/hvc_console.c
> +++ b/drivers/tty/hvc/hvc_console.c
> @@ -143,10 +143,15 @@ static struct hvc_struct *hvc_get_by_index(int index)
>  static void hvc_console_print(struct console *co, const char *b,
> unsigned count)
>  {
> - char c[N_OUTBUF] __ALIGNED__;
>   unsigned i = 0, n = 0;
>   int r, donecr = 0, index = co->index;
>  
> + /*
> +  * Access to the buffer is serialized by console_sem in caller code from
> +  * kernel/printk/printk.c
> +  */
> + static char c[N_OUTBUF] __ALIGNED__;

What about allocating it dynamically?  That's the correct thing to do.

thanks,

greg k-h

Re: tty: panic in tty_ldisc_restore

[Greg Kroah-Hartman]

On Mon, Mar 13, 2017 at 11:15:29AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 2, 2017 at 7:23 PM, Greg Kroah-Hartman
>  wrote:
> > On Thu, Feb 02, 2017 at 07:03:41PM +0100, Dmitry Vyukov wrote:
> >> On Thu, Feb 2, 2017 at 6:55 PM, Greg Kroah-Hartman
> >>  wrote:
> >> > On Thu, Feb 02, 2017 at 06:48:48PM +0100, Dmitry Vyukov wrote:
> >> >> Hello,
> >> >>
> >> >> Syzkaller fuzzer started crashing kernel with the following panics:
> >> >>
> >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ircomm0 --- 
> >> >> error -12.
> >> >> CPU: 0 PID: 5637 Comm: syz-executor3 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801d4ba7a18 8234d0df  11003a974ed6
> >> >>  ed003a974ece 41b58ab3 84b38180 8234cdf1
> >> >>    8801d4ba76a8 dabb4fad
> >> >> Call Trace:
> >> >>  [] __dump_stack lib/dump_stack.c:15 [inline]
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] panic+0x1fb/0x412 kernel/panic.c:179
> >> >>  [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 
> >> >> [inline]
> >> >>  [] tty_set_ldisc+0x704/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [] tiocsetd drivers/tty/tty_io.c:2667 [inline]
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] vfs_ioctl fs/ioctl.c:43 [inline]
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679
> >> >>  [] SYSC_ioctl fs/ioctl.c:694 [inline]
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >>
> >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ptm2 --- 
> >> >> error -12.
> >> >> CPU: 0 PID: 7844 Comm: syz-executor0 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801c3307a18 8234d0df  110038660ed6
> >> >>  ed0038660ece 41b58ab3 84b38180 8234cdf1
> >> >>    8801c33076a8 dabb4fad
> >> >> Call Trace:
> >> >>  [] __dump_stack lib/dump_stack.c:15 [inline]
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] panic+0x1fb/0x412 kernel/panic.c:179
> >> >>  [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 
> >> >> [inline]
> >> >>  [] tty_set_ldisc+0x704/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [] tiocsetd drivers/tty/tty_io.c:2667 [inline]
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] vfs_ioctl fs/ioctl.c:43 [inline]
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679
> >> >>  [] SYSC_ioctl fs/ioctl.c:694 [inline]
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >>
> >> >>
> >> >> In all cases there is a vmalloc failure right before that:
> >> >>
> >> >> syz-executor4: vmalloc: allocation failure, allocated 0 of 16384
> >> >> bytes, mode:0x14000c2(GFP_KERNEL|__GFP_HIGHMEM), nodemask=(null)
> >> >> syz-executor4 cpuset=/ mems_allowed=0
> >> >> CPU: 1 PID: 4852 Comm: syz-executor4 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801c41df898 8234d0df 0001 11003883bea6
> >> >>  ed003883be9e 41b58ab3 84b38180 8234cdf1
> >> >>  0282 84fd53c0 8801dae65b38 8801c41df4d0
> >> >> Call Trace:
> >> >>  [< inline >] __dump_stack lib/dump_stack.c:15
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] warn_alloc+0x21f/0x360
> >> >>  [] __vmalloc_node_range+0x4e9/0x770
> >> >>  [< inline >] __vmalloc_node mm/vmalloc.c:1749
> >> >>  [< inline >] __vmalloc_node_flags mm/vmalloc.c:1763
> >> >>  [] vmalloc+0x5b/0x70 mm/vmalloc.c:1778
> >> >>  [] n_tty_open+0x1b/0x470 drivers/tty/n_tty.c:1883
> >> >>  [] tty_ldisc_open.isra.3+0x73/0xd0
> >> >> drivers/tty/tty_ldisc.c:463
> >> >>  [< inline >] tty_ldisc_restore drivers/tty/tty_ldisc.c:510
> >> >>  [] tty_set_ldisc+0x5e4/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [< inline >] tiocsetd drivers/tty/tty_io.c:2667
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630
> >> >>  [< inline >] SYSC_ioctl fs/ioctl.c:698
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >> arch/x86/entry/entry_64.S:204
> >> >>
> >> >>
> >> >> I've found that it's even documented in the source code, but it does
> >> >> not look like a good failure mode for allocation failure:
> >> >>
> >> >> static int n_tty_open(struct tty_struct *tty)
> >> >> {
> >> >> struct n_tty_data *ldata;
> >> >>
> >> >> /* Currently a malloc failure here can panic */
> >> >> ldata = vmalloc(sizeof(*ldata));
> 

Re: tty: panic in tty_ldisc_restore

[Greg Kroah-Hartman]

On Mon, Mar 13, 2017 at 11:15:29AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 2, 2017 at 7:23 PM, Greg Kroah-Hartman
>  wrote:
> > On Thu, Feb 02, 2017 at 07:03:41PM +0100, Dmitry Vyukov wrote:
> >> On Thu, Feb 2, 2017 at 6:55 PM, Greg Kroah-Hartman
> >>  wrote:
> >> > On Thu, Feb 02, 2017 at 06:48:48PM +0100, Dmitry Vyukov wrote:
> >> >> Hello,
> >> >>
> >> >> Syzkaller fuzzer started crashing kernel with the following panics:
> >> >>
> >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ircomm0 --- 
> >> >> error -12.
> >> >> CPU: 0 PID: 5637 Comm: syz-executor3 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801d4ba7a18 8234d0df  11003a974ed6
> >> >>  ed003a974ece 41b58ab3 84b38180 8234cdf1
> >> >>    8801d4ba76a8 dabb4fad
> >> >> Call Trace:
> >> >>  [] __dump_stack lib/dump_stack.c:15 [inline]
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] panic+0x1fb/0x412 kernel/panic.c:179
> >> >>  [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 
> >> >> [inline]
> >> >>  [] tty_set_ldisc+0x704/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [] tiocsetd drivers/tty/tty_io.c:2667 [inline]
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] vfs_ioctl fs/ioctl.c:43 [inline]
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679
> >> >>  [] SYSC_ioctl fs/ioctl.c:694 [inline]
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >>
> >> >> Kernel panic - not syncing: Couldn't open N_TTY ldisc for ptm2 --- 
> >> >> error -12.
> >> >> CPU: 0 PID: 7844 Comm: syz-executor0 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801c3307a18 8234d0df  110038660ed6
> >> >>  ed0038660ece 41b58ab3 84b38180 8234cdf1
> >> >>    8801c33076a8 dabb4fad
> >> >> Call Trace:
> >> >>  [] __dump_stack lib/dump_stack.c:15 [inline]
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] panic+0x1fb/0x412 kernel/panic.c:179
> >> >>  [] tty_ldisc_restore drivers/tty/tty_ldisc.c:520 
> >> >> [inline]
> >> >>  [] tty_set_ldisc+0x704/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [] tiocsetd drivers/tty/tty_io.c:2667 [inline]
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] vfs_ioctl fs/ioctl.c:43 [inline]
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630 fs/ioctl.c:679
> >> >>  [] SYSC_ioctl fs/ioctl.c:694 [inline]
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >>
> >> >>
> >> >> In all cases there is a vmalloc failure right before that:
> >> >>
> >> >> syz-executor4: vmalloc: allocation failure, allocated 0 of 16384
> >> >> bytes, mode:0x14000c2(GFP_KERNEL|__GFP_HIGHMEM), nodemask=(null)
> >> >> syz-executor4 cpuset=/ mems_allowed=0
> >> >> CPU: 1 PID: 4852 Comm: syz-executor4 Not tainted 4.9.0 #6
> >> >> Hardware name: Google Google Compute Engine/Google Compute Engine,
> >> >> BIOS Google 01/01/2011
> >> >>  8801c41df898 8234d0df 0001 11003883bea6
> >> >>  ed003883be9e 41b58ab3 84b38180 8234cdf1
> >> >>  0282 84fd53c0 8801dae65b38 8801c41df4d0
> >> >> Call Trace:
> >> >>  [< inline >] __dump_stack lib/dump_stack.c:15
> >> >>  [] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
> >> >>  [] warn_alloc+0x21f/0x360
> >> >>  [] __vmalloc_node_range+0x4e9/0x770
> >> >>  [< inline >] __vmalloc_node mm/vmalloc.c:1749
> >> >>  [< inline >] __vmalloc_node_flags mm/vmalloc.c:1763
> >> >>  [] vmalloc+0x5b/0x70 mm/vmalloc.c:1778
> >> >>  [] n_tty_open+0x1b/0x470 drivers/tty/n_tty.c:1883
> >> >>  [] tty_ldisc_open.isra.3+0x73/0xd0
> >> >> drivers/tty/tty_ldisc.c:463
> >> >>  [< inline >] tty_ldisc_restore drivers/tty/tty_ldisc.c:510
> >> >>  [] tty_set_ldisc+0x5e4/0x8b0 
> >> >> drivers/tty/tty_ldisc.c:579
> >> >>  [< inline >] tiocsetd drivers/tty/tty_io.c:2667
> >> >>  [] tty_ioctl+0xc63/0x2370 drivers/tty/tty_io.c:2924
> >> >>  [] do_vfs_ioctl+0x1bf/0x1630
> >> >>  [< inline >] SYSC_ioctl fs/ioctl.c:698
> >> >>  [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
> >> >>  [] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >> >> arch/x86/entry/entry_64.S:204
> >> >>
> >> >>
> >> >> I've found that it's even documented in the source code, but it does
> >> >> not look like a good failure mode for allocation failure:
> >> >>
> >> >> static int n_tty_open(struct tty_struct *tty)
> >> >> {
> >> >> struct n_tty_data *ldata;
> >> >>
> >> >> /* Currently a malloc failure here can panic */
> >> >> ldata = vmalloc(sizeof(*ldata));
> >> >
> >> > How are you running out of vmalloc() memory?

Re: [PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

[Greg Kroah-Hartman]

On Thu, Mar 16, 2017 at 12:31:53PM +0300, Aleksey Makarov wrote:
> 
> 
> On 03/16/2017 10:11 AM, Jayachandran C. wrote:
> > Hi Greg,
> > 
> > On Tue, Mar 14, 2017 at 9:44 PM, Sudeep Holla  wrote:
> >>
> >>
> >> On 01/03/17 15:23, Aleksey Makarov wrote:
> >>> The original patch makes the condition always true, so it is wrong.
> >>>
> >>> It masks (but not fixes) the bug described in the commit message
> >>> but introduces a regression (no console is selected by SPCR)
> >>> in regular (no 'console=ttyAMA') case.
> >>>
> >>> s/||/&&/ would not fix the problem as the root cause was identified
> >>> incorrectly.
> >>>
> >>> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b.
> >>>
> >>
> >> Sorry for that, I will test your patches and respond to that. For this
> >> patch:
> >>
> >> Acked-by: Sudeep Holla 
> >>
> > 
> > This fixes a regression I see in v4.11-rc2
> > 
> > Tested-by: Jayachandran C 
> > 
> > I don't see it in the tty/serial tree yet
> 
> It's commit 713b93f1b849 from tty-next branch of 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> 
> So it looks like it is scheduled for 4.12
> 
> Greg, this is a fix for regression.  Can it be applied to 4.11-rcX?

Yes, will do that now, thanks.

greg k-h

Re: [PATCH v3] Revert "tty: serial: pl011: add ttyAMA for matching pl011 console"

[Greg Kroah-Hartman]

On Thu, Mar 16, 2017 at 12:31:53PM +0300, Aleksey Makarov wrote:
> 
> 
> On 03/16/2017 10:11 AM, Jayachandran C. wrote:
> > Hi Greg,
> > 
> > On Tue, Mar 14, 2017 at 9:44 PM, Sudeep Holla  wrote:
> >>
> >>
> >> On 01/03/17 15:23, Aleksey Makarov wrote:
> >>> The original patch makes the condition always true, so it is wrong.
> >>>
> >>> It masks (but not fixes) the bug described in the commit message
> >>> but introduces a regression (no console is selected by SPCR)
> >>> in regular (no 'console=ttyAMA') case.
> >>>
> >>> s/||/&&/ would not fix the problem as the root cause was identified
> >>> incorrectly.
> >>>
> >>> This reverts commit aea9a80ba98a0c9b4de88850260e9fbdcc98360b.
> >>>
> >>
> >> Sorry for that, I will test your patches and respond to that. For this
> >> patch:
> >>
> >> Acked-by: Sudeep Holla 
> >>
> > 
> > This fixes a regression I see in v4.11-rc2
> > 
> > Tested-by: Jayachandran C 
> > 
> > I don't see it in the tty/serial tree yet
> 
> It's commit 713b93f1b849 from tty-next branch of 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> 
> So it looks like it is scheduled for 4.12
> 
> Greg, this is a fix for regression.  Can it be applied to 4.11-rcX?

Yes, will do that now, thanks.

greg k-h

Re: [lkp-robot] [mm] bae58218d8: WARNING:at_mm/page_alloc.c:#drain_all_pages

[Ye Xiaolong]

On 03/16, Michal Hocko wrote:
>On Thu 16-03-17 10:38:49, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: bae58218d80c6beffd5c96c0fcae372a0e63ca32 ("mm: move pcp and lru-pcp 
>> draining into single wq")
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
>Could you test with
>http://lkml.kernel.org/r/20170315164021.28532-1-mho...@kernel.org
>applied?

This warning is gone with above patch applied for 10 time boot.

Tested-by: Xiaolong Ye 

Thanks,
Xiaolong
>-- 
>Michal Hocko
>SUSE Labs

Re: [lkp-robot] [mm] bae58218d8: WARNING:at_mm/page_alloc.c:#drain_all_pages

[Ye Xiaolong]

On 03/16, Michal Hocko wrote:
>On Thu 16-03-17 10:38:49, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: bae58218d80c6beffd5c96c0fcae372a0e63ca32 ("mm: move pcp and lru-pcp 
>> draining into single wq")
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
>Could you test with
>http://lkml.kernel.org/r/20170315164021.28532-1-mho...@kernel.org
>applied?

This warning is gone with above patch applied for 10 time boot.

Tested-by: Xiaolong Ye 

Thanks,
Xiaolong
>-- 
>Michal Hocko
>SUSE Labs

Re: [patch 1/3] procfs: fdinfo -- Extend information about epoll target files

[Andrei Vagin]

On Fri, Mar 10, 2017 at 11:16:56AM +0300, Cyrill Gorcunov wrote:
> Since it is possbile to have same number in tfd field (say
> file added, closed, then nother file dup'ed to same number
> and added back) it is imposible to distinguish such target
> files solely by their numbers.
> 
> Strictly speaking regular applications don't need to recognize
> these targets at all but for checkpoint/restore sake we need
> to collect targets to be able to push them back on restore
> stage in a proper order.
> 
> Thus lets add file position, inode and device number where
> this target lays. This three fields can be used as a primary
> key for sorting, and together with kcmp help CRIU can find
> out an exact file target (from the whole set of processes
> being checkpointed).
> 
> Signed-off-by: Cyrill Gorcunov 
> CC: Al Viro 
> CC: Andrew Morton 
> CC: Andrey Vagin 
> CC: Pavel Emelyanov 
> CC: Michael Kerrisk 
> CC: Kir Kolyshkin 
> CC: Jason Baron 
> CC: Andy Lutomirski 
> ---
>  Documentation/filesystems/proc.txt |6 +-
>  fs/eventpoll.c |8 ++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> Index: linux-ml.git/Documentation/filesystems/proc.txt
> ===
> --- linux-ml.git.orig/Documentation/filesystems/proc.txt
> +++ linux-ml.git/Documentation/filesystems/proc.txt
> @@ -1779,12 +1779,16 @@ pair provide additional information part
>   pos:0
>   flags:  02
>   mnt_id: 9
> - tfd:5 events:   1d data: 
> + tfd:5 events:   1d data:  pos:0 ino:61af 
> sdev:7

I think it may be better to print mnt_id instead of sdev, because there
may be two file descriptors opened from different bind mounts.

>  
>   where 'tfd' is a target file descriptor number in decimal form,
>   'events' is events mask being watched and the 'data' is data
>   associated with a target [see epoll(7) for more details].
>  
> + The 'pos' is current offset of the target file in decimal form
> + [see lseek(2)], 'ino' and 'sdev' are inode and device numbers
> + where target file resides, all in hex format.
> +
>   Fsnotify files
>   ~~
>   For inotify files the format is the following
> Index: linux-ml.git/fs/eventpoll.c
> ===
> --- linux-ml.git.orig/fs/eventpoll.c
> +++ linux-ml.git/fs/eventpoll.c
> @@ -883,10 +883,14 @@ static void ep_show_fdinfo(struct seq_fi
>   mutex_lock(>mtx);
>   for (rbp = rb_first(>rbr); rbp; rbp = rb_next(rbp)) {
>   struct epitem *epi = rb_entry(rbp, struct epitem, rbn);
> + struct inode *inode = file_inode(epi->ffd.file);
>  
> - seq_printf(m, "tfd: %8d events: %8x data: %16llx\n",
> + seq_printf(m, "tfd: %8d events: %8x data: %16llx "
> +" pos:%lli ino:%lx sdev:%x\n",
>  epi->ffd.fd, epi->event.events,
> -(long long)epi->event.data);
> +(long long)epi->event.data,
> +(long long)epi->ffd.file->f_pos,
> +inode->i_ino, inode->i_sb->s_dev);
>   if (seq_has_overflowed(m))
>   break;
>   }
> 

Re: [patch 1/3] procfs: fdinfo -- Extend information about epoll target files

[Andrei Vagin]

On Fri, Mar 10, 2017 at 11:16:56AM +0300, Cyrill Gorcunov wrote:
> Since it is possbile to have same number in tfd field (say
> file added, closed, then nother file dup'ed to same number
> and added back) it is imposible to distinguish such target
> files solely by their numbers.
> 
> Strictly speaking regular applications don't need to recognize
> these targets at all but for checkpoint/restore sake we need
> to collect targets to be able to push them back on restore
> stage in a proper order.
> 
> Thus lets add file position, inode and device number where
> this target lays. This three fields can be used as a primary
> key for sorting, and together with kcmp help CRIU can find
> out an exact file target (from the whole set of processes
> being checkpointed).
> 
> Signed-off-by: Cyrill Gorcunov 
> CC: Al Viro 
> CC: Andrew Morton 
> CC: Andrey Vagin 
> CC: Pavel Emelyanov 
> CC: Michael Kerrisk 
> CC: Kir Kolyshkin 
> CC: Jason Baron 
> CC: Andy Lutomirski 
> ---
>  Documentation/filesystems/proc.txt |6 +-
>  fs/eventpoll.c |8 ++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> Index: linux-ml.git/Documentation/filesystems/proc.txt
> ===
> --- linux-ml.git.orig/Documentation/filesystems/proc.txt
> +++ linux-ml.git/Documentation/filesystems/proc.txt
> @@ -1779,12 +1779,16 @@ pair provide additional information part
>   pos:0
>   flags:  02
>   mnt_id: 9
> - tfd:5 events:   1d data: 
> + tfd:5 events:   1d data:  pos:0 ino:61af 
> sdev:7

I think it may be better to print mnt_id instead of sdev, because there
may be two file descriptors opened from different bind mounts.

>  
>   where 'tfd' is a target file descriptor number in decimal form,
>   'events' is events mask being watched and the 'data' is data
>   associated with a target [see epoll(7) for more details].
>  
> + The 'pos' is current offset of the target file in decimal form
> + [see lseek(2)], 'ino' and 'sdev' are inode and device numbers
> + where target file resides, all in hex format.
> +
>   Fsnotify files
>   ~~
>   For inotify files the format is the following
> Index: linux-ml.git/fs/eventpoll.c
> ===
> --- linux-ml.git.orig/fs/eventpoll.c
> +++ linux-ml.git/fs/eventpoll.c
> @@ -883,10 +883,14 @@ static void ep_show_fdinfo(struct seq_fi
>   mutex_lock(>mtx);
>   for (rbp = rb_first(>rbr); rbp; rbp = rb_next(rbp)) {
>   struct epitem *epi = rb_entry(rbp, struct epitem, rbn);
> + struct inode *inode = file_inode(epi->ffd.file);
>  
> - seq_printf(m, "tfd: %8d events: %8x data: %16llx\n",
> + seq_printf(m, "tfd: %8d events: %8x data: %16llx "
> +" pos:%lli ino:%lx sdev:%x\n",
>  epi->ffd.fd, epi->event.events,
> -(long long)epi->event.data);
> +(long long)epi->event.data,
> +(long long)epi->ffd.file->f_pos,
> +inode->i_ino, inode->i_sb->s_dev);
>   if (seq_has_overflowed(m))
>   break;
>   }
> 

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 16/03/17 19:03, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Juergen Gross wrote:
>> On 15/03/17 19:44, Stefano Stabellini wrote:
>>> On Wed, 15 Mar 2017, Juergen Gross wrote:
 On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
>
> thank you for the review!
>
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
>
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

 I'm fine with the workqueues as long as you have decided to use them
 considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
>
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

 Is this documented somewhere?

 Hmm, are any of the Xenstore entries documented? Shouldn't this be done
 in xen_9pfs.h ?
>>>  
>>> They are documented in docs/misc/9pfs.markdown, under "Xenstore". Given
>>> that it's all written there, especially the semantics, I didn't repeat
>>> it in xen_9pfs.h
>>
>> Looking at it from the Linux kernel perspective this documentation is
>> not really highly visible. For me it is okay, but there have been
>> multiple examples in the past where documentation in the Xen repository
>> wasn't regarded as being sufficient.
>>
>> I recommend moving the documentation regarding the interface into the
>> header file like for the other pv interfaces.
> 
> What about adding a link such as:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD
> 
> that should be easily accessible, right? For other specifications, such
> as 9p, only links are provided (see Documentation/filesystems/9p.txt).
> I am suggesting a link, because then we are sure the specs don't go out
> of sync. I realize that older PV protocols were described in header
> files, but that was before Xen Project had a formal process for getting
> new specifications accepted, and a formal place where to publish them.

Fine with me. Lets see if other maintainers are okay with it, too.


Juergen

Re: [PATCH v3 4/7] xen/9pfs: connect to the backend

[Juergen Gross]

On 16/03/17 19:03, Stefano Stabellini wrote:
> On Thu, 16 Mar 2017, Juergen Gross wrote:
>> On 15/03/17 19:44, Stefano Stabellini wrote:
>>> On Wed, 15 Mar 2017, Juergen Gross wrote:
 On 14/03/17 22:22, Stefano Stabellini wrote:
> Hi Juergen,
>
> thank you for the review!
>
> On Tue, 14 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 00:50, Stefano Stabellini wrote:
>>> Implement functions to handle the xenbus handshake. Upon connection,
>>> allocate the rings according to the protocol specification.
>>>
>>> Initialize a work_struct and a wait_queue. The work_struct will be used
>>> to schedule work upon receiving an event channel notification from the
>>> backend. The wait_queue will be used to wait when the ring is full and
>>> we need to send a new request.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Eric Van Hensbergen 
>>> CC: Ron Minnich 
>>> CC: Latchesar Ionkov 
>>> CC: v9fs-develo...@lists.sourceforge.net
>>> ---

>> Did you think about using request_threaded_irq() instead of a workqueue?
>> For an example see e.g. drivers/scsi/xen-scsifront.c
>
> I like workqueues :-)  It might come down to personal preferences, but I
> think workqueues are more flexible and a better fit for this use case.
> Not only it is easy to schedule work in a workqueue from the interrupt
> handler, but also they can be used for sleeping in the request function
> if there is not enough room on the ring. Besides, they can easily be
> configured to share a single thread or to have multiple independent
> threads.

 I'm fine with the workqueues as long as you have decided to use them
 considering the alternatives. :-)

>> Can't you use xenbus_read_unsigned() instead of xenbus_read()?
>
> I can use xenbus_read_unsigned in the other cases below, but not here,
> because versions is in the form: "1,3,4"

 Is this documented somewhere?

 Hmm, are any of the Xenstore entries documented? Shouldn't this be done
 in xen_9pfs.h ?
>>>  
>>> They are documented in docs/misc/9pfs.markdown, under "Xenstore". Given
>>> that it's all written there, especially the semantics, I didn't repeat
>>> it in xen_9pfs.h
>>
>> Looking at it from the Linux kernel perspective this documentation is
>> not really highly visible. For me it is okay, but there have been
>> multiple examples in the past where documentation in the Xen repository
>> wasn't regarded as being sufficient.
>>
>> I recommend moving the documentation regarding the interface into the
>> header file like for the other pv interfaces.
> 
> What about adding a link such as:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD
> 
> that should be easily accessible, right? For other specifications, such
> as 9p, only links are provided (see Documentation/filesystems/9p.txt).
> I am suggesting a link, because then we are sure the specs don't go out
> of sync. I realize that older PV protocols were described in header
> files, but that was before Xen Project had a formal process for getting
> new specifications accepted, and a formal place where to publish them.

Fine with me. Lets see if other maintainers are okay with it, too.


Juergen

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Balbir Singh]

On 17/03/17 14:42, Balbir Singh wrote:
>>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT?
>>>
>>
>> Yes, that was my first reaction too, but these particular routines are
>> aspiring to be generic routines--in fact, you have had an influence there,
>> because these might possibly help with NUMA migrations. :)
>>
> 
> Yes, I still stick to them being generic, but I'd be OK if they worked
> just for 64 bit systems.
> Having said that even the 64 bit works version work for upto physical
> sizes of 64 - PAGE_SHIFT
> which is a little limiting I think.
> 
> One option is to make pfn's unsigned long long and do 32 and 64 bit 
> computations
> separately
> 
> Option 2, could be something like you said
> 
> a. Define a __weak migrate_vma to return -EINVAL
> b. In a 64BIT only file define migrate_vma
> 
> Option 3
> 
> Something totally different
> 
> If we care to support 32 bit we go with 1, else option 2 is a good
> starting point. There might
> be other ways of doing option 2, like you've suggested


So this is what I ended up with, a quick fix for the 32 bit
build failures

Date: Fri, 17 Mar 2017 15:42:52 +1100
Subject: [PATCH] mm/hmm: Fix build on 32 bit systems

Fix build breakage of hmm-v18 in the current mmotm by
making the migrate_vma() and related functions 64
bit only. The 32 bit variant will return -EINVAL.
There are other approaches to solving this problem,
but we can enable 32 bit systems as we need them.

This patch tries to limit the impact on 32 bit systems
by turning HMM off on them and not enabling the migrate
functions.

I've built this on ppc64/i386 and x86_64

Signed-off-by: Balbir Singh 
---
 include/linux/migrate.h | 18 +-
 mm/Kconfig  |  4 +++-
 mm/migrate.c|  3 ++-
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 01f4945..1888a70 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -124,7 +124,7 @@ static inline int migrate_misplaced_transhuge_page(struct 
mm_struct *mm,
 }
 #endif /* CONFIG_NUMA_BALANCING && CONFIG_TRANSPARENT_HUGEPAGE*/
 
-
+#ifdef CONFIG_64BIT
 #define MIGRATE_PFN_VALID  (1UL << (BITS_PER_LONG_LONG - 1))
 #define MIGRATE_PFN_MIGRATE(1UL << (BITS_PER_LONG_LONG - 2))
 #define MIGRATE_PFN_HUGE   (1UL << (BITS_PER_LONG_LONG - 3))
@@ -145,6 +145,7 @@ static inline unsigned long migrate_pfn_size(unsigned long 
mpfn)
 {
return mpfn & MIGRATE_PFN_HUGE ? PMD_SIZE : PAGE_SIZE;
 }
+#endif
 
 /*
  * struct migrate_vma_ops - migrate operation callback
@@ -194,6 +195,7 @@ struct migrate_vma_ops {
 void *private);
 };
 
+#ifdef CONFIG_64BIT
 int migrate_vma(const struct migrate_vma_ops *ops,
struct vm_area_struct *vma,
unsigned long mentries,
@@ -202,5 +204,19 @@ int migrate_vma(const struct migrate_vma_ops *ops,
unsigned long *src,
unsigned long *dst,
void *private);
+#else
+static inline int migrate_vma(const struct migrate_vma_ops *ops,
+   struct vm_area_struct *vma,
+   unsigned long mentries,
+   unsigned long start,
+   unsigned long end,
+   unsigned long *src,
+   unsigned long *dst,
+   void *private)
+{
+   return -EINVAL;
+}
+#endif
+
 
 #endif /* _LINUX_MIGRATE_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index a430d51..c13677f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -291,7 +291,7 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
 
 config HMM
bool
-   depends on MMU
+   depends on MMU && 64BIT
 
 config HMM_MIRROR
bool "HMM mirror CPU page table into a device page table"
@@ -307,6 +307,7 @@ config HMM_MIRROR
  Second side of the equation is replicating CPU page table content for
  range of virtual address. This require careful synchronization with
  CPU page table update.
+   depends on 64BIT
 
 config HMM_DEVMEM
bool "HMM device memory helpers (to leverage ZONE_DEVICE)"
@@ -314,6 +315,7 @@ config HMM_DEVMEM
help
  HMM devmem are helpers to leverage new ZONE_DEVICE feature. This is
  just to avoid device driver to replicate boiler plate code.
+   depends on 64BIT
 
 config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
diff --git a/mm/migrate.c b/mm/migrate.c
index b9d25d1..15f2972 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2080,7 +2080,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
 
 #endif /* CONFIG_NUMA */
 
-
+#ifdef CONFIG_64BIT
 struct migrate_vma {
struct vm_area_struct   *vma;
unsigned long   *dst;
@@ -2787,3 +2787,4 @@ int migrate_vma(const struct migrate_vma_ops *ops,
return 0;
 }
 

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Balbir Singh]

On 17/03/17 14:42, Balbir Singh wrote:
>>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT?
>>>
>>
>> Yes, that was my first reaction too, but these particular routines are
>> aspiring to be generic routines--in fact, you have had an influence there,
>> because these might possibly help with NUMA migrations. :)
>>
> 
> Yes, I still stick to them being generic, but I'd be OK if they worked
> just for 64 bit systems.
> Having said that even the 64 bit works version work for upto physical
> sizes of 64 - PAGE_SHIFT
> which is a little limiting I think.
> 
> One option is to make pfn's unsigned long long and do 32 and 64 bit 
> computations
> separately
> 
> Option 2, could be something like you said
> 
> a. Define a __weak migrate_vma to return -EINVAL
> b. In a 64BIT only file define migrate_vma
> 
> Option 3
> 
> Something totally different
> 
> If we care to support 32 bit we go with 1, else option 2 is a good
> starting point. There might
> be other ways of doing option 2, like you've suggested


So this is what I ended up with, a quick fix for the 32 bit
build failures

Date: Fri, 17 Mar 2017 15:42:52 +1100
Subject: [PATCH] mm/hmm: Fix build on 32 bit systems

Fix build breakage of hmm-v18 in the current mmotm by
making the migrate_vma() and related functions 64
bit only. The 32 bit variant will return -EINVAL.
There are other approaches to solving this problem,
but we can enable 32 bit systems as we need them.

This patch tries to limit the impact on 32 bit systems
by turning HMM off on them and not enabling the migrate
functions.

I've built this on ppc64/i386 and x86_64

Signed-off-by: Balbir Singh 
---
 include/linux/migrate.h | 18 +-
 mm/Kconfig  |  4 +++-
 mm/migrate.c|  3 ++-
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 01f4945..1888a70 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -124,7 +124,7 @@ static inline int migrate_misplaced_transhuge_page(struct 
mm_struct *mm,
 }
 #endif /* CONFIG_NUMA_BALANCING && CONFIG_TRANSPARENT_HUGEPAGE*/
 
-
+#ifdef CONFIG_64BIT
 #define MIGRATE_PFN_VALID  (1UL << (BITS_PER_LONG_LONG - 1))
 #define MIGRATE_PFN_MIGRATE(1UL << (BITS_PER_LONG_LONG - 2))
 #define MIGRATE_PFN_HUGE   (1UL << (BITS_PER_LONG_LONG - 3))
@@ -145,6 +145,7 @@ static inline unsigned long migrate_pfn_size(unsigned long 
mpfn)
 {
return mpfn & MIGRATE_PFN_HUGE ? PMD_SIZE : PAGE_SIZE;
 }
+#endif
 
 /*
  * struct migrate_vma_ops - migrate operation callback
@@ -194,6 +195,7 @@ struct migrate_vma_ops {
 void *private);
 };
 
+#ifdef CONFIG_64BIT
 int migrate_vma(const struct migrate_vma_ops *ops,
struct vm_area_struct *vma,
unsigned long mentries,
@@ -202,5 +204,19 @@ int migrate_vma(const struct migrate_vma_ops *ops,
unsigned long *src,
unsigned long *dst,
void *private);
+#else
+static inline int migrate_vma(const struct migrate_vma_ops *ops,
+   struct vm_area_struct *vma,
+   unsigned long mentries,
+   unsigned long start,
+   unsigned long end,
+   unsigned long *src,
+   unsigned long *dst,
+   void *private)
+{
+   return -EINVAL;
+}
+#endif
+
 
 #endif /* _LINUX_MIGRATE_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index a430d51..c13677f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -291,7 +291,7 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
 
 config HMM
bool
-   depends on MMU
+   depends on MMU && 64BIT
 
 config HMM_MIRROR
bool "HMM mirror CPU page table into a device page table"
@@ -307,6 +307,7 @@ config HMM_MIRROR
  Second side of the equation is replicating CPU page table content for
  range of virtual address. This require careful synchronization with
  CPU page table update.
+   depends on 64BIT
 
 config HMM_DEVMEM
bool "HMM device memory helpers (to leverage ZONE_DEVICE)"
@@ -314,6 +315,7 @@ config HMM_DEVMEM
help
  HMM devmem are helpers to leverage new ZONE_DEVICE feature. This is
  just to avoid device driver to replicate boiler plate code.
+   depends on 64BIT
 
 config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
diff --git a/mm/migrate.c b/mm/migrate.c
index b9d25d1..15f2972 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2080,7 +2080,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
 
 #endif /* CONFIG_NUMA */
 
-
+#ifdef CONFIG_64BIT
 struct migrate_vma {
struct vm_area_struct   *vma;
unsigned long   *dst;
@@ -2787,3 +2787,4 @@ int migrate_vma(const struct migrate_vma_ops *ops,
return 0;
 }
 EXPORT_SYMBOL(migrate_vma);
+#endif
-- 

Re: [PATCH v5 0/7] perf/sdt: Directly record SDT events with 'perf record'

[Masami Hiramatsu]

Hi Ravi,

On Thu, 16 Mar 2017 16:57:52 +0530
Ravi Bangoria  wrote:

> Hi Masami,
> 
> On Thursday 16 March 2017 03:21 PM, Masami Hiramatsu wrote:
> > On Tue, 14 Mar 2017 20:36:51 +0530
> > Ravi Bangoria  wrote:
> >
> >> Changes in v5:
> >>   - Patch 2/7 is new. New option introduced in this patch helps to pass
> >> custome data from builtin-*.c to libperf.
> >>
> >>   - All direct callbacks from libelf to builtin-record.c is removed.
> >>  
> 
> Minor correction.. s/libelf/libperf/
> 
> >>   - Merged 2nd and 4th patch of v4 into patch 2 of v5.
> 
> s/patch 2 of v5/patch 3 of v5/
> 
> >>
> >>   - Moved all functions from util/probe-file.c to util/probe-event.c
> >> which operates on perf_probe_event.
> >>
> >>   - Made free_sdt_list() static as it's only used inside 
> >> util/probe-event.c.
> >>
> >>   - Couple of other changes as Masami has suggested in v4 review.
> > Hi Ravi,
> > Could you also describe which patches are updated? It seems 1/7 is not
> > modified, correct?
> 
> Let me list a patch-wise brief changelog.
> 
> patch 1/7:- Introduced dummy version of is_sdt_event() which always return 
> false
>  if !HAVE_LIBELF_SUPPORT.
> 
> patch 2/7: - is new. A new option introduced in this patch helps to passcustom
>  data from builtin-*.c to libperf.
> 
> patch 3/7: - Removed direct calls from libperf to builtin-record.c which was 
> used
>  to prepare record.sdt_event_list. Instead pass list to libperf 
> and let
>  libperf manage it.
> 
>- Introduce new wrapper func record__parse_events_option() that can
>  differentiate between sdt and other events while parsing them in
>  perf record.
> 
>- Moved all functions from util/probe-file.c to util/probe-event.c
>  which operates on perf_probe_event.
> 
>- Merged 2nd and 4th patch of v4 into this patch.
> 
>- Made free_sdt_list() static as it's only used inside 
> util/probe-event.c.
> 
> patch 4/7:- Removed direct calls from libperf to builtin-record.c which was 
> used
>  to prepare record.sdt_event_list. Instead pass list to libperf 
> and let
>  libperf manage it.
> 
>- Moved all functions from util/probe-file.c to util/probe-event.c
>  which operates on perf_probe_event.
> 
> patch 5/7: No changes
> 
> patch 6/7: No changes
> 
> patch 7/7: No changes
> 
> Let me know if you need more details.

Thanks! that's very helpful for me to review it.


-- 
Masami Hiramatsu 

Re: [PATCH v5 0/7] perf/sdt: Directly record SDT events with 'perf record'

[Masami Hiramatsu]

Hi Ravi,

On Thu, 16 Mar 2017 16:57:52 +0530
Ravi Bangoria  wrote:

> Hi Masami,
> 
> On Thursday 16 March 2017 03:21 PM, Masami Hiramatsu wrote:
> > On Tue, 14 Mar 2017 20:36:51 +0530
> > Ravi Bangoria  wrote:
> >
> >> Changes in v5:
> >>   - Patch 2/7 is new. New option introduced in this patch helps to pass
> >> custome data from builtin-*.c to libperf.
> >>
> >>   - All direct callbacks from libelf to builtin-record.c is removed.
> >>  
> 
> Minor correction.. s/libelf/libperf/
> 
> >>   - Merged 2nd and 4th patch of v4 into patch 2 of v5.
> 
> s/patch 2 of v5/patch 3 of v5/
> 
> >>
> >>   - Moved all functions from util/probe-file.c to util/probe-event.c
> >> which operates on perf_probe_event.
> >>
> >>   - Made free_sdt_list() static as it's only used inside 
> >> util/probe-event.c.
> >>
> >>   - Couple of other changes as Masami has suggested in v4 review.
> > Hi Ravi,
> > Could you also describe which patches are updated? It seems 1/7 is not
> > modified, correct?
> 
> Let me list a patch-wise brief changelog.
> 
> patch 1/7:- Introduced dummy version of is_sdt_event() which always return 
> false
>  if !HAVE_LIBELF_SUPPORT.
> 
> patch 2/7: - is new. A new option introduced in this patch helps to passcustom
>  data from builtin-*.c to libperf.
> 
> patch 3/7: - Removed direct calls from libperf to builtin-record.c which was 
> used
>  to prepare record.sdt_event_list. Instead pass list to libperf 
> and let
>  libperf manage it.
> 
>- Introduce new wrapper func record__parse_events_option() that can
>  differentiate between sdt and other events while parsing them in
>  perf record.
> 
>- Moved all functions from util/probe-file.c to util/probe-event.c
>  which operates on perf_probe_event.
> 
>- Merged 2nd and 4th patch of v4 into this patch.
> 
>- Made free_sdt_list() static as it's only used inside 
> util/probe-event.c.
> 
> patch 4/7:- Removed direct calls from libperf to builtin-record.c which was 
> used
>  to prepare record.sdt_event_list. Instead pass list to libperf 
> and let
>  libperf manage it.
> 
>- Moved all functions from util/probe-file.c to util/probe-event.c
>  which operates on perf_probe_event.
> 
> patch 5/7: No changes
> 
> patch 6/7: No changes
> 
> patch 7/7: No changes
> 
> Let me know if you need more details.

Thanks! that's very helpful for me to review it.


-- 
Masami Hiramatsu 

[PATCH net-next v3 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[R. Parameswaran]

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: R. Parameswaran 
---
 net/l2tp/l2tp_eth.c | 51 +++
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 8bf18a5..f512d97 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "l2tp_core.h"
 
@@ -204,6 +207,49 @@ static void l2tp_eth_show(struct seq_file *m, void *arg)
 }
 #endif
 
+static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
+   struct l2tp_session *session,
+   struct net_device *dev)
+{
+   unsigned int overhead = 0;
+   struct dst_entry *dst;
+   u32 l3_overhead = 0;
+
+   if (session->mtu != 0) {
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+   return;
+   }
+   overhead = session->hdr_len;
+   l3_overhead = kernel_sock_ip_overhead(tunnel->sock);
+   if (!tunnel->sock || (l3_overhead == 0)) {
+   /* L3 Overhead couldn't be identified, dev mtu stays at 1500 */
+   return;
+   }
+   /* Adjust MTU, factor overhead - underlay L3, overlay L2 hdr */
+   overhead += ETH_HLEN + l3_overhead;
+   /* Additionally, if the encap is UDP, account for UDP header size */
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP) {
+   overhead += sizeof(struct udphdr);
+   dev->needed_headroom += sizeof(struct udphdr);
+   }
+   /* If PMTU discovery was enabled, use discovered MTU on L2TP device */
+   dst = sk_dst_get(tunnel->sock);
+   if (dst) {
+   /* dst_mtu will use PMTU if found, else fallback to intf MTU */
+   u32 pmtu = dst_mtu(dst);
+
+   if (pmtu != 0)
+   dev->mtu = pmtu;
+   dst_release(dst);
+   }
+   session->mtu = dev->mtu - overhead;
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+}
+
 static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 
peer_session_id, struct l2tp_session_cfg *cfg)
 {
struct net_device *dev;
@@ -253,12 +299,9 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, 
u32 session_id, u32 p
}
 
dev_net_set(dev, net);
-   if (session->mtu == 0)
-   session->mtu = dev->mtu - session->hdr_len;
-   dev->mtu = session->mtu;
-   dev->needed_headroom += session->hdr_len;
dev->min_mtu = 0;
dev->max_mtu = ETH_MAX_MTU;
+   l2tp_eth_adjust_mtu(tunnel, session, dev);
 
priv = netdev_priv(dev);
priv->dev = dev;
-- 
2.1.4

[PATCH net-next v3 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[R. Parameswaran]

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: R. Parameswaran 
---
 net/l2tp/l2tp_eth.c | 51 +++
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 8bf18a5..f512d97 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "l2tp_core.h"
 
@@ -204,6 +207,49 @@ static void l2tp_eth_show(struct seq_file *m, void *arg)
 }
 #endif
 
+static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
+   struct l2tp_session *session,
+   struct net_device *dev)
+{
+   unsigned int overhead = 0;
+   struct dst_entry *dst;
+   u32 l3_overhead = 0;
+
+   if (session->mtu != 0) {
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+   dev->needed_headroom += sizeof(struct udphdr);
+   return;
+   }
+   overhead = session->hdr_len;
+   l3_overhead = kernel_sock_ip_overhead(tunnel->sock);
+   if (!tunnel->sock || (l3_overhead == 0)) {
+   /* L3 Overhead couldn't be identified, dev mtu stays at 1500 */
+   return;
+   }
+   /* Adjust MTU, factor overhead - underlay L3, overlay L2 hdr */
+   overhead += ETH_HLEN + l3_overhead;
+   /* Additionally, if the encap is UDP, account for UDP header size */
+   if (tunnel->encap == L2TP_ENCAPTYPE_UDP) {
+   overhead += sizeof(struct udphdr);
+   dev->needed_headroom += sizeof(struct udphdr);
+   }
+   /* If PMTU discovery was enabled, use discovered MTU on L2TP device */
+   dst = sk_dst_get(tunnel->sock);
+   if (dst) {
+   /* dst_mtu will use PMTU if found, else fallback to intf MTU */
+   u32 pmtu = dst_mtu(dst);
+
+   if (pmtu != 0)
+   dev->mtu = pmtu;
+   dst_release(dst);
+   }
+   session->mtu = dev->mtu - overhead;
+   dev->mtu = session->mtu;
+   dev->needed_headroom += session->hdr_len;
+}
+
 static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 
peer_session_id, struct l2tp_session_cfg *cfg)
 {
struct net_device *dev;
@@ -253,12 +299,9 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, 
u32 session_id, u32 p
}
 
dev_net_set(dev, net);
-   if (session->mtu == 0)
-   session->mtu = dev->mtu - session->hdr_len;
-   dev->mtu = session->mtu;
-   dev->needed_headroom += session->hdr_len;
dev->min_mtu = 0;
dev->max_mtu = ETH_MAX_MTU;
+   l2tp_eth_adjust_mtu(tunnel, session, dev);
 
priv = netdev_priv(dev);
priv->dev = dev;
-- 
2.1.4

[git pull] drm fixes for v4.10-rc3.

[Dave Airlie]

Hi Linus,

Bunch of fixes across the drivers, in a St Patrick's day pull request.
(please turn terminal colors to green on black or black on green for full
effect).

On the arm side, tilcdc, omap and malidp got fixes,
while amd has some powermanagement fixes, and intel has a set of fixes
across the driver.

Nothing seems to bad or scary at this point.

Dave.

The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:

  Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.11-rc3

for you to fetch changes up to 27b713c2e08ef27d500a79166098d42b24977500:

  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-03-16
11:28:44 +1000)


amd, intel, tilcdc, omap, and malidp fixes.


Alex Deucher (2):
  drm/radeon/si: add dpm quirk for Oland
  drm/amdgpu/si: add dpm quirk for Oland

Ander Conselvan de Oliveira (1):
  drm/i915/glk: Fix watermark computations for third sprite plane

Arnd Bergmann (1):
  drm: amd: remove broken include path

Chris Wilson (6):
  drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl
  drm/i915/fbdev: Stop repeating tile configuration on stagnation
  drm/i915: Remove the vma from the drm_mm if binding fails
  drm/i915: Store a permanent error in obj->mm.pages
  drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl
  drm/i915: Drain the freed state from the tail of the next commit

Dave Airlie (6):
  drm/amdgpu: fix parser init error path to avoid crash in parser fini
  Merge tag 'tilcdc-4.11-fixes' of https://github.com/jsarha/linux
into drm-fixes
  Merge tag 'omapdrm-4.11-fixes' of
git://git.kernel.org/.../tomba/linux into drm-fixes
  Merge branch 'for-upstream/malidp-fixes' of
git://linux-arm.org/linux-ld into drm-fixes
  Merge tag 'drm-intel-fixes-2017-03-14' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Dmitry V. Levin (1):
  uapi: fix drm/omap_drm.h userspace compilation errors

Imre Deak (1):
  drm/i915/gen9: Increase PCODE request timeout to 50ms

Jyri Sarha (2):
  drm/tilcdc: Fix hardcoded fail-return value in tilcdc_crtc_create()
  drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled

Maarten Lankhorst (2):
  drm/i915: Move updating color management to before vblank evasion
  drm/i915: Nuke skl_update_plane debug message from the pipe
update critical section

Matthew Auld (1):
  drm/i915: use correct node for handling cache domain eviction

Mihail Atanassov (2):
  drm: mali-dp: Remove mclk rate management
  drm: mali-dp: Fix smart layer not going to composition

Mika Kuoppala (1):
  drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

Rex Zhu (1):
  drm/amd/powerplay: fix copy error in smu7_clockpoweragting.c

Tom St Denis (2):
  drm/amd/amdgpu: Disable GFX_PG on Carrizo until compute issues solved
  drm/amd/amdgpu:  Fix debugfs reg read/write address width

Tomi Valkeinen (1):
  drm/omap: fix dmabuf mmap for dma_alloc'ed buffers

Tvrtko Ursulin (1):
  drm/i915: Fix forcewake active domain tracking

Ville Syrjälä (1):
  drm/i915: Nuke debug messages from the pipe update critical section

 drivers/gpu/drm/amd/acp/Makefile   |  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  6 ++
 drivers/gpu/drm/amd/amdgpu/vi.c|  2 +-
 .../amd/powerplay/hwmgr/smu7_clockpowergating.c|  2 +-
 drivers/gpu/drm/arm/malidp_crtc.c  |  3 +-
 drivers/gpu/drm/arm/malidp_hw.c|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c| 18 +++-
 drivers/gpu/drm/arm/malidp_regs.h  |  1 +
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c| 97 +-
 drivers/gpu/drm/i915/i915_gem_evict.c  |  8 +-
 drivers/gpu/drm/i915/i915_gem_object.h |  3 +
 drivers/gpu/drm/i915/i915_vma.c| 57 -
 drivers/gpu/drm/i915/intel_display.c   | 58 ++---
 drivers/gpu/drm/i915/intel_fbdev.c | 10 +--
 drivers/gpu/drm/i915/intel_pm.c| 18 ++--
 drivers/gpu/drm/i915/intel_sprite.c|  3 -
 drivers/gpu/drm/i915/intel_uncore.c| 13 ++-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  3 -
 drivers/gpu/drm/radeon/si_dpm.c|  6 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 37 ++---
 

[git pull] drm fixes for v4.10-rc3.

[Dave Airlie]

Hi Linus,

Bunch of fixes across the drivers, in a St Patrick's day pull request.
(please turn terminal colors to green on black or black on green for full
effect).

On the arm side, tilcdc, omap and malidp got fixes,
while amd has some powermanagement fixes, and intel has a set of fixes
across the driver.

Nothing seems to bad or scary at this point.

Dave.

The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:

  Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.11-rc3

for you to fetch changes up to 27b713c2e08ef27d500a79166098d42b24977500:

  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-03-16
11:28:44 +1000)


amd, intel, tilcdc, omap, and malidp fixes.


Alex Deucher (2):
  drm/radeon/si: add dpm quirk for Oland
  drm/amdgpu/si: add dpm quirk for Oland

Ander Conselvan de Oliveira (1):
  drm/i915/glk: Fix watermark computations for third sprite plane

Arnd Bergmann (1):
  drm: amd: remove broken include path

Chris Wilson (6):
  drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl
  drm/i915/fbdev: Stop repeating tile configuration on stagnation
  drm/i915: Remove the vma from the drm_mm if binding fails
  drm/i915: Store a permanent error in obj->mm.pages
  drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl
  drm/i915: Drain the freed state from the tail of the next commit

Dave Airlie (6):
  drm/amdgpu: fix parser init error path to avoid crash in parser fini
  Merge tag 'tilcdc-4.11-fixes' of https://github.com/jsarha/linux
into drm-fixes
  Merge tag 'omapdrm-4.11-fixes' of
git://git.kernel.org/.../tomba/linux into drm-fixes
  Merge branch 'for-upstream/malidp-fixes' of
git://linux-arm.org/linux-ld into drm-fixes
  Merge tag 'drm-intel-fixes-2017-03-14' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Dmitry V. Levin (1):
  uapi: fix drm/omap_drm.h userspace compilation errors

Imre Deak (1):
  drm/i915/gen9: Increase PCODE request timeout to 50ms

Jyri Sarha (2):
  drm/tilcdc: Fix hardcoded fail-return value in tilcdc_crtc_create()
  drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled

Maarten Lankhorst (2):
  drm/i915: Move updating color management to before vblank evasion
  drm/i915: Nuke skl_update_plane debug message from the pipe
update critical section

Matthew Auld (1):
  drm/i915: use correct node for handling cache domain eviction

Mihail Atanassov (2):
  drm: mali-dp: Remove mclk rate management
  drm: mali-dp: Fix smart layer not going to composition

Mika Kuoppala (1):
  drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

Rex Zhu (1):
  drm/amd/powerplay: fix copy error in smu7_clockpoweragting.c

Tom St Denis (2):
  drm/amd/amdgpu: Disable GFX_PG on Carrizo until compute issues solved
  drm/amd/amdgpu:  Fix debugfs reg read/write address width

Tomi Valkeinen (1):
  drm/omap: fix dmabuf mmap for dma_alloc'ed buffers

Tvrtko Ursulin (1):
  drm/i915: Fix forcewake active domain tracking

Ville Syrjälä (1):
  drm/i915: Nuke debug messages from the pipe update critical section

 drivers/gpu/drm/amd/acp/Makefile   |  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  6 ++
 drivers/gpu/drm/amd/amdgpu/vi.c|  2 +-
 .../amd/powerplay/hwmgr/smu7_clockpowergating.c|  2 +-
 drivers/gpu/drm/arm/malidp_crtc.c  |  3 +-
 drivers/gpu/drm/arm/malidp_hw.c|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c| 18 +++-
 drivers/gpu/drm/arm/malidp_regs.h  |  1 +
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c| 97 +-
 drivers/gpu/drm/i915/i915_gem_evict.c  |  8 +-
 drivers/gpu/drm/i915/i915_gem_object.h |  3 +
 drivers/gpu/drm/i915/i915_vma.c| 57 -
 drivers/gpu/drm/i915/intel_display.c   | 58 ++---
 drivers/gpu/drm/i915/intel_fbdev.c | 10 +--
 drivers/gpu/drm/i915/intel_pm.c| 18 ++--
 drivers/gpu/drm/i915/intel_sprite.c|  3 -
 drivers/gpu/drm/i915/intel_uncore.c| 13 ++-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  3 -
 drivers/gpu/drm/radeon/si_dpm.c|  6 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 37 ++---
 

Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

[David Miller]

From: David Howells 
Date: Thu, 16 Mar 2017 16:27:10 +

> If we receive a BUSY packet for a call we think we've just completed, the
> packet is handed off to the connection processor to deal with - but the
> connection processor doesn't expect a BUSY packet and so flags a protocol
> error.
> 
> Fix this by simply ignoring the BUSY packet for the moment.
> 
> The symptom of this may appear as a system call failing with EPROTO.  This
> may be triggered by pressing ctrl-C under some circumstances.
> 
> This comes about we abort calls due to interruption by a signal (which we
> shouldn't do, but that's going to be a large fix and mostly in fs/afs/).
> What happens is that we abort the call and may also abort follow up calls
> too (this needs offloading somehoe).  So we see a transmission of something
> like the following sequence of packets:
> 
>   DATA for call N
>   ABORT call N
>   DATA for call N+1
>   ABORT call N+1
> 
> in very quick succession on the same channel.  However, the peer may have
> deferred the processing of the ABORT from the call N to a background thread
> and thus sees the DATA message from the call N+1 coming in before it has
> cleared the channel.  Thus it sends a BUSY packet[*].
> 
> [*] Note that some implementations (OpenAFS, for example) mark the BUSY
> packet with one plus the callNumber of the call prior to call N.
> Ordinarily, this would be call N, but there's no requirement for the
> calls on a channel to be numbered strictly sequentially (the number is
> required to increase).
> 
> This is wrong and means that the callNumber in the BUSY packet should
> be ignored (it really ought to be N+1 since that's what it's in
> response to).
> 
> Signed-off-by: David Howells 

Applied, thanks David.

Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

[David Miller]

From: David Howells 
Date: Thu, 16 Mar 2017 16:27:10 +

> If we receive a BUSY packet for a call we think we've just completed, the
> packet is handed off to the connection processor to deal with - but the
> connection processor doesn't expect a BUSY packet and so flags a protocol
> error.
> 
> Fix this by simply ignoring the BUSY packet for the moment.
> 
> The symptom of this may appear as a system call failing with EPROTO.  This
> may be triggered by pressing ctrl-C under some circumstances.
> 
> This comes about we abort calls due to interruption by a signal (which we
> shouldn't do, but that's going to be a large fix and mostly in fs/afs/).
> What happens is that we abort the call and may also abort follow up calls
> too (this needs offloading somehoe).  So we see a transmission of something
> like the following sequence of packets:
> 
>   DATA for call N
>   ABORT call N
>   DATA for call N+1
>   ABORT call N+1
> 
> in very quick succession on the same channel.  However, the peer may have
> deferred the processing of the ABORT from the call N to a background thread
> and thus sees the DATA message from the call N+1 coming in before it has
> cleared the channel.  Thus it sends a BUSY packet[*].
> 
> [*] Note that some implementations (OpenAFS, for example) mark the BUSY
> packet with one plus the callNumber of the call prior to call N.
> Ordinarily, this would be call N, but there's no requirement for the
> calls on a channel to be numbered strictly sequentially (the number is
> required to increase).
> 
> This is wrong and means that the callNumber in the BUSY packet should
> be ignored (it really ought to be N+1 since that's what it's in
> response to).
> 
> Signed-off-by: David Howells 

Applied, thanks David.

[PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[R. Parameswaran]

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: R. Parameswaran 
---
 include/linux/net.h |  3 +++
 net/socket.c| 41 +
 2 files changed, 44 insertions(+)

diff --git a/include/linux/net.h b/include/linux/net.h
index 0620f5e..a42fab2 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -298,6 +298,9 @@ int kernel_sendpage(struct socket *sock, struct page *page, 
int offset,
 int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how);
 
+/* Following routine returns the IP overhead imposed by a socket.  */
+u32 kernel_sock_ip_overhead(struct sock *sk);
+
 #define MODULE_ALIAS_NETPROTO(proto) \
MODULE_ALIAS("net-pf-" __stringify(proto))
 
diff --git a/net/socket.c b/net/socket.c
index e034fe4..af54b12 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3345,3 +3345,44 @@ int kernel_sock_shutdown(struct socket *sock, enum 
sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
 }
 EXPORT_SYMBOL(kernel_sock_shutdown);
+
+/* This routine returns the IP overhead imposed by a socket i.e.
+ * the length of the underlying IP header, depending on whether
+ * this is an IPv4 or IPv6 socket and the length from IP options turned
+ * on at the socket.
+ */
+u32 kernel_sock_ip_overhead(struct sock *sk)
+{
+   struct inet_sock *inet;
+   struct ipv6_pinfo *np;
+   struct ip_options_rcu *opt = NULL;
+   struct ipv6_txoptions *optv6 = NULL;
+   u32 overhead = 0;
+   bool owned_by_user = sock_owned_by_user(sk);
+
+   if (!sk)
+   return overhead;
+   switch (sk->sk_family) {
+   case AF_INET:
+   inet = inet_sk(sk);
+   overhead += sizeof(struct iphdr);
+   if (inet)
+   opt = rcu_dereference_protected(inet->inet_opt,
+   owned_by_user);
+   if (opt)
+   overhead += opt->opt.optlen;
+   return overhead;
+   case AF_INET6:
+   np = inet6_sk(sk);
+   overhead += sizeof(struct ipv6hdr);
+   if (np)
+   optv6 = rcu_dereference_protected(np->opt,
+ owned_by_user);
+   if (optv6)
+   overhead += (optv6->opt_flen + optv6->opt_nflen);
+   return overhead;
+   default: /* Returns 0 overhead if the socket is not ipv4 or ipv6 */
+   return overhead;
+   }
+}
+EXPORT_SYMBOL(kernel_sock_ip_overhead);
-- 
2.1.4

[PATCH net-next v3 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

[R. Parameswaran]

In existing kernel code, when setting up the L2TP interface, all of the
tunnel encapsulation headers are not taken into account when setting
up the MTU on the  L2TP logical interface device. Due to this, the
packets created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, which leads to
needless fragmentation once the L2TP packet is encapsulated in an outer IP
packet.

Specifically, the MTU calculation  does not take into account the (outer)
IP header imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner L2TP packet prior to encapsulation. The patch posted
here takes care of these.

Existing code also seems to assume an Ethernet (non-jumbo) underlay. The
patch uses the PMTU mechanism and the dst entry in the L2TP tunnel socket
to directly pull up the underlay MTU (as the baseline number on top of
which the encapsulation headers are factored in).  Ethernet MTU is
assumed as a fallback only if this fails.

Picked up review comments from James Chapman, added a function
to compute ip header + ip option overhead on a socket, and factored it
into L2TP change-set.

Signed-off-by: R. Parameswaran 
---
 include/linux/net.h |  3 +++
 net/socket.c| 41 +
 2 files changed, 44 insertions(+)

diff --git a/include/linux/net.h b/include/linux/net.h
index 0620f5e..a42fab2 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -298,6 +298,9 @@ int kernel_sendpage(struct socket *sock, struct page *page, 
int offset,
 int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
 int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how);
 
+/* Following routine returns the IP overhead imposed by a socket.  */
+u32 kernel_sock_ip_overhead(struct sock *sk);
+
 #define MODULE_ALIAS_NETPROTO(proto) \
MODULE_ALIAS("net-pf-" __stringify(proto))
 
diff --git a/net/socket.c b/net/socket.c
index e034fe4..af54b12 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3345,3 +3345,44 @@ int kernel_sock_shutdown(struct socket *sock, enum 
sock_shutdown_cmd how)
return sock->ops->shutdown(sock, how);
 }
 EXPORT_SYMBOL(kernel_sock_shutdown);
+
+/* This routine returns the IP overhead imposed by a socket i.e.
+ * the length of the underlying IP header, depending on whether
+ * this is an IPv4 or IPv6 socket and the length from IP options turned
+ * on at the socket.
+ */
+u32 kernel_sock_ip_overhead(struct sock *sk)
+{
+   struct inet_sock *inet;
+   struct ipv6_pinfo *np;
+   struct ip_options_rcu *opt = NULL;
+   struct ipv6_txoptions *optv6 = NULL;
+   u32 overhead = 0;
+   bool owned_by_user = sock_owned_by_user(sk);
+
+   if (!sk)
+   return overhead;
+   switch (sk->sk_family) {
+   case AF_INET:
+   inet = inet_sk(sk);
+   overhead += sizeof(struct iphdr);
+   if (inet)
+   opt = rcu_dereference_protected(inet->inet_opt,
+   owned_by_user);
+   if (opt)
+   overhead += opt->opt.optlen;
+   return overhead;
+   case AF_INET6:
+   np = inet6_sk(sk);
+   overhead += sizeof(struct ipv6hdr);
+   if (np)
+   optv6 = rcu_dereference_protected(np->opt,
+ owned_by_user);
+   if (optv6)
+   overhead += (optv6->opt_flen + optv6->opt_nflen);
+   return overhead;
+   default: /* Returns 0 overhead if the socket is not ipv4 or ipv6 */
+   return overhead;
+   }
+}
+EXPORT_SYMBOL(kernel_sock_ip_overhead);
-- 
2.1.4

[PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

[Chris Zhong]

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is
disabled, MIPI phy can not work. Let's return a error if there is no
phy_cfg_clk in dts property, when the pdata match RK3399.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399

Changes in v2: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..68f48b0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -251,6 +251,8 @@
 #define THS_PRE_PROGRAM_EN BIT(7)
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
+#define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+
 enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -279,6 +281,7 @@ struct dw_mipi_dsi_plat_data {
u32 grf_switch_reg;
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
+   unsigned int flags;
unsigned int max_data_lanes;
 };
 
@@ -1136,6 +1139,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
.max_data_lanes = 4,
 };
 
@@ -1227,15 +1231,13 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(dsi->pclk);
}
 
-   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
-   if (IS_ERR(dsi->phy_cfg_clk)) {
-   ret = PTR_ERR(dsi->phy_cfg_clk);
-   if (ret != -ENOENT) {
+   if (pdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
+   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
+   if (IS_ERR(dsi->phy_cfg_clk)) {
+   ret = PTR_ERR(dsi->phy_cfg_clk);
dev_err(dev, "Unable to get phy_cfg_clk: %d\n", ret);
return ret;
}
-   dsi->phy_cfg_clk = NULL;
-   dev_dbg(dev, "have not phy_cfg_clk\n");
}
 
ret = clk_prepare_enable(dsi->pllref_clk);
-- 
2.6.3

[PATCH v3 1/4] drm/rockchip/dsi: check phy_cfg_clk only for RK3399

[Chris Zhong]

For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is
disabled, MIPI phy can not work. Let's return a error if there is no
phy_cfg_clk in dts property, when the pdata match RK3399.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399

Changes in v2: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..68f48b0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -251,6 +251,8 @@
 #define THS_PRE_PROGRAM_EN BIT(7)
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
+#define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+
 enum {
BANDGAP_97_07,
BANDGAP_98_05,
@@ -279,6 +281,7 @@ struct dw_mipi_dsi_plat_data {
u32 grf_switch_reg;
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
+   unsigned int flags;
unsigned int max_data_lanes;
 };
 
@@ -1136,6 +1139,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
.max_data_lanes = 4,
 };
 
@@ -1227,15 +1231,13 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(dsi->pclk);
}
 
-   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
-   if (IS_ERR(dsi->phy_cfg_clk)) {
-   ret = PTR_ERR(dsi->phy_cfg_clk);
-   if (ret != -ENOENT) {
+   if (pdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
+   dsi->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
+   if (IS_ERR(dsi->phy_cfg_clk)) {
+   ret = PTR_ERR(dsi->phy_cfg_clk);
dev_err(dev, "Unable to get phy_cfg_clk: %d\n", ret);
return ret;
}
-   dsi->phy_cfg_clk = NULL;
-   dev_dbg(dev, "have not phy_cfg_clk\n");
}
 
ret = clk_prepare_enable(dsi->pllref_clk);
-- 
2.6.3

[PATCH v3 0/4] RK3399 dw-mipi-dsi patches

[Chris Zhong]

Hi all

This series set the phy_cfg_clk to be a required clock for RK3399, and
add a grf clock control in dw-mipi-dsi driver. And then correct a
register name.


Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

Chris Zhong (4):
  drm/rockchip/dsi: check phy_cfg_clk only for RK3399
  dt-bindings: add the grf clock for dw-mipi-dsi
  drm/rockchip/dsi: enable the grf clk before writing grf registers
  drm/rockchip/dsi: correct the grf_switch_reg name

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 42 +-
 2 files changed, 35 insertions(+), 9 deletions(-)

-- 
2.6.3

[PATCH v3 0/4] RK3399 dw-mipi-dsi patches

[Chris Zhong]

Hi all

This series set the phy_cfg_clk to be a required clock for RK3399, and
add a grf clock control in dw-mipi-dsi driver. And then correct a
register name.


Changes in v3:
- add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

Chris Zhong (4):
  drm/rockchip/dsi: check phy_cfg_clk only for RK3399
  dt-bindings: add the grf clock for dw-mipi-dsi
  drm/rockchip/dsi: enable the grf clk before writing grf registers
  drm/rockchip/dsi: correct the grf_switch_reg name

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 42 +-
 2 files changed, 35 insertions(+), 9 deletions(-)

-- 
2.6.3

[PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

[Chris Zhong]

For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 68f48b0..5a18281 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -252,6 +252,7 @@
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
 #define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+#define DW_MIPI_NEEDS_GRF_CLK  BIT(1)
 
 enum {
BANDGAP_97_07,
@@ -294,6 +295,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
 
+   struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -982,6 +984,17 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
 
+   /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register. And for RK3288 or other soc, this grf_clk must be NULL,
+* the clk_prepare_enable return true directly.
+*/
+   ret = clk_prepare_enable(dsi->grf_clk);
+   if (ret) {
+   dev_err(dsi->dev, "Failed to enable grf_clk\n");
+   return;
+   }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
 pdata->grf_dsi0_mode);
@@ -1006,6 +1019,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
dsi->dpms_mode = DRM_MODE_DPMS_ON;
+
+   clk_disable_unprepare(dsi->grf_clk);
 }
 
 static int
@@ -1139,7 +1154,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
-   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
 };
 
@@ -1240,6 +1255,15 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
}
}
 
+   if (pdata->flags & DW_MIPI_NEEDS_GRF_CLK) {
+   dsi->grf_clk = devm_clk_get(dev, "grf");
+   if (IS_ERR(dsi->grf_clk)) {
+   ret = PTR_ERR(dsi->grf_clk);
+   dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+   return ret;
+   }
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
-- 
2.6.3

[PATCH v3 3/4] drm/rockchip/dsi: enable the grf clk before writing grf registers

[Chris Zhong]

For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- add a DW_MIPI_NEEDS_GRF_CLK for RK3399

Changes in v2:
- check the grf_clk only for RK3399

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 68f48b0..5a18281 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -252,6 +252,7 @@
 #define THS_ZERO_PROGRAM_ENBIT(6)
 
 #define DW_MIPI_NEEDS_PHY_CFG_CLK  BIT(0)
+#define DW_MIPI_NEEDS_GRF_CLK  BIT(1)
 
 enum {
BANDGAP_97_07,
@@ -294,6 +295,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
 
+   struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -982,6 +984,17 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
 
+   /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register. And for RK3288 or other soc, this grf_clk must be NULL,
+* the clk_prepare_enable return true directly.
+*/
+   ret = clk_prepare_enable(dsi->grf_clk);
+   if (ret) {
+   dev_err(dsi->dev, "Failed to enable grf_clk\n");
+   return;
+   }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
 pdata->grf_dsi0_mode);
@@ -1006,6 +1019,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder 
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
dsi->dpms_mode = DRM_MODE_DPMS_ON;
+
+   clk_disable_unprepare(dsi->grf_clk);
 }
 
 static int
@@ -1139,7 +1154,7 @@ static struct dw_mipi_dsi_plat_data 
rk3399_mipi_dsi_drv_data = {
.grf_switch_reg = RK3399_GRF_SOC_CON19,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
-   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK,
+   .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
 };
 
@@ -1240,6 +1255,15 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
}
}
 
+   if (pdata->flags & DW_MIPI_NEEDS_GRF_CLK) {
+   dsi->grf_clk = devm_clk_get(dev, "grf");
+   if (IS_ERR(dsi->grf_clk)) {
+   ret = PTR_ERR(dsi->grf_clk);
+   dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+   return ret;
+   }
+   }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
-- 
2.6.3

[PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Chris Zhong]

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
add the description for this clock.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 188f6f7..7e17a60 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -10,7 +10,7 @@ Required properties:
 - interrupts: Represent the controller's interrupt to the CPU(s).
 - clocks, clock-names: Phandles to the controller's pll reference
   clock(ref) and APB clock(pclk). For RK3399, a phy config clock
-  (phy_cfg) is additional required. As described in [1].
+  (phy_cfg) and a grf clock(grf) are additional required. As described in [1].
 - rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
-- 
2.6.3

[PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

[Chris Zhong]

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5a18281..19b9208 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
 #define RK3288_DSI0_SEL_VOP_LITBIT(6)
 #define RK3288_DSI1_SEL_VOP_LITBIT(9)
 
-#define RK3399_GRF_SOC_CON19   0x6250
+#define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_DSI0_SEL_VOP_LITBIT(0)
 #define RK3399_DSI1_SEL_VOP_LITBIT(4)
 
@@ -1151,7 +1151,7 @@ static struct dw_mipi_dsi_plat_data 
rk3288_mipi_dsi_drv_data = {
 static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
-   .grf_switch_reg = RK3399_GRF_SOC_CON19,
+   .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
-- 
2.6.3

[PATCH v3 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Chris Zhong]

For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
add the description for this clock.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 188f6f7..7e17a60 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -10,7 +10,7 @@ Required properties:
 - interrupts: Represent the controller's interrupt to the CPU(s).
 - clocks, clock-names: Phandles to the controller's pll reference
   clock(ref) and APB clock(pclk). For RK3399, a phy config clock
-  (phy_cfg) is additional required. As described in [1].
+  (phy_cfg) and a grf clock(grf) are additional required. As described in [1].
 - rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
 - ports: contain a port node with endpoint definitions as defined in [2].
   For vopb,set the reg = <0> and set the reg = <1> for vopl.
-- 
2.6.3

[PATCH v3 4/4] drm/rockchip/dsi: correct the grf_switch_reg name

[Chris Zhong]

For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5a18281..19b9208 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
 #define RK3288_DSI0_SEL_VOP_LITBIT(6)
 #define RK3288_DSI1_SEL_VOP_LITBIT(9)
 
-#define RK3399_GRF_SOC_CON19   0x6250
+#define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_DSI0_SEL_VOP_LITBIT(0)
 #define RK3399_DSI1_SEL_VOP_LITBIT(4)
 
@@ -1151,7 +1151,7 @@ static struct dw_mipi_dsi_plat_data 
rk3288_mipi_dsi_drv_data = {
 static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
-   .grf_switch_reg = RK3399_GRF_SOC_CON19,
+   .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
-- 
2.6.3

[PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 695 +
 4 files changed, 744 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,695 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren 
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap 
Cc: Michael Scott 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 695 +
 4 files changed, 744 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,695 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright (C) 2017 Tony Lindgren 
+ *
+ * Some parts based on earlier Motorola Linux kernel tree code in
+ * board-mapphone-usb.c and cpcap-usb-det.c:
+ * Copyright (C) 2007 - 2011 Motorola, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 

Re: [PATCH v2] net: sun: sungem: rix a possible null dereference

[David Miller]

From: Philippe Reynes 
Date: Wed, 15 Mar 2017 22:51:13 +0100

> The function gem_begin_auto_negotiation dereference
> the pointer ep before testing if it's null. This
> patch add a check on ep before dereferencing it.
> 
> Fixes: 92552fdd557 ("net: sun: sungem: use new api

[davem@localhost net-next]$ git describe 92552fdd557
fatal: Not a valid object name 92552fdd557
[davem@localhost net-next]$

I don't know where you got that SHA1-ID, but it's not the one that
was actually used.

It is advised that you use Linus's or one of my GIT trees to find the
proper commit IDs.

Re: [PATCH v2] net: sun: sungem: rix a possible null dereference

[David Miller]

From: Philippe Reynes 
Date: Wed, 15 Mar 2017 22:51:13 +0100

> The function gem_begin_auto_negotiation dereference
> the pointer ep before testing if it's null. This
> patch add a check on ep before dereferencing it.
> 
> Fixes: 92552fdd557 ("net: sun: sungem: use new api

[davem@localhost net-next]$ git describe 92552fdd557
fatal: Not a valid object name 92552fdd557
[davem@localhost net-next]$

I don't know where you got that SHA1-ID, but it's not the one that
was actually used.

It is advised that you use Linus's or one of my GIT trees to find the
proper commit IDs.

[PATCH] sched/core: Fix rq lock pinning warning after call balance callbacks

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running rt-migrate-test:

 WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 
lock_unpin_lock+0x172/0x180
 unpinning an unpinned lock
 CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW   4.11.0-rc2+ #1
 Call Trace:
  dump_stack+0x85/0xc2
  __warn+0xcb/0xf0
  warn_slowpath_fmt+0x5f/0x80
  lock_unpin_lock+0x172/0x180
  __balance_callback+0x75/0x90
  __schedule+0x83f/0xc00
  ? futex_wait_setup+0x82/0x130
  schedule+0x3d/0x90
  futex_wait_queue_me+0xd4/0x170
  futex_wait+0x119/0x260
  ? __lock_acquire+0x4c8/0x1900
  ? stop_one_cpu+0x94/0xc0
  do_futex+0x2fe/0xc10
  ? sched_setaffinity+0x1c1/0x290
  SyS_futex+0x81/0x190
  ? rcu_read_lock_sched_held+0x72/0x80
  do_syscall_64+0x73/0x1f0
  entry_SYSCALL64_slow_path+0x25/0x25

We utilize balance callbacks to delay the load-balancing operations 
{rt,dl}*{push,pull} until we've done all the important work. The 
push/pull operations can unlock/lock the current rq for safety acquires 
the src's and dest's rq->locks in a fair way. It's safe to drop the 
rq lock here, unpin and repin to avoid the splat.

Reported-by: Fengguang Wu 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Wanpeng Li 
---
 kernel/sched/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c762f62..cd901f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2787,7 +2787,9 @@ static void __balance_callback(struct rq *rq)
head->next = NULL;
head = next;
 
+   rq_unpin_lock(rq, );
func(rq);
+   rq_repin_lock(rq, );
}
rq_unlock_irqrestore(rq, );
 }
-- 
2.7.4

[PATCH] sched/core: Fix rq lock pinning warning after call balance callbacks

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by running rt-migrate-test:

 WARNING: CPU: 2 PID: 2195 at kernel/locking/lockdep.c:3670 
lock_unpin_lock+0x172/0x180
 unpinning an unpinned lock
 CPU: 2 PID: 2195 Comm: rt-migrate-test Tainted: GW   4.11.0-rc2+ #1
 Call Trace:
  dump_stack+0x85/0xc2
  __warn+0xcb/0xf0
  warn_slowpath_fmt+0x5f/0x80
  lock_unpin_lock+0x172/0x180
  __balance_callback+0x75/0x90
  __schedule+0x83f/0xc00
  ? futex_wait_setup+0x82/0x130
  schedule+0x3d/0x90
  futex_wait_queue_me+0xd4/0x170
  futex_wait+0x119/0x260
  ? __lock_acquire+0x4c8/0x1900
  ? stop_one_cpu+0x94/0xc0
  do_futex+0x2fe/0xc10
  ? sched_setaffinity+0x1c1/0x290
  SyS_futex+0x81/0x190
  ? rcu_read_lock_sched_held+0x72/0x80
  do_syscall_64+0x73/0x1f0
  entry_SYSCALL64_slow_path+0x25/0x25

We utilize balance callbacks to delay the load-balancing operations 
{rt,dl}*{push,pull} until we've done all the important work. The 
push/pull operations can unlock/lock the current rq for safety acquires 
the src's and dest's rq->locks in a fair way. It's safe to drop the 
rq lock here, unpin and repin to avoid the splat.

Reported-by: Fengguang Wu 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Wanpeng Li 
---
 kernel/sched/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c762f62..cd901f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2787,7 +2787,9 @@ static void __balance_callback(struct rq *rq)
head->next = NULL;
head = next;
 
+   rq_unpin_lock(rq, );
func(rq);
+   rq_repin_lock(rq, );
}
rq_unlock_irqrestore(rq, );
 }
-- 
2.7.4

[PATCH v2 2/3] arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs

[Jianqun Xu]

I2S of RK3368 SoCs keep same as RK3066 SoCs found on Rockchip,
add nodes to support them.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- fix compile error caused by dumplicate label 'i2s1'


 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 38 
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index c9be1b2..74fbcc2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -715,6 +715,30 @@
interrupts = ;
};
 
+   i2s_2ch: i2s-2ch@ff89 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff89 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 6>, <_bus 7>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_2CH>, < HCLK_I2S_2CH>;
+   status = "disabled";
+   };
+
+   i2s_8ch: i2s-8ch@ff898000 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff898000 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 0>, <_bus 1>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_8CH>, < HCLK_I2S_8CH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_8ch_bus>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffb71000 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -917,6 +941,20 @@
};
};
 
+   i2s {
+   i2s_8ch_bus: i2s-8ch-bus {
+   rockchip,pins = <2 12 RK_FUNC_1 
_pull_none>,
+   <2 13 RK_FUNC_1 
_pull_none>,
+   <2 14 RK_FUNC_1 
_pull_none>,
+   <2 15 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 18 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none>,
+   <2 20 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <3 8 RK_FUNC_2 _pull_none>;
-- 
1.9.1

Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property

[Chen-Yu Tsai]

On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring  wrote:
> On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote:
>> The Allwinner Timings Controller has two, mutually exclusive, channels.
>> When the binding has been introduced, it was assumed that there would be
>> only a single user per channel in the system.
>>
>> While this is likely for the channel 0 which only connects to LCD displays,
>> it turns out that the channel 1 can be connected to multiple controllers in
>> the SoC (HDMI and TV encoders for example). And while the simultaneous use
>> of HDMI and TV outputs cannot be achieved, switching from one to the other
>> at runtime definitely sounds plausible.
>>
>> Add an extra property, allwinner,tcon-channel, to specify for a given
>> endpoint which TCON channel it is connected to, while falling back to the
>> previous mechanism if that property is missing.
>
> I think perhaps TCON channels should have been ports rather than
> endpoints. The fact that the channels are mutually exclusive can be
> handled in the driver and doesn't really matter in the binding. How
> painful would it be to rework things to move TCON channel 1 from port 0,
> endpoint 1 to port 1?

Having a separate output port for channel 1 was one option we discussed.
However it wouldn't work well with the kernel's of_graph based crtc
detection (drm_of_find_possible_crtcs / drm_of_find_possible_crtcs),
which has the crtcs bound via the output port. As the logic is used
by multiple drivers, I'm not sure it's easy to rework or test.

Also, we still have to support old device trees using channel 1 from
output port 0 endpoint 1. This is the TV encoder on sun5i (A10s/A13/R8).

Regards
ChenYu

[PATCH v2 2/3] arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs

[Jianqun Xu]

I2S of RK3368 SoCs keep same as RK3066 SoCs found on Rockchip,
add nodes to support them.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- fix compile error caused by dumplicate label 'i2s1'


 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 38 
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index c9be1b2..74fbcc2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -715,6 +715,30 @@
interrupts = ;
};
 
+   i2s_2ch: i2s-2ch@ff89 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff89 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 6>, <_bus 7>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_2CH>, < HCLK_I2S_2CH>;
+   status = "disabled";
+   };
+
+   i2s_8ch: i2s-8ch@ff898000 {
+   compatible = "rockchip,rk3368-i2s", "rockchip,rk3066-i2s";
+   reg = <0x0 0xff898000 0x0 0x1000>;
+   interrupts = ;
+   dmas = <_bus 0>, <_bus 1>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_clk", "i2s_hclk";
+   clocks = < SCLK_I2S_8CH>, < HCLK_I2S_8CH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_8ch_bus>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffb71000 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -917,6 +941,20 @@
};
};
 
+   i2s {
+   i2s_8ch_bus: i2s-8ch-bus {
+   rockchip,pins = <2 12 RK_FUNC_1 
_pull_none>,
+   <2 13 RK_FUNC_1 
_pull_none>,
+   <2 14 RK_FUNC_1 
_pull_none>,
+   <2 15 RK_FUNC_1 
_pull_none>,
+   <2 16 RK_FUNC_1 
_pull_none>,
+   <2 17 RK_FUNC_1 
_pull_none>,
+   <2 18 RK_FUNC_1 
_pull_none>,
+   <2 19 RK_FUNC_1 
_pull_none>,
+   <2 20 RK_FUNC_1 
_pull_none>;
+   };
+   };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <3 8 RK_FUNC_2 _pull_none>;
-- 
1.9.1

Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property

[Chen-Yu Tsai]

On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring  wrote:
> On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote:
>> The Allwinner Timings Controller has two, mutually exclusive, channels.
>> When the binding has been introduced, it was assumed that there would be
>> only a single user per channel in the system.
>>
>> While this is likely for the channel 0 which only connects to LCD displays,
>> it turns out that the channel 1 can be connected to multiple controllers in
>> the SoC (HDMI and TV encoders for example). And while the simultaneous use
>> of HDMI and TV outputs cannot be achieved, switching from one to the other
>> at runtime definitely sounds plausible.
>>
>> Add an extra property, allwinner,tcon-channel, to specify for a given
>> endpoint which TCON channel it is connected to, while falling back to the
>> previous mechanism if that property is missing.
>
> I think perhaps TCON channels should have been ports rather than
> endpoints. The fact that the channels are mutually exclusive can be
> handled in the driver and doesn't really matter in the binding. How
> painful would it be to rework things to move TCON channel 1 from port 0,
> endpoint 1 to port 1?

Having a separate output port for channel 1 was one option we discussed.
However it wouldn't work well with the kernel's of_graph based crtc
detection (drm_of_find_possible_crtcs / drm_of_find_possible_crtcs),
which has the crtcs bound via the output port. As the logic is used
by multiple drivers, I'm not sure it's easy to rework or test.

Also, we still have to support old device trees using channel 1 from
output port 0 endpoint 1. This is the TV encoder on sun5i (A10s/A13/R8).

Regards
ChenYu

[PATCH v2 1/3] arm64: dts: rockchip: add amba node support for RK3368 SoCs

[Jianqun Xu]

There are two dmacs found on RK3368 SoCs, peripher dmac and bus dmac,
and the dmacs are same as previous SoCs' dmac.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- none

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a635adc..c9be1b2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -204,6 +204,37 @@
 <_b2>, <_b3>;
};
 
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   dmac_peri: dma-controller@ff25 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff25 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_PERI>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+
+   dmac_bus: dma-controller@ff60 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff60 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_BUS>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+   };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
-- 
1.9.1

[PATCH 0/3] arm64: dts: rockchip: rk3368 add dmac and i2s nodes

[Jianqun Xu]

These patches add dmac, i2s nodes, and disable mailbox.

Jianqun Xu (3):
  arm64: dts: rockchip: add amba node support for RK3368 SoCs
  arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs
  arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 70 
 1 file changed, 70 insertions(+)

-- 
1.9.1

[PATCH 0/3] arm64: dts: rockchip: rk3368 add dmac and i2s nodes

[Jianqun Xu]

These patches add dmac, i2s nodes, and disable mailbox.

Jianqun Xu (3):
  arm64: dts: rockchip: add amba node support for RK3368 SoCs
  arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs
  arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 70 
 1 file changed, 70 insertions(+)

-- 
1.9.1

[PATCH v2 1/3] arm64: dts: rockchip: add amba node support for RK3368 SoCs

[Jianqun Xu]

There are two dmacs found on RK3368 SoCs, peripher dmac and bus dmac,
and the dmacs are same as previous SoCs' dmac.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- none

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a635adc..c9be1b2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -204,6 +204,37 @@
 <_b2>, <_b3>;
};
 
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   dmac_peri: dma-controller@ff25 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff25 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_PERI>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+
+   dmac_bus: dma-controller@ff60 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x0 0xff60 0x0 0x4000>;
+   interrupts = ,
+;
+   #dma-cells = <1>;
+   clocks = < ACLK_DMAC_BUS>;
+   clock-names = "apb_pclk";
+   arm,pl330-broken-no-flushp;
+   peripherals-req-type-burst;
+   };
+   };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
-- 
1.9.1

[PATCH v2] kexec: Introduce vmcoreinfo signature verification

[Xunlei Pang]

Currently vmcoreinfo data is updated at boot time subsys_initcall(),
it has the risk of being modified by some wrong code during system
is running.

As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
when using "crash" or "makedumpfile"(etc) utility to parse this vmcore,
we probably will get "Segmentation fault" or other unexpected/confusing
errors.

As vmcoreinfo is the most fundamental information for vmcore, we better
double check its correctness. Here we generate a signature(using crc32)
after it is saved, then verify it in crash_save_vmcoreinfo() to see if
the signature was broken, if so we have to re-save the vmcoreinfo data
to get the correct vmcoreinfo for kdump as possible as we can.

Signed-off-by: Xunlei Pang 
---
v1->v2:
- Keep crash_save_vmcoreinfo_init() because "makedumpfile --mem-usage"
  uses the information.
- Add crc32 verification for vmcoreinfo, re-save when failure.

 arch/Kconfig|  1 +
 kernel/kexec_core.c | 43 +++
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index c4d6833..66eb296 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -4,6 +4,7 @@
 
 config KEXEC_CORE
bool
+   select CRC32
 
 config HAVE_IMA_KEXEC
bool
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index bfe62d5..012acbe 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -53,9 +54,10 @@
 
 /* vmcoreinfo stuff */
 static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
-u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
+static u32 vmcoreinfo_sig;
 size_t vmcoreinfo_size;
 size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
+u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
 
 /* Flag to indicate we are going to kexec a new kernel */
 bool kexec_in_progress = false;
@@ -1367,12 +1369,6 @@ static void update_vmcoreinfo_note(void)
final_note(buf);
 }
 
-void crash_save_vmcoreinfo(void)
-{
-   vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
-   update_vmcoreinfo_note();
-}
-
 void vmcoreinfo_append_str(const char *fmt, ...)
 {
va_list args;
@@ -1402,7 +1398,7 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
return __pa_symbol((unsigned long)(char *)_note);
 }
 
-static int __init crash_save_vmcoreinfo_init(void)
+static void do_crash_save_vmcoreinfo_init(void)
 {
VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
VMCOREINFO_PAGESIZE(PAGE_SIZE);
@@ -1474,6 +1470,37 @@ static int __init crash_save_vmcoreinfo_init(void)
 #endif
 
arch_crash_save_vmcoreinfo();
+}
+
+static u32 crash_calc_vmcoreinfo_sig(void)
+{
+   return crc32(~0, vmcoreinfo_data, vmcoreinfo_size);
+}
+
+static bool crash_verify_vmcoreinfo(void)
+{
+   if (crash_calc_vmcoreinfo_sig() == vmcoreinfo_sig)
+   return true;
+
+   return false;
+}
+
+void crash_save_vmcoreinfo(void)
+{
+   /* Re-save if verification fails */
+   if (!crash_verify_vmcoreinfo()) {
+   vmcoreinfo_size = 0;
+   do_crash_save_vmcoreinfo_init();
+   }
+
+   vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
+   update_vmcoreinfo_note();
+}
+
+static int __init crash_save_vmcoreinfo_init(void)
+{
+   do_crash_save_vmcoreinfo_init();
+   vmcoreinfo_sig = crash_calc_vmcoreinfo_sig();
update_vmcoreinfo_note();
 
return 0;
-- 
1.8.3.1

[PATCH v2] kexec: Introduce vmcoreinfo signature verification

[Xunlei Pang]

Currently vmcoreinfo data is updated at boot time subsys_initcall(),
it has the risk of being modified by some wrong code during system
is running.

As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on,
when using "crash" or "makedumpfile"(etc) utility to parse this vmcore,
we probably will get "Segmentation fault" or other unexpected/confusing
errors.

As vmcoreinfo is the most fundamental information for vmcore, we better
double check its correctness. Here we generate a signature(using crc32)
after it is saved, then verify it in crash_save_vmcoreinfo() to see if
the signature was broken, if so we have to re-save the vmcoreinfo data
to get the correct vmcoreinfo for kdump as possible as we can.

Signed-off-by: Xunlei Pang 
---
v1->v2:
- Keep crash_save_vmcoreinfo_init() because "makedumpfile --mem-usage"
  uses the information.
- Add crc32 verification for vmcoreinfo, re-save when failure.

 arch/Kconfig|  1 +
 kernel/kexec_core.c | 43 +++
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index c4d6833..66eb296 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -4,6 +4,7 @@
 
 config KEXEC_CORE
bool
+   select CRC32
 
 config HAVE_IMA_KEXEC
bool
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index bfe62d5..012acbe 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -53,9 +54,10 @@
 
 /* vmcoreinfo stuff */
 static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
-u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
+static u32 vmcoreinfo_sig;
 size_t vmcoreinfo_size;
 size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
+u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
 
 /* Flag to indicate we are going to kexec a new kernel */
 bool kexec_in_progress = false;
@@ -1367,12 +1369,6 @@ static void update_vmcoreinfo_note(void)
final_note(buf);
 }
 
-void crash_save_vmcoreinfo(void)
-{
-   vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
-   update_vmcoreinfo_note();
-}
-
 void vmcoreinfo_append_str(const char *fmt, ...)
 {
va_list args;
@@ -1402,7 +1398,7 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
return __pa_symbol((unsigned long)(char *)_note);
 }
 
-static int __init crash_save_vmcoreinfo_init(void)
+static void do_crash_save_vmcoreinfo_init(void)
 {
VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
VMCOREINFO_PAGESIZE(PAGE_SIZE);
@@ -1474,6 +1470,37 @@ static int __init crash_save_vmcoreinfo_init(void)
 #endif
 
arch_crash_save_vmcoreinfo();
+}
+
+static u32 crash_calc_vmcoreinfo_sig(void)
+{
+   return crc32(~0, vmcoreinfo_data, vmcoreinfo_size);
+}
+
+static bool crash_verify_vmcoreinfo(void)
+{
+   if (crash_calc_vmcoreinfo_sig() == vmcoreinfo_sig)
+   return true;
+
+   return false;
+}
+
+void crash_save_vmcoreinfo(void)
+{
+   /* Re-save if verification fails */
+   if (!crash_verify_vmcoreinfo()) {
+   vmcoreinfo_size = 0;
+   do_crash_save_vmcoreinfo_init();
+   }
+
+   vmcoreinfo_append_str("CRASHTIME=%ld\n", get_seconds());
+   update_vmcoreinfo_note();
+}
+
+static int __init crash_save_vmcoreinfo_init(void)
+{
+   do_crash_save_vmcoreinfo_init();
+   vmcoreinfo_sig = crash_calc_vmcoreinfo_sig();
update_vmcoreinfo_note();
 
return 0;
-- 
1.8.3.1

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Balbir Singh]

>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT?
>>
>
> Yes, that was my first reaction too, but these particular routines are
> aspiring to be generic routines--in fact, you have had an influence there,
> because these might possibly help with NUMA migrations. :)
>

Yes, I still stick to them being generic, but I'd be OK if they worked
just for 64 bit systems.
Having said that even the 64 bit works version work for upto physical
sizes of 64 - PAGE_SHIFT
which is a little limiting I think.

One option is to make pfn's unsigned long long and do 32 and 64 bit computations
separately

Option 2, could be something like you said

a. Define a __weak migrate_vma to return -EINVAL
b. In a 64BIT only file define migrate_vma

Option 3

Something totally different

If we care to support 32 bit we go with 1, else option 2 is a good
starting point. There might
be other ways of doing option 2, like you've suggested

Balbir

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Balbir Singh]

>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT?
>>
>
> Yes, that was my first reaction too, but these particular routines are
> aspiring to be generic routines--in fact, you have had an influence there,
> because these might possibly help with NUMA migrations. :)
>

Yes, I still stick to them being generic, but I'd be OK if they worked
just for 64 bit systems.
Having said that even the 64 bit works version work for upto physical
sizes of 64 - PAGE_SHIFT
which is a little limiting I think.

One option is to make pfn's unsigned long long and do 32 and 64 bit computations
separately

Option 2, could be something like you said

a. Define a __weak migrate_vma to return -EINVAL
b. In a 64BIT only file define migrate_vma

Option 3

Something totally different

If we care to support 32 bit we go with 1, else option 2 is a good
starting point. There might
be other ways of doing option 2, like you've suggested

Balbir

[PATCH v2 3/3] arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

[Jianqun Xu]

Default to disable mailbox in rk3368 core dts file.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- none

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 74fbcc2..eeb31f1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -662,6 +662,7 @@
clocks = < PCLK_MAILBOX>;
clock-names = "pclk_mailbox";
#mbox-cells = <1>;
+   status = "disabled";
};
 
pmugrf: syscon@ff738000 {
-- 
1.9.1

[PATCH v2 3/3] arm64: dts: rockchip: disable mailbox of RK3368 SoCs defaultly

[Jianqun Xu]

Default to disable mailbox in rk3368 core dts file.

Signed-off-by: Jianqun Xu 
---
changes since v1:
- none

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 74fbcc2..eeb31f1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -662,6 +662,7 @@
clocks = < PCLK_MAILBOX>;
clock-names = "pclk_mailbox";
#mbox-cells = <1>;
+   status = "disabled";
};
 
pmugrf: syscon@ff738000 {
-- 
1.9.1

RE: [PATCH net-next] r8152: simply the arguments

[Hayes Wang]

David Laight [mailto:david.lai...@aculab.com]
> Sent: Thursday, March 16, 2017 10:28 PM
[...]
> If you are really lucky the compiler will optimise it away.
> Otherwise it will generate another local variable and possibly
> a register spill to stack.

However, I could reduce the time for calculating the address,
because I only calculate it once and save the result to a variable.
Right?

Best Regards,
Hayes

RE: [PATCH net-next] r8152: simply the arguments

[Hayes Wang]

David Laight [mailto:david.lai...@aculab.com]
> Sent: Thursday, March 16, 2017 10:28 PM
[...]
> If you are really lucky the compiler will optimise it away.
> Otherwise it will generate another local variable and possibly
> a register spill to stack.

However, I could reduce the time for calculating the address,
because I only calculate it once and save the result to a variable.
Right?

Best Regards,
Hayes

[PATCH] f2fs: don't allow volatile writes for non-regular file

[Chao Yu]

Now f2fs only supports volatile writes for journal db regular file.

Signed-off-by: Chao Yu 
---
 fs/f2fs/file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index d486e02b43c2..e090d34f732d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1593,6 +1593,9 @@ static int f2fs_ioc_start_volatile_write(struct file 
*filp)
if (!inode_owner_or_capable(inode))
return -EACCES;
 
+   if (!S_ISREG(inode))
+   return -EINVAL;
+
ret = mnt_want_write_file(filp);
if (ret)
return ret;
-- 
2.8.2.295.g3f1c1d0

[PATCH] f2fs: don't allow volatile writes for non-regular file

[Chao Yu]

Now f2fs only supports volatile writes for journal db regular file.

Signed-off-by: Chao Yu 
---
 fs/f2fs/file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index d486e02b43c2..e090d34f732d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1593,6 +1593,9 @@ static int f2fs_ioc_start_volatile_write(struct file 
*filp)
if (!inode_owner_or_capable(inode))
return -EACCES;
 
+   if (!S_ISREG(inode))
+   return -EINVAL;
+
ret = mnt_want_write_file(filp);
if (ret)
return ret;
-- 
2.8.2.295.g3f1c1d0

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Andrew Morton]

On Thu, 16 Mar 2017 21:52:23 -0400 (EDT) Jerome Glisse  
wrote:

> The original intention was for it to be 64bit only, 32bit is a dying
> species and before splitting out hmm_ prefix from this code and moving
> it to be generic it was behind a 64bit flag.
> 
> If latter one someone really care about 32bit we can only move to u64

I think that's the best compromise.  If someone wants this on 32-bit
then they're free to get it working.  That "someone" will actually be
able to test it, which you clearly won't be doing!

However, please do check that the impact of this patchset on 32-bit's
`size vmlinux' is minimal.  Preferably zero.

[PATCH net-next] r8152: check hw version first

[Hayes Wang]

Check hw version first in probe(). Do nothing if the driver doesn't
support the chip.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 102 ++--
 1 file changed, 63 insertions(+), 39 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4b85e95..3262a32 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4236,44 +4236,6 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_features_check = rtl8152_features_check,
 };
 
-static void r8152b_get_version(struct r8152 *tp)
-{
-   u32 ocp_data;
-   u16 version;
-
-   ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR1);
-   version = (u16)(ocp_data & VERSION_MASK);
-
-   switch (version) {
-   case 0x4c00:
-   tp->version = RTL_VER_01;
-   break;
-   case 0x4c10:
-   tp->version = RTL_VER_02;
-   break;
-   case 0x5c00:
-   tp->version = RTL_VER_03;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c10:
-   tp->version = RTL_VER_04;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c20:
-   tp->version = RTL_VER_05;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c30:
-   tp->version = RTL_VER_06;
-   tp->mii.supports_gmii = 1;
-   break;
-   default:
-   netif_info(tp, probe, tp->netdev,
-  "Unknown version 0x%04x\n", version);
-   break;
-   }
-}
-
 static void rtl8152_unload(struct r8152 *tp)
 {
if (test_bit(RTL8152_UNPLUG, >flags))
@@ -4338,14 +4300,66 @@ static int rtl_ops_init(struct r8152 *tp)
return ret;
 }
 
+static u8 rtl_get_version(struct usb_interface *intf)
+{
+   struct usb_device *udev = interface_to_usbdev(intf);
+   u32 ocp_data = 0;
+   __le32 *tmp;
+   u8 version;
+   int ret;
+
+   tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+   if (!tmp)
+   return 0;
+
+   ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+ PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500);
+   if (ret > 0)
+   ocp_data = (__le32_to_cpu(*tmp) >> 16) & VERSION_MASK;
+
+   kfree(tmp);
+
+   switch (ocp_data) {
+   case 0x4c00:
+   version = RTL_VER_01;
+   break;
+   case 0x4c10:
+   version = RTL_VER_02;
+   break;
+   case 0x5c00:
+   version = RTL_VER_03;
+   break;
+   case 0x5c10:
+   version = RTL_VER_04;
+   break;
+   case 0x5c20:
+   version = RTL_VER_05;
+   break;
+   case 0x5c30:
+   version = RTL_VER_06;
+   break;
+   default:
+   version = RTL_VER_UNKNOWN;
+   dev_info(>dev, "Unknown version 0x%04x\n", ocp_data);
+   break;
+   }
+
+   return version;
+}
+
 static int rtl8152_probe(struct usb_interface *intf,
 const struct usb_device_id *id)
 {
struct usb_device *udev = interface_to_usbdev(intf);
+   u8 version = rtl_get_version(intf);
struct r8152 *tp;
struct net_device *netdev;
int ret;
 
+   if (version == RTL_VER_UNKNOWN)
+   return -ENODEV;
+
if (udev->actconfig->desc.bConfigurationValue != 1) {
usb_driver_set_configuration(udev, 1);
return -ENODEV;
@@ -4365,8 +4379,18 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->udev = udev;
tp->netdev = netdev;
tp->intf = intf;
+   tp->version = version;
+
+   switch (version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   tp->mii.supports_gmii = 0;
+   break;
+   default:
+   tp->mii.supports_gmii = 1;
+   break;
+   }
 
-   r8152b_get_version(tp);
ret = rtl_ops_init(tp);
if (ret)
goto out;
-- 
2.7.4

Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4

[Andrew Morton]

On Thu, 16 Mar 2017 21:52:23 -0400 (EDT) Jerome Glisse  
wrote:

> The original intention was for it to be 64bit only, 32bit is a dying
> species and before splitting out hmm_ prefix from this code and moving
> it to be generic it was behind a 64bit flag.
> 
> If latter one someone really care about 32bit we can only move to u64

I think that's the best compromise.  If someone wants this on 32-bit
then they're free to get it working.  That "someone" will actually be
able to test it, which you clearly won't be doing!

However, please do check that the impact of this patchset on 32-bit's
`size vmlinux' is minimal.  Preferably zero.

[PATCH net-next] r8152: check hw version first

[Hayes Wang]

Check hw version first in probe(). Do nothing if the driver doesn't
support the chip.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 102 ++--
 1 file changed, 63 insertions(+), 39 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4b85e95..3262a32 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -4236,44 +4236,6 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_features_check = rtl8152_features_check,
 };
 
-static void r8152b_get_version(struct r8152 *tp)
-{
-   u32 ocp_data;
-   u16 version;
-
-   ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR1);
-   version = (u16)(ocp_data & VERSION_MASK);
-
-   switch (version) {
-   case 0x4c00:
-   tp->version = RTL_VER_01;
-   break;
-   case 0x4c10:
-   tp->version = RTL_VER_02;
-   break;
-   case 0x5c00:
-   tp->version = RTL_VER_03;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c10:
-   tp->version = RTL_VER_04;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c20:
-   tp->version = RTL_VER_05;
-   tp->mii.supports_gmii = 1;
-   break;
-   case 0x5c30:
-   tp->version = RTL_VER_06;
-   tp->mii.supports_gmii = 1;
-   break;
-   default:
-   netif_info(tp, probe, tp->netdev,
-  "Unknown version 0x%04x\n", version);
-   break;
-   }
-}
-
 static void rtl8152_unload(struct r8152 *tp)
 {
if (test_bit(RTL8152_UNPLUG, >flags))
@@ -4338,14 +4300,66 @@ static int rtl_ops_init(struct r8152 *tp)
return ret;
 }
 
+static u8 rtl_get_version(struct usb_interface *intf)
+{
+   struct usb_device *udev = interface_to_usbdev(intf);
+   u32 ocp_data = 0;
+   __le32 *tmp;
+   u8 version;
+   int ret;
+
+   tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
+   if (!tmp)
+   return 0;
+
+   ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+ PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500);
+   if (ret > 0)
+   ocp_data = (__le32_to_cpu(*tmp) >> 16) & VERSION_MASK;
+
+   kfree(tmp);
+
+   switch (ocp_data) {
+   case 0x4c00:
+   version = RTL_VER_01;
+   break;
+   case 0x4c10:
+   version = RTL_VER_02;
+   break;
+   case 0x5c00:
+   version = RTL_VER_03;
+   break;
+   case 0x5c10:
+   version = RTL_VER_04;
+   break;
+   case 0x5c20:
+   version = RTL_VER_05;
+   break;
+   case 0x5c30:
+   version = RTL_VER_06;
+   break;
+   default:
+   version = RTL_VER_UNKNOWN;
+   dev_info(>dev, "Unknown version 0x%04x\n", ocp_data);
+   break;
+   }
+
+   return version;
+}
+
 static int rtl8152_probe(struct usb_interface *intf,
 const struct usb_device_id *id)
 {
struct usb_device *udev = interface_to_usbdev(intf);
+   u8 version = rtl_get_version(intf);
struct r8152 *tp;
struct net_device *netdev;
int ret;
 
+   if (version == RTL_VER_UNKNOWN)
+   return -ENODEV;
+
if (udev->actconfig->desc.bConfigurationValue != 1) {
usb_driver_set_configuration(udev, 1);
return -ENODEV;
@@ -4365,8 +4379,18 @@ static int rtl8152_probe(struct usb_interface *intf,
tp->udev = udev;
tp->netdev = netdev;
tp->intf = intf;
+   tp->version = version;
+
+   switch (version) {
+   case RTL_VER_01:
+   case RTL_VER_02:
+   tp->mii.supports_gmii = 0;
+   break;
+   default:
+   tp->mii.supports_gmii = 1;
+   break;
+   }
 
-   r8152b_get_version(tp);
ret = rtl_ops_init(tp);
if (ret)
goto out;
-- 
2.7.4

Re: [PATCH v2 net-next 0/5] sunvnet: better connection management

[David Miller]

From: Shannon Nelson 
Date: Tue, 14 Mar 2017 10:24:38 -0700

> These patches remove some problems in handling of carrier state
> with the ldmvsw vswitch, remove  an xoff misuse in sunvnet, and
> add stats for debug and tracking of point-to-point connections
> between the ldom VMs.
> 
> v2:
>  - added ldmvsw ndo_open to reset the LDC channel
>  - updated copyrights

Series applied, thanks Shannon.

Re: [PATCH v2 net-next 0/5] sunvnet: better connection management

[David Miller]

From: Shannon Nelson 
Date: Tue, 14 Mar 2017 10:24:38 -0700

> These patches remove some problems in handling of carrier state
> with the ldmvsw vswitch, remove  an xoff misuse in sunvnet, and
> add stats for debug and tracking of point-to-point connections
> between the ldom VMs.
> 
> v2:
>  - added ldmvsw ndo_open to reset the LDC channel
>  - updated copyrights

Series applied, thanks Shannon.

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

[Viresh Kumar]

On 16-03-17, 23:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> On CPU online the cpufreq core restores the previous governor (or
> the previous "policy" setting for ->setpolicy drivers), but it does
> not restore the min/max limits at the same time, which is confusing,
> inconsistent and real pain for users who set the limits and then
> suspend/resume the system (using full suspend), in which case the
> limits are reset on all CPUs except for the boot one.
> 
> Fix this by making cpufreq_init_policy() restore the limits when it
> sees that this is CPU online and not initialization from scratch.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -979,6 +979,8 @@ static int cpufreq_init_policy(struct cp
>   /* Update governor of new_policy to the governor used before hotplug */
>   gov = find_governor(policy->last_governor);
>   if (gov) {
> + new_policy.min = policy->user_policy.min;
> + new_policy.max = policy->user_policy.max;
>   pr_debug("Restoring governor %s for cpu %d\n",
>   policy->governor->name, policy->cpu);
>   } else {
> @@ -991,11 +993,14 @@ static int cpufreq_init_policy(struct cp
>  
>   /* Use the default policy if there is no last_policy. */
>   if (cpufreq_driver->setpolicy) {
> - if (policy->last_policy)
> + if (policy->last_policy) {
>   new_policy.policy = policy->last_policy;
> - else
> + new_policy.min = policy->user_policy.min;
> + new_policy.max = policy->user_policy.max;
> + } else {
>   cpufreq_parse_governor(gov->name, _policy.policy,
>  NULL);
> + }
>   }
>   /* set default policy */
>   return cpufreq_set_policy(policy, _policy);

What about something like this instead ?

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b8ff617d449d..5dbdd261aa73 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1184,6 +1184,9 @@ static int cpufreq_online(unsigned int cpu)
for_each_cpu(j, policy->related_cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
write_unlock_irqrestore(_driver_lock, flags);
+   } else {
+   policy->min = policy->user_policy.min;
+   policy->max = policy->user_policy.max;
}
 
if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {


-- 
viresh

Re: [PATCH net-next] bonding: add 802.3ad support for 25G speeds

[David Miller]

From: Jarod Wilson 
Date: Tue, 14 Mar 2017 11:48:32 -0400

> Cut-n-paste enablement of 802.3ad bonding on 25G NICs, which currently
> report 0 as their bandwidth.
> 
> CC: Jay Vosburgh 
> CC: Veaceslav Falico 
> CC: Andy Gospodarek 
> CC: net...@vger.kernel.org
> Signed-off-by: Jarod Wilson 

Applied.

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

[Viresh Kumar]

On 16-03-17, 23:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> On CPU online the cpufreq core restores the previous governor (or
> the previous "policy" setting for ->setpolicy drivers), but it does
> not restore the min/max limits at the same time, which is confusing,
> inconsistent and real pain for users who set the limits and then
> suspend/resume the system (using full suspend), in which case the
> limits are reset on all CPUs except for the boot one.
> 
> Fix this by making cpufreq_init_policy() restore the limits when it
> sees that this is CPU online and not initialization from scratch.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -979,6 +979,8 @@ static int cpufreq_init_policy(struct cp
>   /* Update governor of new_policy to the governor used before hotplug */
>   gov = find_governor(policy->last_governor);
>   if (gov) {
> + new_policy.min = policy->user_policy.min;
> + new_policy.max = policy->user_policy.max;
>   pr_debug("Restoring governor %s for cpu %d\n",
>   policy->governor->name, policy->cpu);
>   } else {
> @@ -991,11 +993,14 @@ static int cpufreq_init_policy(struct cp
>  
>   /* Use the default policy if there is no last_policy. */
>   if (cpufreq_driver->setpolicy) {
> - if (policy->last_policy)
> + if (policy->last_policy) {
>   new_policy.policy = policy->last_policy;
> - else
> + new_policy.min = policy->user_policy.min;
> + new_policy.max = policy->user_policy.max;
> + } else {
>   cpufreq_parse_governor(gov->name, _policy.policy,
>  NULL);
> + }
>   }
>   /* set default policy */
>   return cpufreq_set_policy(policy, _policy);

What about something like this instead ?

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b8ff617d449d..5dbdd261aa73 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1184,6 +1184,9 @@ static int cpufreq_online(unsigned int cpu)
for_each_cpu(j, policy->related_cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
write_unlock_irqrestore(_driver_lock, flags);
+   } else {
+   policy->min = policy->user_policy.min;
+   policy->max = policy->user_policy.max;
}
 
if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {


-- 
viresh

Re: [PATCH net-next] bonding: add 802.3ad support for 25G speeds

[David Miller]

From: Jarod Wilson 
Date: Tue, 14 Mar 2017 11:48:32 -0400

> Cut-n-paste enablement of 802.3ad bonding on 25G NICs, which currently
> report 0 as their bandwidth.
> 
> CC: Jay Vosburgh 
> CC: Veaceslav Falico 
> CC: Andy Gospodarek 
> CC: net...@vger.kernel.org
> Signed-off-by: Jarod Wilson 

Applied.

Re: [f2fs-dev] [PATCH 2/2] f2fs: don't allow atomic writes for not regular files

[Chao Yu]

On 2017/3/17 10:09, Jaegeuk Kim wrote:
> The atomic writes only supports regular files for database.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index da6d33d1bb34..d486e02b43c2 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1522,6 +1522,9 @@ static int f2fs_ioc_start_atomic_write(struct file 
> *filp)
>   if (f2fs_is_atomic_file(inode))
>   goto out;
>  
> + if (!S_ISREG(inode->i_mode))
> + return -EINVAL;

goto out;

Thanks,

> +
>   ret = f2fs_convert_inline_inode(inode);
>   if (ret)
>   goto out;
> 

Re: [f2fs-dev] [PATCH 2/2] f2fs: don't allow atomic writes for not regular files

[Chao Yu]

On 2017/3/17 10:09, Jaegeuk Kim wrote:
> The atomic writes only supports regular files for database.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/file.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index da6d33d1bb34..d486e02b43c2 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1522,6 +1522,9 @@ static int f2fs_ioc_start_atomic_write(struct file 
> *filp)
>   if (f2fs_is_atomic_file(inode))
>   goto out;
>  
> + if (!S_ISREG(inode->i_mode))
> + return -EINVAL;

goto out;

Thanks,

> +
>   ret = f2fs_convert_inline_inode(inode);
>   if (ret)
>   goto out;
> 

Re: [RESEND PATCH -net] cpsw/netcp: work around reverse cpts dependency

[David Miller]

From: Arnd Bergmann 
Date: Mon, 13 Mar 2017 17:59:04 +0100

> The dependency is reversed: cpsw and netcp call into cpts,
> but cpts depends on the other two in Kconfig. This can lead
> to cpts being a loadable module and its callers built-in:
> 
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_remove':
> cpsw.c:(.text.cpsw_remove+0xd0): undefined reference to `cpts_release'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_rx_handler':
> cpsw.c:(.text.cpsw_rx_handler+0x2dc): undefined reference to 
> `cpts_rx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_tx_handler':
> cpsw.c:(.text.cpsw_tx_handler+0x7c): undefined reference to 
> `cpts_tx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_ndo_stop':
> 
> As a workaround, I'm introducing another Kconfig symbol to
> control the compilation of cpts, while making the actual
> module controlled by a silent symbol that is =y when necessary.
> 
> Fixes: 6246168b4a38 ("net: ethernet: ti: netcp: add support of cpts")
> Signed-off-by: Arnd Bergmann 
> Reviewed-by: Grygorii Strashko 
> ---
> Originally submitted on Dec 16, still needed for v4.10 and v4.11-rc2

I'm fine with this change, but please keep the user visible Kconfig
symbol name the same, use the new name for the internal one.

I know that this means you have to make more changes elsewhere in
order to accomplish this.

Re: [RESEND PATCH -net] cpsw/netcp: work around reverse cpts dependency

[David Miller]

From: Arnd Bergmann 
Date: Mon, 13 Mar 2017 17:59:04 +0100

> The dependency is reversed: cpsw and netcp call into cpts,
> but cpts depends on the other two in Kconfig. This can lead
> to cpts being a loadable module and its callers built-in:
> 
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_remove':
> cpsw.c:(.text.cpsw_remove+0xd0): undefined reference to `cpts_release'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_rx_handler':
> cpsw.c:(.text.cpsw_rx_handler+0x2dc): undefined reference to 
> `cpts_rx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_tx_handler':
> cpsw.c:(.text.cpsw_tx_handler+0x7c): undefined reference to 
> `cpts_tx_timestamp'
> drivers/net/ethernet/ti/cpsw.o: In function `cpsw_ndo_stop':
> 
> As a workaround, I'm introducing another Kconfig symbol to
> control the compilation of cpts, while making the actual
> module controlled by a silent symbol that is =y when necessary.
> 
> Fixes: 6246168b4a38 ("net: ethernet: ti: netcp: add support of cpts")
> Signed-off-by: Arnd Bergmann 
> Reviewed-by: Grygorii Strashko 
> ---
> Originally submitted on Dec 16, still needed for v4.10 and v4.11-rc2

I'm fine with this change, but please keep the user visible Kconfig
symbol name the same, use the new name for the internal one.

I know that this means you have to make more changes elsewhere in
order to accomplish this.

Re: [PATCH v2 0/5] mm: support parallel free of memory

[Aaron Lu]

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote:
> I wonder if the difference would be larger if the parallelism was done
> on a higher level, something around unmap_page_range(). IIUC the current

I guess I misunderstand you in my last email - doing it at
unmap_page_range() level is essentially doing it at a per-VMA level
since it is the main function used in unmap_single_vma(). We have tried
that and felt that it's not flexible as the proposed approach since
it wouldn't parallize well for:
1 work load that uses only 1 or very few huge VMA;
2 work load that has a lot of small VMAs.

The code is nice and easy though(developed at v4.9 time frame):

>From f6d5cfde888b9e0356719fabe8754fdfe6fe236b Mon Sep 17 00:00:00 2001
From: Aaron Lu 
Date: Wed, 11 Jan 2017 15:56:06 +0800
Subject: [PATCH] mm: async free vma

---
 include/linux/mm_types.h |  6 ++
 mm/memory.c  | 23 ++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 4a8acedf4b7d..d10d2ce8f8f4 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -358,6 +358,12 @@ struct vm_area_struct {
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
+
+   struct vma_free_ctx {
+   unsigned long start_addr;
+   unsigned long end_addr;
+   struct work_struct work;
+   } free_ctx;
 };
 
 struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index e18c57bdc75c..0fe4e45a044b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1345,6 +1345,17 @@ static void unmap_single_vma(struct mmu_gather *tlb,
}
 }
 
+static void unmap_single_vma_work(struct work_struct *work)
+{
+   struct vma_free_ctx *ctx = container_of(work, struct vma_free_ctx, 
work);
+   struct vm_area_struct *vma = container_of(ctx, struct vm_area_struct, 
free_ctx);
+   struct mmu_gather tlb;
+
+   tlb_gather_mmu(, vma->vm_mm, ctx->start_addr, ctx->end_addr);
+   unmap_single_vma(, vma, ctx->start_addr, ctx->end_addr, NULL);
+   tlb_finish_mmu(, ctx->start_addr, ctx->end_addr);
+}
+
 /**
  * unmap_vmas - unmap a range of memory covered by a list of vma's
  * @tlb: address of the caller's struct mmu_gather
@@ -1368,10 +1379,20 @@ void unmap_vmas(struct mmu_gather *tlb,
unsigned long end_addr)
 {
struct mm_struct *mm = vma->vm_mm;
+   struct vma_free_ctx *ctx;
+   struct vm_area_struct *tmp = vma;
 
mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
+   for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next) {
+   ctx = >free_ctx;
+   ctx->start_addr = start_addr;
+   ctx->end_addr = end_addr;
+   INIT_WORK(>work, unmap_single_vma_work);
+   queue_work(system_unbound_wq, >work);
+   }
+   vma = tmp;
for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next)
-   unmap_single_vma(tlb, vma, start_addr, end_addr, NULL);
+   flush_work(>free_ctx.work);
mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
 }
 
-- 
2.9.3

Re: [PATCH v2 0/5] mm: support parallel free of memory

[Aaron Lu]

On Wed, Mar 15, 2017 at 03:56:02PM +0100, Vlastimil Babka wrote:
> I wonder if the difference would be larger if the parallelism was done
> on a higher level, something around unmap_page_range(). IIUC the current

I guess I misunderstand you in my last email - doing it at
unmap_page_range() level is essentially doing it at a per-VMA level
since it is the main function used in unmap_single_vma(). We have tried
that and felt that it's not flexible as the proposed approach since
it wouldn't parallize well for:
1 work load that uses only 1 or very few huge VMA;
2 work load that has a lot of small VMAs.

The code is nice and easy though(developed at v4.9 time frame):

>From f6d5cfde888b9e0356719fabe8754fdfe6fe236b Mon Sep 17 00:00:00 2001
From: Aaron Lu 
Date: Wed, 11 Jan 2017 15:56:06 +0800
Subject: [PATCH] mm: async free vma

---
 include/linux/mm_types.h |  6 ++
 mm/memory.c  | 23 ++-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 4a8acedf4b7d..d10d2ce8f8f4 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -358,6 +358,12 @@ struct vm_area_struct {
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
 #endif
struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
+
+   struct vma_free_ctx {
+   unsigned long start_addr;
+   unsigned long end_addr;
+   struct work_struct work;
+   } free_ctx;
 };
 
 struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index e18c57bdc75c..0fe4e45a044b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1345,6 +1345,17 @@ static void unmap_single_vma(struct mmu_gather *tlb,
}
 }
 
+static void unmap_single_vma_work(struct work_struct *work)
+{
+   struct vma_free_ctx *ctx = container_of(work, struct vma_free_ctx, 
work);
+   struct vm_area_struct *vma = container_of(ctx, struct vm_area_struct, 
free_ctx);
+   struct mmu_gather tlb;
+
+   tlb_gather_mmu(, vma->vm_mm, ctx->start_addr, ctx->end_addr);
+   unmap_single_vma(, vma, ctx->start_addr, ctx->end_addr, NULL);
+   tlb_finish_mmu(, ctx->start_addr, ctx->end_addr);
+}
+
 /**
  * unmap_vmas - unmap a range of memory covered by a list of vma's
  * @tlb: address of the caller's struct mmu_gather
@@ -1368,10 +1379,20 @@ void unmap_vmas(struct mmu_gather *tlb,
unsigned long end_addr)
 {
struct mm_struct *mm = vma->vm_mm;
+   struct vma_free_ctx *ctx;
+   struct vm_area_struct *tmp = vma;
 
mmu_notifier_invalidate_range_start(mm, start_addr, end_addr);
+   for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next) {
+   ctx = >free_ctx;
+   ctx->start_addr = start_addr;
+   ctx->end_addr = end_addr;
+   INIT_WORK(>work, unmap_single_vma_work);
+   queue_work(system_unbound_wq, >work);
+   }
+   vma = tmp;
for ( ; vma && vma->vm_start < end_addr; vma = vma->vm_next)
-   unmap_single_vma(tlb, vma, start_addr, end_addr, NULL);
+   flush_work(>free_ctx.work);
mmu_notifier_invalidate_range_end(mm, start_addr, end_addr);
 }
 
-- 
2.9.3

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Eric Dumazet]

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:

> What I probably can do is go through and replace all the spots where
> we where checking for sk_napi_id being 0, and instead replace it with
> a check against NR_CPUS.

This seems a good idea.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Eric Dumazet]

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:

> What I probably can do is go through and replace all the spots where
> we where checking for sk_napi_id being 0, and instead replace it with
> a check against NR_CPUS.

This seems a good idea.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Alexander Duyck]

On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet  wrote:
> On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:
>
>> What I probably can do is go through and replace all the spots where
>> we where checking for sk_napi_id being 0, and instead replace it with
>> a check against NR_CPUS.
>
> This seems a good idea.

Right.  This is the path I am planning to go with.  It will require
about the same amount of code change but replaces those checks.  I
just have to make sure I catch all the spots where we were checking it
for 0 but that shouldn't be too difficult of an issue.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Alexander Duyck]

On Thu, Mar 16, 2017 at 7:57 PM, Eric Dumazet  wrote:
> On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:
>
>> What I probably can do is go through and replace all the spots where
>> we where checking for sk_napi_id being 0, and instead replace it with
>> a check against NR_CPUS.
>
> This seems a good idea.

Right.  This is the path I am planning to go with.  It will require
about the same amount of code change but replaces those checks.  I
just have to make sure I catch all the spots where we were checking it
for 0 but that shouldn't be too difficult of an issue.

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Eric Dumazet]

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:

> I don't know.  My concern here is about the cost of going through all
> that code just for something that we know shouldn't be valid.  If
> nothing else I might update sk_can_busy_loop so that it doesn't try
> busy looping on a sk_napi_id that is NR_CPU or less.

But why would that be a win ?

if napi_by_id() returns NULL, we immediately give up, (goto out;)

So why should we add a code that will add something that will not be
useful for the vast majority of the cases where the ID is valid and we
need to do the hash look up ?

Is libc trying to avoid doing syscalls like close(-1) ?

Re: [net-next PATCH 1/5] net: Do not record sender_cpu as napi_id in socket receive paths

[Eric Dumazet]

On Thu, 2017-03-16 at 19:40 -0700, Alexander Duyck wrote:

> I don't know.  My concern here is about the cost of going through all
> that code just for something that we know shouldn't be valid.  If
> nothing else I might update sk_can_busy_loop so that it doesn't try
> busy looping on a sk_napi_id that is NR_CPU or less.

But why would that be a win ?

if napi_by_id() returns NULL, we immediately give up, (goto out;)

So why should we add a code that will add something that will not be
useful for the vast majority of the cases where the ID is valid and we
need to do the hash look up ?

Is libc trying to avoid doing syscalls like close(-1) ?