Re: [GIT PULL] percpu fix for v4.10-rc6

[David Howells]

Linus Torvalds  wrote:

> The fact is, atomic_long_inc_not_zero() shouldn't be returning
> anything with high bits..

Ummm...  Why's that the case?  If atomic_long_t can never exceed UINT_MAX,
then why does it exist at all?

David

Re: [GIT PULL] percpu fix for v4.10-rc6

[David Howells]

Linus Torvalds  wrote:

> The fact is, atomic_long_inc_not_zero() shouldn't be returning
> anything with high bits..

Ummm...  Why's that the case?  If atomic_long_t can never exceed UINT_MAX,
then why does it exist at all?

David

[PATCH v9 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index dea0a6f..db3fed2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <25000>, <4>;
 };
 
+ {
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _9 {
status = "okay";
 
-- 
1.9.1

[PATCH v9 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index dea0a6f..db3fed2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <25000>, <4>;
 };
 
+ {
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _9 {
status = "okay";
 
-- 
1.9.1

[PATCH v9 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding

[Hoegeun Kwon]

The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..18854f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

[PATCH v9 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding

[Hoegeun Kwon]

The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..18854f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

[PATCH v9 0/3] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Changes for V9:
- Fixed the te-gpio to optional in bindings

Changes for V8:
- Applied below two patches: (drm/exynos)
  : drm/exynos: mic: Add mode_set callback function
  : drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ (for-next 
branch)
[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3ha2 panel binding
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  12 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 5 files changed, 801 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

[PATCH v9 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 ++
 3 files changed, 761 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 

[PATCH v9 0/3] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Changes for V9:
- Fixed the te-gpio to optional in bindings

Changes for V8:
- Applied below two patches: (drm/exynos)
  : drm/exynos: mic: Add mode_set callback function
  : drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ (for-next 
branch)
[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3ha2 panel binding
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  12 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 754 +
 5 files changed, 801 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

-- 
1.9.1

[PATCH v9 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 ++
 3 files changed, 761 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..0b9c6f4
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,754 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x88, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8c,
+ 0x91, 0x86, 0xac, 0xaa, 0x89, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello,

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.


This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?

Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello,

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.


This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?

Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:31, Inki Dae wrote:
>>
>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>> In some platforms there is attached another device to the end of HDMI.
>>> The patch adds support for it.
>> Andrzej, can you clarify what bridge device can be attached and actually is 
>> now attached to the end of HDMI?
>> And I wonder if we have the device tree file which defines the bridge device 
>> in mainline. Seems we have no the device tree file.
>>
>> If nothing, then this patch should be merged with real use case.
> 
> SiI8620 MHL bridge in tm2/tm2e.

Did you post dt patch to add the properties related to SiI8620 MHL bridge 
device?

I see below patch series,
[PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support

but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge device 
as description would be needed.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>>> +---
>>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index a73b192..41fb894 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -35,6 +35,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>> struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>> struct regulator*reg_hdmi_en;
>>> struct exynos_drm_clk   phy_clk;
>>> +   struct drm_bridge   *bridge;
>>>  };
>>>  
>>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>>> *encoder)
>>> drm_connector_register(connector);
>>> drm_mode_connector_attach_encoder(connector, encoder);
>>>  
>>> -   return 0;
>>> +   if (hdata->bridge) {
>>> +   encoder->bridge = hdata->bridge;
>>> +   hdata->bridge->encoder = encoder;
>>> +   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>>> +   if (ret)
>>> +   DRM_ERROR("Failed to attach bridge\n");
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  
>>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>>> *clk, bool enable)
>>> hdmiphy_disable(hdata);
>>>  }
>>>  
>>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>>> +{
>>> +   struct device *dev = hdata->dev;
>>> +   struct device_node *ep, *np;
>>> +
>>> +   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>>> +   if (!ep)
>>> +   return 0;
>>> +
>>> +   np = of_graph_get_remote_port_parent(ep);
>>> +   of_node_put(ep);
>>> +   if (!np) {
>>> +   DRM_ERROR("failed to get remote port parent");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   hdata->bridge = of_drm_find_bridge(np);
>>> +   of_node_put(np);
>>> +
>>> +   if (!hdata->bridge)
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>>  {
>>> struct device *dev = hdata->dev;
>>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>>> *hdata)
>>>  
>>> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>>  
>>> -   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>>> -   return 0;
>>> +   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>>> +   if (IS_ERR(hdata->reg_hdmi_en))
>>> +   return PTR_ERR(hdata->reg_hdmi_en);
>>>  
>>> -   if (IS_ERR(hdata->reg_hdmi_en))
>>> -   return PTR_ERR(hdata->reg_hdmi_en);
>>> -
>>> -   ret = regulator_enable(hdata->reg_hdmi_en);
>>> -   if (ret)
>>> -   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   ret = regulator_enable(hdata->reg_hdmi_en);
>>> +   if (ret) {
>>> +   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   return ret;
>>> +   }
>>> +   }
>>>  
>>> -   return ret;
>>> +   return hdmi_bridge_init(hdata);
>>>  }
>>>  
>>>  static struct of_device_id hdmi_match_types[] = {
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:31, Inki Dae wrote:
>>
>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>>> In some platforms there is attached another device to the end of HDMI.
>>> The patch adds support for it.
>> Andrzej, can you clarify what bridge device can be attached and actually is 
>> now attached to the end of HDMI?
>> And I wonder if we have the device tree file which defines the bridge device 
>> in mainline. Seems we have no the device tree file.
>>
>> If nothing, then this patch should be merged with real use case.
> 
> SiI8620 MHL bridge in tm2/tm2e.

Did you post dt patch to add the properties related to SiI8620 MHL bridge 
device?

I see below patch series,
[PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support

but I couldn't find dt patch for it. And specifying SiI8620 MHL bridge device 
as description would be needed.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>> Thanks.
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>>> +---
>>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index a73b192..41fb894 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -35,6 +35,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>> struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>> struct regulator*reg_hdmi_en;
>>> struct exynos_drm_clk   phy_clk;
>>> +   struct drm_bridge   *bridge;
>>>  };
>>>  
>>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>>> *encoder)
>>> drm_connector_register(connector);
>>> drm_mode_connector_attach_encoder(connector, encoder);
>>>  
>>> -   return 0;
>>> +   if (hdata->bridge) {
>>> +   encoder->bridge = hdata->bridge;
>>> +   hdata->bridge->encoder = encoder;
>>> +   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>>> +   if (ret)
>>> +   DRM_ERROR("Failed to attach bridge\n");
>>> +   }
>>> +
>>> +   return ret;
>>>  }
>>>  
>>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>>> *clk, bool enable)
>>> hdmiphy_disable(hdata);
>>>  }
>>>  
>>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>>> +{
>>> +   struct device *dev = hdata->dev;
>>> +   struct device_node *ep, *np;
>>> +
>>> +   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>>> +   if (!ep)
>>> +   return 0;
>>> +
>>> +   np = of_graph_get_remote_port_parent(ep);
>>> +   of_node_put(ep);
>>> +   if (!np) {
>>> +   DRM_ERROR("failed to get remote port parent");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   hdata->bridge = of_drm_find_bridge(np);
>>> +   of_node_put(np);
>>> +
>>> +   if (!hdata->bridge)
>>> +   return -EPROBE_DEFER;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>>  {
>>> struct device *dev = hdata->dev;
>>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>>> *hdata)
>>>  
>>> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>>  
>>> -   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>>> -   return 0;
>>> +   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>>> +   if (IS_ERR(hdata->reg_hdmi_en))
>>> +   return PTR_ERR(hdata->reg_hdmi_en);
>>>  
>>> -   if (IS_ERR(hdata->reg_hdmi_en))
>>> -   return PTR_ERR(hdata->reg_hdmi_en);
>>> -
>>> -   ret = regulator_enable(hdata->reg_hdmi_en);
>>> -   if (ret)
>>> -   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   ret = regulator_enable(hdata->reg_hdmi_en);
>>> +   if (ret) {
>>> +   DRM_ERROR("failed to enable hdmi-en regulator\n");
>>> +   return ret;
>>> +   }
>>> +   }
>>>  
>>> -   return ret;
>>> +   return hdmi_bridge_init(hdata);
>>>  }
>>>  
>>>  static struct of_device_id hdmi_match_types[] = {
>>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Andrzej Hajda]

On 01.02.2017 08:31, Inki Dae wrote:
>
> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>> In some platforms there is attached another device to the end of HDMI.
>> The patch adds support for it.
> Andrzej, can you clarify what bridge device can be attached and actually is 
> now attached to the end of HDMI?
> And I wonder if we have the device tree file which defines the bridge device 
> in mainline. Seems we have no the device tree file.
>
> If nothing, then this patch should be merged with real use case.

SiI8620 MHL bridge in tm2/tm2e.

Regards
Andrzej

>
> Thanks.
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>> +---
>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a73b192..41fb894 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>  struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>  struct regulator*reg_hdmi_en;
>>  struct exynos_drm_clk   phy_clk;
>> +struct drm_bridge   *bridge;
>>  };
>>  
>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>> *encoder)
>>  drm_connector_register(connector);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>  
>> -return 0;
>> +if (hdata->bridge) {
>> +encoder->bridge = hdata->bridge;
>> +hdata->bridge->encoder = encoder;
>> +ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>> +if (ret)
>> +DRM_ERROR("Failed to attach bridge\n");
>> +}
>> +
>> +return ret;
>>  }
>>  
>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>> *clk, bool enable)
>>  hdmiphy_disable(hdata);
>>  }
>>  
>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>> +{
>> +struct device *dev = hdata->dev;
>> +struct device_node *ep, *np;
>> +
>> +ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>> +if (!ep)
>> +return 0;
>> +
>> +np = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>> +if (!np) {
>> +DRM_ERROR("failed to get remote port parent");
>> +return -EINVAL;
>> +}
>> +
>> +hdata->bridge = of_drm_find_bridge(np);
>> +of_node_put(np);
>> +
>> +if (!hdata->bridge)
>> +return -EPROBE_DEFER;
>> +
>> +return 0;
>> +}
>> +
>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>  {
>>  struct device *dev = hdata->dev;
>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>> *hdata)
>>  
>>  hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>  
>> -if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>> -return 0;
>> +if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>> +if (IS_ERR(hdata->reg_hdmi_en))
>> +return PTR_ERR(hdata->reg_hdmi_en);
>>  
>> -if (IS_ERR(hdata->reg_hdmi_en))
>> -return PTR_ERR(hdata->reg_hdmi_en);
>> -
>> -ret = regulator_enable(hdata->reg_hdmi_en);
>> -if (ret)
>> -DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +ret = regulator_enable(hdata->reg_hdmi_en);
>> +if (ret) {
>> +DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +return ret;
>> +}
>> +}
>>  
>> -return ret;
>> +return hdmi_bridge_init(hdata);
>>  }
>>  
>>  static struct of_device_id hdmi_match_types[] = {
>>
>

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Andrzej Hajda]

On 01.02.2017 08:31, Inki Dae wrote:
>
> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
>> In some platforms there is attached another device to the end of HDMI.
>> The patch adds support for it.
> Andrzej, can you clarify what bridge device can be attached and actually is 
> now attached to the end of HDMI?
> And I wonder if we have the device tree file which defines the bridge device 
> in mainline. Seems we have no the device tree file.
>
> If nothing, then this patch should be merged with real use case.

SiI8620 MHL bridge in tm2/tm2e.

Regards
Andrzej

>
> Thanks.
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
>> +---
>>  1 file changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a73b192..41fb894 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -133,6 +134,7 @@ struct hdmi_context {
>>  struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>  struct regulator*reg_hdmi_en;
>>  struct exynos_drm_clk   phy_clk;
>> +struct drm_bridge   *bridge;
>>  };
>>  
>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
>> *encoder)
>>  drm_connector_register(connector);
>>  drm_mode_connector_attach_encoder(connector, encoder);
>>  
>> -return 0;
>> +if (hdata->bridge) {
>> +encoder->bridge = hdata->bridge;
>> +hdata->bridge->encoder = encoder;
>> +ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>> +if (ret)
>> +DRM_ERROR("Failed to attach bridge\n");
>> +}
>> +
>> +return ret;
>>  }
>>  
>>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
>> *clk, bool enable)
>>  hdmiphy_disable(hdata);
>>  }
>>  
>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>> +{
>> +struct device *dev = hdata->dev;
>> +struct device_node *ep, *np;
>> +
>> +ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>> +if (!ep)
>> +return 0;
>> +
>> +np = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>> +if (!np) {
>> +DRM_ERROR("failed to get remote port parent");
>> +return -EINVAL;
>> +}
>> +
>> +hdata->bridge = of_drm_find_bridge(np);
>> +of_node_put(np);
>> +
>> +if (!hdata->bridge)
>> +return -EPROBE_DEFER;
>> +
>> +return 0;
>> +}
>> +
>>  static int hdmi_resources_init(struct hdmi_context *hdata)
>>  {
>>  struct device *dev = hdata->dev;
>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
>> *hdata)
>>  
>>  hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>  
>> -if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>> -return 0;
>> +if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>> +if (IS_ERR(hdata->reg_hdmi_en))
>> +return PTR_ERR(hdata->reg_hdmi_en);
>>  
>> -if (IS_ERR(hdata->reg_hdmi_en))
>> -return PTR_ERR(hdata->reg_hdmi_en);
>> -
>> -ret = regulator_enable(hdata->reg_hdmi_en);
>> -if (ret)
>> -DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +ret = regulator_enable(hdata->reg_hdmi_en);
>> +if (ret) {
>> +DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +return ret;
>> +}
>> +}
>>  
>> -return ret;
>> +return hdmi_bridge_init(hdata);
>>  }
>>  
>>  static struct of_device_id hdmi_match_types[] = {
>>
>

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Nayna]

On 02/01/2017 02:20 AM, Jarkko Sakkinen wrote:

On Wed, Feb 01, 2017 at 12:14:12AM +0530, Nayna wrote:

I already sent my pull request to 4.11 and even today I found something
fishy. You declared a function local array by using a variable in "tpm:
enhance TPM 2.0 PCR extend to support multiple banks" (max_active_banks
or something). And the event log patches have just passed the review.


Yes. I have checked using clang and it has passed the clang.. and I also
verified there were no complains during build.


What we can deduce from that is that they didn't expose the issue in
question.

I found this by running sparse with make C=2 M=drives/char/tpm


What type of problem do you see ?


It is disallowed to do stack allocation in the kernel code even if C
standard would allow it. Stack is scarce resource so you need to know
its usage at compile time.

In this case you actually know the allocation because the value is not
changed during the course of the function but it is still bad. Probably
compiler will optimize it out. Still it is not a good practice.


Thanks Jarkko for explaining it.

Hmm, do you want me to send a patch for this ?
I think what we want is actually define it just array of size as 7.




Also, to understand, this is related to multi-bank patchset. I mean how does
it affect for event log patchset ?


Well in both cases these have landed fairly late but I asked from James
whether I'll have to postpone these to 4.12.

Usually when I've sent my release pull request I do not want to make any
radical changes to the codebase because they always require extra QA and
thus take extra time.


Thanks again for explaining details.

Thanks & Regards,
   - Nayna



/Jarkko

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Nayna]

On 02/01/2017 02:20 AM, Jarkko Sakkinen wrote:

On Wed, Feb 01, 2017 at 12:14:12AM +0530, Nayna wrote:

I already sent my pull request to 4.11 and even today I found something
fishy. You declared a function local array by using a variable in "tpm:
enhance TPM 2.0 PCR extend to support multiple banks" (max_active_banks
or something). And the event log patches have just passed the review.


Yes. I have checked using clang and it has passed the clang.. and I also
verified there were no complains during build.


What we can deduce from that is that they didn't expose the issue in
question.

I found this by running sparse with make C=2 M=drives/char/tpm


What type of problem do you see ?


It is disallowed to do stack allocation in the kernel code even if C
standard would allow it. Stack is scarce resource so you need to know
its usage at compile time.

In this case you actually know the allocation because the value is not
changed during the course of the function but it is still bad. Probably
compiler will optimize it out. Still it is not a good practice.


Thanks Jarkko for explaining it.

Hmm, do you want me to send a patch for this ?
I think what we want is actually define it just array of size as 7.




Also, to understand, this is related to multi-bank patchset. I mean how does
it affect for event log patchset ?


Well in both cases these have landed fairly late but I asked from James
whether I'll have to postpone these to 4.12.

Usually when I've sent my release pull request I do not want to make any
radical changes to the codebase because they always require extra QA and
thus take extra time.


Thanks again for explaining details.

Thanks & Regards,
   - Nayna



/Jarkko

Re: [RFC] cpuset: Enable changing of top_cpuset's mems_allowed nodemask

[Anshuman Khandual]

On 01/31/2017 09:30 PM, Mel Gorman wrote:
> On Tue, Jan 31, 2017 at 07:52:37PM +0530, Anshuman Khandual wrote:
>> At present, top_cpuset.mems_allowed is same as node_states[N_MEMORY] and it
>> cannot be changed at the runtime. Maximum possible node_states[N_MEMORY]
>> also gets reflected in top_cpuset.effective_mems interface. It prevents some
>> one from removing or restricting memory placement which will be applicable
>> system wide on a given memory node through cpuset mechanism which might be
>> limiting. This solves the problem by enabling update_nodemask() function to
>> accept changes to top_cpuset.mems_allowed as well. Once changed, it also
>> updates the value of top_cpuset.effective_mems. Updates all it's task's
>> mems_allowed nodemask as well. It calls cpuset_inc() to make sure cpuset
>> is accounted for in the buddy allocator through cpusets_enabled() check.
>>
> 
> What's the point of allowing the root cpuset to be restricted?

After an extended period of run time on a system, currently if we have
to run HW diagnostics and dump (which are run out of band) for debug
purpose, we have to stop further allocations to the node. Hot plugging
the memory node out of the kernel will achieve this. But it can also
be made possible by just enabling top_cpuset.memory_migrate and then
restricting all the allocations by removing the node from top_cpuset.
mems_allowed nodemask. This will force all the existing allocations
out of the target node.

More importantly it also extends the cpuset memory restriction feature
to the logical completion without adding any regressions for the
existing use cases. Then why not do this ? Does it add any overhead ?

In the future this feature can also be used to isolate a memory node
from all possible general allocations and at the same time provide an
alternate method for explicit allocation into it (still working on this
part, though have a hack right now). The current RFC series proposes
one such possible use case through the top_cpuset.mems_allowed nodemask.
But in this case it is being restricted during boot as well as after
hotplug of a memory only NUMA node.

If you think currently this does not have a use case to stand on it's
own, then I will carry it along with this patch series as part of the
proposed cpuset based isolation solution (with explicit allocation
access to the isolated node) as described just above.

- Anshuman

Re: [RFC] cpuset: Enable changing of top_cpuset's mems_allowed nodemask

[Anshuman Khandual]

On 01/31/2017 09:30 PM, Mel Gorman wrote:
> On Tue, Jan 31, 2017 at 07:52:37PM +0530, Anshuman Khandual wrote:
>> At present, top_cpuset.mems_allowed is same as node_states[N_MEMORY] and it
>> cannot be changed at the runtime. Maximum possible node_states[N_MEMORY]
>> also gets reflected in top_cpuset.effective_mems interface. It prevents some
>> one from removing or restricting memory placement which will be applicable
>> system wide on a given memory node through cpuset mechanism which might be
>> limiting. This solves the problem by enabling update_nodemask() function to
>> accept changes to top_cpuset.mems_allowed as well. Once changed, it also
>> updates the value of top_cpuset.effective_mems. Updates all it's task's
>> mems_allowed nodemask as well. It calls cpuset_inc() to make sure cpuset
>> is accounted for in the buddy allocator through cpusets_enabled() check.
>>
> 
> What's the point of allowing the root cpuset to be restricted?

After an extended period of run time on a system, currently if we have
to run HW diagnostics and dump (which are run out of band) for debug
purpose, we have to stop further allocations to the node. Hot plugging
the memory node out of the kernel will achieve this. But it can also
be made possible by just enabling top_cpuset.memory_migrate and then
restricting all the allocations by removing the node from top_cpuset.
mems_allowed nodemask. This will force all the existing allocations
out of the target node.

More importantly it also extends the cpuset memory restriction feature
to the logical completion without adding any regressions for the
existing use cases. Then why not do this ? Does it add any overhead ?

In the future this feature can also be used to isolate a memory node
from all possible general allocations and at the same time provide an
alternate method for explicit allocation into it (still working on this
part, though have a hack right now). The current RFC series proposes
one such possible use case through the top_cpuset.mems_allowed nodemask.
But in this case it is being restricted during boot as well as after
hotplug of a memory only NUMA node.

If you think currently this does not have a use case to stand on it's
own, then I will carry it along with this patch series as part of the
proposed cpuset based isolation solution (with explicit allocation
access to the isolated node) as described just above.

- Anshuman

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
> In some platforms there is attached another device to the end of HDMI.
> The patch adds support for it.

Andrzej, can you clarify what bridge device can be attached and actually is now 
attached to the end of HDMI?
And I wonder if we have the device tree file which defines the bridge device in 
mainline. Seems we have no the device tree file.

If nothing, then this patch should be merged with real use case.

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH 4/7] drm/exynos/hdmi: add bridge support

[Inki Dae]

2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
> In some platforms there is attached another device to the end of HDMI.
> The patch adds support for it.

Andrzej, can you clarify what bridge device can be attached and actually is now 
attached to the end of HDMI?
And I wonder if we have the device tree file which defines the bridge device in 
mainline. Seems we have no the device tree file.

If nothing, then this patch should be merged with real use case.

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 56 
> +---
>  1 file changed, 46 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -133,6 +134,7 @@ struct hdmi_context {
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
>   struct exynos_drm_clk   phy_clk;
> + struct drm_bridge   *bridge;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
> *encoder)
>   drm_connector_register(connector);
>   drm_mode_connector_attach_encoder(connector, encoder);
>  
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);
> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
>  }
>  
>  static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
> *clk, bool enable)
>   hdmiphy_disable(hdata);
>  }
>  
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>  
>   hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>  
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>  
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>  
> - return ret;
> + return hdmi_bridge_init(hdata);
>  }
>  
>  static struct of_device_id hdmi_match_types[] = {
> 

Re: [PATCH 4.9 00/66] 4.9.7-stable review

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 03:06:08PM -0700, Shuah Khan wrote:
> On 01/30/2017 10:36 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.7 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Feb  2 05:35:45 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.7-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Wonderful, thanks for testing and letting me know.

greg k-h

linux-next: Tree for Feb 1

[Stephen Rothwell]

Hi all,

Changes since 20170131:

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree still had its build failure, so I just dropped it
again for today.

The v4l-dvb tree still had its build failure so I used the version from
next-20170130.

The net-next tree gained a conflict against the char-misc.current tree.

The regulator tree gained a build failure so I used the version from
next-20170131.

The tip tree gained a conflict against the drm tree.

The char-misc tree gained a conflict against the driver-core tree.

Non-merge commits (relative to Linus' tree): 6458
 7134 files changed, 269283 insertions(+), 136334 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f1774f46d49f Merge branch 'for-4.10-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (90427ef5d2a4 ipv6: fix flow labels when the traffic class 
is non-0)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (672980c62c68 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.c

Re: [PATCH 4.9 00/66] 4.9.7-stable review

[Greg Kroah-Hartman]

On Tue, Jan 31, 2017 at 03:06:08PM -0700, Shuah Khan wrote:
> On 01/30/2017 10:36 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.7 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Feb  2 05:35:45 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.7-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Wonderful, thanks for testing and letting me know.

greg k-h

linux-next: Tree for Feb 1

[Stephen Rothwell]

Hi all,

Changes since 20170131:

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree still had its build failure, so I just dropped it
again for today.

The v4l-dvb tree still had its build failure so I used the version from
next-20170130.

The net-next tree gained a conflict against the char-misc.current tree.

The regulator tree gained a build failure so I used the version from
next-20170131.

The tip tree gained a conflict against the drm tree.

The char-misc tree gained a conflict against the driver-core tree.

Non-merge commits (relative to Linus' tree): 6458
 7134 files changed, 269283 insertions(+), 136334 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f1774f46d49f Merge branch 'for-4.10-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (90427ef5d2a4 ipv6: fix flow labels when the traffic class 
is non-0)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (672980c62c68 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.c

Re: Staging: ks7010: clean up ks_hostif.h

[Greg KH]

On Tue, Jan 31, 2017 at 09:53:33PM -0800, Logan Gorence wrote:
> >From 58defc62d53cb473f9d745127d98df834a10b321 Mon Sep 17 00:00:00 2001
> From: Logan Gorence 
> Date: Tue, 31 Jan 2017 21:51:05 -0800
> Subject: [PATCH] Staging: ks7010: clean up ks_hostif.h

Why is this all here in the body of your email?

> 
> Clean up the errors in ks_hostif.h put out by checkpatch.pl.
> 
> Signed-off by: Logan Gorence 
> ---
>  drivers/staging/ks7010/ks_hostif.h | 56 +++---
> 

Your patch is line-wrapped and can not be applied :(

Please fix your email client up (or just use 'git send-email' and try
again.

Also, you can't fix "all" errors at once, you need to break this up into
a "one patch per type of fix" series.

thanks,

greg k-h

Re: Staging: ks7010: clean up ks_hostif.h

[Greg KH]

On Tue, Jan 31, 2017 at 09:53:33PM -0800, Logan Gorence wrote:
> >From 58defc62d53cb473f9d745127d98df834a10b321 Mon Sep 17 00:00:00 2001
> From: Logan Gorence 
> Date: Tue, 31 Jan 2017 21:51:05 -0800
> Subject: [PATCH] Staging: ks7010: clean up ks_hostif.h

Why is this all here in the body of your email?

> 
> Clean up the errors in ks_hostif.h put out by checkpatch.pl.
> 
> Signed-off by: Logan Gorence 
> ---
>  drivers/staging/ks7010/ks_hostif.h | 56 +++---
> 

Your patch is line-wrapped and can not be applied :(

Please fix your email client up (or just use 'git send-email' and try
again.

Also, you can't fix "all" errors at once, you need to break this up into
a "one patch per type of fix" series.

thanks,

greg k-h

Re: [PATCH v2 2/4] perf ftrace: Add ftrace.tracer config option

[Taeung Song]

On 01/31/2017 10:15 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Jan 31, 2017 at 09:46:28AM -0300, Arnaldo Carvalho de Melo escreveu:

Also you are silently ignoring any unknown variable in this section, so
if someone has this:

cat ~/.perfconfig

[ftrace]

trace = function


I.e. forgets the 'r', it will keep using the current default,
"function_graph" till the user checks the config and adds that missing
'r'...

I haven't changed this because I think this is so common that we should
instead have a different error return for those config callbacks that
will tell perf_config() to say something like:

  "unknown variable %s.%s\n", section_name, variable_name


So I read a bit more the config code and ended up with this:

static int perf_ftrace_config(const char *var, const char *value, void *cb)
{
struct perf_ftrace *ftrace = cb;

if (prefixcmp(var, "ftrace."))
return 0;

if (strcmp(var, "ftrace.tracer"))
return -1;

if (!strcmp(value, "function_graph") ||
!strcmp(value, "function")) {
ftrace->tracer = value;
return 0;
}

pr_err("Please select \"function_graph\" (default) or \"function\"\n");
return -1;
}

I.e. it will ignore variables for other sections and will stop at an unknown
variable or value for ftrace.tracer:

[root@jouet ~]# cat ~/.perfconfig
[ftrace]
trace = function
[root@jouet ~]# perf ftrace usleep 1
Error: wrong config key-value pair ftrace.trace=function
[root@jouet ~]# cat ~/.perfconfig
[ftrace]
tracer = functin
[root@jouet ~]# perf ftrace usleep 1
Please select "function_graph" (default) or "function"
Error: wrong config key-value pair ftrace.tracer=functin
[root@jouet ~]# cat ~/.perfconfig
[ftrace]
tracer = function
[root@jouet ~]# perf ftrace usleep 1 | head -5
  -0 [000] d...  3855.820847: switch_mm_irqs_off <-__schedule
   <...>-18550 [000] d...  3855.820849: finish_task_switch <-__schedule
   <...>-18550 [000] d...  3855.820851: smp_irq_work_interrupt 
<-irq_work_interrupt
   <...>-18550 [000] d...  3855.820851: irq_enter 
<-smp_irq_work_interrupt
   <...>-18550 [000] d...  3855.820851: rcu_irq_enter <-irq_enter
[root@jouet ~]#



This is great!! I agonized about error message for
each other cases as above! But I think this is more precise than my patch!

Thanks,
Taeung

Re: [PATCH v2 2/4] perf ftrace: Add ftrace.tracer config option

[Taeung Song]

On 01/31/2017 10:15 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Jan 31, 2017 at 09:46:28AM -0300, Arnaldo Carvalho de Melo escreveu:

Also you are silently ignoring any unknown variable in this section, so
if someone has this:

cat ~/.perfconfig

[ftrace]

trace = function


I.e. forgets the 'r', it will keep using the current default,
"function_graph" till the user checks the config and adds that missing
'r'...

I haven't changed this because I think this is so common that we should
instead have a different error return for those config callbacks that
will tell perf_config() to say something like:

  "unknown variable %s.%s\n", section_name, variable_name


So I read a bit more the config code and ended up with this:

static int perf_ftrace_config(const char *var, const char *value, void *cb)
{
struct perf_ftrace *ftrace = cb;

if (prefixcmp(var, "ftrace."))
return 0;

if (strcmp(var, "ftrace.tracer"))
return -1;

if (!strcmp(value, "function_graph") ||
!strcmp(value, "function")) {
ftrace->tracer = value;
return 0;
}

pr_err("Please select \"function_graph\" (default) or \"function\"\n");
return -1;
}

I.e. it will ignore variables for other sections and will stop at an unknown
variable or value for ftrace.tracer:

[root@jouet ~]# cat ~/.perfconfig
[ftrace]
trace = function
[root@jouet ~]# perf ftrace usleep 1
Error: wrong config key-value pair ftrace.trace=function
[root@jouet ~]# cat ~/.perfconfig
[ftrace]
tracer = functin
[root@jouet ~]# perf ftrace usleep 1
Please select "function_graph" (default) or "function"
Error: wrong config key-value pair ftrace.tracer=functin
[root@jouet ~]# cat ~/.perfconfig
[ftrace]
tracer = function
[root@jouet ~]# perf ftrace usleep 1 | head -5
  -0 [000] d...  3855.820847: switch_mm_irqs_off <-__schedule
   <...>-18550 [000] d...  3855.820849: finish_task_switch <-__schedule
   <...>-18550 [000] d...  3855.820851: smp_irq_work_interrupt 
<-irq_work_interrupt
   <...>-18550 [000] d...  3855.820851: irq_enter 
<-smp_irq_work_interrupt
   <...>-18550 [000] d...  3855.820851: rcu_irq_enter <-irq_enter
[root@jouet ~]#



This is great!! I agonized about error message for
each other cases as above! But I think this is more precise than my patch!

Thanks,
Taeung

Re: [PATCH 1/2] ARM: dts: i.MX25: add AIPS control registers

[Sascha Hauer]

On Tue, Jan 31, 2017 at 08:20:01PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of
> control registers. Add the memory regions for the control registers to
> the Device Tree.
> 
> All the registers from the i.MX53 AIPSTZ are present on the i.MX25 as
> well. Indicate that we are compatible to fsl,imx53-aipstz. However,
> don't use aipstz for our name, this seems to be specific to i.MX53.
> 
> Signed-off-by: Martin Kaiser 
> ---
>  arch/arm/boot/dts/imx25.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index e0ba550..4c4768f 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -93,6 +93,11 @@
>   reg = <0x43f0 0x10>;
>   ranges;
>  
> + aips1: bridge@43f0 {
> + compatible = "fsl,imx25-aips", 
> "fsl,imx53-aipstz";
> + reg = <0x43f0 0x60>;
> + };

The additional compatible properties should indicate if there is an
older ip block this one is compatible to. Since i.MX53 is newer than
i.MX25 this goes into the wrong direction. If anything you could add the
"fsl,imx25-aips" compatible to the i.MX53 dtsi file, but I don't think
that's worth it.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 1/2] ARM: dts: i.MX25: add AIPS control registers

[Sascha Hauer]

On Tue, Jan 31, 2017 at 08:20:01PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of
> control registers. Add the memory regions for the control registers to
> the Device Tree.
> 
> All the registers from the i.MX53 AIPSTZ are present on the i.MX25 as
> well. Indicate that we are compatible to fsl,imx53-aipstz. However,
> don't use aipstz for our name, this seems to be specific to i.MX53.
> 
> Signed-off-by: Martin Kaiser 
> ---
>  arch/arm/boot/dts/imx25.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index e0ba550..4c4768f 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -93,6 +93,11 @@
>   reg = <0x43f0 0x10>;
>   ranges;
>  
> + aips1: bridge@43f0 {
> + compatible = "fsl,imx25-aips", 
> "fsl,imx53-aipstz";
> + reg = <0x43f0 0x60>;
> + };

The additional compatible properties should indicate if there is an
older ip block this one is compatible to. Since i.MX53 is newer than
i.MX25 this goes into the wrong direction. If anything you could add the
"fsl,imx25-aips" compatible to the i.MX53 dtsi file, but I don't think
that's worth it.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 1/4] perf tools: Create for_each_event macro for tracepoints iteration

[Taeung Song]

Hi, Arnaldo :)

On 01/31/2017 09:21 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Jan 31, 2017 at 08:38:28PM +0900, Taeung Song escreveu:

Such as for_each_subsystem and for_each_event in util/parse-events.c,
add new macros 'for_each_event' for easy iteration over the tracepoints
in order to be more compact and readable.


Looks ok, applied, but look below for some minor suggestions.

- Arnaldo


Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Signed-off-by: Taeung Song 
---
 tools/perf/util/trace-event-info.c | 38 ++
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/tools/perf/util/trace-event-info.c 
b/tools/perf/util/trace-event-info.c
index ceb0e27..fb6d95d 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -170,6 +170,12 @@ static bool name_in_tp_list(char *sys, struct 
tracepoint_path *tps)
return false;
 }

+#define for_each_event(dir, dent, tps) \
+   while ((dent = readdir(dir)))   \
+   if (dent->d_type == DT_DIR &&\
+   (strcmp(dent->d_name, ".")) && \
+   (strcmp(dent->d_name, "..")))  \
+
 static int copy_event_system(const char *sys, struct tracepoint_path *tps)
 {
struct dirent *dent;
@@ -186,12 +192,10 @@ static int copy_event_system(const char *sys, struct 
tracepoint_path *tps)
return -errno;
}

-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   !name_in_tp_list(dent->d_name, tps))
+   for_each_event(dir, dent, tps) {
+   if (!name_in_tp_list(dent->d_name, tps))
continue;
+
if (asprintf(, "%s/%s/format", sys, dent->d_name) < 0) {
err = -ENOMEM;
goto out;
@@ -210,12 +214,10 @@ static int copy_event_system(const char *sys, struct 
tracepoint_path *tps)
}

rewinddir(dir);
-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   !name_in_tp_list(dent->d_name, tps))
+   for_each_event(dir, dent, tps) {
+   if (!name_in_tp_list(dent->d_name, tps))
continue;
+
if (asprintf(, "%s/%s/format", sys, dent->d_name) < 0) {
err = -ENOMEM;
goto out;
@@ -290,13 +292,11 @@ static int record_event_files(struct tracepoint_path *tps)
goto out;
}

-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   strcmp(dent->d_name, "ftrace") == 0 ||
+   for_each_event(dir, dent, tps) {
+   if (!strcmp(dent->d_name, "ftrace") ||


the existing style was == 0, you switched it to !, equivalent, but
gratuitous, keeping the existing style would make reviewing slightly
faster, as the pattern wouldn't have changed.



I understood !!
In the future, I'll think this when making some patches.

Thanks,
Taeung

Re: [PATCH v2 1/4] perf tools: Create for_each_event macro for tracepoints iteration

[Taeung Song]

Hi, Arnaldo :)

On 01/31/2017 09:21 PM, Arnaldo Carvalho de Melo wrote:

Em Tue, Jan 31, 2017 at 08:38:28PM +0900, Taeung Song escreveu:

Such as for_each_subsystem and for_each_event in util/parse-events.c,
add new macros 'for_each_event' for easy iteration over the tracepoints
in order to be more compact and readable.


Looks ok, applied, but look below for some minor suggestions.

- Arnaldo


Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Signed-off-by: Taeung Song 
---
 tools/perf/util/trace-event-info.c | 38 ++
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/tools/perf/util/trace-event-info.c 
b/tools/perf/util/trace-event-info.c
index ceb0e27..fb6d95d 100644
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -170,6 +170,12 @@ static bool name_in_tp_list(char *sys, struct 
tracepoint_path *tps)
return false;
 }

+#define for_each_event(dir, dent, tps) \
+   while ((dent = readdir(dir)))   \
+   if (dent->d_type == DT_DIR &&\
+   (strcmp(dent->d_name, ".")) && \
+   (strcmp(dent->d_name, "..")))  \
+
 static int copy_event_system(const char *sys, struct tracepoint_path *tps)
 {
struct dirent *dent;
@@ -186,12 +192,10 @@ static int copy_event_system(const char *sys, struct 
tracepoint_path *tps)
return -errno;
}

-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   !name_in_tp_list(dent->d_name, tps))
+   for_each_event(dir, dent, tps) {
+   if (!name_in_tp_list(dent->d_name, tps))
continue;
+
if (asprintf(, "%s/%s/format", sys, dent->d_name) < 0) {
err = -ENOMEM;
goto out;
@@ -210,12 +214,10 @@ static int copy_event_system(const char *sys, struct 
tracepoint_path *tps)
}

rewinddir(dir);
-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   !name_in_tp_list(dent->d_name, tps))
+   for_each_event(dir, dent, tps) {
+   if (!name_in_tp_list(dent->d_name, tps))
continue;
+
if (asprintf(, "%s/%s/format", sys, dent->d_name) < 0) {
err = -ENOMEM;
goto out;
@@ -290,13 +292,11 @@ static int record_event_files(struct tracepoint_path *tps)
goto out;
}

-   while ((dent = readdir(dir))) {
-   if (dent->d_type != DT_DIR ||
-   strcmp(dent->d_name, ".") == 0 ||
-   strcmp(dent->d_name, "..") == 0 ||
-   strcmp(dent->d_name, "ftrace") == 0 ||
+   for_each_event(dir, dent, tps) {
+   if (!strcmp(dent->d_name, "ftrace") ||


the existing style was == 0, you switched it to !, equivalent, but
gratuitous, keeping the existing style would make reviewing slightly
faster, as the pattern wouldn't have changed.



I understood !!
In the future, I'll think this when making some patches.

Thanks,
Taeung

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 11:34 PM, Dave Hansen wrote:
> On 01/30/2017 11:25 PM, John Hubbard wrote:
>> I also don't like having these policies hard-coded, and your 100x
>> example above helps clarify what can go wrong about it. It would be
>> nicer if, instead, we could better express the "distance" between nodes
>> (bandwidth, latency, relative to sysmem, perhaps), and let the NUMA
>> system figure out the Right Thing To Do.
>>
>> I realize that this is not quite possible with NUMA just yet, but I
>> wonder if that's a reasonable direction to go with this?
> 
> In the end, I don't think the kernel can make the "right" decision very
> widely here.
> 
> Intel's Xeon Phis have some high-bandwidth memory (MCDRAM) that
> evidently has a higher latency than DRAM.  Given a plain malloc(), how
> is the kernel to know that the memory will be used for AVX-512
> instructions that need lots of bandwidth vs. some random data structure
> that's latency-sensitive?

CDM has been designed to work with a driver which can take these kind
of appropriate memory placement decisions along the way. But as per
the above example of an generic malloc() allocated buffer.

(1) System RAM gets allocated if there are first CPU faults
(2) CDM memory gets allocated if there are first device access faults
(3) After monitoring the access patterns there after, the driver can
then take required "right" decisions about its eventual placement
and migrates memory as required

> 
> In the end, I think all we can do is keep the kernel's existing default
> of "low latency to the CPU that allocated it", and let apps override
> when that policy doesn't fit them.

I think this is almost similar to what we are trying to achieve with
CDM representation and driver based migrations. Dont you agree ?

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 11:34 PM, Dave Hansen wrote:
> On 01/30/2017 11:25 PM, John Hubbard wrote:
>> I also don't like having these policies hard-coded, and your 100x
>> example above helps clarify what can go wrong about it. It would be
>> nicer if, instead, we could better express the "distance" between nodes
>> (bandwidth, latency, relative to sysmem, perhaps), and let the NUMA
>> system figure out the Right Thing To Do.
>>
>> I realize that this is not quite possible with NUMA just yet, but I
>> wonder if that's a reasonable direction to go with this?
> 
> In the end, I don't think the kernel can make the "right" decision very
> widely here.
> 
> Intel's Xeon Phis have some high-bandwidth memory (MCDRAM) that
> evidently has a higher latency than DRAM.  Given a plain malloc(), how
> is the kernel to know that the memory will be used for AVX-512
> instructions that need lots of bandwidth vs. some random data structure
> that's latency-sensitive?

CDM has been designed to work with a driver which can take these kind
of appropriate memory placement decisions along the way. But as per
the above example of an generic malloc() allocated buffer.

(1) System RAM gets allocated if there are first CPU faults
(2) CDM memory gets allocated if there are first device access faults
(3) After monitoring the access patterns there after, the driver can
then take required "right" decisions about its eventual placement
and migrates memory as required

> 
> In the end, I think all we can do is keep the kernel's existing default
> of "low latency to the CPU that allocated it", and let apps override
> when that policy doesn't fit them.

I think this is almost similar to what we are trying to achieve with
CDM representation and driver based migrations. Dont you agree ?

Re: remove the cmd_type field from struct request

[Hannes Reinecke]

On 01/31/2017 07:02 PM, Jens Axboe wrote:

On 01/31/2017 07:57 AM, Christoph Hellwig wrote:

[1] which were a pain in the ass to untangle and debug during development,
it's really time for it to die..


Outside of the patch series in question, how to we expedite the
euthanasia of IDE? What explicit features/support are we missing through
libata that would need to be added, before we can git rm drivers/ide/ ?

There is only a single driver (sgi_ide) which hasn't been moved over to 
libata. But this is for an old Itanium-based server only, and even SGI 
didn't press us to have this ported.
(And we have disabled the IDE drivers since SLES11, where we still 
support Itanium.)

So they can be safely assumed defunct at this time.

I'm all for removing them.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: remove the cmd_type field from struct request

[Hannes Reinecke]

On 01/31/2017 07:02 PM, Jens Axboe wrote:

On 01/31/2017 07:57 AM, Christoph Hellwig wrote:

[1] which were a pain in the ass to untangle and debug during development,
it's really time for it to die..


Outside of the patch series in question, how to we expedite the
euthanasia of IDE? What explicit features/support are we missing through
libata that would need to be added, before we can git rm drivers/ide/ ?

There is only a single driver (sgi_ide) which hasn't been moved over to 
libata. But this is for an old Itanium-based server only, and even SGI 
didn't press us to have this ported.
(And we have disabled the IDE drivers since SLES11, where we still 
support Itanium.)

So they can be safely assumed defunct at this time.

I'm all for removing them.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

RE: kernel 4.10-rcx iio helper question

[Jonathan Cameron]

On 1 February 2017 00:42:31 GMT+00:00, "Ken.Lin"  wrote:
>
>
>> -Original Message-
>> From: Peter Rosin [mailto:p...@axentia.se]
>> Sent: Tuesday, January 31, 2017 1:10 PM
>> To: Ken.Lin; ji...@kernel.org
>> Cc: knaac...@gmx.de; pme...@pmeerw.net; linux-...@vger.kernel.org;
>linux-
>> ker...@vger.kernel.org; Akshay Bhat; Peter.Stretz; Peter.Chiang
>> Subject: Re: kernel 4.10-rcx iio helper question
>> 
>> On 2017-01-31 19:19, Ken.Lin wrote:
>> > Hi,
>> >
>> > I find the latest kernel introduces new iio sys attributes.
>> > https://patchwork.kernel.org/patch/9391771/
>> > https://patchwork.kernel.org/patch/9391259/
>> >
>> > Is there anyone has some ideas about how the new iio sys attribute
>-
>> in_pressure_scale_available works?
>> > I'm not sure if it's the regression issue or it's just the usage
>issue or something
>> when I tried to read in_pressure_scale_available attribute.
>> 
>> > # cat /sys/bus/iio/devices/iio\:device1/in_pressure_scale_available
>> > Segmentation fault
>> 
>> What driver is providing iio:device1?
>> 
>> > [ 3785.077014] Unable to handle kernel NULL pointer dereference at
>> > virtual address  [ 3785.085138] pgd = ecc3c000 [
>3785.087929]
>> > [] *pgd=87f91831 [ 3785.091563] Internal error: Oops:
>8007
>> > [#1] SMP ARM [ 3785.096806] Modules linked in:
>> > [ 3785.099892] CPU: 1 PID: 1051 Comm: cat Not tainted
>> > 4.10.0-rc5-9-gffd8858-dirty #3
>> 
>> Looks like you have a couple of local changes? What are those?
>> 
>
>I didn't make any changes to the iio drivers locally and MPL3115A2
>pressure/temperature sensor driver (drivers/iio/pressure/mpl3115.c) is
>the driver which provides iio:device1.
>
>> My WAG is that you added the IIO_CHAN_INFO_SCALE bit to one of the
>> .info_mask_*_available fields in the channel spec but failed to
>provide a
>> .read_avail operation in the driver. Am I close?
>> 
>
>I could read iio:device0/in_accel_scale and device0/in_accel_available,
>which are provided by NXP 3-axis accelerometers driver
>(drivers/iio/accel/mma8452.c).
>The attribute iio:/device1/in_pressure_scale is missing unless I
>reverted the commits.
>https://patchwork.kernel.org/patch/9391771/
>https://patchwork.kernel.org/patch/9391259/

Getting weird. Any possibility you have a mix of modules with and without those 
patches?

Would probably be mpl3115 without and industrialio with.  The structure gained 
some
bitmasks between previous masks.

But if so I am little surprised it isn't causing worse issues.

>
>Cheers,
>Ken Lin
>
>> Cheers,
>> peda
>> 
>> > [ 3785.107740] Hardware name: Freescale i.MX6 Quad/DualLite (Device
>> > Tree) [ 3785.114285] task: ed54ec00 task.stack: ee2bc000 [
>> > 3785.118834] PC is at 0x0 [ 3785.121397] LR is at
>> > iio_read_channel_info_avail+0x40/0x280
>> > [ 3785.126992] pc : [<>]lr : []psr:
>a0070013
>> > [ 3785.126992] sp : ee2bdda8  ip :   fp : ee2bddf4 [
>> > 3785.138490] r10: c0a53c74  r9 : ed79f000  r8 : ee8d1018 [
>> > 3785.143733] r7 : 1000  r6 : 0fff  r5 : ee8b9a00  r4 :
>> > ed79f000 [ 3785.150276] r3 : ee2bddc4  r2 : ee2bddbc  r1 : c0a86dcc
>> > r0 : ee8d1000 [ 3785.156820] Flags: NzCv  IRQs on  FIQs on  Mode
>> > SVC_32  ISA ARM  Segment none [ 3785.163971] Control: 10c5387d 
>Table:
>> > 3cc3c04a  DAC: 0051 [ 3785.169734] Process cat (pid: 1051,
>stack
>> > limit = 0xee2bc210) [ 3785.175497] Stack: (0xee2bdda8 to
>0xee2be000)
>> > [ 3785.179880] dda0:   ee2bddc0 0002 c016d720
>c016d394
>> ed54ec00 
>> > [ 3785.188084] ddc0: 60070013 ed413780 0001 edffd480 ee8b9a00
>> > 0fff 1000 ee8d1018 [ 3785.196286] dde0: ed79f000 c0a53c74
>> > ee2bde0c ee2bddf8 c0513c58 c06fbbe8 edffd480 edffd540 [
>3785.204488]
>> > de00: ee2bde3c ee2bde10 c0293474 c0513c40 c02933e4 ee2bde60
>0001
>> > ed413780 [ 3785.212688] de20: 0001 ed413780  edffd480
>> > ee2bde4c ee2bde40 c0291d00 c02933f0 [ 3785.220889] de40: ee2bde9c
>> > ee2bde50 c024679c c0291ce0 edffd4b0 b6e37000 0002 ee2bdf78 [
>> > 3785.229089] de60:   ed54ec00 ed013200 0817
>> > c0a111fc edffd540 ed413780 [ 3785.237289] de80: b6e37000 0002
>> > 0002 ee2bdf78 ee2bded4 ee2bdea0 c0292890 c0246604 [
>3785.245491]
>> > dea0: c0117940 c016ba50 0025 c0a111fc b6e37000 ed413780
>ee2bdf78
>> > 0002 [ 3785.253691] dec0: ee2bc000 b6e37000 ee2bdf44 ee2bded8
>> > c021d158 c0292770 c0117764 b6e36004 [ 3785.261893] dee0: c0f0d7c4
>> > ee2bdfb0 b6f89228 00021008 ee2bdfac ee2bdf00 c0101374 c0117770 [
>> > 3785.270093] df00:   ee2bc000  ee2bdf34
>> > ee2bdf20 c016ba04 c0171080 [ 3785.278292] df20:  0002
>> > ed413780 b6e37000  ee2bdf78 ee2bdf74 ee2bdf48 [
>3785.286493]
>> > df40: c021e7a0 c021d130 c023e300 c023e280 ee2bdf74 
>
>> > ed413780 [ 3785.294693] df60: ed413780 0002 ee2bdfa4 ee2bdf78
>> c021e870 c021e71c   [ 3785.302892] df80: 0002
>> 0002 

RE: kernel 4.10-rcx iio helper question

[Jonathan Cameron]

On 1 February 2017 00:42:31 GMT+00:00, "Ken.Lin"  wrote:
>
>
>> -Original Message-
>> From: Peter Rosin [mailto:p...@axentia.se]
>> Sent: Tuesday, January 31, 2017 1:10 PM
>> To: Ken.Lin; ji...@kernel.org
>> Cc: knaac...@gmx.de; pme...@pmeerw.net; linux-...@vger.kernel.org;
>linux-
>> ker...@vger.kernel.org; Akshay Bhat; Peter.Stretz; Peter.Chiang
>> Subject: Re: kernel 4.10-rcx iio helper question
>> 
>> On 2017-01-31 19:19, Ken.Lin wrote:
>> > Hi,
>> >
>> > I find the latest kernel introduces new iio sys attributes.
>> > https://patchwork.kernel.org/patch/9391771/
>> > https://patchwork.kernel.org/patch/9391259/
>> >
>> > Is there anyone has some ideas about how the new iio sys attribute
>-
>> in_pressure_scale_available works?
>> > I'm not sure if it's the regression issue or it's just the usage
>issue or something
>> when I tried to read in_pressure_scale_available attribute.
>> 
>> > # cat /sys/bus/iio/devices/iio\:device1/in_pressure_scale_available
>> > Segmentation fault
>> 
>> What driver is providing iio:device1?
>> 
>> > [ 3785.077014] Unable to handle kernel NULL pointer dereference at
>> > virtual address  [ 3785.085138] pgd = ecc3c000 [
>3785.087929]
>> > [] *pgd=87f91831 [ 3785.091563] Internal error: Oops:
>8007
>> > [#1] SMP ARM [ 3785.096806] Modules linked in:
>> > [ 3785.099892] CPU: 1 PID: 1051 Comm: cat Not tainted
>> > 4.10.0-rc5-9-gffd8858-dirty #3
>> 
>> Looks like you have a couple of local changes? What are those?
>> 
>
>I didn't make any changes to the iio drivers locally and MPL3115A2
>pressure/temperature sensor driver (drivers/iio/pressure/mpl3115.c) is
>the driver which provides iio:device1.
>
>> My WAG is that you added the IIO_CHAN_INFO_SCALE bit to one of the
>> .info_mask_*_available fields in the channel spec but failed to
>provide a
>> .read_avail operation in the driver. Am I close?
>> 
>
>I could read iio:device0/in_accel_scale and device0/in_accel_available,
>which are provided by NXP 3-axis accelerometers driver
>(drivers/iio/accel/mma8452.c).
>The attribute iio:/device1/in_pressure_scale is missing unless I
>reverted the commits.
>https://patchwork.kernel.org/patch/9391771/
>https://patchwork.kernel.org/patch/9391259/

Getting weird. Any possibility you have a mix of modules with and without those 
patches?

Would probably be mpl3115 without and industrialio with.  The structure gained 
some
bitmasks between previous masks.

But if so I am little surprised it isn't causing worse issues.

>
>Cheers,
>Ken Lin
>
>> Cheers,
>> peda
>> 
>> > [ 3785.107740] Hardware name: Freescale i.MX6 Quad/DualLite (Device
>> > Tree) [ 3785.114285] task: ed54ec00 task.stack: ee2bc000 [
>> > 3785.118834] PC is at 0x0 [ 3785.121397] LR is at
>> > iio_read_channel_info_avail+0x40/0x280
>> > [ 3785.126992] pc : [<>]lr : []psr:
>a0070013
>> > [ 3785.126992] sp : ee2bdda8  ip :   fp : ee2bddf4 [
>> > 3785.138490] r10: c0a53c74  r9 : ed79f000  r8 : ee8d1018 [
>> > 3785.143733] r7 : 1000  r6 : 0fff  r5 : ee8b9a00  r4 :
>> > ed79f000 [ 3785.150276] r3 : ee2bddc4  r2 : ee2bddbc  r1 : c0a86dcc
>> > r0 : ee8d1000 [ 3785.156820] Flags: NzCv  IRQs on  FIQs on  Mode
>> > SVC_32  ISA ARM  Segment none [ 3785.163971] Control: 10c5387d 
>Table:
>> > 3cc3c04a  DAC: 0051 [ 3785.169734] Process cat (pid: 1051,
>stack
>> > limit = 0xee2bc210) [ 3785.175497] Stack: (0xee2bdda8 to
>0xee2be000)
>> > [ 3785.179880] dda0:   ee2bddc0 0002 c016d720
>c016d394
>> ed54ec00 
>> > [ 3785.188084] ddc0: 60070013 ed413780 0001 edffd480 ee8b9a00
>> > 0fff 1000 ee8d1018 [ 3785.196286] dde0: ed79f000 c0a53c74
>> > ee2bde0c ee2bddf8 c0513c58 c06fbbe8 edffd480 edffd540 [
>3785.204488]
>> > de00: ee2bde3c ee2bde10 c0293474 c0513c40 c02933e4 ee2bde60
>0001
>> > ed413780 [ 3785.212688] de20: 0001 ed413780  edffd480
>> > ee2bde4c ee2bde40 c0291d00 c02933f0 [ 3785.220889] de40: ee2bde9c
>> > ee2bde50 c024679c c0291ce0 edffd4b0 b6e37000 0002 ee2bdf78 [
>> > 3785.229089] de60:   ed54ec00 ed013200 0817
>> > c0a111fc edffd540 ed413780 [ 3785.237289] de80: b6e37000 0002
>> > 0002 ee2bdf78 ee2bded4 ee2bdea0 c0292890 c0246604 [
>3785.245491]
>> > dea0: c0117940 c016ba50 0025 c0a111fc b6e37000 ed413780
>ee2bdf78
>> > 0002 [ 3785.253691] dec0: ee2bc000 b6e37000 ee2bdf44 ee2bded8
>> > c021d158 c0292770 c0117764 b6e36004 [ 3785.261893] dee0: c0f0d7c4
>> > ee2bdfb0 b6f89228 00021008 ee2bdfac ee2bdf00 c0101374 c0117770 [
>> > 3785.270093] df00:   ee2bc000  ee2bdf34
>> > ee2bdf20 c016ba04 c0171080 [ 3785.278292] df20:  0002
>> > ed413780 b6e37000  ee2bdf78 ee2bdf74 ee2bdf48 [
>3785.286493]
>> > df40: c021e7a0 c021d130 c023e300 c023e280 ee2bdf74 
>
>> > ed413780 [ 3785.294693] df60: ed413780 0002 ee2bdfa4 ee2bdf78
>> c021e870 c021e71c   [ 3785.302892] df80: 0002
>> 0002 b6e37000 0003 

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

[Minchan Kim]

Hi Yisheng,

On Tue, Jan 31, 2017 at 09:06:18PM +0800, ys...@foxmail.com wrote:
> From: Yisheng Xie 
> 
> This patch changes the return type of isolate_movable_page()
> from bool to int. It will return 0 when isolate movable page
> successfully, return -EINVAL when the page is not a non-lru movable
> page, and for other cases it will return -EBUSY.
> 
> There is no functional change within this patch but prepare
> for later patch.
> 
> Signed-off-by: Yisheng Xie 
> Suggested-by: Michal Hocko 

Sorry for missing this one you guys were discussing.
I don't understand the patch's goal although I read later patches.

isolate_movable_pages returns success/fail so that's why I selected
bool rather than int but it seems you guys want to propagate more
detailed error to the user so added -EBUSY and -EINVAL.

But the question is why isolate_lru_pages doesn't have -EINVAL?
Secondly, madvise man page should update?
Thirdly, if a driver fail isolation due to -ENOMEM, it should be
propagated, too?

if we want to propagte detailed error to user, driver's isolate_page
function should return right error.

I don't feel this all changes should be done now. What's the problem
if we change isolate_lru_page from int to bool? it returns just binary
value so it should be right place to use bool. If it fails, error val
is just -EBUSY.


> Cc: Minchan Kim 
> Cc: Naoya Horiguchi 
> CC: Vlastimil Babka 
> ---
>  include/linux/migrate.h |  2 +-
>  mm/compaction.c |  2 +-
>  mm/migrate.c| 11 +++
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475..43d5deb 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -37,7 +37,7 @@ extern int migrate_page(struct address_space *,
>   struct page *, struct page *, enum migrate_mode);
>  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> free,
>   unsigned long private, enum migrate_mode mode, int reason);
> -extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> +extern int isolate_movable_page(struct page *page, isolate_mode_t mode);
>  extern void putback_movable_page(struct page *page);
>  
>  extern int migrate_prep(void);
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 949198d..1d89147 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -802,7 +802,7 @@ static bool too_many_isolated(struct zone *zone)
>   locked = false;
>   }
>  
> - if (isolate_movable_page(page, isolate_mode))
> + if (!isolate_movable_page(page, isolate_mode))
>   goto isolate_success;
>   }
>  
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 87f4d0f..bbbd170 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -74,8 +74,9 @@ int migrate_prep_local(void)
>   return 0;
>  }
>  
> -bool isolate_movable_page(struct page *page, isolate_mode_t mode)
> +int isolate_movable_page(struct page *page, isolate_mode_t mode)
>  {
> + int ret = -EBUSY;
>   struct address_space *mapping;
>  
>   /*
> @@ -95,8 +96,10 @@ bool isolate_movable_page(struct page *page, 
> isolate_mode_t mode)
>* assumes anybody doesn't touch PG_lock of newly allocated page
>* so unconditionally grapping the lock ruins page's owner side.
>*/
> - if (unlikely(!__PageMovable(page)))
> + if (unlikely(!__PageMovable(page))) {
> + ret = -EINVAL;
>   goto out_putpage;
> + }
>   /*
>* As movable pages are not isolated from LRU lists, concurrent
>* compaction threads can race against page migration functions
> @@ -125,14 +128,14 @@ bool isolate_movable_page(struct page *page, 
> isolate_mode_t mode)
>   __SetPageIsolated(page);
>   unlock_page(page);
>  
> - return true;
> + return 0;
>  
>  out_no_isolated:
>   unlock_page(page);
>  out_putpage:
>   put_page(page);
>  out:
> - return false;
> + return ret;
>  }
>  
>  /* It should be called on page which is PG_movable */
> -- 
> 1.9.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

[Minchan Kim]

Hi Yisheng,

On Tue, Jan 31, 2017 at 09:06:18PM +0800, ys...@foxmail.com wrote:
> From: Yisheng Xie 
> 
> This patch changes the return type of isolate_movable_page()
> from bool to int. It will return 0 when isolate movable page
> successfully, return -EINVAL when the page is not a non-lru movable
> page, and for other cases it will return -EBUSY.
> 
> There is no functional change within this patch but prepare
> for later patch.
> 
> Signed-off-by: Yisheng Xie 
> Suggested-by: Michal Hocko 

Sorry for missing this one you guys were discussing.
I don't understand the patch's goal although I read later patches.

isolate_movable_pages returns success/fail so that's why I selected
bool rather than int but it seems you guys want to propagate more
detailed error to the user so added -EBUSY and -EINVAL.

But the question is why isolate_lru_pages doesn't have -EINVAL?
Secondly, madvise man page should update?
Thirdly, if a driver fail isolation due to -ENOMEM, it should be
propagated, too?

if we want to propagte detailed error to user, driver's isolate_page
function should return right error.

I don't feel this all changes should be done now. What's the problem
if we change isolate_lru_page from int to bool? it returns just binary
value so it should be right place to use bool. If it fails, error val
is just -EBUSY.


> Cc: Minchan Kim 
> Cc: Naoya Horiguchi 
> CC: Vlastimil Babka 
> ---
>  include/linux/migrate.h |  2 +-
>  mm/compaction.c |  2 +-
>  mm/migrate.c| 11 +++
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475..43d5deb 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -37,7 +37,7 @@ extern int migrate_page(struct address_space *,
>   struct page *, struct page *, enum migrate_mode);
>  extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t 
> free,
>   unsigned long private, enum migrate_mode mode, int reason);
> -extern bool isolate_movable_page(struct page *page, isolate_mode_t mode);
> +extern int isolate_movable_page(struct page *page, isolate_mode_t mode);
>  extern void putback_movable_page(struct page *page);
>  
>  extern int migrate_prep(void);
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 949198d..1d89147 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -802,7 +802,7 @@ static bool too_many_isolated(struct zone *zone)
>   locked = false;
>   }
>  
> - if (isolate_movable_page(page, isolate_mode))
> + if (!isolate_movable_page(page, isolate_mode))
>   goto isolate_success;
>   }
>  
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 87f4d0f..bbbd170 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -74,8 +74,9 @@ int migrate_prep_local(void)
>   return 0;
>  }
>  
> -bool isolate_movable_page(struct page *page, isolate_mode_t mode)
> +int isolate_movable_page(struct page *page, isolate_mode_t mode)
>  {
> + int ret = -EBUSY;
>   struct address_space *mapping;
>  
>   /*
> @@ -95,8 +96,10 @@ bool isolate_movable_page(struct page *page, 
> isolate_mode_t mode)
>* assumes anybody doesn't touch PG_lock of newly allocated page
>* so unconditionally grapping the lock ruins page's owner side.
>*/
> - if (unlikely(!__PageMovable(page)))
> + if (unlikely(!__PageMovable(page))) {
> + ret = -EINVAL;
>   goto out_putpage;
> + }
>   /*
>* As movable pages are not isolated from LRU lists, concurrent
>* compaction threads can race against page migration functions
> @@ -125,14 +128,14 @@ bool isolate_movable_page(struct page *page, 
> isolate_mode_t mode)
>   __SetPageIsolated(page);
>   unlock_page(page);
>  
> - return true;
> + return 0;
>  
>  out_no_isolated:
>   unlock_page(page);
>  out_putpage:
>   put_page(page);
>  out:
> - return false;
> + return ret;
>  }
>  
>  /* It should be called on page which is PG_movable */
> -- 
> 1.9.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 12:55 PM, John Hubbard wrote:
> On 01/30/2017 05:57 PM, Dave Hansen wrote:
>> On 01/30/2017 05:36 PM, Anshuman Khandual wrote:
 Let's say we had a CDM node with 100x more RAM than the rest of the
 system and it was just as fast as the rest of the RAM.  Would we still
 want it isolated like this?  Or would we want a different policy?
>>>
>>> But then the other argument being, dont we want to keep this 100X more
>>> memory isolated for some special purpose to be utilized by specific
>>> applications ?
>>
>> I was thinking that in this case, we wouldn't even want to bother with
>> having "system RAM" in the fallback lists.  A device who got its memory
>> usage off by 1% could start to starve the rest of the system.  A sane
>> policy in this case might be to isolate the "system RAM" from the
>> device's.
> 
> I also don't like having these policies hard-coded, and your 100x
> example above helps clarify what can go wrong about it. It would be
> nicer if, instead, we could better express the "distance" between nodes
> (bandwidth, latency, relative to sysmem, perhaps), and let the NUMA
> system figure out the Right Thing To Do.
> 
> I realize that this is not quite possible with NUMA just yet, but I
> wonder if that's a reasonable direction to go with this?

That is complete overhaul of the NUMA representation in the kernel. What
CDM attempts is to find a solution with existing NUMA framework and with
as little code change as possible.

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 12:55 PM, John Hubbard wrote:
> On 01/30/2017 05:57 PM, Dave Hansen wrote:
>> On 01/30/2017 05:36 PM, Anshuman Khandual wrote:
 Let's say we had a CDM node with 100x more RAM than the rest of the
 system and it was just as fast as the rest of the RAM.  Would we still
 want it isolated like this?  Or would we want a different policy?
>>>
>>> But then the other argument being, dont we want to keep this 100X more
>>> memory isolated for some special purpose to be utilized by specific
>>> applications ?
>>
>> I was thinking that in this case, we wouldn't even want to bother with
>> having "system RAM" in the fallback lists.  A device who got its memory
>> usage off by 1% could start to starve the rest of the system.  A sane
>> policy in this case might be to isolate the "system RAM" from the
>> device's.
> 
> I also don't like having these policies hard-coded, and your 100x
> example above helps clarify what can go wrong about it. It would be
> nicer if, instead, we could better express the "distance" between nodes
> (bandwidth, latency, relative to sysmem, perhaps), and let the NUMA
> system figure out the Right Thing To Do.
> 
> I realize that this is not quite possible with NUMA just yet, but I
> wonder if that's a reasonable direction to go with this?

That is complete overhaul of the NUMA representation in the kernel. What
CDM attempts is to find a solution with existing NUMA framework and with
as little code change as possible.

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 07:27 AM, Dave Hansen wrote:
> On 01/30/2017 05:36 PM, Anshuman Khandual wrote:
>>> Let's say we had a CDM node with 100x more RAM than the rest of the
>>> system and it was just as fast as the rest of the RAM.  Would we still
>>> want it isolated like this?  Or would we want a different policy?
>>
>> But then the other argument being, dont we want to keep this 100X more
>> memory isolated for some special purpose to be utilized by specific
>> applications ?
> 
> I was thinking that in this case, we wouldn't even want to bother with
> having "system RAM" in the fallback lists.  A device who got its memory

System RAM is in the fallback list of the CDM node for the following
purpose.

If the user asks explicitly through mbind() and there is insufficient
memory on the CDM node to fulfill the request. Then it is better to
fallback on a system RAM memory node than to fail the request. This is
in line with expectations from the mbind() call. There are other ways
for the user space like /proc/pid/numa_maps to query about from where
exactly a given page has come from in the runtime.

But keeping options open I have noted down this in the cover letter.

"
FALLBACK zonelist creation:

CDM node's FALLBACK zonelist can also be changed to accommodate other CDM
memory zones along with system RAM zones in which case they can be used as
fallback options instead of first depending on the system RAM zones when
it's own memory falls insufficient during allocation.
"

> usage off by 1% could start to starve the rest of the system.  A sane

Did not get this point. Could you please elaborate more on this ?

> policy in this case might be to isolate the "system RAM" from the device's.

Hmm.

> 
>>> Why do we need this hard-coded along with the cpuset stuff later in the
>>> series.  Doesn't taking a node out of the cpuset also take it out of the
>>> fallback lists?
>>
>> There are two mutually exclusive approaches which are described in
>> this patch series.
>>
>> (1) zonelist modification based approach
>> (2) cpuset restriction based approach
>>
>> As mentioned in the cover letter,
> 
> Well, I'm glad you coded both of them up, but now that we have them how
> to we pick which one to throw to the wolves?  Or, do we just merge both
> of them and let one bitrot? ;)

I am just trying to see how each isolation method stack up from benefit
and cost point of view, so that we can have informed debate about their
individual merit. Meanwhile I have started looking at if the core buddy
allocator __alloc_pages_nodemask() and its interaction with nodemask at
various stages can also be modified to implement the intended solution.

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

On 01/31/2017 07:27 AM, Dave Hansen wrote:
> On 01/30/2017 05:36 PM, Anshuman Khandual wrote:
>>> Let's say we had a CDM node with 100x more RAM than the rest of the
>>> system and it was just as fast as the rest of the RAM.  Would we still
>>> want it isolated like this?  Or would we want a different policy?
>>
>> But then the other argument being, dont we want to keep this 100X more
>> memory isolated for some special purpose to be utilized by specific
>> applications ?
> 
> I was thinking that in this case, we wouldn't even want to bother with
> having "system RAM" in the fallback lists.  A device who got its memory

System RAM is in the fallback list of the CDM node for the following
purpose.

If the user asks explicitly through mbind() and there is insufficient
memory on the CDM node to fulfill the request. Then it is better to
fallback on a system RAM memory node than to fail the request. This is
in line with expectations from the mbind() call. There are other ways
for the user space like /proc/pid/numa_maps to query about from where
exactly a given page has come from in the runtime.

But keeping options open I have noted down this in the cover letter.

"
FALLBACK zonelist creation:

CDM node's FALLBACK zonelist can also be changed to accommodate other CDM
memory zones along with system RAM zones in which case they can be used as
fallback options instead of first depending on the system RAM zones when
it's own memory falls insufficient during allocation.
"

> usage off by 1% could start to starve the rest of the system.  A sane

Did not get this point. Could you please elaborate more on this ?

> policy in this case might be to isolate the "system RAM" from the device's.

Hmm.

> 
>>> Why do we need this hard-coded along with the cpuset stuff later in the
>>> series.  Doesn't taking a node out of the cpuset also take it out of the
>>> fallback lists?
>>
>> There are two mutually exclusive approaches which are described in
>> this patch series.
>>
>> (1) zonelist modification based approach
>> (2) cpuset restriction based approach
>>
>> As mentioned in the cover letter,
> 
> Well, I'm glad you coded both of them up, but now that we have them how
> to we pick which one to throw to the wolves?  Or, do we just merge both
> of them and let one bitrot? ;)

I am just trying to see how each isolation method stack up from benefit
and cost point of view, so that we can have informed debate about their
individual merit. Meanwhile I have started looking at if the core buddy
allocator __alloc_pages_nodemask() and its interaction with nodemask at
various stages can also be modified to implement the intended solution.

[PATCH] block: queue lock must be acquired when iterating over rls

[Tahsin Erdogan]

blk_set_queue_dying() does not acquire queue lock before it calls
blk_queue_for_each_rl(). This allows a racing blkg_destroy() to
remove blkg->q_node from the linked list and have
blk_queue_for_each_rl() loop infitely over the removed blkg->q_node
list node.

Signed-off-by: Tahsin Erdogan 
---
 block/blk-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/block/blk-core.c b/block/blk-core.c
index 61ba08c58b64..0488a2b55bf0 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -525,12 +525,14 @@ void blk_set_queue_dying(struct request_queue *q)
else {
struct request_list *rl;
 
+   spin_lock_irq(q->queue_lock);
blk_queue_for_each_rl(rl, q) {
if (rl->rq_pool) {
wake_up(>wait[BLK_RW_SYNC]);
wake_up(>wait[BLK_RW_ASYNC]);
}
}
+   spin_unlock_irq(q->queue_lock);
}
 }
 EXPORT_SYMBOL_GPL(blk_set_queue_dying);
-- 
2.11.0.483.g087da7b7c-goog

[PATCH] block: queue lock must be acquired when iterating over rls

[Tahsin Erdogan]

blk_set_queue_dying() does not acquire queue lock before it calls
blk_queue_for_each_rl(). This allows a racing blkg_destroy() to
remove blkg->q_node from the linked list and have
blk_queue_for_each_rl() loop infitely over the removed blkg->q_node
list node.

Signed-off-by: Tahsin Erdogan 
---
 block/blk-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/block/blk-core.c b/block/blk-core.c
index 61ba08c58b64..0488a2b55bf0 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -525,12 +525,14 @@ void blk_set_queue_dying(struct request_queue *q)
else {
struct request_list *rl;
 
+   spin_lock_irq(q->queue_lock);
blk_queue_for_each_rl(rl, q) {
if (rl->rq_pool) {
wake_up(>wait[BLK_RW_SYNC]);
wake_up(>wait[BLK_RW_ASYNC]);
}
}
+   spin_unlock_irq(q->queue_lock);
}
 }
 EXPORT_SYMBOL_GPL(blk_set_queue_dying);
-- 
2.11.0.483.g087da7b7c-goog

Re: [PATCH v2 2/5] userfaultfd: non-cooperative: add event for memory unmaps

[Mike Rapoport]

On Tue, Jan 31, 2017 at 04:39:28PM -0800, Andrew Morton wrote:
> On Fri, 27 Jan 2017 20:44:30 +0200 Mike Rapoport  
> wrote:
> 
> > When a non-cooperative userfaultfd monitor copies pages in the background,
> > it may encounter regions that were already unmapped. Addition of
> > UFFD_EVENT_UNMAP allows the uffd monitor to track precisely changes in the
> > virtual memory layout.
> > 
> > Since there might be different uffd contexts for the affected VMAs, we
> > first should create a temporary representation for the unmap event for each
> > uffd context and then notify them one by one to the appropriate userfault
> > file descriptors.
> > 
> > The event notification occurs after the mmap_sem has been released.
> 
> I was going to bug you about not updating
> Documentation/vm/userfaultfd.txt but the UFFD_FEATURE flags aren't
> documented?
 
I'm going to send the documentation update in the next few days.

--
Sincerely yours,
Mike.

Re: [PATCH v2 2/5] userfaultfd: non-cooperative: add event for memory unmaps

[Mike Rapoport]

On Tue, Jan 31, 2017 at 04:39:28PM -0800, Andrew Morton wrote:
> On Fri, 27 Jan 2017 20:44:30 +0200 Mike Rapoport  
> wrote:
> 
> > When a non-cooperative userfaultfd monitor copies pages in the background,
> > it may encounter regions that were already unmapped. Addition of
> > UFFD_EVENT_UNMAP allows the uffd monitor to track precisely changes in the
> > virtual memory layout.
> > 
> > Since there might be different uffd contexts for the affected VMAs, we
> > first should create a temporary representation for the unmap event for each
> > uffd context and then notify them one by one to the appropriate userfault
> > file descriptors.
> > 
> > The event notification occurs after the mmap_sem has been released.
> 
> I was going to bug you about not updating
> Documentation/vm/userfaultfd.txt but the UFFD_FEATURE flags aren't
> documented?
 
I'm going to send the documentation update in the next few days.

--
Sincerely yours,
Mike.

Re: [PATCH v2 3/5] userfaultfd: non-cooperative: add event for exit() notification

[Mike Rapoport]

On Tue, Jan 31, 2017 at 04:41:32PM -0800, Andrew Morton wrote:
> On Fri, 27 Jan 2017 20:44:31 +0200 Mike Rapoport  
> wrote:
> 
> > Allow userfaultfd monitor track termination of the processes that have
> > memory backed by the uffd.
> > 
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -774,6 +774,30 @@ void userfaultfd_unmap_complete(struct mm_struct *mm, 
> > struct list_head *uf)
> > }
> >  }
> >  
> > +void userfaultfd_exit(struct mm_struct *mm)
> > +{
> > +   struct vm_area_struct *vma = mm->mmap;
> > +
> > +   while (vma) {
> > +   struct userfaultfd_ctx *ctx = vma->vm_userfaultfd_ctx.ctx;
> > +
> > +   if (ctx && (ctx->features & UFFD_FEATURE_EVENT_EXIT)) {
> > +   struct userfaultfd_wait_queue ewq;
> > +
> > +   userfaultfd_ctx_get(ctx);
> > +
> > +   msg_init();
> > +   ewq.msg.event = UFFD_EVENT_EXIT;
> > +
> > +   userfaultfd_event_wait_completion(ctx, );
> > +
> > +   ctx->features &= ~UFFD_FEATURE_EVENT_EXIT;
> > +   }
> > +
> > +   vma = vma->vm_next;
> > +   }
> > +}
> 
> And we can do the vma walk without locking because the caller (exit_mm)
> knows it now has exclusive access.  Worth a comment?
 
Sure, will add. Do you prefer an incremental patch or update this one?

--
Sincerely yours,
Mike.

Re: [PATCH v2 3/5] userfaultfd: non-cooperative: add event for exit() notification

[Mike Rapoport]

On Tue, Jan 31, 2017 at 04:41:32PM -0800, Andrew Morton wrote:
> On Fri, 27 Jan 2017 20:44:31 +0200 Mike Rapoport  
> wrote:
> 
> > Allow userfaultfd monitor track termination of the processes that have
> > memory backed by the uffd.
> > 
> > --- a/fs/userfaultfd.c
> > +++ b/fs/userfaultfd.c
> > @@ -774,6 +774,30 @@ void userfaultfd_unmap_complete(struct mm_struct *mm, 
> > struct list_head *uf)
> > }
> >  }
> >  
> > +void userfaultfd_exit(struct mm_struct *mm)
> > +{
> > +   struct vm_area_struct *vma = mm->mmap;
> > +
> > +   while (vma) {
> > +   struct userfaultfd_ctx *ctx = vma->vm_userfaultfd_ctx.ctx;
> > +
> > +   if (ctx && (ctx->features & UFFD_FEATURE_EVENT_EXIT)) {
> > +   struct userfaultfd_wait_queue ewq;
> > +
> > +   userfaultfd_ctx_get(ctx);
> > +
> > +   msg_init();
> > +   ewq.msg.event = UFFD_EVENT_EXIT;
> > +
> > +   userfaultfd_event_wait_completion(ctx, );
> > +
> > +   ctx->features &= ~UFFD_FEATURE_EVENT_EXIT;
> > +   }
> > +
> > +   vma = vma->vm_next;
> > +   }
> > +}
> 
> And we can do the vma walk without locking because the caller (exit_mm)
> knows it now has exclusive access.  Worth a comment?
 
Sure, will add. Do you prefer an incremental patch or update this one?

--
Sincerely yours,
Mike.

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

[Minchan Kim]

On Tue, Jan 31, 2017 at 02:32:08PM +0530, Vinayak Menon wrote:
> During global reclaim, the nr_reclaimed passed to vmpressure
> includes the pages reclaimed from slab. But the corresponding
> scanned slab pages is not passed. This can cause total reclaimed
> pages to be greater than scanned, causing an unsigned underflow
> in vmpressure resulting in a critical event being sent to root
> cgroup. So do not consider reclaimed slab pages for vmpressure
> calculation. The reclaimed pages from slab can be excluded because
> the freeing of a page by slab shrinking depends on each slab's
> object population, making the cost model (i.e. scan:free) different
> from that of LRU. Also, not every shrinker accounts the pages it
> reclaims. This is a regression introduced by commit 6b4f7799c6a5
> ("mm: vmscan: invoke slab shrinkers from shrink_zone()").
> 
> Signed-off-by: Vinayak Menon 
Acked-by: Minchan Kim 

Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

[Minchan Kim]

On Tue, Jan 31, 2017 at 02:32:08PM +0530, Vinayak Menon wrote:
> During global reclaim, the nr_reclaimed passed to vmpressure
> includes the pages reclaimed from slab. But the corresponding
> scanned slab pages is not passed. This can cause total reclaimed
> pages to be greater than scanned, causing an unsigned underflow
> in vmpressure resulting in a critical event being sent to root
> cgroup. So do not consider reclaimed slab pages for vmpressure
> calculation. The reclaimed pages from slab can be excluded because
> the freeing of a page by slab shrinking depends on each slab's
> object population, making the cost model (i.e. scan:free) different
> from that of LRU. Also, not every shrinker accounts the pages it
> reclaims. This is a regression introduced by commit 6b4f7799c6a5
> ("mm: vmscan: invoke slab shrinkers from shrink_zone()").
> 
> Signed-off-by: Vinayak Menon 
Acked-by: Minchan Kim 

linux-next: build warning after merge of the random tree

[Stephen Rothwell]

Hi Ted,

[This actually appeared yesterday, but I missed it, sorry.]

After merging the random tree, today's linux-next build (x86_64
allnoconfig) produced this warning:

drivers/char/random.c:318:12: warning: 'random_min_urandom_seed' defined but 
not used [-Wunused-variable]
 static int random_min_urandom_seed = 60;
^

Introduced by commit

  43d8a72cd985 ("random: remove variable limit")

I understand why it is left there, but it would be nice if this warning
could be removed.

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the random tree

[Stephen Rothwell]

Hi Ted,

[This actually appeared yesterday, but I missed it, sorry.]

After merging the random tree, today's linux-next build (x86_64
allnoconfig) produced this warning:

drivers/char/random.c:318:12: warning: 'random_min_urandom_seed' defined but 
not used [-Wunused-variable]
 static int random_min_urandom_seed = 60;
^

Introduced by commit

  43d8a72cd985 ("random: remove variable limit")

I understand why it is left there, but it would be nice if this warning
could be removed.

-- 
Cheers,
Stephen Rothwell

Staging: ks7010: clean up ks_hostif.h

[Logan Gorence]

>From 58defc62d53cb473f9d745127d98df834a10b321 Mon Sep 17 00:00:00 2001
From: Logan Gorence 
Date: Tue, 31 Jan 2017 21:51:05 -0800
Subject: [PATCH] Staging: ks7010: clean up ks_hostif.h

Clean up the errors in ks_hostif.h put out by checkpatch.pl.

Signed-off by: Logan Gorence 
---
 drivers/staging/ks7010/ks_hostif.h | 56 +++---

 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 743f31ead56e..ccc2a7742e80 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -360,7 +360,7 @@ struct hostif_ps_adhoc_set_request_t {
 #define CTS_MODE_TRUE  1
    uint16_t channel;
    struct rate_set16_t rate_set;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
 } __packed;
@@ -376,7 +376,7 @@ struct hostif_infrastructure_set_request_t {
    uint16_t cts_mode;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t beacon_lost_count;
    uint16_t auth_type;
@@ -392,7 +392,7 @@ struct hostif_infrastructure_set2_request_t {
    uint16_t cts_mode;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t beacon_lost_count;
    uint16_t auth_type;
@@ -415,7 +415,7 @@ struct hostif_adhoc_set_request_t {
    uint16_t channel;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
 } __packed;
@@ -427,7 +427,7 @@ struct hostif_adhoc_set2_request_t {
    uint16_t reserved;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
    struct channel_list_t channel_list;
@@ -568,19 +568,19 @@ struct hostif_mic_failure_confirm_t {
 #define TX_RATE_48M(uint8_t)(480/5)
 #define TX_RATE_54M(uint8_t)(540/5)
 
-#define IS_11B_RATE(A)
(((A_MASK)==TX_RATE_1M)||((A_MASK)==TX_RATE_2M)||\
-((A_MASK)==TX_RATE_5M)||((A_MASK)==T
X_RATE_11M))
+#define IS_11B_RATE(A) (((A_MASK) == TX_RATE_1M) ||
((A_MASK) == TX_RATE_2M) || \
+   ((A_MASK) == TX_RATE_5M) ||
((A_MASK) == TX_RATE_11M))
 
-#define IS_OFDM_RATE(A)
(((A_MASK)==TX_RATE_6M)||((A_MASK)==TX_RATE_12M)||\
-((A_MASK)==TX_RATE_24M)||((A_MASK)==
TX_RATE_9M)||\
-((A_MASK)==TX_RATE_18M)||((A_MASK)==
TX_RATE_36M)||\
-((A_MASK)==TX_RATE_48M)||((A_MASK)==
TX_RATE_54M))
+#define IS_OFDM_RATE(A) (((A_MASK) == TX_RATE_6M) ||
((A_MASK) == TX_RATE_12M) || \
+   ((A_MASK) == TX_RATE_24M) ||
((A_MASK) == TX_RATE_9M) || \
+   ((A_MASK) == TX_RATE_18M) ||
((A_MASK) == TX_RATE_36M) || \
+   ((A_MASK) == TX_RATE_48M) ||
((A_MASK) == TX_RATE_54M))
 
-#define IS_11BG_RATE(A) (IS_11B_RATE(A)||IS_OFDM_RATE(A))
+#define IS_11BG_RATE(A) (IS_11B_RATE(A) || IS_OFDM_RATE(A))
 
-#define
IS_OFDM_EXT_RATE(A)  (((A_MASK)==TX_RATE_9M)||((A_MASK)==TX_R
ATE_18M)||\
- ((A_MASK)==TX_RATE_36M)||((A_MA
SK)==TX_RATE_48M)||\
- ((A_MASK)==TX_RATE_54M))
+#define IS_OFDM_EXT_RATE(A)  (((A_MASK) == TX_RATE_9M) ||
((A_MASK) == TX_RATE_18M) || \
+   ((A_MASK) == TX_RATE_36M) ||
((A_MASK) == TX_RATE_48M) || \
+   ((A_MASK) == TX_RATE_54M))
 
 enum {

Staging: ks7010: clean up ks_hostif.h

[Logan Gorence]

>From 58defc62d53cb473f9d745127d98df834a10b321 Mon Sep 17 00:00:00 2001
From: Logan Gorence 
Date: Tue, 31 Jan 2017 21:51:05 -0800
Subject: [PATCH] Staging: ks7010: clean up ks_hostif.h

Clean up the errors in ks_hostif.h put out by checkpatch.pl.

Signed-off by: Logan Gorence 
---
 drivers/staging/ks7010/ks_hostif.h | 56 +++---

 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.h
b/drivers/staging/ks7010/ks_hostif.h
index 743f31ead56e..ccc2a7742e80 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -360,7 +360,7 @@ struct hostif_ps_adhoc_set_request_t {
 #define CTS_MODE_TRUE  1
    uint16_t channel;
    struct rate_set16_t rate_set;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
 } __packed;
@@ -376,7 +376,7 @@ struct hostif_infrastructure_set_request_t {
    uint16_t cts_mode;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t beacon_lost_count;
    uint16_t auth_type;
@@ -392,7 +392,7 @@ struct hostif_infrastructure_set2_request_t {
    uint16_t cts_mode;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t beacon_lost_count;
    uint16_t auth_type;
@@ -415,7 +415,7 @@ struct hostif_adhoc_set_request_t {
    uint16_t channel;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
 } __packed;
@@ -427,7 +427,7 @@ struct hostif_adhoc_set2_request_t {
    uint16_t reserved;
    struct rate_set16_t rate_set;
    struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc
not supported always 0
     * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
    uint16_t scan_type;
    struct channel_list_t channel_list;
@@ -568,19 +568,19 @@ struct hostif_mic_failure_confirm_t {
 #define TX_RATE_48M(uint8_t)(480/5)
 #define TX_RATE_54M(uint8_t)(540/5)
 
-#define IS_11B_RATE(A)
(((A_MASK)==TX_RATE_1M)||((A_MASK)==TX_RATE_2M)||\
-((A_MASK)==TX_RATE_5M)||((A_MASK)==T
X_RATE_11M))
+#define IS_11B_RATE(A) (((A_MASK) == TX_RATE_1M) ||
((A_MASK) == TX_RATE_2M) || \
+   ((A_MASK) == TX_RATE_5M) ||
((A_MASK) == TX_RATE_11M))
 
-#define IS_OFDM_RATE(A)
(((A_MASK)==TX_RATE_6M)||((A_MASK)==TX_RATE_12M)||\
-((A_MASK)==TX_RATE_24M)||((A_MASK)==
TX_RATE_9M)||\
-((A_MASK)==TX_RATE_18M)||((A_MASK)==
TX_RATE_36M)||\
-((A_MASK)==TX_RATE_48M)||((A_MASK)==
TX_RATE_54M))
+#define IS_OFDM_RATE(A) (((A_MASK) == TX_RATE_6M) ||
((A_MASK) == TX_RATE_12M) || \
+   ((A_MASK) == TX_RATE_24M) ||
((A_MASK) == TX_RATE_9M) || \
+   ((A_MASK) == TX_RATE_18M) ||
((A_MASK) == TX_RATE_36M) || \
+   ((A_MASK) == TX_RATE_48M) ||
((A_MASK) == TX_RATE_54M))
 
-#define IS_11BG_RATE(A) (IS_11B_RATE(A)||IS_OFDM_RATE(A))
+#define IS_11BG_RATE(A) (IS_11B_RATE(A) || IS_OFDM_RATE(A))
 
-#define
IS_OFDM_EXT_RATE(A)  (((A_MASK)==TX_RATE_9M)||((A_MASK)==TX_R
ATE_18M)||\
- ((A_MASK)==TX_RATE_36M)||((A_MA
SK)==TX_RATE_48M)||\
- ((A_MASK)==TX_RATE_54M))
+#define IS_OFDM_EXT_RATE(A)  (((A_MASK) == TX_RATE_9M) ||
((A_MASK) == TX_RATE_18M) || \
+   ((A_MASK) == TX_RATE_36M) ||
((A_MASK) == TX_RATE_48M) || \
+   ((A_MASK) == TX_RATE_54M))
 
 enum {
    CONNECT_STATUS = 0,
@@ -602,17 +602,17 @@ 

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

[Minchan Kim]

Hi Shaohua,

On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote:
> Hi,
> 
> We are trying to use MADV_FREE in jemalloc. Several issues are found. Without
> solving the issues, jemalloc can't use the MADV_FREE feature.
> - Doesn't support system without swap enabled. Because if swap is off, we 
> can't
>   or can't efficiently age anonymous pages. And since MADV_FREE pages are 
> mixed
>   with other anonymous pages, we can't reclaim MADV_FREE pages. In current
>   implementation, MADV_FREE will fallback to MADV_DONTNEED without swap 
> enabled.
>   But in our environment, a lot of machines don't enable swap. This will 
> prevent
>   our setup using MADV_FREE.
> - Increases memory pressure. page reclaim bias file pages reclaim against
>   anonymous pages. This doesn't make sense for MADV_FREE pages, because those
>   pages could be freed easily and refilled with very slight penality. Even 
> page
>   reclaim doesn't bias file pages, there is still an issue, because MADV_FREE
>   pages and other anonymous pages are mixed together. To reclaim a MADV_FREE
>   page, we probably must scan a lot of other anonymous pages, which is
>   inefficient. In our test, we usually see oom with MADV_FREE enabled and 
> nothing
>   without it.
> - RSS accounting. MADV_FREE pages are accounted as normal anon pages and
>   reclaimed lazily, so application's RSS becomes bigger. This confuses our
>   workloads. We have monitoring daemon running and if it finds applications' 
> RSS
>   becomes abnormal, the daemon will kill the applications even kernel can 
> reclaim
>   the memory easily. Currently we don't export separate RSS accounting for
>   MADV_FREE pages. This will prevent our setup using MADV_FREE too.
> 
> For the first two issues, introducing a new LRU list for MADV_FREE pages could
> solve the issues. We can directly reclaim MADV_FREE pages without writting 
> them
> out to swap, so the first issue could be fixed. If only MADV_FREE pages are in
> the new list, page reclaim can easily reclaim such pages without interference
> of file or anonymous pages. The memory pressure issue will disappear.
> 
> Actually Minchan posted patches to add the LRU list before, but he didn't
> pursue. So I picked up them and the patches are based on Minchan's previous
> patches. The main difference between my patches and Minchan previous patches 
> is
> page reclaim policy. Minchan's patches introduces a knob to balance the 
> reclaim
> of MADV_FREE pages and anon/file pages, while the patches always reclaim
> MADV_FREE pages first if there are. I described the reason in patch 5.

First of all, thanks for th effort to support MADV_FREE for swapless system,
Shaohua!

CCing Daniel,

The reason I have postponed is due to controverial part about balancing
used-once vs. madv_freed apges. I thought it doesn't make sense to reclaim
madv_freed pages first even if there are lots of used-once pages.

Recently, Johannes posted patches for balancing file/anon and it was based
on the cost model, IIRC. I wanted to base on it.

The idea is VM reclaims file-based pages and if refault happens, we can measure
refault distance and sizeof(LRU_LAZYFREE list). If refault distance is smaller
than lazyfree LRU list's size, it means the file-backed page have been kept
in memory if we have discarded lazyfree pages so it adds more cost to reclaim
lazyfree LRU list more agressively.

I tested your patch with simple MADV_FREE workload(just alloc and then repeated
touch/madv_free) with background stream-read process. In that case, the
MADV_FREE workload regressed in half without any gain for stream-read process.

I tested hacky code to simulate feedback loop I suggested idea and it restores
the performance regression. I'm not saying below hacky patch should merge in
but I think we should have used-once reclaim feedback logic to prevent
unnecessary purging for madv_freed pages.

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 589a165..39d4bba 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -703,6 +703,7 @@ typedef struct pglist_data {
/* Per-node vmstats */
struct per_cpu_nodestat __percpu *per_cpu_nodestats;
atomic_long_t   vm_stat[NR_VM_NODE_STAT_ITEMS];
+   bool lazyfree;
 } pg_data_t;
 
 #define node_present_pages(nid)(NODE_DATA(nid)->node_present_pages)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f809f04..cf54b81 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2364,22 +2364,25 @@ static void shrink_node_memcg(struct pglist_data 
*pgdat, struct mem_cgroup *memc
struct blk_plug plug;
bool scan_adjusted;
 
-   /* reclaim all lazyfree pages so don't apply priority  */
-   nr[LRU_LAZYFREE] = lruvec_lru_size(lruvec, LRU_LAZYFREE, 
sc->reclaim_idx);
-   while (nr[LRU_LAZYFREE]) {
-   nr_to_scan = min(nr[LRU_LAZYFREE], SWAP_CLUSTER_MAX);
-   nr[LRU_LAZYFREE] -= nr_to_scan;
-   nr_reclaimed += 

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

[Minchan Kim]

Hi Shaohua,

On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote:
> Hi,
> 
> We are trying to use MADV_FREE in jemalloc. Several issues are found. Without
> solving the issues, jemalloc can't use the MADV_FREE feature.
> - Doesn't support system without swap enabled. Because if swap is off, we 
> can't
>   or can't efficiently age anonymous pages. And since MADV_FREE pages are 
> mixed
>   with other anonymous pages, we can't reclaim MADV_FREE pages. In current
>   implementation, MADV_FREE will fallback to MADV_DONTNEED without swap 
> enabled.
>   But in our environment, a lot of machines don't enable swap. This will 
> prevent
>   our setup using MADV_FREE.
> - Increases memory pressure. page reclaim bias file pages reclaim against
>   anonymous pages. This doesn't make sense for MADV_FREE pages, because those
>   pages could be freed easily and refilled with very slight penality. Even 
> page
>   reclaim doesn't bias file pages, there is still an issue, because MADV_FREE
>   pages and other anonymous pages are mixed together. To reclaim a MADV_FREE
>   page, we probably must scan a lot of other anonymous pages, which is
>   inefficient. In our test, we usually see oom with MADV_FREE enabled and 
> nothing
>   without it.
> - RSS accounting. MADV_FREE pages are accounted as normal anon pages and
>   reclaimed lazily, so application's RSS becomes bigger. This confuses our
>   workloads. We have monitoring daemon running and if it finds applications' 
> RSS
>   becomes abnormal, the daemon will kill the applications even kernel can 
> reclaim
>   the memory easily. Currently we don't export separate RSS accounting for
>   MADV_FREE pages. This will prevent our setup using MADV_FREE too.
> 
> For the first two issues, introducing a new LRU list for MADV_FREE pages could
> solve the issues. We can directly reclaim MADV_FREE pages without writting 
> them
> out to swap, so the first issue could be fixed. If only MADV_FREE pages are in
> the new list, page reclaim can easily reclaim such pages without interference
> of file or anonymous pages. The memory pressure issue will disappear.
> 
> Actually Minchan posted patches to add the LRU list before, but he didn't
> pursue. So I picked up them and the patches are based on Minchan's previous
> patches. The main difference between my patches and Minchan previous patches 
> is
> page reclaim policy. Minchan's patches introduces a knob to balance the 
> reclaim
> of MADV_FREE pages and anon/file pages, while the patches always reclaim
> MADV_FREE pages first if there are. I described the reason in patch 5.

First of all, thanks for th effort to support MADV_FREE for swapless system,
Shaohua!

CCing Daniel,

The reason I have postponed is due to controverial part about balancing
used-once vs. madv_freed apges. I thought it doesn't make sense to reclaim
madv_freed pages first even if there are lots of used-once pages.

Recently, Johannes posted patches for balancing file/anon and it was based
on the cost model, IIRC. I wanted to base on it.

The idea is VM reclaims file-based pages and if refault happens, we can measure
refault distance and sizeof(LRU_LAZYFREE list). If refault distance is smaller
than lazyfree LRU list's size, it means the file-backed page have been kept
in memory if we have discarded lazyfree pages so it adds more cost to reclaim
lazyfree LRU list more agressively.

I tested your patch with simple MADV_FREE workload(just alloc and then repeated
touch/madv_free) with background stream-read process. In that case, the
MADV_FREE workload regressed in half without any gain for stream-read process.

I tested hacky code to simulate feedback loop I suggested idea and it restores
the performance regression. I'm not saying below hacky patch should merge in
but I think we should have used-once reclaim feedback logic to prevent
unnecessary purging for madv_freed pages.

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 589a165..39d4bba 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -703,6 +703,7 @@ typedef struct pglist_data {
/* Per-node vmstats */
struct per_cpu_nodestat __percpu *per_cpu_nodestats;
atomic_long_t   vm_stat[NR_VM_NODE_STAT_ITEMS];
+   bool lazyfree;
 } pg_data_t;
 
 #define node_present_pages(nid)(NODE_DATA(nid)->node_present_pages)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f809f04..cf54b81 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2364,22 +2364,25 @@ static void shrink_node_memcg(struct pglist_data 
*pgdat, struct mem_cgroup *memc
struct blk_plug plug;
bool scan_adjusted;
 
-   /* reclaim all lazyfree pages so don't apply priority  */
-   nr[LRU_LAZYFREE] = lruvec_lru_size(lruvec, LRU_LAZYFREE, 
sc->reclaim_idx);
-   while (nr[LRU_LAZYFREE]) {
-   nr_to_scan = min(nr[LRU_LAZYFREE], SWAP_CLUSTER_MAX);
-   nr[LRU_LAZYFREE] -= nr_to_scan;
-   nr_reclaimed += 

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

On 01/31/2017 06:22 PM, Krzysztof Kozlowski wrote:

On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae  wrote:


2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:

Dear Thierry,

Could you please review this patch?

Thierry, I think this patch has been reviewed enough but no comment from you. 
Seems you are busy. I will pick up this.


Comments from v8 were not resolved and I think we are waiting for v9:
https://lkml.org/lkml/2017/1/11/178

If that is not correct then please clarify.


Dear Krzysztof,

I'm sorry, I was mistaken.
I will change them to optional and will send it to the V9 patch.

Best Regards,
Hoegeun



Best regards,
Krzysztof

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

On 01/31/2017 06:22 PM, Krzysztof Kozlowski wrote:

On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae  wrote:


2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:

Dear Thierry,

Could you please review this patch?

Thierry, I think this patch has been reviewed enough but no comment from you. 
Seems you are busy. I will pick up this.


Comments from v8 were not resolved and I think we are waiting for v9:
https://lkml.org/lkml/2017/1/11/178

If that is not correct then please clarify.


Dear Krzysztof,

I'm sorry, I was mistaken.
I will change them to optional and will send it to the V9 patch.

Best Regards,
Hoegeun



Best regards,
Krzysztof

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

[Michael Ellerman]

Sukadev Bhattiprolu  writes:
> Paul Clarke [p...@us.ibm.com] wrote:
> ---
>
> From f9e9e8460206bc3fa7eaa741b9a2bde22870b9e0 Mon Sep 17 00:00:00 2001

I know it's been a while but I think it would still be good to get this
in a shape that we can merge it.

Comments inline ...

> From: root 
> Date: Thu, 4 Aug 2016 23:13:37 -0400
> Subject: [PATCH 2/2] powerpc/pseries: Dynamically grow RMA size
>
> When booting a very large system with a large initrd we run out of space
> for the flattened device tree (FDT). To fix this we must increase the
> space allocated for the RMA region.
>
> The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
> the size there will apply to all systems, large and small, so we want to
> increase the RMA region only when necessary.
>
> When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
> to the new RMA size (512MB) and issue a client-architecture-support (CAS)
> call to the firmware. This will initiate a system reboot. Upon reboot we
> notice the new property and update the RMA size accordingly.
>
> Fix suggested by Michael Ellerman.
>
> Signed-off-by: Sukadev Bhattiprolu 
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index f612a99..d1aaeda 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -87,6 +87,9 @@
>  int of_workarounds;
>  #endif
>  
> +#define IBM_NEW_RMA_SIZE_PROP"ibm,new-rma-size"
> +#define IBM_NEW_RMA_SIZE_STR "512"

The property name should really start with "linux,", as it's a Linux
property, not used by firmware at all.

And does it need to contain a value? Just its existence is a flag that
we want to increase the RMA size.

So it could just be called "linux,increase-rma-size".

And we don't need a #define for the name, it's not going to change once
the code is in, and a #define just obscures the actual name.

> @@ -898,6 +910,42 @@ static void fixup_nr_cores(void)
>   ptcores[1] = (cores >> 16) & 0xff;
>   ptcores[2] = (cores >> 8) & 0xff;
>   ptcores[3] = cores & 0xff;
> + fixup_nr_cores_done = true;

That code has changed upstream, so that won't apply. But that's OK, I
don't think we need to do it anyway.

> +static void __init fixup_rma_size(void)
> +{
> + int rc;
> + u64 size;
> + unsigned char *min_rmap;
> + phandle optnode;
> + char str[64];
> +
> + optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
> + if (!PHANDLE_VALID(optnode))
> + prom_panic("Cannot find /options");
> +
> + /*
> +  * If a prior boot specified a new RMA size, use that size in
> +  * ibm_architecture_vec[]. See also increase_rma_size().
> +  */
> + size = 0ULL;
> + memset(str, 0, sizeof(str));
> + rc = prom_getprop(optnode, IBM_NEW_RMA_SIZE_PROP, , sizeof(str));
> + if (rc <= 0)
> + return;

So this can just become something like:

rc = prom_getprop(optnode, "linux,increase-rma-size", NULL, 0)
if (rc == PROM_ERROR)
return;

val = be32_to_cpu(ibm_architecture_vec.vec2.min_rma);
ibm_architecture_vec.vec2.min_rma = cpu_to_be32(val * 2);

> @@ -946,6 +996,49 @@ static void __init prom_send_capabilities(void)
>   }
>  #endif /* __BIG_ENDIAN__ */
>  }
> +
> +static void __init increase_rma_size(void)
> +{
> + int rc, len;
> + char str[64];
> + phandle optnode;
> +
> + optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
> + if (!PHANDLE_VALID(optnode))
> + prom_panic("Cannot find /options");
> +
> + /*
> +  * If we already increased the RMA size, return.
> +  */
> + memset(str, 0, sizeof(str));
> + rc = prom_getprop(optnode, IBM_NEW_RMA_SIZE_PROP, , sizeof(str));
> +
> + if (!strcmp(str, IBM_NEW_RMA_SIZE_STR)) {
> + prom_printf("RMA size already at %.3s.\n", str);
> + return;
> + }
> + /*
> +  * Otherwise, set the ibm,new-rma-size property and initiate a CAS
> +  * reboot so the RMA size can take effect. See also init_rma_size().
> +  */
> + len = strlen(IBM_NEW_RMA_SIZE_STR) + 1;
> + memcpy(str, IBM_NEW_RMA_SIZE_STR, len);
> +
> + prom_printf("Setting %s property to %s\n", IBM_NEW_RMA_SIZE_PROP, str);
> + rc = prom_setprop(optnode, "/options", IBM_NEW_RMA_SIZE_PROP, str, len);

We should check rc there shouldn't we?

Again that code can be simpler if the property is just a flag.

> + /* Force a reboot. Will work only if ibm,fw-override-cas==false */
> + prom_send_capabilities();
> +
> + prom_printf("No CAS initiated reboot? Try setting ibm,fw-override-cas 
> to 'false' in Open Firmware\n");

I'm not sure if we want to be referring to ibm,fw-override-case. I don't
thing it's a documented property (not in PAPR anyway), and it's
certainly IBM PFW 

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

[Michael Ellerman]

Sukadev Bhattiprolu  writes:
> Paul Clarke [p...@us.ibm.com] wrote:
> ---
>
> From f9e9e8460206bc3fa7eaa741b9a2bde22870b9e0 Mon Sep 17 00:00:00 2001

I know it's been a while but I think it would still be good to get this
in a shape that we can merge it.

Comments inline ...

> From: root 
> Date: Thu, 4 Aug 2016 23:13:37 -0400
> Subject: [PATCH 2/2] powerpc/pseries: Dynamically grow RMA size
>
> When booting a very large system with a large initrd we run out of space
> for the flattened device tree (FDT). To fix this we must increase the
> space allocated for the RMA region.
>
> The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
> the size there will apply to all systems, large and small, so we want to
> increase the RMA region only when necessary.
>
> When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
> to the new RMA size (512MB) and issue a client-architecture-support (CAS)
> call to the firmware. This will initiate a system reboot. Upon reboot we
> notice the new property and update the RMA size accordingly.
>
> Fix suggested by Michael Ellerman.
>
> Signed-off-by: Sukadev Bhattiprolu 
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index f612a99..d1aaeda 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -87,6 +87,9 @@
>  int of_workarounds;
>  #endif
>  
> +#define IBM_NEW_RMA_SIZE_PROP"ibm,new-rma-size"
> +#define IBM_NEW_RMA_SIZE_STR "512"

The property name should really start with "linux,", as it's a Linux
property, not used by firmware at all.

And does it need to contain a value? Just its existence is a flag that
we want to increase the RMA size.

So it could just be called "linux,increase-rma-size".

And we don't need a #define for the name, it's not going to change once
the code is in, and a #define just obscures the actual name.

> @@ -898,6 +910,42 @@ static void fixup_nr_cores(void)
>   ptcores[1] = (cores >> 16) & 0xff;
>   ptcores[2] = (cores >> 8) & 0xff;
>   ptcores[3] = cores & 0xff;
> + fixup_nr_cores_done = true;

That code has changed upstream, so that won't apply. But that's OK, I
don't think we need to do it anyway.

> +static void __init fixup_rma_size(void)
> +{
> + int rc;
> + u64 size;
> + unsigned char *min_rmap;
> + phandle optnode;
> + char str[64];
> +
> + optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
> + if (!PHANDLE_VALID(optnode))
> + prom_panic("Cannot find /options");
> +
> + /*
> +  * If a prior boot specified a new RMA size, use that size in
> +  * ibm_architecture_vec[]. See also increase_rma_size().
> +  */
> + size = 0ULL;
> + memset(str, 0, sizeof(str));
> + rc = prom_getprop(optnode, IBM_NEW_RMA_SIZE_PROP, , sizeof(str));
> + if (rc <= 0)
> + return;

So this can just become something like:

rc = prom_getprop(optnode, "linux,increase-rma-size", NULL, 0)
if (rc == PROM_ERROR)
return;

val = be32_to_cpu(ibm_architecture_vec.vec2.min_rma);
ibm_architecture_vec.vec2.min_rma = cpu_to_be32(val * 2);

> @@ -946,6 +996,49 @@ static void __init prom_send_capabilities(void)
>   }
>  #endif /* __BIG_ENDIAN__ */
>  }
> +
> +static void __init increase_rma_size(void)
> +{
> + int rc, len;
> + char str[64];
> + phandle optnode;
> +
> + optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
> + if (!PHANDLE_VALID(optnode))
> + prom_panic("Cannot find /options");
> +
> + /*
> +  * If we already increased the RMA size, return.
> +  */
> + memset(str, 0, sizeof(str));
> + rc = prom_getprop(optnode, IBM_NEW_RMA_SIZE_PROP, , sizeof(str));
> +
> + if (!strcmp(str, IBM_NEW_RMA_SIZE_STR)) {
> + prom_printf("RMA size already at %.3s.\n", str);
> + return;
> + }
> + /*
> +  * Otherwise, set the ibm,new-rma-size property and initiate a CAS
> +  * reboot so the RMA size can take effect. See also init_rma_size().
> +  */
> + len = strlen(IBM_NEW_RMA_SIZE_STR) + 1;
> + memcpy(str, IBM_NEW_RMA_SIZE_STR, len);
> +
> + prom_printf("Setting %s property to %s\n", IBM_NEW_RMA_SIZE_PROP, str);
> + rc = prom_setprop(optnode, "/options", IBM_NEW_RMA_SIZE_PROP, str, len);

We should check rc there shouldn't we?

Again that code can be simpler if the property is just a flag.

> + /* Force a reboot. Will work only if ibm,fw-override-cas==false */
> + prom_send_capabilities();
> +
> + prom_printf("No CAS initiated reboot? Try setting ibm,fw-override-cas 
> to 'false' in Open Firmware\n");

I'm not sure if we want to be referring to ibm,fw-override-case. I don't
thing it's a documented property (not in PAPR anyway), and it's
certainly IBM PFW specific even if it is.

I know for a fact that on KVM you won't get rebooted here, so 

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

[Stephen Warren]

On 01/31/2017 12:48 PM, Eric Anholt wrote:

I've been maintaining the bcm2835 branches here for a year or so.


Acked-by: Stephen Warren 

Re: [PATCH] MAINTAINERS: Update for the current location of the bcm2835 tree.

[Stephen Warren]

On 01/31/2017 12:48 PM, Eric Anholt wrote:

I've been maintaining the bcm2835 branches here for a year or so.


Acked-by: Stephen Warren 

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[Jassi Brar]

On Thu, Jan 26, 2017 at 2:07 PM, Horng-Shyang Liao  wrote:
> Hi Jassi,
>
> On Thu, 2017-01-26 at 10:08 +0530, Jassi Brar wrote:
>> On Wed, Jan 4, 2017 at 8:36 AM, HS Liao  wrote:
>>
>> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
>> > b/drivers/mailbox/mtk-cmdq-mailbox.c
>> > new file mode 100644
>> > index 000..747bcd3
>> > --- /dev/null
>> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
>>
>> ...
>>
>> > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread 
>> > *thread)
>> > +{
>> > +   struct cmdq *cmdq;
>> > +   struct cmdq_task *task;
>> > +   unsigned long curr_pa, end_pa;
>> > +
>> > +   cmdq = dev_get_drvdata(thread->chan->mbox->dev);
>> > +
>> > +   /* Client should not flush new tasks if suspended. */
>> > +   WARN_ON(cmdq->suspended);
>> > +
>> > +   task = kzalloc(sizeof(*task), GFP_ATOMIC);
>> > +   task->cmdq = cmdq;
>> > +   INIT_LIST_HEAD(>list_entry);
>> > +   task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
>> > +  pkt->cmd_buf_size, DMA_TO_DEVICE);
>> >
>> You seem to parse the requests and responses, that should ideally be
>> done in client driver.
>> Also, we are here in atomic context, can you move it in client driver
>> (before the spin_lock)?
>> Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.
>
> will do
>
>> 
>> > +
>> > +   cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
>> > +   cmdq->mbox.ops = _mbox_chan_ops;
>> > +   cmdq->mbox.of_xlate = cmdq_xlate;
>> > +
>> > +   /* make use of TXDONE_BY_ACK */
>> > +   cmdq->mbox.txdone_irq = false;
>> > +   cmdq->mbox.txdone_poll = false;
>> > +
>> > +   for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
>> >
>> You mean  i < CMDQ_THR_MAX_COUNT
>
> will do
>
>> > +   cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
>> > +   CMDQ_THR_SIZE * i;
>> > +   INIT_LIST_HEAD(>thread[i].task_busy_list);
>> >
>> You seem the queue mailbox requests in this controller driver? why not
>> use the mailbox api for that?
>>
>> > +   init_timer(>thread[i].timeout);
>> > +   cmdq->thread[i].timeout.function = 
>> > cmdq_thread_handle_timeout;
>> > +   cmdq->thread[i].timeout.data = (unsigned 
>> > long)>thread[i];
>> >
>> Here again... you seem to ignore the polling mechanism provided by the
>> mailbox api, and implement your own.
>
> The queue is used to record the tasks which are flushed into CMDQ
> hardware (GCE). We are handling time critical tasks, so we have to
> queue them in GCE rather than a software queue (e.g. mailbox buffer).
> Let me use display as an example. Many display tasks are flushed into
> CMDQ to wait next vsync event. When vsync event is triggered by display
> hardware, GCE needs to process all flushed tasks "within vblank" to
> prevent garbage on screen. This is all done by GCE (without CPU)
> to fulfill time critical requirement. After GCE finish its work,
> it will generate interrupts, and then CMDQ driver will let clients know
> which tasks are done.
>
Does the GCE provide any 'lock' to prevent modifying (by adding tasks
to) the GCE h/w buffer when it is processing it at vsync?  Otherwise
there maybe race/error. If there is such a 'lock' flag/irq, that could
help here. However, you are supposed to know your h/w better, so I
will accept this implementation assuming it can't be done any better.

Please address other comments and resubmit.

Thanks

Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[Jassi Brar]

On Thu, Jan 26, 2017 at 2:07 PM, Horng-Shyang Liao  wrote:
> Hi Jassi,
>
> On Thu, 2017-01-26 at 10:08 +0530, Jassi Brar wrote:
>> On Wed, Jan 4, 2017 at 8:36 AM, HS Liao  wrote:
>>
>> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
>> > b/drivers/mailbox/mtk-cmdq-mailbox.c
>> > new file mode 100644
>> > index 000..747bcd3
>> > --- /dev/null
>> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
>>
>> ...
>>
>> > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread 
>> > *thread)
>> > +{
>> > +   struct cmdq *cmdq;
>> > +   struct cmdq_task *task;
>> > +   unsigned long curr_pa, end_pa;
>> > +
>> > +   cmdq = dev_get_drvdata(thread->chan->mbox->dev);
>> > +
>> > +   /* Client should not flush new tasks if suspended. */
>> > +   WARN_ON(cmdq->suspended);
>> > +
>> > +   task = kzalloc(sizeof(*task), GFP_ATOMIC);
>> > +   task->cmdq = cmdq;
>> > +   INIT_LIST_HEAD(>list_entry);
>> > +   task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
>> > +  pkt->cmd_buf_size, DMA_TO_DEVICE);
>> >
>> You seem to parse the requests and responses, that should ideally be
>> done in client driver.
>> Also, we are here in atomic context, can you move it in client driver
>> (before the spin_lock)?
>> Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.
>
> will do
>
>> 
>> > +
>> > +   cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
>> > +   cmdq->mbox.ops = _mbox_chan_ops;
>> > +   cmdq->mbox.of_xlate = cmdq_xlate;
>> > +
>> > +   /* make use of TXDONE_BY_ACK */
>> > +   cmdq->mbox.txdone_irq = false;
>> > +   cmdq->mbox.txdone_poll = false;
>> > +
>> > +   for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
>> >
>> You mean  i < CMDQ_THR_MAX_COUNT
>
> will do
>
>> > +   cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
>> > +   CMDQ_THR_SIZE * i;
>> > +   INIT_LIST_HEAD(>thread[i].task_busy_list);
>> >
>> You seem the queue mailbox requests in this controller driver? why not
>> use the mailbox api for that?
>>
>> > +   init_timer(>thread[i].timeout);
>> > +   cmdq->thread[i].timeout.function = 
>> > cmdq_thread_handle_timeout;
>> > +   cmdq->thread[i].timeout.data = (unsigned 
>> > long)>thread[i];
>> >
>> Here again... you seem to ignore the polling mechanism provided by the
>> mailbox api, and implement your own.
>
> The queue is used to record the tasks which are flushed into CMDQ
> hardware (GCE). We are handling time critical tasks, so we have to
> queue them in GCE rather than a software queue (e.g. mailbox buffer).
> Let me use display as an example. Many display tasks are flushed into
> CMDQ to wait next vsync event. When vsync event is triggered by display
> hardware, GCE needs to process all flushed tasks "within vblank" to
> prevent garbage on screen. This is all done by GCE (without CPU)
> to fulfill time critical requirement. After GCE finish its work,
> it will generate interrupts, and then CMDQ driver will let clients know
> which tasks are done.
>
Does the GCE provide any 'lock' to prevent modifying (by adding tasks
to) the GCE h/w buffer when it is processing it at vsync?  Otherwise
there maybe race/error. If there is such a 'lock' flag/irq, that could
help here. However, you are supposed to know your h/w better, so I
will accept this implementation assuming it can't be done any better.

Please address other comments and resubmit.

Thanks

net: macb: lack of statistics - tx_dropped

[Hyung Jin Jung]

macb doesn't maintain statistics of dropped packets when transmitting.
so that it's not possible to detect packet loss in user space (sysfs, procfs...)

macb_start_xmit should to increase tx_dropped in case of exception - buffer 
full, dma mapping fail

Davy

net: macb: lack of statistics - tx_dropped

[Hyung Jin Jung]

macb doesn't maintain statistics of dropped packets when transmitting.
so that it's not possible to detect packet loss in user space (sysfs, procfs...)

macb_start_xmit should to increase tx_dropped in case of exception - buffer 
full, dma mapping fail

Davy

pri hiadani partnera!

[Barr Su]

Ahoj,

Som zastupca investicneho zaujmu o zaujem zahranicnych investícii 
zahrnajuce velky objem financnych prostriedkov, u ktorych sa snazime 
svoju ucast ako v zamori zastupcu. Moj klient, ktory je rodak z Thajska, 
ma nejake peniaze zo svojich obchodnych uspor chce investovať na základe 
kvalifikovanych zahranicnych partnerstva legitimne transakcie. uvedte, o 
rychlu odpoved, ak mate zaujem, takze ja vam moze poskytnut dalsie 
podrobnosti spoluprace.


S pozdravom,
E-mail: xiasu...@gmail.com
Barr. Su

pri hiadani partnera!

[Barr Su]

Ahoj,

Som zastupca investicneho zaujmu o zaujem zahranicnych investícii 
zahrnajuce velky objem financnych prostriedkov, u ktorych sa snazime 
svoju ucast ako v zamori zastupcu. Moj klient, ktory je rodak z Thajska, 
ma nejake peniaze zo svojich obchodnych uspor chce investovať na základe 
kvalifikovanych zahranicnych partnerstva legitimne transakcie. uvedte, o 
rychlu odpoved, ak mate zaujem, takze ja vam moze poskytnut dalsie 
podrobnosti spoluprace.


S pozdravom,
E-mail: xiasu...@gmail.com
Barr. Su

Re: [PATCHv2 00/11] KVM implementation of PAPR HPT resizing extension

[Paul Mackerras]

On Wed, Feb 01, 2017 at 03:56:36PM +1100, David Gibson wrote:
> On Wed, Feb 01, 2017 at 09:18:13AM +1100, Paul Mackerras wrote:
> > On Tue, Dec 20, 2016 at 04:48:56PM +1100, David Gibson wrote:
> > > Here is the KVM implementation for the proposed PAPR extension which
> > > allows the runtime resizing of a PAPR guest's Hashed Page Table (HPT).
> > > 
> > > Using this requires a guest kernel with support for the extension.
> > > Patches for guest side support in Linux were posted earlier:
> > >   
> > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-December/152164.html
> > > 
> > > It also requires userspace (i.e. qemu) to intercept the HPT resizing
> > > hypercalls and invoke the KVM ioctl()s to implement them.  This is
> > > done instead of having KVM direclty intercept the hypercalls, so that
> > > userspace can, if useful, impose additional restrictions on resizes:
> > > for example it could refuse them entirely if policy for the VM
> > > precludes resizing, or it could limit the size of HPT the guest can
> > > request to meet resource limits.
> > > 
> > > Patches to implement the userspace part of HPT resizing are proposed
> > > for qemu-2.9, and can be found at:
> > >   https://github.com/dgibson/qemu/tree/hpt-resize
> > > 
> > > I'm posting these now, in the hopes that both these and the
> > > corresponding guest side patches can be staged and merged for the 4.11
> > > window.
> > 
> > Thanks, series applied to my kvm-ppc-next branch.
> 
> Great.  Where can I grab that tree?

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc

> > Next time, please cc kvm-...@vger.kernel.org so I shows up in
> > patchwork and I don't miss it.
> 
> Sorry, I hadn't realized that list existed.  Noted for future
> reference.

Thanks,
Paul.

Re: [PATCHv2 00/11] KVM implementation of PAPR HPT resizing extension

[Paul Mackerras]

On Wed, Feb 01, 2017 at 03:56:36PM +1100, David Gibson wrote:
> On Wed, Feb 01, 2017 at 09:18:13AM +1100, Paul Mackerras wrote:
> > On Tue, Dec 20, 2016 at 04:48:56PM +1100, David Gibson wrote:
> > > Here is the KVM implementation for the proposed PAPR extension which
> > > allows the runtime resizing of a PAPR guest's Hashed Page Table (HPT).
> > > 
> > > Using this requires a guest kernel with support for the extension.
> > > Patches for guest side support in Linux were posted earlier:
> > >   
> > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-December/152164.html
> > > 
> > > It also requires userspace (i.e. qemu) to intercept the HPT resizing
> > > hypercalls and invoke the KVM ioctl()s to implement them.  This is
> > > done instead of having KVM direclty intercept the hypercalls, so that
> > > userspace can, if useful, impose additional restrictions on resizes:
> > > for example it could refuse them entirely if policy for the VM
> > > precludes resizing, or it could limit the size of HPT the guest can
> > > request to meet resource limits.
> > > 
> > > Patches to implement the userspace part of HPT resizing are proposed
> > > for qemu-2.9, and can be found at:
> > >   https://github.com/dgibson/qemu/tree/hpt-resize
> > > 
> > > I'm posting these now, in the hopes that both these and the
> > > corresponding guest side patches can be staged and merged for the 4.11
> > > window.
> > 
> > Thanks, series applied to my kvm-ppc-next branch.
> 
> Great.  Where can I grab that tree?

git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc

> > Next time, please cc kvm-...@vger.kernel.org so I shows up in
> > patchwork and I don't miss it.
> 
> Sorry, I hadn't realized that list existed.  Noted for future
> reference.

Thanks,
Paul.

Re: [PATCHv2 00/11] KVM implementation of PAPR HPT resizing extension

[David Gibson]

On Wed, Feb 01, 2017 at 09:18:13AM +1100, Paul Mackerras wrote:
> On Tue, Dec 20, 2016 at 04:48:56PM +1100, David Gibson wrote:
> > Here is the KVM implementation for the proposed PAPR extension which
> > allows the runtime resizing of a PAPR guest's Hashed Page Table (HPT).
> > 
> > Using this requires a guest kernel with support for the extension.
> > Patches for guest side support in Linux were posted earlier:
> >   https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-December/152164.html
> > 
> > It also requires userspace (i.e. qemu) to intercept the HPT resizing
> > hypercalls and invoke the KVM ioctl()s to implement them.  This is
> > done instead of having KVM direclty intercept the hypercalls, so that
> > userspace can, if useful, impose additional restrictions on resizes:
> > for example it could refuse them entirely if policy for the VM
> > precludes resizing, or it could limit the size of HPT the guest can
> > request to meet resource limits.
> > 
> > Patches to implement the userspace part of HPT resizing are proposed
> > for qemu-2.9, and can be found at:
> >   https://github.com/dgibson/qemu/tree/hpt-resize
> > 
> > I'm posting these now, in the hopes that both these and the
> > corresponding guest side patches can be staged and merged for the 4.11
> > window.
> 
> Thanks, series applied to my kvm-ppc-next branch.

Great.  Where can I grab that tree?

> Next time, please cc kvm-...@vger.kernel.org so I shows up in
> patchwork and I don't miss it.

Sorry, I hadn't realized that list existed.  Noted for future
reference.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCHv2 00/11] KVM implementation of PAPR HPT resizing extension

[David Gibson]

On Wed, Feb 01, 2017 at 09:18:13AM +1100, Paul Mackerras wrote:
> On Tue, Dec 20, 2016 at 04:48:56PM +1100, David Gibson wrote:
> > Here is the KVM implementation for the proposed PAPR extension which
> > allows the runtime resizing of a PAPR guest's Hashed Page Table (HPT).
> > 
> > Using this requires a guest kernel with support for the extension.
> > Patches for guest side support in Linux were posted earlier:
> >   https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-December/152164.html
> > 
> > It also requires userspace (i.e. qemu) to intercept the HPT resizing
> > hypercalls and invoke the KVM ioctl()s to implement them.  This is
> > done instead of having KVM direclty intercept the hypercalls, so that
> > userspace can, if useful, impose additional restrictions on resizes:
> > for example it could refuse them entirely if policy for the VM
> > precludes resizing, or it could limit the size of HPT the guest can
> > request to meet resource limits.
> > 
> > Patches to implement the userspace part of HPT resizing are proposed
> > for qemu-2.9, and can be found at:
> >   https://github.com/dgibson/qemu/tree/hpt-resize
> > 
> > I'm posting these now, in the hopes that both these and the
> > corresponding guest side patches can be staged and merged for the 4.11
> > window.
> 
> Thanks, series applied to my kvm-ppc-next branch.

Great.  Where can I grab that tree?

> Next time, please cc kvm-...@vger.kernel.org so I shows up in
> patchwork and I don't miss it.

Sorry, I hadn't realized that list existed.  Noted for future
reference.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[PATCH v3] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T 

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T 
Signed-off-by: Pankaj Dubey 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Alim Akhtar 
Reviewed-by: Jaehoon Chung 
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch-v3 [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2017/1/16/19

Changes from v2:
 - Included Acked-by from Krzysztof
 - Rebased on top of cleanup patch-v3 from Jaehoon Chung and latest
   for-next of Krzysztof tree.

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index faee7d3..0f255ab 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = 

[PATCH v3] PCI: exynos: refactor exynos pcie driver

[Pankaj Dubey]

From: Niyas Ahmed S T 

Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
This patch does refactoring of Exynos PCIe driver to extend support
for other Exynos SoC.

Following are the main changes done via this patch:

1) It adds separate structs for memory, clock resources.

Reason behind this change is, moving ahead various Exynos SoC will
have different hardware resources such as iomem, clocks, regmap handles
etc. for PCIe controller, so keeping these resources in separate struct
will help us in intiailizing them via per SoC ops, and will avoid too
many of_machine_is_compatible in code, and help us simplifying
exynos_pcie struct.

2) It add exynos_pcie_ops struct which will allow us to support the
differences in resources in different Exynos SoC.

No functional change intended.

Signed-off-by: Niyas Ahmed S T 
Signed-off-by: Pankaj Dubey 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Alim Akhtar 
Reviewed-by: Jaehoon Chung 
---
This patch set is prepared on top of Krzysztof's for-next and
PCIe driver cleanup patch-v3 [1] by Jaehoon Chung.

[1]: https://lkml.org/lkml/2017/1/16/19

Changes from v2:
 - Included Acked-by from Krzysztof
 - Rebased on top of cleanup patch-v3 from Jaehoon Chung and latest
   for-next of Krzysztof tree.

Changes from v1:
 - Addressed review comments from Krzysztof and Jingoo Han.

 drivers/pci/host/pci-exynos.c | 346 ++
 1 file changed, 217 insertions(+), 129 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index faee7d3..0f255ab 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,16 +29,6 @@
 
 #define to_exynos_pcie(x)  container_of(x, struct exynos_pcie, pp)
 
-struct exynos_pcie {
-   struct pcie_portpp;
-   void __iomem*elbi_base; /* DT 0th resource */
-   void __iomem*phy_base;  /* DT 1st resource */
-   void __iomem*block_base;/* DT 2nd resource */
-   int reset_gpio;
-   struct clk  *clk;
-   struct clk  *bus_clk;
-};
-
 /* PCIe ELBI registers */
 #define PCIE_IRQ_PULSE 0x000
 #define IRQ_INTA_ASSERTBIT(0)
@@ -102,6 +93,122 @@ struct exynos_pcie {
 #define PCIE_PHY_TRSV3_PD_TSV  BIT(7)
 #define PCIE_PHY_TRSV3_LVCC0x31c
 
+struct exynos_pcie_mem_res {
+   void __iomem *elbi_base; /* DT 0th resource: PCIE CTRL */
+   void __iomem *phy_base; /* DT 1st resource: PHY CTRL */
+   void __iomem *block_base; /* DT 2nd resource: PHY ADDITIONAL CTRL */
+};
+
+struct exynos_pcie_clk_res {
+   struct clk *clk;
+   struct clk *bus_clk;
+};
+
+struct exynos_pcie {
+   struct pcie_portpp;
+   struct exynos_pcie_mem_res  *mem_res;
+   struct exynos_pcie_clk_res  *clk_res;
+   const struct exynos_pcie_ops*ops;
+   int reset_gpio;
+};
+
+struct exynos_pcie_ops {
+   int (*get_mem_resources)(struct platform_device *pdev,
+   struct exynos_pcie *ep);
+   int (*get_clk_resources)(struct exynos_pcie *ep);
+   int (*init_clk_resources)(struct exynos_pcie *ep);
+   void (*deinit_clk_resources)(struct exynos_pcie *ep);
+};
+
+static int exynos5440_pcie_get_mem_resources(struct platform_device *pdev,
+   struct exynos_pcie *ep)
+{
+   struct resource *res;
+   struct device *dev = ep->pp.dev;
+
+   ep->mem_res = devm_kzalloc(dev, sizeof(*ep->mem_res), GFP_KERNEL);
+   if (!ep->mem_res)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ep->mem_res->elbi_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->elbi_base))
+   return PTR_ERR(ep->mem_res->elbi_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->phy_base))
+   return PTR_ERR(ep->mem_res->phy_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   ep->mem_res->block_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(ep->mem_res->block_base))
+   return PTR_ERR(ep->mem_res->block_base);
+
+   return 0;
+}
+
+static int exynos5440_pcie_get_clk_resources(struct exynos_pcie *ep)
+{
+   struct device *dev = ep->pp.dev;
+
+   ep->clk_res = devm_kzalloc(dev, sizeof(*ep->clk_res), GFP_KERNEL);
+   if (!ep->clk_res)
+   return -ENOMEM;
+
+   ep->clk_res->clk = devm_clk_get(dev, "pcie");
+   if (IS_ERR(ep->clk_res->clk)) {
+   dev_err(dev, "Failed to get pcie rc clock\n");
+   return 

linux-next: manual merge of the char-misc tree with the driver-core tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  Documentation/driver-api/index.rst

between commit:

  113ccc38378b ("firmware: revamp firmware documentation")

from the driver-core tree and commit:

  cadf8106661c ("doc: convert UIO howto from docbook to sphinx")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/driver-api/index.rst
index 2359618746ec,c5a1cd0a4ae7..
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@@ -31,7 -30,7 +31,8 @@@ available subsections can be seen below
 miscellaneous
 vme
 80211/index
 +   firmware/index
+uio-howto
  
  .. only::  subproject and html
  

linux-next: manual merge of the char-misc tree with the driver-core tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  Documentation/driver-api/index.rst

between commit:

  113ccc38378b ("firmware: revamp firmware documentation")

from the driver-core tree and commit:

  cadf8106661c ("doc: convert UIO howto from docbook to sphinx")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/driver-api/index.rst
index 2359618746ec,c5a1cd0a4ae7..
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@@ -31,7 -30,7 +31,8 @@@ available subsections can be seen below
 miscellaneous
 vme
 80211/index
 +   firmware/index
+uio-howto
  
  .. only::  subproject and html
  

[PATCH 1/2] blk-mq: allocate blk_mq_tags and requests in correct node

[Shaohua Li]

blk_mq_tags/requests of specific hardware queue are mostly used in
specific cpus, which might not be in the same numa node as disk. For
example, a nvme card is in node 0. half hardware queue will be used by
node 0, the other node 1.

Signed-off-by: Shaohua Li 
---
 block/blk-mq.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index c3400b5..90a37ba 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1594,9 +1594,13 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
struct blk_mq_tags *tags;
unsigned int i, j, entries_per_page, max_order = 4;
size_t rq_size, left;
+   int node;
+
+   node = blk_mq_hw_queue_to_node(set->mq_map, hctx_idx);
+   if (node == NUMA_NO_NODE)
+   node = set->numa_node;
 
-   tags = blk_mq_init_tags(set->queue_depth, set->reserved_tags,
-   set->numa_node,
+   tags = blk_mq_init_tags(set->queue_depth, set->reserved_tags, node,
BLK_MQ_FLAG_TO_ALLOC_POLICY(set->flags));
if (!tags)
return NULL;
@@ -1605,7 +1609,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
 
tags->rqs = kzalloc_node(set->queue_depth * sizeof(struct request *),
 GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY,
-set->numa_node);
+node);
if (!tags->rqs) {
blk_mq_free_tags(tags);
return NULL;
@@ -1629,7 +1633,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
this_order--;
 
do {
-   page = alloc_pages_node(set->numa_node,
+   page = alloc_pages_node(node,
GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
this_order);
if (page)
@@ -1660,7 +1664,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
if (set->ops->init_request) {
if (set->ops->init_request(set->driver_data,
tags->rqs[i], hctx_idx, i,
-   set->numa_node)) {
+   node)) {
tags->rqs[i] = NULL;
goto fail;
}
-- 
2.9.3

[PATCH 2/2] nvme: allocate nvme_queue in correct node

[Shaohua Li]

nvme_queue is per-cpu queue (mostly). Allocating it in node where blk-mq
will use it.

Signed-off-by: Shaohua Li 
---
 drivers/nvme/host/pci.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 3faefab..f81c0ed 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1041,9 +1041,10 @@ static int nvme_alloc_sq_cmds(struct nvme_dev *dev, 
struct nvme_queue *nvmeq,
 }
 
 static struct nvme_queue *nvme_alloc_queue(struct nvme_dev *dev, int qid,
-   int depth)
+   int depth, int node)
 {
-   struct nvme_queue *nvmeq = kzalloc(sizeof(*nvmeq), GFP_KERNEL);
+   struct nvme_queue *nvmeq = kzalloc_node(sizeof(*nvmeq), GFP_KERNEL,
+   node);
if (!nvmeq)
return NULL;
 
@@ -1219,7 +1220,8 @@ static int nvme_configure_admin_queue(struct nvme_dev 
*dev)
 
nvmeq = dev->queues[0];
if (!nvmeq) {
-   nvmeq = nvme_alloc_queue(dev, 0, NVME_AQ_DEPTH);
+   nvmeq = nvme_alloc_queue(dev, 0, NVME_AQ_DEPTH,
+   dev_to_node(dev->dev));
if (!nvmeq)
return -ENOMEM;
}
@@ -1309,9 +1311,18 @@ static int nvme_create_io_queues(struct nvme_dev *dev)
 {
unsigned i, max;
int ret = 0;
+   const struct cpumask *mask;
 
for (i = dev->queue_count; i <= dev->max_qid; i++) {
-   if (!nvme_alloc_queue(dev, i, dev->q_depth)) {
+   int node = dev_to_node(dev->dev);
+
+   mask = pci_irq_get_affinity(to_pci_dev(dev->dev), i);
+   if (mask) {
+   node = cpu_to_node(cpumask_first(mask));
+   node = local_memory_node(node);
+   }
+
+   if (!nvme_alloc_queue(dev, i, dev->q_depth, node)) {
ret = -ENOMEM;
break;
}
-- 
2.9.3

[PATCH 1/2] blk-mq: allocate blk_mq_tags and requests in correct node

[Shaohua Li]

blk_mq_tags/requests of specific hardware queue are mostly used in
specific cpus, which might not be in the same numa node as disk. For
example, a nvme card is in node 0. half hardware queue will be used by
node 0, the other node 1.

Signed-off-by: Shaohua Li 
---
 block/blk-mq.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index c3400b5..90a37ba 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1594,9 +1594,13 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
struct blk_mq_tags *tags;
unsigned int i, j, entries_per_page, max_order = 4;
size_t rq_size, left;
+   int node;
+
+   node = blk_mq_hw_queue_to_node(set->mq_map, hctx_idx);
+   if (node == NUMA_NO_NODE)
+   node = set->numa_node;
 
-   tags = blk_mq_init_tags(set->queue_depth, set->reserved_tags,
-   set->numa_node,
+   tags = blk_mq_init_tags(set->queue_depth, set->reserved_tags, node,
BLK_MQ_FLAG_TO_ALLOC_POLICY(set->flags));
if (!tags)
return NULL;
@@ -1605,7 +1609,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
 
tags->rqs = kzalloc_node(set->queue_depth * sizeof(struct request *),
 GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY,
-set->numa_node);
+node);
if (!tags->rqs) {
blk_mq_free_tags(tags);
return NULL;
@@ -1629,7 +1633,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
this_order--;
 
do {
-   page = alloc_pages_node(set->numa_node,
+   page = alloc_pages_node(node,
GFP_NOIO | __GFP_NOWARN | __GFP_NORETRY | 
__GFP_ZERO,
this_order);
if (page)
@@ -1660,7 +1664,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct 
blk_mq_tag_set *set,
if (set->ops->init_request) {
if (set->ops->init_request(set->driver_data,
tags->rqs[i], hctx_idx, i,
-   set->numa_node)) {
+   node)) {
tags->rqs[i] = NULL;
goto fail;
}
-- 
2.9.3

[PATCH 2/2] nvme: allocate nvme_queue in correct node

[Shaohua Li]

nvme_queue is per-cpu queue (mostly). Allocating it in node where blk-mq
will use it.

Signed-off-by: Shaohua Li 
---
 drivers/nvme/host/pci.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 3faefab..f81c0ed 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1041,9 +1041,10 @@ static int nvme_alloc_sq_cmds(struct nvme_dev *dev, 
struct nvme_queue *nvmeq,
 }
 
 static struct nvme_queue *nvme_alloc_queue(struct nvme_dev *dev, int qid,
-   int depth)
+   int depth, int node)
 {
-   struct nvme_queue *nvmeq = kzalloc(sizeof(*nvmeq), GFP_KERNEL);
+   struct nvme_queue *nvmeq = kzalloc_node(sizeof(*nvmeq), GFP_KERNEL,
+   node);
if (!nvmeq)
return NULL;
 
@@ -1219,7 +1220,8 @@ static int nvme_configure_admin_queue(struct nvme_dev 
*dev)
 
nvmeq = dev->queues[0];
if (!nvmeq) {
-   nvmeq = nvme_alloc_queue(dev, 0, NVME_AQ_DEPTH);
+   nvmeq = nvme_alloc_queue(dev, 0, NVME_AQ_DEPTH,
+   dev_to_node(dev->dev));
if (!nvmeq)
return -ENOMEM;
}
@@ -1309,9 +1311,18 @@ static int nvme_create_io_queues(struct nvme_dev *dev)
 {
unsigned i, max;
int ret = 0;
+   const struct cpumask *mask;
 
for (i = dev->queue_count; i <= dev->max_qid; i++) {
-   if (!nvme_alloc_queue(dev, i, dev->q_depth)) {
+   int node = dev_to_node(dev->dev);
+
+   mask = pci_irq_get_affinity(to_pci_dev(dev->dev), i);
+   if (mask) {
+   node = cpu_to_node(cpumask_first(mask));
+   node = local_memory_node(node);
+   }
+
+   if (!nvme_alloc_queue(dev, i, dev->q_depth, node)) {
ret = -ENOMEM;
break;
}
-- 
2.9.3

Re: [PATCH] jbd2: Fix use after free in kjournald2()

[Tummala, Sahitya]

On 1/31/2017 9:21 PM, Jan Kara wrote:

On Tue 31-01-17 20:08:57, Sahitya Tummala wrote:

Below is the synchronization issue between unmount and kjournald2
contexts, which results into use after free issue in kjournald2().
Fix this issue by using journal->j_state_lock to synchronize the
wait_event() done in journal_kill_thread() and the wake_up() done
in kjournald2().

TASK 1:
umount cmd:
|--jbd2_journal_destroy() {
|--journal_kill_thread() {
 write_lock(>j_state_lock);
journal->j_flags |= JBD2_UNMOUNT;
...
write_unlock(>j_state_lock);
wake_up(>j_wait_commit);   TASK 2 wakes up here:
   kjournald2() {
 ...
 checks JBD2_UNMOUNT flag 
and calls goto end-loop;
 ...
 end_loop:
   
write_unlock(>j_state_lock);
   journal->j_task = NULL; 
--> If this thread gets
   pre-empted here, then 
TASK 1 wait_event will
   exit even before this 
thread is completely
   done.
wait_event(journal->j_wait_done_commit, journal->j_task == NULL);
...
write_lock(>j_state_lock);
write_unlock(>j_state_lock);
  }
|--kfree(journal);
  }
}
   
wake_up(>j_wait_done_commit); --> this step
   now results into use 
after free issue.
   }

Signed-off-by: Sahitya Tummala 

Yeah, what you write looks possible (although rather unlikely). Thanks for
catching this. One small nit below:

Yes, it was observed only once and is very hard to reproduce.

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..f5cd3c0 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -278,9 +278,11 @@ static int kjournald2(void *arg)
  end_loop:
write_unlock(>j_state_lock);
del_timer_sync(>j_commit_timer);
+   write_lock(>j_state_lock);

There's no good reason to do del_timer_sync() outside of j_state_lock. This
is not performance critical code and commit_timeout is trivial and cannot
block on anything. So just keep j_state_lock locked upto the place where
you unlock it now...


Sure, I will update the patch.

Honza

journal->j_task = NULL;
wake_up(>j_wait_done_commit);
jbd_debug(1, "Journal thread exiting.\n");
+   write_unlock(>j_state_lock);
return 0;
  }
  
--

Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.




--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] jbd2: Fix use after free in kjournald2()

[Tummala, Sahitya]

On 1/31/2017 9:21 PM, Jan Kara wrote:

On Tue 31-01-17 20:08:57, Sahitya Tummala wrote:

Below is the synchronization issue between unmount and kjournald2
contexts, which results into use after free issue in kjournald2().
Fix this issue by using journal->j_state_lock to synchronize the
wait_event() done in journal_kill_thread() and the wake_up() done
in kjournald2().

TASK 1:
umount cmd:
|--jbd2_journal_destroy() {
|--journal_kill_thread() {
 write_lock(>j_state_lock);
journal->j_flags |= JBD2_UNMOUNT;
...
write_unlock(>j_state_lock);
wake_up(>j_wait_commit);   TASK 2 wakes up here:
   kjournald2() {
 ...
 checks JBD2_UNMOUNT flag 
and calls goto end-loop;
 ...
 end_loop:
   
write_unlock(>j_state_lock);
   journal->j_task = NULL; 
--> If this thread gets
   pre-empted here, then 
TASK 1 wait_event will
   exit even before this 
thread is completely
   done.
wait_event(journal->j_wait_done_commit, journal->j_task == NULL);
...
write_lock(>j_state_lock);
write_unlock(>j_state_lock);
  }
|--kfree(journal);
  }
}
   
wake_up(>j_wait_done_commit); --> this step
   now results into use 
after free issue.
   }

Signed-off-by: Sahitya Tummala 

Yeah, what you write looks possible (although rather unlikely). Thanks for
catching this. One small nit below:

Yes, it was observed only once and is very hard to reproduce.

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index a097048..f5cd3c0 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -278,9 +278,11 @@ static int kjournald2(void *arg)
  end_loop:
write_unlock(>j_state_lock);
del_timer_sync(>j_commit_timer);
+   write_lock(>j_state_lock);

There's no good reason to do del_timer_sync() outside of j_state_lock. This
is not performance critical code and commit_timeout is trivial and cannot
block on anything. So just keep j_state_lock locked upto the place where
you unlock it now...


Sure, I will update the patch.

Honza

journal->j_task = NULL;
wake_up(>j_wait_done_commit);
jbd_debug(1, "Journal thread exiting.\n");
+   write_unlock(>j_state_lock);
return 0;
  }
  
--

Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.




--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH 13/17] net: stmmac: Implement NAPI for TX

[David Miller]

From: Corentin Labbe 
Date: Tue, 31 Jan 2017 10:11:48 +0100

> The stmmac driver run TX completion under NAPI but without checking
> the work done by the TX completion function.

The current behavior is correct and completely intentional.

A driver should _never_ account TX work to the NAPI poll budget.

This is because TX liberation is orders of magnitude cheaper than
receiving a packet, and such SKB freeing makes more SKBs available
for RX processing.

Therefore, TX work should never count against the NAPI budget.

Please do not fix something which is not broken.

Re: [PATCH 13/17] net: stmmac: Implement NAPI for TX

[David Miller]

From: Corentin Labbe 
Date: Tue, 31 Jan 2017 10:11:48 +0100

> The stmmac driver run TX completion under NAPI but without checking
> the work done by the TX completion function.

The current behavior is correct and completely intentional.

A driver should _never_ account TX work to the NAPI poll budget.

This is because TX liberation is orders of magnitude cheaper than
receiving a packet, and such SKB freeing makes more SKBs available
for RX processing.

Therefore, TX work should never count against the NAPI budget.

Please do not fix something which is not broken.

[PATCH v2 00/01] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Robert O'Callahan]

Changes in version 2:
- Fixed block comment formatting as requested by Ingo Molnar
- Changed commit summary to refer to a testcase that more easily shows the
problem.

For reference here's a complete testcase for an Intel TSX-enabled KVM guest:

#include 
#include 
#include 
#include 
#include 
#include 
int main(void) {
struct perf_event_attr attr;
int fd;
long long count;
memset(, 0, sizeof(attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
attr.config = 0x2005101c4; // conditional branches retired IN_TXCP
attr.sample_period = 0;
attr.exclude_kernel = 1;
attr.exclude_guest = 1;
fd = syscall(__NR_perf_event_open, , 0, -1, -1, 0);
ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);
for (int i = 0; i < 500; ++i) {
putchar('.');
}
read(fd, , sizeof(count));
printf("\nConditional branches: %lld\n%s\n", count,
   count < 500 ? "FAILED" : "PASSED");
return 0;
}

Robert O'Callahan (1):
  KVM: x86: never specify a sample period for virtualized in_tx_cp
counters

 arch/x86/kvm/pmu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH v2 00/01] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Robert O'Callahan]

Changes in version 2:
- Fixed block comment formatting as requested by Ingo Molnar
- Changed commit summary to refer to a testcase that more easily shows the
problem.

For reference here's a complete testcase for an Intel TSX-enabled KVM guest:

#include 
#include 
#include 
#include 
#include 
#include 
int main(void) {
struct perf_event_attr attr;
int fd;
long long count;
memset(, 0, sizeof(attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
attr.config = 0x2005101c4; // conditional branches retired IN_TXCP
attr.sample_period = 0;
attr.exclude_kernel = 1;
attr.exclude_guest = 1;
fd = syscall(__NR_perf_event_open, , 0, -1, -1, 0);
ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);
for (int i = 0; i < 500; ++i) {
putchar('.');
}
read(fd, , sizeof(count));
printf("\nConditional branches: %lld\n%s\n", count,
   count < 500 ? "FAILED" : "PASSED");
return 0;
}

Robert O'Callahan (1):
  KVM: x86: never specify a sample period for virtualized in_tx_cp
counters

 arch/x86/kvm/pmu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

-- 
2.9.3

[PATCH v2 01/01] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Robert O'Callahan]

pmc_reprogram_counter() always sets a sample period based on the value of
pmc->counter. However, hsw_hw_config() rejects sample periods less than
2^31 - 1. So for example, if a KVM guest does

struct perf_event_attr attr;
memset(, 0, sizeof(attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
attr.config = 0x2005101c4; // conditional branches retired IN_TXCP
attr.sample_period = 0;
int fd = syscall(__NR_perf_event_open, , 0, -1, -1, 0);
ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);

the guest kernel counts some conditional branch events, then updates the
virtual PMU register with a nonzero count. The host reaches
pmc_reprogram_counter() with nonzero pmc->counter, triggers EOPNOTSUPP
in hsw_hw_config(), prints "kvm_pmu: event creation failed" in
pmc_reprogram_counter(), and silently (from the guest's point of view) stops
counting events.

We fix event counting by forcing attr.sample_period to always be zero for
in_tx_cp counters. Sampling doesn't work, but it already didn't work and
can't be fixed without major changes to the approach in hsw_hw_config().

Signed-off-by: Robert O'Callahan 
---
 arch/x86/kvm/pmu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 06ce377..026db42 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -113,12 +113,19 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, 
u32 type,
.config = config,
};
 
+   attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
+
if (in_tx)
attr.config |= HSW_IN_TX;
-   if (in_tx_cp)
+   if (in_tx_cp) {
+   /*
+* HSW_IN_TX_CHECKPOINTED is not supported with nonzero
+* period. Just clear the sample period so at least
+* allocating the counter doesn't fail.
+*/
+   attr.sample_period = 0;
attr.config |= HSW_IN_TX_CHECKPOINTED;
-
-   attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
+   }
 
event = perf_event_create_kernel_counter(, -1, current,
 intr ? kvm_perf_overflow_intr :
-- 
2.9.3

[PATCH v2 01/01] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

[Robert O'Callahan]

pmc_reprogram_counter() always sets a sample period based on the value of
pmc->counter. However, hsw_hw_config() rejects sample periods less than
2^31 - 1. So for example, if a KVM guest does

struct perf_event_attr attr;
memset(, 0, sizeof(attr));
attr.type = PERF_TYPE_RAW;
attr.size = sizeof(attr);
attr.config = 0x2005101c4; // conditional branches retired IN_TXCP
attr.sample_period = 0;
int fd = syscall(__NR_perf_event_open, , 0, -1, -1, 0);
ioctl(fd, PERF_EVENT_IOC_DISABLE, 0);
ioctl(fd, PERF_EVENT_IOC_ENABLE, 0);

the guest kernel counts some conditional branch events, then updates the
virtual PMU register with a nonzero count. The host reaches
pmc_reprogram_counter() with nonzero pmc->counter, triggers EOPNOTSUPP
in hsw_hw_config(), prints "kvm_pmu: event creation failed" in
pmc_reprogram_counter(), and silently (from the guest's point of view) stops
counting events.

We fix event counting by forcing attr.sample_period to always be zero for
in_tx_cp counters. Sampling doesn't work, but it already didn't work and
can't be fixed without major changes to the approach in hsw_hw_config().

Signed-off-by: Robert O'Callahan 
---
 arch/x86/kvm/pmu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 06ce377..026db42 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -113,12 +113,19 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, 
u32 type,
.config = config,
};
 
+   attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
+
if (in_tx)
attr.config |= HSW_IN_TX;
-   if (in_tx_cp)
+   if (in_tx_cp) {
+   /*
+* HSW_IN_TX_CHECKPOINTED is not supported with nonzero
+* period. Just clear the sample period so at least
+* allocating the counter doesn't fail.
+*/
+   attr.sample_period = 0;
attr.config |= HSW_IN_TX_CHECKPOINTED;
-
-   attr.sample_period = (-pmc->counter) & pmc_bitmask(pmc);
+   }
 
event = perf_event_create_kernel_counter(, -1, current,
 intr ? kvm_perf_overflow_intr :
-- 
2.9.3

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Mimi Zohar]

On Wed, 2017-02-01 at 08:46 +1100, James Morris wrote:
> On Tue, 31 Jan 2017, Jarkko Sakkinen wrote:
> 
> > James,
> > 
> > The discussion is about two features:
> > 
> > 1. Extension to tpm_pcr_extend() (used by IMA) to extend all PCR banks
> >instead of just SHA-1 banks. It is recommended by TCG to do so in
> >order to prevent malicious use of PCRs.
> > 2. TPM 2.0 event log with backend support for OF device tree (for
> >getting address where you can grab it).
> > 
> > These are required as baseline to implement full TPM 2.0 support for
> > IMA. The commits are fairly well baked and went through many iterations.
> > I've tested tpm_pcr_extend() patches. I haven't tested event log patches
> > but have extensively reviewed them and Ken Goldman has tested them with
> > POWER hardware.
> > 
> > I don't believe that there is major risk to put them already into 4.11
> > but it is fairly late so I just want a second opinion before putting
> > them into pull request.
> > 
> 
> I'll take this for 4.11.  IMA + TPM 2.0 is still developmental and not in 
> wide use, afaik.

Thank you!   FYI, I've been running with them as well.

Mimi

Re: Fwd: Re: [tpmdd-devel] [PATCH v9 2/2] tpm: add securityfs support,for TPM 2.0 firmware event log

[Mimi Zohar]

On Wed, 2017-02-01 at 08:46 +1100, James Morris wrote:
> On Tue, 31 Jan 2017, Jarkko Sakkinen wrote:
> 
> > James,
> > 
> > The discussion is about two features:
> > 
> > 1. Extension to tpm_pcr_extend() (used by IMA) to extend all PCR banks
> >instead of just SHA-1 banks. It is recommended by TCG to do so in
> >order to prevent malicious use of PCRs.
> > 2. TPM 2.0 event log with backend support for OF device tree (for
> >getting address where you can grab it).
> > 
> > These are required as baseline to implement full TPM 2.0 support for
> > IMA. The commits are fairly well baked and went through many iterations.
> > I've tested tpm_pcr_extend() patches. I haven't tested event log patches
> > but have extensively reviewed them and Ken Goldman has tested them with
> > POWER hardware.
> > 
> > I don't believe that there is major risk to put them already into 4.11
> > but it is fairly late so I just want a second opinion before putting
> > them into pull request.
> > 
> 
> I'll take this for 4.11.  IMA + TPM 2.0 is still developmental and not in 
> wide use, afaik.

Thank you!   FYI, I've been running with them as well.

Mimi

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/gpu/drm/ttm/ttm_bo.c

between commit:

  239ac65fa5ff ("drm/ttm: Make sure BOs being swapped out are cacheable")

from the drm tree and commit:

  bdfafc4ffdd2 ("locking/atomic, kref: Kill kref_sub()")
  cf6c467d67d3 ("drm/ttm: add BO priorities for the LRUs")
  896d630d240e ("drm/ttm: revert "add optional LRU removal callback v2"")

from the tip tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/ttm/ttm_bo.c
index 4562e53c8244,ffc6cb55c78c..
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@@ -184,37 -181,26 +184,26 @@@ void ttm_bo_add_to_lru(struct ttm_buffe
  }
  EXPORT_SYMBOL(ttm_bo_add_to_lru);
  
- int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
+ static void ttm_bo_ref_bug(struct kref *list_kref)
  {
-   int put_count = 0;
+   BUG();
+ }
  
+ void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
+ {
 -  struct ttm_bo_device *bdev = bo->bdev;
 -
 -  if (bdev->driver->lru_removal)
 -  bdev->driver->lru_removal(bo);
 -
if (!list_empty(>swap)) {
list_del_init(>swap);
-   ++put_count;
+   kref_put(>list_kref, ttm_bo_ref_bug);
}
if (!list_empty(>lru)) {
list_del_init(>lru);
-   ++put_count;
+   kref_put(>list_kref, ttm_bo_ref_bug);
}
 +
 +  /*
 +   * TODO: Add a driver hook to delete from
 +   * driver-specific LRU's here.
 +   */
- 
-   return put_count;
- }
- 
- static void ttm_bo_ref_bug(struct kref *list_kref)
- {
-   BUG();
- }
- 
- void ttm_bo_list_ref_sub(struct ttm_buffer_object *bo, int count,
-bool never_free)
- {
-   kref_sub(>list_kref, count,
-(never_free) ? ttm_bo_ref_bug : ttm_bo_release_list);
  }
  
  void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
@@@ -230,12 -213,14 +216,9 @@@ EXPORT_SYMBOL(ttm_bo_del_sub_from_lru)
  
  void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
  {
-   int put_count = 0;
 -  struct ttm_bo_device *bdev = bo->bdev;
--
lockdep_assert_held(>resv->lock.base);
  
-   put_count = ttm_bo_del_from_lru(bo);
-   ttm_bo_list_ref_sub(bo, put_count, true);
 -  if (bdev->driver->lru_removal)
 -  bdev->driver->lru_removal(bo);
 -
+   ttm_bo_del_from_lru(bo);
ttm_bo_add_to_lru(bo);
  }
  EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
@@@ -728,28 -718,21 +704,28 @@@ static int ttm_mem_evict_first(struct t
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo;
-   int ret = -EBUSY, put_count;
+   int ret = -EBUSY;
 +  unsigned i;
  
spin_lock(>lru_lock);
 -  list_for_each_entry(bo, >lru, lru) {
 -  ret = __ttm_bo_reserve(bo, false, true, NULL);
 -  if (ret)
 -  continue;
 +  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
 +  list_for_each_entry(bo, >lru[i], lru) {
 +  ret = __ttm_bo_reserve(bo, false, true, NULL);
 +  if (ret)
 +  continue;
  
 -  if (place && !bdev->driver->eviction_valuable(bo, place)) {
 -  __ttm_bo_unreserve(bo);
 -  ret = -EBUSY;
 -  continue;
 +  if (place && !bdev->driver->eviction_valuable(bo,
 +place)) {
 +  __ttm_bo_unreserve(bo);
 +  ret = -EBUSY;
 +  continue;
 +  }
 +
 +  break;
}
  
 -  break;
 +  if (!ret)
 +  break;
}
  
if (ret) {
@@@ -1667,16 -1645,11 +1641,15 @@@ static int ttm_bo_swapout(struct ttm_me
container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
-   int put_count;
 -  uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);
 +  unsigned i;
  
spin_lock(>lru_lock);
 -  list_for_each_entry(bo, >swap_lru, swap) {
 -  ret = __ttm_bo_reserve(bo, false, true, NULL);
 +  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
 +  list_for_each_entry(bo, >swap_lru[i], swap) {
 +  ret = __ttm_bo_reserve(bo, false, true, NULL);
 + 

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/gpu/drm/ttm/ttm_bo.c

between commit:

  239ac65fa5ff ("drm/ttm: Make sure BOs being swapped out are cacheable")

from the drm tree and commit:

  bdfafc4ffdd2 ("locking/atomic, kref: Kill kref_sub()")
  cf6c467d67d3 ("drm/ttm: add BO priorities for the LRUs")
  896d630d240e ("drm/ttm: revert "add optional LRU removal callback v2"")

from the tip tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/ttm/ttm_bo.c
index 4562e53c8244,ffc6cb55c78c..
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@@ -184,37 -181,26 +184,26 @@@ void ttm_bo_add_to_lru(struct ttm_buffe
  }
  EXPORT_SYMBOL(ttm_bo_add_to_lru);
  
- int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
+ static void ttm_bo_ref_bug(struct kref *list_kref)
  {
-   int put_count = 0;
+   BUG();
+ }
  
+ void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
+ {
 -  struct ttm_bo_device *bdev = bo->bdev;
 -
 -  if (bdev->driver->lru_removal)
 -  bdev->driver->lru_removal(bo);
 -
if (!list_empty(>swap)) {
list_del_init(>swap);
-   ++put_count;
+   kref_put(>list_kref, ttm_bo_ref_bug);
}
if (!list_empty(>lru)) {
list_del_init(>lru);
-   ++put_count;
+   kref_put(>list_kref, ttm_bo_ref_bug);
}
 +
 +  /*
 +   * TODO: Add a driver hook to delete from
 +   * driver-specific LRU's here.
 +   */
- 
-   return put_count;
- }
- 
- static void ttm_bo_ref_bug(struct kref *list_kref)
- {
-   BUG();
- }
- 
- void ttm_bo_list_ref_sub(struct ttm_buffer_object *bo, int count,
-bool never_free)
- {
-   kref_sub(>list_kref, count,
-(never_free) ? ttm_bo_ref_bug : ttm_bo_release_list);
  }
  
  void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
@@@ -230,12 -213,14 +216,9 @@@ EXPORT_SYMBOL(ttm_bo_del_sub_from_lru)
  
  void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
  {
-   int put_count = 0;
 -  struct ttm_bo_device *bdev = bo->bdev;
--
lockdep_assert_held(>resv->lock.base);
  
-   put_count = ttm_bo_del_from_lru(bo);
-   ttm_bo_list_ref_sub(bo, put_count, true);
 -  if (bdev->driver->lru_removal)
 -  bdev->driver->lru_removal(bo);
 -
+   ttm_bo_del_from_lru(bo);
ttm_bo_add_to_lru(bo);
  }
  EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
@@@ -728,28 -718,21 +704,28 @@@ static int ttm_mem_evict_first(struct t
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo;
-   int ret = -EBUSY, put_count;
+   int ret = -EBUSY;
 +  unsigned i;
  
spin_lock(>lru_lock);
 -  list_for_each_entry(bo, >lru, lru) {
 -  ret = __ttm_bo_reserve(bo, false, true, NULL);
 -  if (ret)
 -  continue;
 +  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
 +  list_for_each_entry(bo, >lru[i], lru) {
 +  ret = __ttm_bo_reserve(bo, false, true, NULL);
 +  if (ret)
 +  continue;
  
 -  if (place && !bdev->driver->eviction_valuable(bo, place)) {
 -  __ttm_bo_unreserve(bo);
 -  ret = -EBUSY;
 -  continue;
 +  if (place && !bdev->driver->eviction_valuable(bo,
 +place)) {
 +  __ttm_bo_unreserve(bo);
 +  ret = -EBUSY;
 +  continue;
 +  }
 +
 +  break;
}
  
 -  break;
 +  if (!ret)
 +  break;
}
  
if (ret) {
@@@ -1667,16 -1645,11 +1641,15 @@@ static int ttm_bo_swapout(struct ttm_me
container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
-   int put_count;
 -  uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);
 +  unsigned i;
  
spin_lock(>lru_lock);
 -  list_for_each_entry(bo, >swap_lru, swap) {
 -  ret = __ttm_bo_reserve(bo, false, true, NULL);
 +  for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
 +  list_for_each_entry(bo, >swap_lru[i], swap) {
 +  ret = __ttm_bo_reserve(bo, false, true, NULL);
 + 

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

[takafumi-sslab]

Thanks for your reply.

I think you mentioned about the below if-block in __extent_writepage().

if (nr == 0) {
/* make sure the mapping tag for page dirty gets cleared */
set_page_writeback(page);
end_page_writeback(page);
}

However, this if-block only works when nr is 0, and does not work in the 
case we indicated.
According to the below codes that we excerpt from 
__extent_writepage_io(), nr is incremented even if submit_extent_page() 
fails.
Therefore, we should safely clear the writeback bit in the error 
handling after the fail of submit_extent_page() call


while (cur <= end) {
...
ret = submit_extent_page(...);
if (ret)
SetPageError(page);

cur = cur + iosize;
pg_offset += iosize;
nr++;
}
done:
*nr_ret = nr; // *nr_ret is nr of __extent_writepage()

Sincerely,

On 2017/01/31 5:09, Liu Bo wrote:

On Fri, Jan 13, 2017 at 03:12:31PM +0900, takafumi-sslab wrote:

Thanks for your replying.

I understand this bug is more complicated than I expected.
I classify error cases under submit_extent_page() below

A: ENOMEM error at btrfs_bio_alloc() in submit_extent_page()
I first assumed this case and sent the mail.
When bio_ret is NULL, submit_extent_page() calls btrfs_bio_alloc().
Then, btrfs_bio_alloc() may fail and submit_extent_page() returns -ENOMEM.
In this case, bio_endio() is not called and the page's writeback bit
remains.
So, there is a need to call end_page_writeback() in the error handling.

B: errors under submit_one_bio() of submit_extent_page()
Errors that occur under submit_one_bio() handles at bio_endio(), and
bio_endio() would call end_page_writeback().

Therefore, as you mentioned in the last mail, simply adding
end_page_writeback() like my last email and commit 55e3bd2e0c2e1 can
conflict in the case of B.
To avoid such conflict, one easy solution is adding PageWriteback() check
too.

How do you think of this solution?

(sorry for the late reply.)

I think its caller, "__extent_writepage", has covered the above case
by setting page writeback again.

Thanks,

-liubo

Sincerely,

On 2016/12/22 15:20, Liu Bo wrote:

On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote:

This is actually inspired by Filipe's patch(55e3bd2e0c2e1).

When submit_extent_page() in __extent_writepage_io() fails,
Btrfs misses clearing a writeback bit of the failed page.
This causes the false under-writeback page.
Then, another sync task hangs in filemap_fdatawait_range(),
because it waits the false under-writeback page.

CPU0CPU1

__extent_writepage_io()
ret = submit_extent_page() // fail

if (ret)
  SetPageError(page)
  // miss clearing the writeback bit

  sync()
...
filemap_fdatawait_range()
  wait_on_page_writeback(page);
  // wait the false under-writeback page

Signed-off-by: Takafumi Kubota 
---
   fs/btrfs/extent_io.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e67723..ef9793b 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3443,8 +3443,10 @@ static noinline_for_stack int 
__extent_writepage_io(struct inode *inode,
 bdev->bio, max_nr,
 end_bio_extent_writepage,
 0, 0, 0, false);
-   if (ret)
+   if (ret) {
SetPageError(page);
+   end_page_writeback(page);
+   }

OK...this could be complex as we don't know which part in
submit_extent_page gets the error, if the page has been added into bio
and bio_end would call end_page_writepage(page) as well, so whichever
comes later, the BUG() in end_page_writeback() would complain.

Looks like commit 55e3bd2e0c2e1 also has the same problem although I
gave it my reviewed-by.

Thanks,

-liubo


cur = cur + iosize;
pg_offset += iosize;
--
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp



--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

[takafumi-sslab]

Thanks for your reply.

I think you mentioned about the below if-block in __extent_writepage().

if (nr == 0) {
/* make sure the mapping tag for page dirty gets cleared */
set_page_writeback(page);
end_page_writeback(page);
}

However, this if-block only works when nr is 0, and does not work in the 
case we indicated.
According to the below codes that we excerpt from 
__extent_writepage_io(), nr is incremented even if submit_extent_page() 
fails.
Therefore, we should safely clear the writeback bit in the error 
handling after the fail of submit_extent_page() call


while (cur <= end) {
...
ret = submit_extent_page(...);
if (ret)
SetPageError(page);

cur = cur + iosize;
pg_offset += iosize;
nr++;
}
done:
*nr_ret = nr; // *nr_ret is nr of __extent_writepage()

Sincerely,

On 2017/01/31 5:09, Liu Bo wrote:

On Fri, Jan 13, 2017 at 03:12:31PM +0900, takafumi-sslab wrote:

Thanks for your replying.

I understand this bug is more complicated than I expected.
I classify error cases under submit_extent_page() below

A: ENOMEM error at btrfs_bio_alloc() in submit_extent_page()
I first assumed this case and sent the mail.
When bio_ret is NULL, submit_extent_page() calls btrfs_bio_alloc().
Then, btrfs_bio_alloc() may fail and submit_extent_page() returns -ENOMEM.
In this case, bio_endio() is not called and the page's writeback bit
remains.
So, there is a need to call end_page_writeback() in the error handling.

B: errors under submit_one_bio() of submit_extent_page()
Errors that occur under submit_one_bio() handles at bio_endio(), and
bio_endio() would call end_page_writeback().

Therefore, as you mentioned in the last mail, simply adding
end_page_writeback() like my last email and commit 55e3bd2e0c2e1 can
conflict in the case of B.
To avoid such conflict, one easy solution is adding PageWriteback() check
too.

How do you think of this solution?

(sorry for the late reply.)

I think its caller, "__extent_writepage", has covered the above case
by setting page writeback again.

Thanks,

-liubo

Sincerely,

On 2016/12/22 15:20, Liu Bo wrote:

On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote:

This is actually inspired by Filipe's patch(55e3bd2e0c2e1).

When submit_extent_page() in __extent_writepage_io() fails,
Btrfs misses clearing a writeback bit of the failed page.
This causes the false under-writeback page.
Then, another sync task hangs in filemap_fdatawait_range(),
because it waits the false under-writeback page.

CPU0CPU1

__extent_writepage_io()
ret = submit_extent_page() // fail

if (ret)
  SetPageError(page)
  // miss clearing the writeback bit

  sync()
...
filemap_fdatawait_range()
  wait_on_page_writeback(page);
  // wait the false under-writeback page

Signed-off-by: Takafumi Kubota 
---
   fs/btrfs/extent_io.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e67723..ef9793b 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3443,8 +3443,10 @@ static noinline_for_stack int 
__extent_writepage_io(struct inode *inode,
 bdev->bio, max_nr,
 end_bio_extent_writepage,
 0, 0, 0, false);
-   if (ret)
+   if (ret) {
SetPageError(page);
+   end_page_writeback(page);
+   }

OK...this could be complex as we don't know which part in
submit_extent_page gets the error, if the page has been added into bio
and bio_end would call end_page_writepage(page) as well, so whichever
comes later, the BUG() in end_page_writeback() would complain.

Looks like commit 55e3bd2e0c2e1 also has the same problem although I
gave it my reviewed-by.

Thanks,

-liubo


cur = cur + iosize;
pg_offset += iosize;
--
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp



--
Keio University
System Software Laboratory
Takafumi Kubota
takafumi.kubota1...@sslab.ics.keio.jp

Re: [PATCH] dt-bindings: display: move ANX7814 and SiI8620 bridge bindings

[Archit Taneja]

On 01/31/2017 11:24 PM, Rob Herring wrote:

A few bindings snuck into bindings/video/bridge since consolidating
everything under bindings/display/bridge/. Move them to the correct
spot.

Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Enric Balletbo i Serra 
Cc: Thierry Reding 
Signed-off-by: Rob Herring 


Acked-by: Archit Taneja 


---

I plan to apply this to my tree.

Rob

 Documentation/devicetree/bindings/{video => display}/bridge/anx7814.txt   | 0
 .../devicetree/bindings/{video => display}/bridge/sil-sii8620.txt | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{video => display}/bridge/anx7814.txt 
(100%)
 rename Documentation/devicetree/bindings/{video => 
display}/bridge/sil-sii8620.txt (100%)

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
b/Documentation/devicetree/bindings/display/bridge/anx7814.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/bridge/anx7814.txt
rename to Documentation/devicetree/bindings/display/bridge/anx7814.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
rename to Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] dt-bindings: display: move ANX7814 and SiI8620 bridge bindings

[Archit Taneja]

On 01/31/2017 11:24 PM, Rob Herring wrote:

A few bindings snuck into bindings/video/bridge since consolidating
everything under bindings/display/bridge/. Move them to the correct
spot.

Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Enric Balletbo i Serra 
Cc: Thierry Reding 
Signed-off-by: Rob Herring 


Acked-by: Archit Taneja 


---

I plan to apply this to my tree.

Rob

 Documentation/devicetree/bindings/{video => display}/bridge/anx7814.txt   | 0
 .../devicetree/bindings/{video => display}/bridge/sil-sii8620.txt | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{video => display}/bridge/anx7814.txt 
(100%)
 rename Documentation/devicetree/bindings/{video => 
display}/bridge/sil-sii8620.txt (100%)

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
b/Documentation/devicetree/bindings/display/bridge/anx7814.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/bridge/anx7814.txt
rename to Documentation/devicetree/bindings/display/bridge/anx7814.txt
diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt 
b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
rename to Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project