[PATCH v3 6/9] arm64: dts: actions: Add Reset Controller support for S900 SoC

[Manivannan Sadhasivam]

Add reset controller property and bindings header for the
Actions Semi S900 SoC DTS.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900.dtsi 
b/arch/arm64/boot/dts/actions/s900.dtsi
index aa3a49b0d646..4fbb39fd7971 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "actions,s900";
@@ -172,6 +173,7 @@
reg = <0x0 0xe016 0x0 0x1000>;
clocks = <>, <>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
pinctrl: pinctrl@e01b {
-- 
2.17.1

[PATCH v3 6/9] arm64: dts: actions: Add Reset Controller support for S900 SoC

[Manivannan Sadhasivam]

Add reset controller property and bindings header for the
Actions Semi S900 SoC DTS.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s900.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s900.dtsi 
b/arch/arm64/boot/dts/actions/s900.dtsi
index aa3a49b0d646..4fbb39fd7971 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "actions,s900";
@@ -172,6 +173,7 @@
reg = <0x0 0xe016 0x0 0x1000>;
clocks = <>, <>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
pinctrl: pinctrl@e01b {
-- 
2.17.1

[PATCH v3 3/9] dt-bindings: reset: Add binding constants for Actions Semi S700 RMU

[Manivannan Sadhasivam]

Add device tree binding constants for Actions Semi S700 SoC Reset
Management Unit (RMU).

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 .../dt-bindings/reset/actions,s700-reset.h| 34 +++
 1 file changed, 34 insertions(+)
 create mode 100644 include/dt-bindings/reset/actions,s700-reset.h

diff --git a/include/dt-bindings/reset/actions,s700-reset.h 
b/include/dt-bindings/reset/actions,s700-reset.h
new file mode 100644
index ..5e3b16b8ef53
--- /dev/null
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+//
+// Device Tree binding constants for Actions Semi S700 Reset Management Unit
+//
+// Copyright (c) 2018 Linaro Ltd.
+
+#ifndef __DT_BINDINGS_ACTIONS_S700_RESET_H
+#define __DT_BINDINGS_ACTIONS_S700_RESET_H
+
+#define RESET_AUDIO0
+#define RESET_CSI  1
+#define RESET_DE   2
+#define RESET_DSI  3
+#define RESET_GPIO 4
+#define RESET_I2C0 5
+#define RESET_I2C1 6
+#define RESET_I2C2 7
+#define RESET_I2C3 8
+#define RESET_KEY  9
+#define RESET_LCD0 10
+#define RESET_SI   11
+#define RESET_SPI0 12
+#define RESET_SPI1 13
+#define RESET_SPI2 14
+#define RESET_SPI3 15
+#define RESET_UART016
+#define RESET_UART117
+#define RESET_UART218
+#define RESET_UART319
+#define RESET_UART420
+#define RESET_UART521
+#define RESET_UART622
+
+#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
-- 
2.17.1

[PATCH v3 7/9] clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support

[Manivannan Sadhasivam]

Add Reset Management Unit (RMU) support for Actions Semi Owl SoCs.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/Kconfig  |  1 +
 drivers/clk/actions/Makefile |  1 +
 drivers/clk/actions/owl-common.h |  2 +
 drivers/clk/actions/owl-reset.c  | 66 
 drivers/clk/actions/owl-reset.h  | 31 +++
 5 files changed, 101 insertions(+)
 create mode 100644 drivers/clk/actions/owl-reset.c
 create mode 100644 drivers/clk/actions/owl-reset.h

diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
index dc38c85a4833..04f0a6355726 100644
--- a/drivers/clk/actions/Kconfig
+++ b/drivers/clk/actions/Kconfig
@@ -2,6 +2,7 @@ config CLK_ACTIONS
bool "Clock driver for Actions Semi SoCs"
depends on ARCH_ACTIONS || COMPILE_TEST
select REGMAP_MMIO
+   select RESET_CONTROLLER
default ARCH_ACTIONS
 
 if CLK_ACTIONS
diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
index 78c17d56f991..ccfdf9781cef 100644
--- a/drivers/clk/actions/Makefile
+++ b/drivers/clk/actions/Makefile
@@ -7,6 +7,7 @@ clk-owl-y   += owl-divider.o
 clk-owl-y  += owl-factor.o
 clk-owl-y  += owl-composite.o
 clk-owl-y  += owl-pll.o
+clk-owl-y  += owl-reset.o
 
 # SoC support
 obj-$(CONFIG_CLK_OWL_S700) += owl-s700.o
diff --git a/drivers/clk/actions/owl-common.h b/drivers/clk/actions/owl-common.h
index 56f01f7774aa..5a866a8b913d 100644
--- a/drivers/clk/actions/owl-common.h
+++ b/drivers/clk/actions/owl-common.h
@@ -26,6 +26,8 @@ struct owl_clk_desc {
struct owl_clk_common   **clks;
unsigned long   num_clks;
struct clk_hw_onecell_data  *hw_clks;
+   const struct owl_reset_map  *resets;
+   unsigned long   num_resets;
struct regmap   *regmap;
 };
 
diff --git a/drivers/clk/actions/owl-reset.c b/drivers/clk/actions/owl-reset.c
new file mode 100644
index ..203f8f34a8d4
--- /dev/null
+++ b/drivers/clk/actions/owl-reset.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Actions Semi Owl SoCs Reset Management Unit driver
+//
+// Copyright (c) 2018 Linaro Ltd.
+// Author: Manivannan Sadhasivam 
+
+#include 
+#include 
+#include 
+
+#include "owl-reset.h"
+
+static int owl_reset_assert(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+
+   return regmap_update_bits(reset->regmap, map->reg, map->bit, 0);
+}
+
+static int owl_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+
+   return regmap_update_bits(reset->regmap, map->reg, map->bit, map->bit);
+}
+
+static int owl_reset_reset(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   owl_reset_assert(rcdev, id);
+   udelay(1);
+   owl_reset_deassert(rcdev, id);
+
+   return 0;
+}
+
+static int owl_reset_status(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+   u32 reg;
+   int ret;
+
+   ret = regmap_read(reset->regmap, map->reg, );
+   if (ret)
+   return ret;
+
+   /*
+* The reset control API expects 0 if reset is not asserted,
+* which is the opposite of what our hardware uses.
+*/
+   return !(map->bit & reg);
+}
+
+const struct reset_control_ops owl_reset_ops = {
+   .assert = owl_reset_assert,
+   .deassert   = owl_reset_deassert,
+   .reset  = owl_reset_reset,
+   .status = owl_reset_status,
+};
diff --git a/drivers/clk/actions/owl-reset.h b/drivers/clk/actions/owl-reset.h
new file mode 100644
index ..10f5774979a6
--- /dev/null
+++ b/drivers/clk/actions/owl-reset.h
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Actions Semi Owl SoCs Reset Management Unit driver
+//
+// Copyright (c) 2018 Linaro Ltd.
+// Author: Manivannan Sadhasivam 
+
+#ifndef _OWL_RESET_H_
+#define _OWL_RESET_H_
+
+#include 
+
+struct owl_reset_map {
+   u32 reg;
+   u32 bit;
+};
+
+struct owl_reset {
+   struct reset_controller_dev rcdev;
+   const struct owl_reset_map  *reset_map;
+   struct regmap   *regmap;
+};
+
+static inline struct owl_reset *to_owl_reset(struct reset_controller_dev 
*rcdev)
+{
+   return container_of(rcdev, struct owl_reset, rcdev);
+}
+
+extern const struct reset_control_ops owl_reset_ops;
+
+#endif /* _OWL_RESET_H_ */
-- 
2.17.1

[PATCH v3 5/9] arm64: dts: actions: Add Reset Controller support for S700 SoC

[Manivannan Sadhasivam]

Add reset controller property and bindings header for the
Actions Semi S700 SoC DTS.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s700.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s700.dtsi 
b/arch/arm64/boot/dts/actions/s700.dtsi
index 59d29e4ca404..30c4c6ea89ea 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "actions,s700";
@@ -165,6 +166,7 @@
reg = <0x0 0xe0168000 0x0 0x1000>;
clocks = <>, <>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
sps: power-controller@e01b0100 {
-- 
2.17.1

[PATCH v3 7/9] clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support

[Manivannan Sadhasivam]

Add Reset Management Unit (RMU) support for Actions Semi Owl SoCs.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/Kconfig  |  1 +
 drivers/clk/actions/Makefile |  1 +
 drivers/clk/actions/owl-common.h |  2 +
 drivers/clk/actions/owl-reset.c  | 66 
 drivers/clk/actions/owl-reset.h  | 31 +++
 5 files changed, 101 insertions(+)
 create mode 100644 drivers/clk/actions/owl-reset.c
 create mode 100644 drivers/clk/actions/owl-reset.h

diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
index dc38c85a4833..04f0a6355726 100644
--- a/drivers/clk/actions/Kconfig
+++ b/drivers/clk/actions/Kconfig
@@ -2,6 +2,7 @@ config CLK_ACTIONS
bool "Clock driver for Actions Semi SoCs"
depends on ARCH_ACTIONS || COMPILE_TEST
select REGMAP_MMIO
+   select RESET_CONTROLLER
default ARCH_ACTIONS
 
 if CLK_ACTIONS
diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
index 78c17d56f991..ccfdf9781cef 100644
--- a/drivers/clk/actions/Makefile
+++ b/drivers/clk/actions/Makefile
@@ -7,6 +7,7 @@ clk-owl-y   += owl-divider.o
 clk-owl-y  += owl-factor.o
 clk-owl-y  += owl-composite.o
 clk-owl-y  += owl-pll.o
+clk-owl-y  += owl-reset.o
 
 # SoC support
 obj-$(CONFIG_CLK_OWL_S700) += owl-s700.o
diff --git a/drivers/clk/actions/owl-common.h b/drivers/clk/actions/owl-common.h
index 56f01f7774aa..5a866a8b913d 100644
--- a/drivers/clk/actions/owl-common.h
+++ b/drivers/clk/actions/owl-common.h
@@ -26,6 +26,8 @@ struct owl_clk_desc {
struct owl_clk_common   **clks;
unsigned long   num_clks;
struct clk_hw_onecell_data  *hw_clks;
+   const struct owl_reset_map  *resets;
+   unsigned long   num_resets;
struct regmap   *regmap;
 };
 
diff --git a/drivers/clk/actions/owl-reset.c b/drivers/clk/actions/owl-reset.c
new file mode 100644
index ..203f8f34a8d4
--- /dev/null
+++ b/drivers/clk/actions/owl-reset.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Actions Semi Owl SoCs Reset Management Unit driver
+//
+// Copyright (c) 2018 Linaro Ltd.
+// Author: Manivannan Sadhasivam 
+
+#include 
+#include 
+#include 
+
+#include "owl-reset.h"
+
+static int owl_reset_assert(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+
+   return regmap_update_bits(reset->regmap, map->reg, map->bit, 0);
+}
+
+static int owl_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+
+   return regmap_update_bits(reset->regmap, map->reg, map->bit, map->bit);
+}
+
+static int owl_reset_reset(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   owl_reset_assert(rcdev, id);
+   udelay(1);
+   owl_reset_deassert(rcdev, id);
+
+   return 0;
+}
+
+static int owl_reset_status(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   struct owl_reset *reset = to_owl_reset(rcdev);
+   const struct owl_reset_map *map = >reset_map[id];
+   u32 reg;
+   int ret;
+
+   ret = regmap_read(reset->regmap, map->reg, );
+   if (ret)
+   return ret;
+
+   /*
+* The reset control API expects 0 if reset is not asserted,
+* which is the opposite of what our hardware uses.
+*/
+   return !(map->bit & reg);
+}
+
+const struct reset_control_ops owl_reset_ops = {
+   .assert = owl_reset_assert,
+   .deassert   = owl_reset_deassert,
+   .reset  = owl_reset_reset,
+   .status = owl_reset_status,
+};
diff --git a/drivers/clk/actions/owl-reset.h b/drivers/clk/actions/owl-reset.h
new file mode 100644
index ..10f5774979a6
--- /dev/null
+++ b/drivers/clk/actions/owl-reset.h
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Actions Semi Owl SoCs Reset Management Unit driver
+//
+// Copyright (c) 2018 Linaro Ltd.
+// Author: Manivannan Sadhasivam 
+
+#ifndef _OWL_RESET_H_
+#define _OWL_RESET_H_
+
+#include 
+
+struct owl_reset_map {
+   u32 reg;
+   u32 bit;
+};
+
+struct owl_reset {
+   struct reset_controller_dev rcdev;
+   const struct owl_reset_map  *reset_map;
+   struct regmap   *regmap;
+};
+
+static inline struct owl_reset *to_owl_reset(struct reset_controller_dev 
*rcdev)
+{
+   return container_of(rcdev, struct owl_reset, rcdev);
+}
+
+extern const struct reset_control_ops owl_reset_ops;
+
+#endif /* _OWL_RESET_H_ */
-- 
2.17.1

[PATCH v3 5/9] arm64: dts: actions: Add Reset Controller support for S700 SoC

[Manivannan Sadhasivam]

Add reset controller property and bindings header for the
Actions Semi S700 SoC DTS.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/actions/s700.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/actions/s700.dtsi 
b/arch/arm64/boot/dts/actions/s700.dtsi
index 59d29e4ca404..30c4c6ea89ea 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "actions,s700";
@@ -165,6 +166,7 @@
reg = <0x0 0xe0168000 0x0 0x1000>;
clocks = <>, <>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
sps: power-controller@e01b0100 {
-- 
2.17.1

[PATCH v3 3/9] dt-bindings: reset: Add binding constants for Actions Semi S700 RMU

[Manivannan Sadhasivam]

Add device tree binding constants for Actions Semi S700 SoC Reset
Management Unit (RMU).

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 .../dt-bindings/reset/actions,s700-reset.h| 34 +++
 1 file changed, 34 insertions(+)
 create mode 100644 include/dt-bindings/reset/actions,s700-reset.h

diff --git a/include/dt-bindings/reset/actions,s700-reset.h 
b/include/dt-bindings/reset/actions,s700-reset.h
new file mode 100644
index ..5e3b16b8ef53
--- /dev/null
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+//
+// Device Tree binding constants for Actions Semi S700 Reset Management Unit
+//
+// Copyright (c) 2018 Linaro Ltd.
+
+#ifndef __DT_BINDINGS_ACTIONS_S700_RESET_H
+#define __DT_BINDINGS_ACTIONS_S700_RESET_H
+
+#define RESET_AUDIO0
+#define RESET_CSI  1
+#define RESET_DE   2
+#define RESET_DSI  3
+#define RESET_GPIO 4
+#define RESET_I2C0 5
+#define RESET_I2C1 6
+#define RESET_I2C2 7
+#define RESET_I2C3 8
+#define RESET_KEY  9
+#define RESET_LCD0 10
+#define RESET_SI   11
+#define RESET_SPI0 12
+#define RESET_SPI1 13
+#define RESET_SPI2 14
+#define RESET_SPI3 15
+#define RESET_UART016
+#define RESET_UART117
+#define RESET_UART218
+#define RESET_UART319
+#define RESET_UART420
+#define RESET_UART521
+#define RESET_UART622
+
+#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
-- 
2.17.1

[PATCH v3 4/9] dt-bindings: reset: Add binding constants for Actions Semi S900 RMU

[Manivannan Sadhasivam]

Add device tree binding constants for Actions Semi S900 SoC Reset
Management Unit (RMU).

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 .../dt-bindings/reset/actions,s900-reset.h| 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 include/dt-bindings/reset/actions,s900-reset.h

diff --git a/include/dt-bindings/reset/actions,s900-reset.h 
b/include/dt-bindings/reset/actions,s900-reset.h
new file mode 100644
index ..42c19d02e43b
--- /dev/null
+++ b/include/dt-bindings/reset/actions,s900-reset.h
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+//
+// Device Tree binding constants for Actions Semi S900 Reset Management Unit
+//
+// Copyright (c) 2018 Linaro Ltd.
+
+#ifndef __DT_BINDINGS_ACTIONS_S900_RESET_H
+#define __DT_BINDINGS_ACTIONS_S900_RESET_H
+
+#define RESET_CHIPID   0
+#define RESET_CPU_SCNT 1
+#define RESET_SRAMI2
+#define RESET_DDR_CTL_PHY  3
+#define RESET_DMAC 4
+#define RESET_GPIO 5
+#define RESET_BISP_AXI 6
+#define RESET_CSI0 7
+#define RESET_CSI1 8
+#define RESET_DE   9
+#define RESET_DSI  10
+#define RESET_GPU3D_PA 11
+#define RESET_GPU3D_PB 12
+#define RESET_HDE  13
+#define RESET_I2C0 14
+#define RESET_I2C1 15
+#define RESET_I2C2 16
+#define RESET_I2C3 17
+#define RESET_I2C4 18
+#define RESET_I2C5 19
+#define RESET_IMX  20
+#define RESET_NANDC0   21
+#define RESET_NANDC1   22
+#define RESET_SD0  23
+#define RESET_SD1  24
+#define RESET_SD2  25
+#define RESET_SD3  26
+#define RESET_SPI0 27
+#define RESET_SPI1 28
+#define RESET_SPI2 29
+#define RESET_SPI3 30
+#define RESET_UART031
+#define RESET_UART132
+#define RESET_UART233
+#define RESET_UART334
+#define RESET_UART435
+#define RESET_UART536
+#define RESET_UART637
+#define RESET_HDMI 38
+#define RESET_LVDS 39
+#define RESET_EDP  40
+#define RESET_USB2HUB  41
+#define RESET_USB2HSIC 42
+#define RESET_USB3 43
+#define RESET_PCM1 44
+#define RESET_AUDIO45
+#define RESET_PCM0 46
+#define RESET_SE   47
+#define RESET_GIC  48
+#define RESET_DDR_CTL_PHY_AXI  49
+#define RESET_CMU_DDR  50
+#define RESET_DMM  51
+#define RESET_HDCP2TX  52
+#define RESET_ETHERNET 53
+
+#endif /* __DT_BINDINGS_ACTIONS_S900_RESET_H */
-- 
2.17.1

[PATCH v3 4/9] dt-bindings: reset: Add binding constants for Actions Semi S900 RMU

[Manivannan Sadhasivam]

Add device tree binding constants for Actions Semi S900 SoC Reset
Management Unit (RMU).

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 .../dt-bindings/reset/actions,s900-reset.h| 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 include/dt-bindings/reset/actions,s900-reset.h

diff --git a/include/dt-bindings/reset/actions,s900-reset.h 
b/include/dt-bindings/reset/actions,s900-reset.h
new file mode 100644
index ..42c19d02e43b
--- /dev/null
+++ b/include/dt-bindings/reset/actions,s900-reset.h
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+//
+// Device Tree binding constants for Actions Semi S900 Reset Management Unit
+//
+// Copyright (c) 2018 Linaro Ltd.
+
+#ifndef __DT_BINDINGS_ACTIONS_S900_RESET_H
+#define __DT_BINDINGS_ACTIONS_S900_RESET_H
+
+#define RESET_CHIPID   0
+#define RESET_CPU_SCNT 1
+#define RESET_SRAMI2
+#define RESET_DDR_CTL_PHY  3
+#define RESET_DMAC 4
+#define RESET_GPIO 5
+#define RESET_BISP_AXI 6
+#define RESET_CSI0 7
+#define RESET_CSI1 8
+#define RESET_DE   9
+#define RESET_DSI  10
+#define RESET_GPU3D_PA 11
+#define RESET_GPU3D_PB 12
+#define RESET_HDE  13
+#define RESET_I2C0 14
+#define RESET_I2C1 15
+#define RESET_I2C2 16
+#define RESET_I2C3 17
+#define RESET_I2C4 18
+#define RESET_I2C5 19
+#define RESET_IMX  20
+#define RESET_NANDC0   21
+#define RESET_NANDC1   22
+#define RESET_SD0  23
+#define RESET_SD1  24
+#define RESET_SD2  25
+#define RESET_SD3  26
+#define RESET_SPI0 27
+#define RESET_SPI1 28
+#define RESET_SPI2 29
+#define RESET_SPI3 30
+#define RESET_UART031
+#define RESET_UART132
+#define RESET_UART233
+#define RESET_UART334
+#define RESET_UART435
+#define RESET_UART536
+#define RESET_UART637
+#define RESET_HDMI 38
+#define RESET_LVDS 39
+#define RESET_EDP  40
+#define RESET_USB2HUB  41
+#define RESET_USB2HSIC 42
+#define RESET_USB3 43
+#define RESET_PCM1 44
+#define RESET_AUDIO45
+#define RESET_PCM0 46
+#define RESET_SE   47
+#define RESET_GIC  48
+#define RESET_DDR_CTL_PHY_AXI  49
+#define RESET_CMU_DDR  50
+#define RESET_DMM  51
+#define RESET_HDCP2TX  52
+#define RESET_ETHERNET 53
+
+#endif /* __DT_BINDINGS_ACTIONS_S900_RESET_H */
-- 
2.17.1

[PATCH v3 2/9] dt-bindings: clock: Add reset controller bindings for Actions Semi Owl SoCs

[Manivannan Sadhasivam]

Add Reset Controller bindings to clock bindings for Actions Semi Owl
SoCs, S700 and S900.

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/actions,owl-cmu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt 
b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
index d1e60d297387..2ef86ae96df8 100644
--- a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
+++ b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
@@ -13,6 +13,7 @@ Required Properties:
   region.
 - clocks: Reference to the parent clocks ("hosc", "losc")
 - #clock-cells: should be 1.
+- #reset-cells: should be 1.
 
 Each clock is assigned an identifier, and client nodes can use this identifier
 to specify the clock which they consume.
@@ -36,6 +37,7 @@ Example: Clock Management Unit node:
 reg = <0x0 0xe016 0x0 0x1000>;
 clocks = <>, <>;
 #clock-cells = <1>;
+#reset-cells = <1>;
 };
 
 Example: UART controller node that consumes clock generated by the clock
-- 
2.17.1

[PATCH v3 1/9] clk: actions: Cache regmap info in private clock descriptor

[Manivannan Sadhasivam]

In order to support the reset controller, regmap info needs to
be cached in the private clock descriptor, owl_clk_desc. Hence,
save that and also make the clock descriptor struct non const.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/owl-common.c | 3 ++-
 drivers/clk/actions/owl-common.h | 3 ++-
 drivers/clk/actions/owl-s700.c   | 4 ++--
 drivers/clk/actions/owl-s900.c   | 4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/actions/owl-common.c b/drivers/clk/actions/owl-common.c
index 61c1071b5180..32dd29e0a37e 100644
--- a/drivers/clk/actions/owl-common.c
+++ b/drivers/clk/actions/owl-common.c
@@ -39,7 +39,7 @@ static void owl_clk_set_regmap(const struct owl_clk_desc 
*desc,
 }
 
 int owl_clk_regmap_init(struct platform_device *pdev,
-const struct owl_clk_desc *desc)
+   struct owl_clk_desc *desc)
 {
void __iomem *base;
struct regmap *regmap;
@@ -57,6 +57,7 @@ int owl_clk_regmap_init(struct platform_device *pdev,
}
 
owl_clk_set_regmap(desc, regmap);
+   desc->regmap = regmap;
 
return 0;
 }
diff --git a/drivers/clk/actions/owl-common.h b/drivers/clk/actions/owl-common.h
index 4fd726ec54a6..56f01f7774aa 100644
--- a/drivers/clk/actions/owl-common.h
+++ b/drivers/clk/actions/owl-common.h
@@ -26,6 +26,7 @@ struct owl_clk_desc {
struct owl_clk_common   **clks;
unsigned long   num_clks;
struct clk_hw_onecell_data  *hw_clks;
+   struct regmap   *regmap;
 };
 
 static inline struct owl_clk_common *
@@ -35,7 +36,7 @@ static inline struct owl_clk_common *
 }
 
 int owl_clk_regmap_init(struct platform_device *pdev,
-const struct owl_clk_desc *desc);
+   struct owl_clk_desc *desc);
 int owl_clk_probe(struct device *dev, struct clk_hw_onecell_data *hw_clks);
 
 #endif /* _OWL_COMMON_H_ */
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
index 5e9531392ee5..e7cacd677275 100644
--- a/drivers/clk/actions/owl-s700.c
+++ b/drivers/clk/actions/owl-s700.c
@@ -569,7 +569,7 @@ static struct clk_hw_onecell_data s700_hw_clks = {
.num= CLK_NR_CLKS,
 };
 
-static const struct owl_clk_desc s700_clk_desc = {
+static struct owl_clk_desc s700_clk_desc = {
.clks   = s700_clks,
.num_clks   = ARRAY_SIZE(s700_clks),
 
@@ -578,7 +578,7 @@ static const struct owl_clk_desc s700_clk_desc = {
 
 static int s700_clk_probe(struct platform_device *pdev)
 {
-   const struct owl_clk_desc *desc;
+   struct owl_clk_desc *desc;
 
desc = _clk_desc;
owl_clk_regmap_init(pdev, desc);
diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
index 7f60ed6afe63..bb7ee872d316 100644
--- a/drivers/clk/actions/owl-s900.c
+++ b/drivers/clk/actions/owl-s900.c
@@ -684,7 +684,7 @@ static struct clk_hw_onecell_data s900_hw_clks = {
.num= CLK_NR_CLKS,
 };
 
-static const struct owl_clk_desc s900_clk_desc = {
+static struct owl_clk_desc s900_clk_desc = {
.clks   = s900_clks,
.num_clks   = ARRAY_SIZE(s900_clks),
 
@@ -693,7 +693,7 @@ static const struct owl_clk_desc s900_clk_desc = {
 
 static int s900_clk_probe(struct platform_device *pdev)
 {
-   const struct owl_clk_desc *desc;
+   struct owl_clk_desc *desc;
 
desc = _clk_desc;
owl_clk_regmap_init(pdev, desc);
-- 
2.17.1

[PATCH v3 2/9] dt-bindings: clock: Add reset controller bindings for Actions Semi Owl SoCs

[Manivannan Sadhasivam]

Add Reset Controller bindings to clock bindings for Actions Semi Owl
SoCs, S700 and S900.

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/actions,owl-cmu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt 
b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
index d1e60d297387..2ef86ae96df8 100644
--- a/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
+++ b/Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
@@ -13,6 +13,7 @@ Required Properties:
   region.
 - clocks: Reference to the parent clocks ("hosc", "losc")
 - #clock-cells: should be 1.
+- #reset-cells: should be 1.
 
 Each clock is assigned an identifier, and client nodes can use this identifier
 to specify the clock which they consume.
@@ -36,6 +37,7 @@ Example: Clock Management Unit node:
 reg = <0x0 0xe016 0x0 0x1000>;
 clocks = <>, <>;
 #clock-cells = <1>;
+#reset-cells = <1>;
 };
 
 Example: UART controller node that consumes clock generated by the clock
-- 
2.17.1

[PATCH v3 1/9] clk: actions: Cache regmap info in private clock descriptor

[Manivannan Sadhasivam]

In order to support the reset controller, regmap info needs to
be cached in the private clock descriptor, owl_clk_desc. Hence,
save that and also make the clock descriptor struct non const.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/clk/actions/owl-common.c | 3 ++-
 drivers/clk/actions/owl-common.h | 3 ++-
 drivers/clk/actions/owl-s700.c   | 4 ++--
 drivers/clk/actions/owl-s900.c   | 4 ++--
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/actions/owl-common.c b/drivers/clk/actions/owl-common.c
index 61c1071b5180..32dd29e0a37e 100644
--- a/drivers/clk/actions/owl-common.c
+++ b/drivers/clk/actions/owl-common.c
@@ -39,7 +39,7 @@ static void owl_clk_set_regmap(const struct owl_clk_desc 
*desc,
 }
 
 int owl_clk_regmap_init(struct platform_device *pdev,
-const struct owl_clk_desc *desc)
+   struct owl_clk_desc *desc)
 {
void __iomem *base;
struct regmap *regmap;
@@ -57,6 +57,7 @@ int owl_clk_regmap_init(struct platform_device *pdev,
}
 
owl_clk_set_regmap(desc, regmap);
+   desc->regmap = regmap;
 
return 0;
 }
diff --git a/drivers/clk/actions/owl-common.h b/drivers/clk/actions/owl-common.h
index 4fd726ec54a6..56f01f7774aa 100644
--- a/drivers/clk/actions/owl-common.h
+++ b/drivers/clk/actions/owl-common.h
@@ -26,6 +26,7 @@ struct owl_clk_desc {
struct owl_clk_common   **clks;
unsigned long   num_clks;
struct clk_hw_onecell_data  *hw_clks;
+   struct regmap   *regmap;
 };
 
 static inline struct owl_clk_common *
@@ -35,7 +36,7 @@ static inline struct owl_clk_common *
 }
 
 int owl_clk_regmap_init(struct platform_device *pdev,
-const struct owl_clk_desc *desc);
+   struct owl_clk_desc *desc);
 int owl_clk_probe(struct device *dev, struct clk_hw_onecell_data *hw_clks);
 
 #endif /* _OWL_COMMON_H_ */
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
index 5e9531392ee5..e7cacd677275 100644
--- a/drivers/clk/actions/owl-s700.c
+++ b/drivers/clk/actions/owl-s700.c
@@ -569,7 +569,7 @@ static struct clk_hw_onecell_data s700_hw_clks = {
.num= CLK_NR_CLKS,
 };
 
-static const struct owl_clk_desc s700_clk_desc = {
+static struct owl_clk_desc s700_clk_desc = {
.clks   = s700_clks,
.num_clks   = ARRAY_SIZE(s700_clks),
 
@@ -578,7 +578,7 @@ static const struct owl_clk_desc s700_clk_desc = {
 
 static int s700_clk_probe(struct platform_device *pdev)
 {
-   const struct owl_clk_desc *desc;
+   struct owl_clk_desc *desc;
 
desc = _clk_desc;
owl_clk_regmap_init(pdev, desc);
diff --git a/drivers/clk/actions/owl-s900.c b/drivers/clk/actions/owl-s900.c
index 7f60ed6afe63..bb7ee872d316 100644
--- a/drivers/clk/actions/owl-s900.c
+++ b/drivers/clk/actions/owl-s900.c
@@ -684,7 +684,7 @@ static struct clk_hw_onecell_data s900_hw_clks = {
.num= CLK_NR_CLKS,
 };
 
-static const struct owl_clk_desc s900_clk_desc = {
+static struct owl_clk_desc s900_clk_desc = {
.clks   = s900_clks,
.num_clks   = ARRAY_SIZE(s900_clks),
 
@@ -693,7 +693,7 @@ static const struct owl_clk_desc s900_clk_desc = {
 
 static int s900_clk_probe(struct platform_device *pdev)
 {
-   const struct owl_clk_desc *desc;
+   struct owl_clk_desc *desc;
 
desc = _clk_desc;
owl_clk_regmap_init(pdev, desc);
-- 
2.17.1

[PATCH v3 0/9] Add Reset Controller support for Actions Semi Owl SoCs

[Manivannan Sadhasivam]

This patchset adds Reset Controller (RMU) support for Actions Semi
Owl SoCs, S900 and S700. For the Owl SoCs, RMU has been integrated into
the clock subsystem in hardware. Hence, in software we integrate RMU
support into common clock driver inorder to maintain compatibility. The
syscon approach is not taken into account based on the review by Rob.

This patch series depends on the recently posted S700 clk series:
"[PATCH v7 0/5] Add clock driver for Actions S700 SoC". For the S700 clk
series, driver and bindings patches are applied through the clk tree.
But the DTS patches are not yet picked up by the platform maintainer,
Andreas.

Hence, Andreas is expected to pick the DTS patches in this series once
reviewed by the maintainers along with S700 clk DTS patches.

Because of the absence of the S500 SoC clk support, the reset controller
registration code is added to both S700 and S900 SoC clk drivers for now.
But once S500 clk support is added, the reset controller registration part
will be moved to Owl SoCs common clk code.

Thanks,
Mani

Changes in v3:

* Reverted back the syscon approach based on the review by Rob Herring
* Dropped the MAINTAINERS patch
* Converted reset_map struct definitions to const based on the review by
  Philipp
* Fixed S700 header in DT spotted by Parthiban
* Added Reviewed-by tags from Rob for 3 bindings patches

Changes in v2:

* Converted the CMU and RMU drivers to syscon for a more cleaner
  approach
* Declared the owl_reset_map structs to const
* Used regmap_update_bits instead of a combined regmap_read and write
* Removed unused headers in RMU drivers
* Added MAINTAINERS entry for the RMU driver and bindings

Manivannan Sadhasivam (9):
  clk: actions: Cache regmap info in private clock descriptor
  dt-bindings: clock: Add reset controller bindings for Actions Semi Owl
SoCs
  dt-bindings: reset: Add binding constants for Actions Semi S700 RMU
  dt-bindings: reset: Add binding constants for Actions Semi S900 RMU
  arm64: dts: actions: Add Reset Controller support for S700 SoC
  arm64: dts: actions: Add Reset Controller support for S900 SoC
  clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support
  clk: actions: Add Actions Semi S700 SoC Reset Management Unit support
  clk: actions: Add Actions Semi S900 SoC Reset Management Unit support

 .../bindings/clock/actions,owl-cmu.txt|  2 +
 arch/arm64/boot/dts/actions/s700.dtsi |  2 +
 arch/arm64/boot/dts/actions/s900.dtsi |  2 +
 drivers/clk/actions/Kconfig   |  1 +
 drivers/clk/actions/Makefile  |  1 +
 drivers/clk/actions/owl-common.c  |  3 +-
 drivers/clk/actions/owl-common.h  |  5 +-
 drivers/clk/actions/owl-reset.c   | 66 ++
 drivers/clk/actions/owl-reset.h   | 31 +++
 drivers/clk/actions/owl-s700.c| 55 +++-
 drivers/clk/actions/owl-s900.c| 86 ++-
 .../dt-bindings/reset/actions,s700-reset.h| 34 
 .../dt-bindings/reset/actions,s900-reset.h| 65 ++
 13 files changed, 347 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/actions/owl-reset.c
 create mode 100644 drivers/clk/actions/owl-reset.h
 create mode 100644 include/dt-bindings/reset/actions,s700-reset.h
 create mode 100644 include/dt-bindings/reset/actions,s900-reset.h

-- 
2.17.1

[PATCH v3 0/9] Add Reset Controller support for Actions Semi Owl SoCs

[Manivannan Sadhasivam]

This patchset adds Reset Controller (RMU) support for Actions Semi
Owl SoCs, S900 and S700. For the Owl SoCs, RMU has been integrated into
the clock subsystem in hardware. Hence, in software we integrate RMU
support into common clock driver inorder to maintain compatibility. The
syscon approach is not taken into account based on the review by Rob.

This patch series depends on the recently posted S700 clk series:
"[PATCH v7 0/5] Add clock driver for Actions S700 SoC". For the S700 clk
series, driver and bindings patches are applied through the clk tree.
But the DTS patches are not yet picked up by the platform maintainer,
Andreas.

Hence, Andreas is expected to pick the DTS patches in this series once
reviewed by the maintainers along with S700 clk DTS patches.

Because of the absence of the S500 SoC clk support, the reset controller
registration code is added to both S700 and S900 SoC clk drivers for now.
But once S500 clk support is added, the reset controller registration part
will be moved to Owl SoCs common clk code.

Thanks,
Mani

Changes in v3:

* Reverted back the syscon approach based on the review by Rob Herring
* Dropped the MAINTAINERS patch
* Converted reset_map struct definitions to const based on the review by
  Philipp
* Fixed S700 header in DT spotted by Parthiban
* Added Reviewed-by tags from Rob for 3 bindings patches

Changes in v2:

* Converted the CMU and RMU drivers to syscon for a more cleaner
  approach
* Declared the owl_reset_map structs to const
* Used regmap_update_bits instead of a combined regmap_read and write
* Removed unused headers in RMU drivers
* Added MAINTAINERS entry for the RMU driver and bindings

Manivannan Sadhasivam (9):
  clk: actions: Cache regmap info in private clock descriptor
  dt-bindings: clock: Add reset controller bindings for Actions Semi Owl
SoCs
  dt-bindings: reset: Add binding constants for Actions Semi S700 RMU
  dt-bindings: reset: Add binding constants for Actions Semi S900 RMU
  arm64: dts: actions: Add Reset Controller support for S700 SoC
  arm64: dts: actions: Add Reset Controller support for S900 SoC
  clk: actions: Add Actions Semi Owl SoCs Reset Management Unit support
  clk: actions: Add Actions Semi S700 SoC Reset Management Unit support
  clk: actions: Add Actions Semi S900 SoC Reset Management Unit support

 .../bindings/clock/actions,owl-cmu.txt|  2 +
 arch/arm64/boot/dts/actions/s700.dtsi |  2 +
 arch/arm64/boot/dts/actions/s900.dtsi |  2 +
 drivers/clk/actions/Kconfig   |  1 +
 drivers/clk/actions/Makefile  |  1 +
 drivers/clk/actions/owl-common.c  |  3 +-
 drivers/clk/actions/owl-common.h  |  5 +-
 drivers/clk/actions/owl-reset.c   | 66 ++
 drivers/clk/actions/owl-reset.h   | 31 +++
 drivers/clk/actions/owl-s700.c| 55 +++-
 drivers/clk/actions/owl-s900.c| 86 ++-
 .../dt-bindings/reset/actions,s700-reset.h| 34 
 .../dt-bindings/reset/actions,s900-reset.h| 65 ++
 13 files changed, 347 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clk/actions/owl-reset.c
 create mode 100644 drivers/clk/actions/owl-reset.h
 create mode 100644 include/dt-bindings/reset/actions,s700-reset.h
 create mode 100644 include/dt-bindings/reset/actions,s900-reset.h

-- 
2.17.1

Re: [PATCH v2 5/5] staging: rtl8188eu: use phydm_reg.h from rtlwifi

[Dan Carpenter]

Looks good.  Thanks!  I reviewed the series.

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

Re: [PATCH v2 5/5] staging: rtl8188eu: use phydm_reg.h from rtlwifi

[Dan Carpenter]

Looks good.  Thanks!  I reviewed the series.

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

[PATCH] ASoC: core: add support to card rebind

[Srinivas Kandagatla]

Current behaviour of ASoC core w.r.t to component removal is that it
unregisters dependent sound card totally. There is no support to
rebind the card if the component comes back.
Typical use case is DSP restart or kernel modules itself.

With this patch, core now maintains list of cards that are unbind due to
any of its depended components are removed and card not unregistered yet.
This list is cleared when the card is rebind successfully or when the
card is unregistered from machine driver.

This list of unbind cards are tried to bind once again after every new
component is successfully added, giving a fair chance for card bind
to be successful.

Signed-off-by: Srinivas Kandagatla 
---
Hi Mark,

This time I tried doing this without component framework, by maintaining
list of ubind card in ASoC core that are still not unregistered.
This list is tried to bind for every successful add of component.
It looks much better than the component framework one!

thanks,
srini

 include/sound/soc.h  |  2 ++
 sound/soc/soc-core.c | 86 ++--
 2 files changed, 61 insertions(+), 27 deletions(-)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index a4915148f739..d9a8aea213cf 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1092,6 +1092,7 @@ struct snd_soc_card {
 
/* lists of probed devices belonging to this card */
struct list_head component_dev_list;
+   struct list_head list;
 
struct list_head widgets;
struct list_head paths;
@@ -1359,6 +1360,7 @@ static inline void snd_soc_initialize_card_lists(struct 
snd_soc_card *card)
INIT_LIST_HEAD(>dapm_list);
INIT_LIST_HEAD(>aux_comp_list);
INIT_LIST_HEAD(>component_dev_list);
+   INIT_LIST_HEAD(>list);
 }
 
 static inline bool snd_soc_volsw_is_stereo(struct soc_mixer_control *mc)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 6d33634b934b..795796978fc8 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL_GPL(snd_soc_debugfs_root);
 
 static DEFINE_MUTEX(client_mutex);
 static LIST_HEAD(component_list);
+static LIST_HEAD(unbind_card_list);
 
 /*
  * This is a timeout to do a DAPM powerdown after a stream is closed().
@@ -2678,6 +2679,34 @@ int snd_soc_dai_digital_mute(struct snd_soc_dai *dai, 
int mute,
 }
 EXPORT_SYMBOL_GPL(snd_soc_dai_digital_mute);
 
+static int snd_soc_bind_card(struct snd_soc_card *card)
+{
+   struct snd_soc_pcm_runtime *rtd;
+   int ret;
+
+   ret = snd_soc_instantiate_card(card);
+   if (ret != 0)
+   return ret;
+
+   /* deactivate pins to sleep state */
+   list_for_each_entry(rtd, >rtd_list, list)  {
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   int j;
+
+   for (j = 0; j < rtd->num_codecs; j++) {
+   struct snd_soc_dai *codec_dai = rtd->codec_dais[j];
+
+   if (!codec_dai->active)
+   pinctrl_pm_select_sleep_state(codec_dai->dev);
+   }
+
+   if (!cpu_dai->active)
+   pinctrl_pm_select_sleep_state(cpu_dai->dev);
+   }
+
+   return ret;
+}
+
 /**
  * snd_soc_register_card - Register a card with the ASoC core
  *
@@ -2687,7 +2716,6 @@ EXPORT_SYMBOL_GPL(snd_soc_dai_digital_mute);
 int snd_soc_register_card(struct snd_soc_card *card)
 {
int i, ret;
-   struct snd_soc_pcm_runtime *rtd;
 
if (!card->name || !card->dev)
return -EINVAL;
@@ -2719,28 +2747,23 @@ int snd_soc_register_card(struct snd_soc_card *card)
mutex_init(>mutex);
mutex_init(>dapm_mutex);
 
-   ret = snd_soc_instantiate_card(card);
-   if (ret != 0)
-   return ret;
-
-   /* deactivate pins to sleep state */
-   list_for_each_entry(rtd, >rtd_list, list)  {
-   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
-   int j;
-
-   for (j = 0; j < rtd->num_codecs; j++) {
-   struct snd_soc_dai *codec_dai = rtd->codec_dais[j];
-   if (!codec_dai->active)
-   pinctrl_pm_select_sleep_state(codec_dai->dev);
-   }
+   return snd_soc_bind_card(card);
+}
+EXPORT_SYMBOL_GPL(snd_soc_register_card);
 
-   if (!cpu_dai->active)
-   pinctrl_pm_select_sleep_state(cpu_dai->dev);
+static void snd_soc_unbind_card(struct snd_soc_card *card, bool unregister)
+{
+   if (card->instantiated) {
+   card->instantiated = false;
+   snd_soc_dapm_shutdown(card);
+   soc_cleanup_card_resources(card);
+   if (!unregister)
+   list_add(>list, _card_list);
+   } else {
+   if (unregister)
+   list_del(>list);
}
-
-   return ret;
 }
-EXPORT_SYMBOL_GPL(snd_soc_register_card);
 
 /**
  * snd_soc_unregister_card - 

[PATCH] ASoC: core: add support to card rebind

[Srinivas Kandagatla]

Current behaviour of ASoC core w.r.t to component removal is that it
unregisters dependent sound card totally. There is no support to
rebind the card if the component comes back.
Typical use case is DSP restart or kernel modules itself.

With this patch, core now maintains list of cards that are unbind due to
any of its depended components are removed and card not unregistered yet.
This list is cleared when the card is rebind successfully or when the
card is unregistered from machine driver.

This list of unbind cards are tried to bind once again after every new
component is successfully added, giving a fair chance for card bind
to be successful.

Signed-off-by: Srinivas Kandagatla 
---
Hi Mark,

This time I tried doing this without component framework, by maintaining
list of ubind card in ASoC core that are still not unregistered.
This list is tried to bind for every successful add of component.
It looks much better than the component framework one!

thanks,
srini

 include/sound/soc.h  |  2 ++
 sound/soc/soc-core.c | 86 ++--
 2 files changed, 61 insertions(+), 27 deletions(-)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index a4915148f739..d9a8aea213cf 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1092,6 +1092,7 @@ struct snd_soc_card {
 
/* lists of probed devices belonging to this card */
struct list_head component_dev_list;
+   struct list_head list;
 
struct list_head widgets;
struct list_head paths;
@@ -1359,6 +1360,7 @@ static inline void snd_soc_initialize_card_lists(struct 
snd_soc_card *card)
INIT_LIST_HEAD(>dapm_list);
INIT_LIST_HEAD(>aux_comp_list);
INIT_LIST_HEAD(>component_dev_list);
+   INIT_LIST_HEAD(>list);
 }
 
 static inline bool snd_soc_volsw_is_stereo(struct soc_mixer_control *mc)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 6d33634b934b..795796978fc8 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -52,6 +52,7 @@ EXPORT_SYMBOL_GPL(snd_soc_debugfs_root);
 
 static DEFINE_MUTEX(client_mutex);
 static LIST_HEAD(component_list);
+static LIST_HEAD(unbind_card_list);
 
 /*
  * This is a timeout to do a DAPM powerdown after a stream is closed().
@@ -2678,6 +2679,34 @@ int snd_soc_dai_digital_mute(struct snd_soc_dai *dai, 
int mute,
 }
 EXPORT_SYMBOL_GPL(snd_soc_dai_digital_mute);
 
+static int snd_soc_bind_card(struct snd_soc_card *card)
+{
+   struct snd_soc_pcm_runtime *rtd;
+   int ret;
+
+   ret = snd_soc_instantiate_card(card);
+   if (ret != 0)
+   return ret;
+
+   /* deactivate pins to sleep state */
+   list_for_each_entry(rtd, >rtd_list, list)  {
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+   int j;
+
+   for (j = 0; j < rtd->num_codecs; j++) {
+   struct snd_soc_dai *codec_dai = rtd->codec_dais[j];
+
+   if (!codec_dai->active)
+   pinctrl_pm_select_sleep_state(codec_dai->dev);
+   }
+
+   if (!cpu_dai->active)
+   pinctrl_pm_select_sleep_state(cpu_dai->dev);
+   }
+
+   return ret;
+}
+
 /**
  * snd_soc_register_card - Register a card with the ASoC core
  *
@@ -2687,7 +2716,6 @@ EXPORT_SYMBOL_GPL(snd_soc_dai_digital_mute);
 int snd_soc_register_card(struct snd_soc_card *card)
 {
int i, ret;
-   struct snd_soc_pcm_runtime *rtd;
 
if (!card->name || !card->dev)
return -EINVAL;
@@ -2719,28 +2747,23 @@ int snd_soc_register_card(struct snd_soc_card *card)
mutex_init(>mutex);
mutex_init(>dapm_mutex);
 
-   ret = snd_soc_instantiate_card(card);
-   if (ret != 0)
-   return ret;
-
-   /* deactivate pins to sleep state */
-   list_for_each_entry(rtd, >rtd_list, list)  {
-   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
-   int j;
-
-   for (j = 0; j < rtd->num_codecs; j++) {
-   struct snd_soc_dai *codec_dai = rtd->codec_dais[j];
-   if (!codec_dai->active)
-   pinctrl_pm_select_sleep_state(codec_dai->dev);
-   }
+   return snd_soc_bind_card(card);
+}
+EXPORT_SYMBOL_GPL(snd_soc_register_card);
 
-   if (!cpu_dai->active)
-   pinctrl_pm_select_sleep_state(cpu_dai->dev);
+static void snd_soc_unbind_card(struct snd_soc_card *card, bool unregister)
+{
+   if (card->instantiated) {
+   card->instantiated = false;
+   snd_soc_dapm_shutdown(card);
+   soc_cleanup_card_resources(card);
+   if (!unregister)
+   list_add(>list, _card_list);
+   } else {
+   if (unregister)
+   list_del(>list);
}
-
-   return ret;
 }
-EXPORT_SYMBOL_GPL(snd_soc_register_card);
 
 /**
  * snd_soc_unregister_card - 

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Harald Freudenberger]

On 10.08.2018 10:49, Cornelia Huck wrote:
> On Thu, 9 Aug 2018 12:06:56 -0400
> Tony Krowiak  wrote:
>
>> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
>>> On 09.08.2018 11:06, Cornelia Huck wrote:  
 On Wed,  8 Aug 2018 10:44:14 -0400
 Tony Krowiak  wrote:
  
> From: Harald Freudenberger 
>
> Move all the inline functions from the ap bus header
> file ap_asm.h into the in-kernel api header file
> arch/s390/include/asm/ap.h so that KVM can make use
> of all the low level AP functions.
>
> Signed-off-by: Harald Freudenberger 
> Signed-off-by: Christian Borntraeger   
 You should add your own s-o-b if you are sending on patches written by
 others (even if it does not matter in the end, when they are merged
 through a different path anyway.)
  
> ---
>   arch/s390/include/asm/ap.h |  284 
> 
>   drivers/s390/crypto/ap_asm.h   |  261 
> 
>   drivers/s390/crypto/ap_bus.c   |   21 +---
>   drivers/s390/crypto/ap_bus.h   |1 +
>   drivers/s390/crypto/ap_card.c  |1 -
>   drivers/s390/crypto/ap_queue.c |1 -
>   6 files changed, 259 insertions(+), 310 deletions(-)
>   delete mode 100644 drivers/s390/crypto/ap_asm.h
>
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index c1bedb4..046e044 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -47,6 +47,50 @@ struct ap_queue_status {
>   };
>   
>   /**
> + * ap_intructions_available() - Test if AP instructions are available.
> + *
> + * Returns 0 if the AP instructions are installed.  
 Stumbled over this when I was looking at the usage in patch 7: if I see
 a function called '_available' return 0, I'd assume that whatever the
 function tests for is *not* available.

 Rather call this function ap_instructions_check_availability() (and
 keep the return code convention), or switch this to return 0 if not
 available and !0 if available?  
>>> Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
>>> are available and 0 if not. However, this patch will come via Martin's pipe
>>> to the Linus Torwald kernel sources.  
>> Is your intent to simply indicate whether the AP instructions are 
>> available or
>> not; or is the intention to indicate whether the AP instructions are 
>> available
>> and if not, they why? In the former, then I agree that a boolean should be
>> returned; however, if the case is the latter, then what you have is fine but
>> maybe the function name should be changed as Connie suggests.
> So, can this actually fail for any reason other than "instructions not
> installed"? Even if it did, the end result is that the instructions are
> not usable -- I don't think the "why" would be interesting at that
> point.
I can not think of any other reason why the PQAP(TAPQ) would fail
other than the AP instructions are not available at all. However,
the old implementation returned -ENODEV on failure and 0 on
success. The new implementation now returns 1 for success
and 0 for failure. This is just one of a couple of functions related
to ap xxx available. I'll rework them all to return a boolean value
soon.
>
> + */
> +static inline int ap_instructions_available(void)
> +{
> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> + register unsigned long reg1 asm ("1") = -ENODEV;
> + register unsigned long reg2 asm ("2");
> +
> + asm volatile(
> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> + "0: la%0,0\n"
> + "1:\n"
> + EX_TABLE(0b, 1b)
> + : "+d" (reg1), "=d" (reg2)
> + : "d" (reg0)
> + : "cc");
> + return reg1;
> +}  

Re: [PATCH] hid: microsoft: Add rumble support for Xbox One S controller

[Benjamin Tissoires]

Hi Andrew,

On Fri, Aug 10, 2018 at 2:17 AM Andrey Smirnov  wrote:
>
> Add HID quirk driver for Xbox One S controller over bluetooth.
>
> This driver only adds support for rumble. Standard controller
> functionality is exposed by default HID driver.
>
> Cc: Dmitry Torokhov 
> Cc: Jiri Kosina 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Pierre-Loup A. Griffais 
> Signed-off-by: Juha Kuikka 
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/hid/Kconfig |   8 ++
>  drivers/hid/hid-ids.h   |   1 +
>  drivers/hid/hid-microsoft.c | 142 ++--
>  drivers/hid/hid-quirks.c|   1 +
>  4 files changed, 147 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a49a10437c40..b2e983cb32f0 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -589,6 +589,14 @@ config HID_MICROSOFT
> ---help---
> Support for Microsoft devices that are not fully compliant with HID 
> standard.
>
> +config MICROSOFT_FF
> +   bool "Microsoft Xbox One S controller force feedback support"
> +   depends on HID_MICROSOFT
> +   select INPUT_FF_MEMLESS
> +   ---help---
> +   Say Y here if you have a Microsoft Xbox One S controller and want to 
> enable
> +   force feedback support for it.
> +

Is there really a need to have a kernel that doesn't enable FF on
those particular devices?
It adds a lot of #ifdefs in the code and I would think users want it
enabled by default.

>  config HID_MONTEREY
> tristate "Monterey Genius KB29E keyboard"
> depends on HID
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c7981ddd8776..c8b4bc7fe053 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -798,6 +798,7 @@
>  #define USB_DEVICE_ID_MS_TOUCH_COVER_2   0x07a7
>  #define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
>  #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
> +#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
>
>  #define USB_VENDOR_ID_MOJO 0x8282
>  #define USB_DEVICE_ID_RETRO_ADAPTER0x3201
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 96e7d3231d2f..e2bd31d54e62 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -29,10 +29,29 @@
>  #define MS_NOGET   0x10
>  #define MS_DUPLICATE_USAGES0x20
>
> +struct ms_data {
> +   unsigned long quirks;
> +   struct hid_device *hdev;
> +   struct work_struct ff_worker;
> +   __u8 strong;
> +   __u8 weak;
> +   __u8 *output_report_dmabuf;
> +};
> +
> +struct xb1s_ff_report {
> +   __u8report_id;
> +   __u8enable;
> +   __u8magnitude[4];
> +   __u8duration_10ms;
> +   __u8start_delay_10ms;
> +   __u8loop_count;
> +};
> +
>  static __u8 *ms_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> unsigned int *rsize)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
>
> /*
>  * Microsoft Wireless Desktop Receiver (Model 1028) has
> @@ -134,7 +153,8 @@ static int ms_input_mapping(struct hid_device *hdev, 
> struct hid_input *hi,
> struct hid_field *field, struct hid_usage *usage,
> unsigned long **bit, int *max)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;

Could you split the change of the quirks mechanism in its own patch.
This will make the whole code easier to review and spot errors if
there are.

>
> if (quirks & MS_ERGONOMY) {
> int ret = ms_ergonomy_kb_quirk(hi, usage, bit, max);
> @@ -153,7 +173,8 @@ static int ms_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
> struct hid_field *field, struct hid_usage *usage,
> unsigned long **bit, int *max)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
>
> if (quirks & MS_DUPLICATE_USAGES)
> clear_bit(usage->code, *bit);
> @@ -164,7 +185,8 @@ static int ms_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
>  static int ms_event(struct hid_device *hdev, struct hid_field *field,
> struct hid_usage *usage, __s32 value)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
> struct input_dev *input;
>
> if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
> @@ -219,12 +241,96 @@ static int ms_event(struct hid_device *hdev, struct 
> hid_field *field,
>

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Harald Freudenberger]

On 10.08.2018 10:49, Cornelia Huck wrote:
> On Thu, 9 Aug 2018 12:06:56 -0400
> Tony Krowiak  wrote:
>
>> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
>>> On 09.08.2018 11:06, Cornelia Huck wrote:  
 On Wed,  8 Aug 2018 10:44:14 -0400
 Tony Krowiak  wrote:
  
> From: Harald Freudenberger 
>
> Move all the inline functions from the ap bus header
> file ap_asm.h into the in-kernel api header file
> arch/s390/include/asm/ap.h so that KVM can make use
> of all the low level AP functions.
>
> Signed-off-by: Harald Freudenberger 
> Signed-off-by: Christian Borntraeger   
 You should add your own s-o-b if you are sending on patches written by
 others (even if it does not matter in the end, when they are merged
 through a different path anyway.)
  
> ---
>   arch/s390/include/asm/ap.h |  284 
> 
>   drivers/s390/crypto/ap_asm.h   |  261 
> 
>   drivers/s390/crypto/ap_bus.c   |   21 +---
>   drivers/s390/crypto/ap_bus.h   |1 +
>   drivers/s390/crypto/ap_card.c  |1 -
>   drivers/s390/crypto/ap_queue.c |1 -
>   6 files changed, 259 insertions(+), 310 deletions(-)
>   delete mode 100644 drivers/s390/crypto/ap_asm.h
>
> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> index c1bedb4..046e044 100644
> --- a/arch/s390/include/asm/ap.h
> +++ b/arch/s390/include/asm/ap.h
> @@ -47,6 +47,50 @@ struct ap_queue_status {
>   };
>   
>   /**
> + * ap_intructions_available() - Test if AP instructions are available.
> + *
> + * Returns 0 if the AP instructions are installed.  
 Stumbled over this when I was looking at the usage in patch 7: if I see
 a function called '_available' return 0, I'd assume that whatever the
 function tests for is *not* available.

 Rather call this function ap_instructions_check_availability() (and
 keep the return code convention), or switch this to return 0 if not
 available and !0 if available?  
>>> Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
>>> are available and 0 if not. However, this patch will come via Martin's pipe
>>> to the Linus Torwald kernel sources.  
>> Is your intent to simply indicate whether the AP instructions are 
>> available or
>> not; or is the intention to indicate whether the AP instructions are 
>> available
>> and if not, they why? In the former, then I agree that a boolean should be
>> returned; however, if the case is the latter, then what you have is fine but
>> maybe the function name should be changed as Connie suggests.
> So, can this actually fail for any reason other than "instructions not
> installed"? Even if it did, the end result is that the instructions are
> not usable -- I don't think the "why" would be interesting at that
> point.
I can not think of any other reason why the PQAP(TAPQ) would fail
other than the AP instructions are not available at all. However,
the old implementation returned -ENODEV on failure and 0 on
success. The new implementation now returns 1 for success
and 0 for failure. This is just one of a couple of functions related
to ap xxx available. I'll rework them all to return a boolean value
soon.
>
> + */
> +static inline int ap_instructions_available(void)
> +{
> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> + register unsigned long reg1 asm ("1") = -ENODEV;
> + register unsigned long reg2 asm ("2");
> +
> + asm volatile(
> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> + "0: la%0,0\n"
> + "1:\n"
> + EX_TABLE(0b, 1b)
> + : "+d" (reg1), "=d" (reg2)
> + : "d" (reg0)
> + : "cc");
> + return reg1;
> +}  

Re: [PATCH] hid: microsoft: Add rumble support for Xbox One S controller

[Benjamin Tissoires]

Hi Andrew,

On Fri, Aug 10, 2018 at 2:17 AM Andrey Smirnov  wrote:
>
> Add HID quirk driver for Xbox One S controller over bluetooth.
>
> This driver only adds support for rumble. Standard controller
> functionality is exposed by default HID driver.
>
> Cc: Dmitry Torokhov 
> Cc: Jiri Kosina 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Pierre-Loup A. Griffais 
> Signed-off-by: Juha Kuikka 
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/hid/Kconfig |   8 ++
>  drivers/hid/hid-ids.h   |   1 +
>  drivers/hid/hid-microsoft.c | 142 ++--
>  drivers/hid/hid-quirks.c|   1 +
>  4 files changed, 147 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index a49a10437c40..b2e983cb32f0 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -589,6 +589,14 @@ config HID_MICROSOFT
> ---help---
> Support for Microsoft devices that are not fully compliant with HID 
> standard.
>
> +config MICROSOFT_FF
> +   bool "Microsoft Xbox One S controller force feedback support"
> +   depends on HID_MICROSOFT
> +   select INPUT_FF_MEMLESS
> +   ---help---
> +   Say Y here if you have a Microsoft Xbox One S controller and want to 
> enable
> +   force feedback support for it.
> +

Is there really a need to have a kernel that doesn't enable FF on
those particular devices?
It adds a lot of #ifdefs in the code and I would think users want it
enabled by default.

>  config HID_MONTEREY
> tristate "Monterey Genius KB29E keyboard"
> depends on HID
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c7981ddd8776..c8b4bc7fe053 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -798,6 +798,7 @@
>  #define USB_DEVICE_ID_MS_TOUCH_COVER_2   0x07a7
>  #define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
>  #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
> +#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
>
>  #define USB_VENDOR_ID_MOJO 0x8282
>  #define USB_DEVICE_ID_RETRO_ADAPTER0x3201
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 96e7d3231d2f..e2bd31d54e62 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -29,10 +29,29 @@
>  #define MS_NOGET   0x10
>  #define MS_DUPLICATE_USAGES0x20
>
> +struct ms_data {
> +   unsigned long quirks;
> +   struct hid_device *hdev;
> +   struct work_struct ff_worker;
> +   __u8 strong;
> +   __u8 weak;
> +   __u8 *output_report_dmabuf;
> +};
> +
> +struct xb1s_ff_report {
> +   __u8report_id;
> +   __u8enable;
> +   __u8magnitude[4];
> +   __u8duration_10ms;
> +   __u8start_delay_10ms;
> +   __u8loop_count;
> +};
> +
>  static __u8 *ms_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> unsigned int *rsize)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
>
> /*
>  * Microsoft Wireless Desktop Receiver (Model 1028) has
> @@ -134,7 +153,8 @@ static int ms_input_mapping(struct hid_device *hdev, 
> struct hid_input *hi,
> struct hid_field *field, struct hid_usage *usage,
> unsigned long **bit, int *max)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;

Could you split the change of the quirks mechanism in its own patch.
This will make the whole code easier to review and spot errors if
there are.

>
> if (quirks & MS_ERGONOMY) {
> int ret = ms_ergonomy_kb_quirk(hi, usage, bit, max);
> @@ -153,7 +173,8 @@ static int ms_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
> struct hid_field *field, struct hid_usage *usage,
> unsigned long **bit, int *max)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
>
> if (quirks & MS_DUPLICATE_USAGES)
> clear_bit(usage->code, *bit);
> @@ -164,7 +185,8 @@ static int ms_input_mapped(struct hid_device *hdev, 
> struct hid_input *hi,
>  static int ms_event(struct hid_device *hdev, struct hid_field *field,
> struct hid_usage *usage, __s32 value)
>  {
> -   unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
> +   struct ms_data *ms = hid_get_drvdata(hdev);
> +   unsigned long quirks = ms->quirks;
> struct input_dev *input;
>
> if (!(hdev->claimed & HID_CLAIMED_INPUT) || !field->hidinput ||
> @@ -219,12 +241,96 @@ static int ms_event(struct hid_device *hdev, struct 
> hid_field *field,
>

Re: [PATCHv4 12/12] sched/core: Disable SD_PREFER_SIBLING on asymmetric cpu capacity domains

[Vincent Guittot]

On Mon, 6 Aug 2018 at 12:53, Valentin Schneider
 wrote:
>
> Hi,
>
> On 06/08/18 11:20, Vincent Guittot wrote:
> > Hi Valentin,
> >
> > On Tue, 31 Jul 2018 at 14:33, Valentin Schneider
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 31/07/18 13:17, Vincent Guittot wrote:
> >> [...]
> 
>  This can easily happen with SD_PREFER_SIBLING enabled too so I wouldn't
>  say that this patch breaks anything that isn't broken already. In fact
>  we this happening with and without this patch applied.
> >>>
> >>> At least for the use case  above, this doesn't happen when
> >>> SD_PREFER_SIBLING is set
> >>>
> >>
> >> On my HiKey960 I can see coscheduling on a big CPU while a LITTLE is free
> >> with **and** without SD_PREFER_SIBLING. Having it set only means that in
> >> some cases the imbalance will be re-classified as group_overloaded instead
> >> of group_misfit_task, so we'll skip the misfit logic when we shouldn't 
> >> (this
> >> happens on Juno for instance).
> >
> > Can you give more details about your test case ?
> >
>
> I've been running the same test case as presented in the cover letter on
> my HiKey960 but with sched_switch tracing and with no tasksets. I've just
> re-run the testcase with tasksets and I get similar results (i.e. a big
> with coscheduling while a LITTLE is free) with or without the flag.
>
> >>
> >> It does nothing for the "1 task per CPU" problem that Morten described 
> >> above.
> >> When you have this little amount of tasks, load isn't very relevant, but it
> >> skews the load-balancer into thinking the LITTLE CPUs are more busy than
> >> the bigs even though there's an idle one in the lot.

ok. I meant  that without misfit patch, SD_PREFER_SIBLING ensures 1
task per CPU and no co scheduling. But co scheduling appears with
misfit task patchset

Vincent
> >>
> 
>  Morten

Re: [PATCHv4 12/12] sched/core: Disable SD_PREFER_SIBLING on asymmetric cpu capacity domains

[Vincent Guittot]

On Mon, 6 Aug 2018 at 12:53, Valentin Schneider
 wrote:
>
> Hi,
>
> On 06/08/18 11:20, Vincent Guittot wrote:
> > Hi Valentin,
> >
> > On Tue, 31 Jul 2018 at 14:33, Valentin Schneider
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 31/07/18 13:17, Vincent Guittot wrote:
> >> [...]
> 
>  This can easily happen with SD_PREFER_SIBLING enabled too so I wouldn't
>  say that this patch breaks anything that isn't broken already. In fact
>  we this happening with and without this patch applied.
> >>>
> >>> At least for the use case  above, this doesn't happen when
> >>> SD_PREFER_SIBLING is set
> >>>
> >>
> >> On my HiKey960 I can see coscheduling on a big CPU while a LITTLE is free
> >> with **and** without SD_PREFER_SIBLING. Having it set only means that in
> >> some cases the imbalance will be re-classified as group_overloaded instead
> >> of group_misfit_task, so we'll skip the misfit logic when we shouldn't 
> >> (this
> >> happens on Juno for instance).
> >
> > Can you give more details about your test case ?
> >
>
> I've been running the same test case as presented in the cover letter on
> my HiKey960 but with sched_switch tracing and with no tasksets. I've just
> re-run the testcase with tasksets and I get similar results (i.e. a big
> with coscheduling while a LITTLE is free) with or without the flag.
>
> >>
> >> It does nothing for the "1 task per CPU" problem that Morten described 
> >> above.
> >> When you have this little amount of tasks, load isn't very relevant, but it
> >> skews the load-balancer into thinking the LITTLE CPUs are more busy than
> >> the bigs even though there's an idle one in the lot.

ok. I meant  that without misfit patch, SD_PREFER_SIBLING ensures 1
task per CPU and no co scheduling. But co scheduling appears with
misfit task patchset

Vincent
> >>
> 
>  Morten

Re: [PATCH v2 3/4] i2c: imx: Simplify stopped state tracking

[Esben Haabendal]

Uwe Kleine-König  writes:

> On Thu, Aug 09, 2018 at 02:06:43PM +0200, Esben Haabendal wrote:
>> Uwe Kleine-König  writes:
>> 
>> > On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> >> From: Esben Haabendal 
>> >> 
>> >> Always update the stopped state when busy status have been checked.
>> >> This is identical to what was done before, with the exception of error
>> >> handling.
>> >> Without this change, some errors cause the stopped state to be left in
>> >> incorrect state in i2c_imx_stop(), i2c_imx_dma_read(), i2c_imx_read() and
>> >> i2c_imx_xfer().
>> >> 
>> >> Signed-off-by: Esben Haabendal 
>> >> ---
>> >>  drivers/i2c/busses/i2c-imx.c | 12 ++--
>> >>  1 file changed, 6 insertions(+), 6 deletions(-)
>> >> 
>> >> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> >> index d86f152176a4..1db8e6790afc 100644
>> >> --- a/drivers/i2c/busses/i2c-imx.c
>> >> +++ b/drivers/i2c/busses/i2c-imx.c
>> >> @@ -421,10 +421,14 @@ static int i2c_imx_bus_busy(struct imx_i2c_struct 
>> >> *i2c_imx, int for_busy)
>> >>   return -EAGAIN;
>> >>   }
>> >>  
>> >> - if (for_busy && (temp & I2SR_IBB))
>> >> + if (for_busy && (temp & I2SR_IBB)) {
>> >> + i2c_imx->stopped = 0;
>> >>   break;
>> >> - if (!for_busy && !(temp & I2SR_IBB))
>> >> + }
>> >> + if (!for_busy && !(temp & I2SR_IBB)) {
>> >> + i2c_imx->stopped = 1;
>> >>   break;
>> >> + }
>> >
>> > Would it make sense to assign to ->stopped independent of for_busy?
>> 
>> What do you mean?
>> 
>> Assigning to ->stopped on each check for I2SR_IBB in loop, independent
>> of the for_busy argument?  I don't think so.  The additional assignments
>> would be to the same value as it is set to already.
>
> Currently you have:
>
>   if (for_busy && (temp & I2SR_IBB)) {
>   i2c_imx->stopped = 0;
>   break;
>   }
>
>   if (!for_busy && !(temp & I2SR_IBB)) {
>   i2c_imx->stopped = 1;
>   break;
>   }
>
> The semantic of this is the same (apart from always updating .stopped)
> but is imho easier:
>
>   i2c_imx->stopped = !(temp & I2SR_IBB);
>
>   if (for_busy != i2c_imx->stopped)
>   break;

Yes, that should work also.
Shorter, but IMHO a bit more convoluted to read.
Let me know if I should send a new version with this change.

/Esben

Re: [PATCH v2 3/4] i2c: imx: Simplify stopped state tracking

[Esben Haabendal]

Uwe Kleine-König  writes:

> On Thu, Aug 09, 2018 at 02:06:43PM +0200, Esben Haabendal wrote:
>> Uwe Kleine-König  writes:
>> 
>> > On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
>> >> From: Esben Haabendal 
>> >> 
>> >> Always update the stopped state when busy status have been checked.
>> >> This is identical to what was done before, with the exception of error
>> >> handling.
>> >> Without this change, some errors cause the stopped state to be left in
>> >> incorrect state in i2c_imx_stop(), i2c_imx_dma_read(), i2c_imx_read() and
>> >> i2c_imx_xfer().
>> >> 
>> >> Signed-off-by: Esben Haabendal 
>> >> ---
>> >>  drivers/i2c/busses/i2c-imx.c | 12 ++--
>> >>  1 file changed, 6 insertions(+), 6 deletions(-)
>> >> 
>> >> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> >> index d86f152176a4..1db8e6790afc 100644
>> >> --- a/drivers/i2c/busses/i2c-imx.c
>> >> +++ b/drivers/i2c/busses/i2c-imx.c
>> >> @@ -421,10 +421,14 @@ static int i2c_imx_bus_busy(struct imx_i2c_struct 
>> >> *i2c_imx, int for_busy)
>> >>   return -EAGAIN;
>> >>   }
>> >>  
>> >> - if (for_busy && (temp & I2SR_IBB))
>> >> + if (for_busy && (temp & I2SR_IBB)) {
>> >> + i2c_imx->stopped = 0;
>> >>   break;
>> >> - if (!for_busy && !(temp & I2SR_IBB))
>> >> + }
>> >> + if (!for_busy && !(temp & I2SR_IBB)) {
>> >> + i2c_imx->stopped = 1;
>> >>   break;
>> >> + }
>> >
>> > Would it make sense to assign to ->stopped independent of for_busy?
>> 
>> What do you mean?
>> 
>> Assigning to ->stopped on each check for I2SR_IBB in loop, independent
>> of the for_busy argument?  I don't think so.  The additional assignments
>> would be to the same value as it is set to already.
>
> Currently you have:
>
>   if (for_busy && (temp & I2SR_IBB)) {
>   i2c_imx->stopped = 0;
>   break;
>   }
>
>   if (!for_busy && !(temp & I2SR_IBB)) {
>   i2c_imx->stopped = 1;
>   break;
>   }
>
> The semantic of this is the same (apart from always updating .stopped)
> but is imho easier:
>
>   i2c_imx->stopped = !(temp & I2SR_IBB);
>
>   if (for_busy != i2c_imx->stopped)
>   break;

Yes, that should work also.
Shorter, but IMHO a bit more convoluted to read.
Let me know if I should send a new version with this change.

/Esben

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 08, 2018 at 11:53:18PM +0800, joeyli wrote:
> > Hi Bjorn,
> > 
> > First, thanks for your review!
> > 
> > On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > > > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > > > with the resource of a children bus when the PCI host bus be hotplug.
> > > > 
> > > > [ 3182.243325] PCI host bridge to bus 0001:40
> > > > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff 
> > > > window]
> > > > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > > > 0xdc00-0xebff window]
> > > > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > > > 0x2124-0x2125 window]
> > > > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > > > ...
> > > > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > > > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > > > ...
> > > > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > > > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 
> > > > 0xdc00-0xdc7f]
> > > > ...
> > > > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: 
> > > > address conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > > > 
> > > > The bus topology:
> > > > 
> > > >  +-[0001:40]-+-02.0-[41]--
> > > >  |   +-03.0-[41]--
> > > >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.1  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.2  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |\-00.3  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D Map/VTd_Misc/System Management
> > > >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO Hot Plug
> > > >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO RAS/Control Status/Global Errors
> > > >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D I/O APIC
> > > > 
> > > > This problem causes that the NIC behine the child bus was not available
> > > > after PCI host bridge hotpluged.
> > > > 
> > > > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > > > the priority of children bus's resources are higher than any other 
> > > > devices.
> > > > So this conflict can not be handled by the reassigning logic of kernel.
> > 
> > Sorry for my description is not clear. The "priority" is for resources
> > clamining, not for the address decoding.
> > 
> > > I don't understand this paragraph.  AFAIK, if two devices on a bus
> > > both decode the same address, as the IOAPIC and the bridge do here,
> > > the only real "priority" in PCI would be subtractive decode.  But I
> > > don't think that applies here since the bridge is using a positive
> > > decode window.
> > 
> > Sorry for I didn't understand... How could you know the bridge doesn't
> > apply subtractive decode?
> 
> A subtractive decode bridge forwards anything appearing on its primary
> bus to its secondary bus.  In conventional PCI, it only does this if
> no other agent on the primary bus asserts DEVSEL# (PCI r3.0, sec
> 3.6.1).  In PCIe, the primary "bus" is a link and there's only one
> device on it, so a subtractive decode bridge could forward anything it
> sees.  If the subtractive decode bridge is part of a multi-function
> device, I assume that multi-function device would have to determine
> internally whether the subtractive decode bridge or another function
> should claim the transaction.
> 
> Either way, a subtractive decode bridge can forward anything that
> appears on its primary bus, so a subtractive decode window effectively
> contains everything the upstream bridge passes down.  In this case you
> have:
> 
>   pci_bus 0001:40: root bus resource [mem 0xdc00-0xebff window]
>   pci_bus 0001:40: root bus resource [mem 0x2124-0x2125 
> window]
>   pci 0001:40:02.0: PCI bridge to [bus 41]
>   pci 0001:40:02.0:   bridge window [mem 0xdc00-0xdc7f]
> 
> The 40:02.0 bridge could see [mem 0xdc00-0xebff] or [mem
> 0x2124-0x2125] on its primary bus, so if it were a
> subtractive decode bridge, its "window" would contain both of those
> regions, and we should label them as "(subtractive decode)" in the
> dmesg log.
>

Learned! Thanks a lot!
 
> Since [mem 0xdc00-0xdc7f] is only part of the first root bus
> resource, I infer that it must be a positively decoded window.
> "lspci -vv" would tell you for sure.
>

The lspci log shows "Normal decode" on the bridge, I 

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

[joeyli]

On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 08, 2018 at 11:53:18PM +0800, joeyli wrote:
> > Hi Bjorn,
> > 
> > First, thanks for your review!
> > 
> > On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote:
> > > > I got a machine that the resource of firmware enabled IOAPIC conflicts
> > > > with the resource of a children bus when the PCI host bus be hotplug.
> > > > 
> > > > [ 3182.243325] PCI host bridge to bus 0001:40
> > > > [ 3182.243328] pci_bus 0001:40: root bus resource [io  0xc000-0xdfff 
> > > > window]
> > > > [ 3182.243330] pci_bus 0001:40: root bus resource [mem 
> > > > 0xdc00-0xebff window]
> > > > [ 3182.243331] pci_bus 0001:40: root bus resource [mem 
> > > > 0x2124-0x2125 window]
> > > > [ 3182.243334] pci_bus 0001:40: root bus resource [bus 40-7e]
> > > > ...
> > > > [ 3182.244737] pci 0001:40:05.4: [8086:6f2c] type 00 class 0x080020
> > > > [ 3182.244746] pci 0001:40:05.4: reg 0x10: [mem 0xdc00-0xdc000fff]
> > > > ...
> > > > [ 3182.246697] pci 0001:40:02.0: PCI bridge to [bus 41]
> > > > [ 3182.246702] pci 0001:40:02.0:   bridge window [mem 
> > > > 0xdc00-0xdc7f]
> > > > ...
> > > > pci 0001:40:05.4: can't claim BAR 0 [mem 0xdc00-0xdc000fff]: 
> > > > address conflict with PCI Bus 0001:41 [mem 0xdc00-0xdc7f]
> > > > 
> > > > The bus topology:
> > > > 
> > > >  +-[0001:40]-+-02.0-[41]--
> > > >  |   +-03.0-[41]--
> > > >  |   +-03.2-[41]--+-00.0  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.1  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |+-00.2  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   |\-00.3  Intel Corporation I350 Gigabit 
> > > > Network Connection
> > > >  |   +-05.0  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D Map/VTd_Misc/System Management
> > > >  |   +-05.1  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO Hot Plug
> > > >  |   +-05.2  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D IIO RAS/Control Status/Global Errors
> > > >  |   \-05.4  Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 
> > > > v4/Xeon D I/O APIC
> > > > 
> > > > This problem causes that the NIC behine the child bus was not available
> > > > after PCI host bridge hotpluged.
> > > > 
> > > > Kernel does not want to change resource of firmware enabled IOAPIC, but
> > > > the priority of children bus's resources are higher than any other 
> > > > devices.
> > > > So this conflict can not be handled by the reassigning logic of kernel.
> > 
> > Sorry for my description is not clear. The "priority" is for resources
> > clamining, not for the address decoding.
> > 
> > > I don't understand this paragraph.  AFAIK, if two devices on a bus
> > > both decode the same address, as the IOAPIC and the bridge do here,
> > > the only real "priority" in PCI would be subtractive decode.  But I
> > > don't think that applies here since the bridge is using a positive
> > > decode window.
> > 
> > Sorry for I didn't understand... How could you know the bridge doesn't
> > apply subtractive decode?
> 
> A subtractive decode bridge forwards anything appearing on its primary
> bus to its secondary bus.  In conventional PCI, it only does this if
> no other agent on the primary bus asserts DEVSEL# (PCI r3.0, sec
> 3.6.1).  In PCIe, the primary "bus" is a link and there's only one
> device on it, so a subtractive decode bridge could forward anything it
> sees.  If the subtractive decode bridge is part of a multi-function
> device, I assume that multi-function device would have to determine
> internally whether the subtractive decode bridge or another function
> should claim the transaction.
> 
> Either way, a subtractive decode bridge can forward anything that
> appears on its primary bus, so a subtractive decode window effectively
> contains everything the upstream bridge passes down.  In this case you
> have:
> 
>   pci_bus 0001:40: root bus resource [mem 0xdc00-0xebff window]
>   pci_bus 0001:40: root bus resource [mem 0x2124-0x2125 
> window]
>   pci 0001:40:02.0: PCI bridge to [bus 41]
>   pci 0001:40:02.0:   bridge window [mem 0xdc00-0xdc7f]
> 
> The 40:02.0 bridge could see [mem 0xdc00-0xebff] or [mem
> 0x2124-0x2125] on its primary bus, so if it were a
> subtractive decode bridge, its "window" would contain both of those
> regions, and we should label them as "(subtractive decode)" in the
> dmesg log.
>

Learned! Thanks a lot!
 
> Since [mem 0xdc00-0xdc7f] is only part of the first root bus
> resource, I infer that it must be a positively decoded window.
> "lspci -vv" would tell you for sure.
>

The lspci log shows "Normal decode" on the bridge, I 

Re: [RFC][PATCH 00/24] tools lib traceevent: Rename pevent to tep for preparation for library

[Jiri Olsa]

On Wed, Aug 08, 2018 at 11:55:48AM -0400, Steven Rostedt wrote:
> Having libtraceevent turn into a proper library has long been asked for.
> I never had time to do it before. Luckily, Tzvetomir was able to spend
> the time to start the preparation. The first thing that needs to be done
> is to handle namespace collisions. "pevent" was the prefix I chose, but
> many people were displeased by it, as it didn't express what the functions
> were used for. After discussing with many people at many conferences
> I've come up with "tep", which means "Trace Event Parser". Please don't
> question this. The bikeshed has been painted and I'm not changing the
> color.
> 
> This series changes all the function names and data structures from the
> "pevent_" prefix to the "tep_" prefix. Note, it does not change the
> names of local variables or even parameters. "pevent" variables and
> parameters still exist. We can change those later, but for now, I want
> all global references to "pevent" to be "tep_" instead.
> 
> This is not complete. It is only one of many preparations to make
> libtraceevent into a legitimate library. There's other naming conventions
> that will be made. But for now, I would like to hear thoughts about
> this change before we proceed further.

right, I can see more things that needs rename, like in print_arg*,
trace_* stuff and others

I'm also getting weird make error when compiling in libtraceevent dir:

  [jolsa@krava traceevent]$ make
GEN  libtraceevent-dynamic-list
  Either missing one of [ plugin_jbd2.so plugin_hrtimer.so plugin_kmem.so 
plugin_kvm.so plugin_mac80211.so plugin_sched_switch.so plugin_function.so 
plugin_xen.so plugin_scsi.so plugin_cfg80211.so] or bad version of nm

but that seems to be there even without your patchset,
so probably something we should look into

other than that it looks ok to me

once this is done, we can move forward to put this
to kernel-tools-libs-devel rpm

thanks,
jirka

Re: [RFC][PATCH 00/24] tools lib traceevent: Rename pevent to tep for preparation for library

[Jiri Olsa]

On Wed, Aug 08, 2018 at 11:55:48AM -0400, Steven Rostedt wrote:
> Having libtraceevent turn into a proper library has long been asked for.
> I never had time to do it before. Luckily, Tzvetomir was able to spend
> the time to start the preparation. The first thing that needs to be done
> is to handle namespace collisions. "pevent" was the prefix I chose, but
> many people were displeased by it, as it didn't express what the functions
> were used for. After discussing with many people at many conferences
> I've come up with "tep", which means "Trace Event Parser". Please don't
> question this. The bikeshed has been painted and I'm not changing the
> color.
> 
> This series changes all the function names and data structures from the
> "pevent_" prefix to the "tep_" prefix. Note, it does not change the
> names of local variables or even parameters. "pevent" variables and
> parameters still exist. We can change those later, but for now, I want
> all global references to "pevent" to be "tep_" instead.
> 
> This is not complete. It is only one of many preparations to make
> libtraceevent into a legitimate library. There's other naming conventions
> that will be made. But for now, I would like to hear thoughts about
> this change before we proceed further.

right, I can see more things that needs rename, like in print_arg*,
trace_* stuff and others

I'm also getting weird make error when compiling in libtraceevent dir:

  [jolsa@krava traceevent]$ make
GEN  libtraceevent-dynamic-list
  Either missing one of [ plugin_jbd2.so plugin_hrtimer.so plugin_kmem.so 
plugin_kvm.so plugin_mac80211.so plugin_sched_switch.so plugin_function.so 
plugin_xen.so plugin_scsi.so plugin_cfg80211.so] or bad version of nm

but that seems to be there even without your patchset,
so probably something we should look into

other than that it looks ok to me

once this is done, we can move forward to put this
to kernel-tools-libs-devel rpm

thanks,
jirka

Re: [PATCH v2] cpuidle: menu: Handle stopped tick more aggressively

[leo . yan]

On Fri, Aug 10, 2018 at 09:57:18AM +0200, Rafael J . Wysocki wrote:
> From: Rafael J. Wysocki 
> Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively
> 
> Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
> with stopped tick) missed the case when the target residencies of
> deep idle states of CPUs are above the tick boundary which may cause
> the CPU to get stuck in a shallow idle state for a long time.
> 
> Say there are two CPU idle states available: one shallow, with the
> target residency much below the tick boundary and one deep, with
> the target residency significantly above the tick boundary.  In
> that case, if the tick has been stopped already and the expected
> next timer event is relatively far in the future, the governor will
> assume the idle duration to be equal to TICK_USEC and it will select
> the idle state for the CPU accordingly.  However, that will cause the
> shallow state to be selected even though it would have been more
> energy-efficient to select the deep one.
> 
> To address this issue, modify the governor to always assume idle
> duration to be equal to the time till the closest timer event if
> the tick is not running which will cause the selected idle states
> to always match the known CPU wakeup time.
> 
> Also make it always indicate that the tick should be stopped in
> that case for consistency.
> 
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with 
> stopped tick)
> Reported-by: Leo Yan 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2: Initialize first_idx properly in the stopped tick case.
> 
> ---
>  drivers/cpuidle/governors/menu.c |   55 
> +--
>  1 file changed, 25 insertions(+), 30 deletions(-)
> 
> Index: linux-pm/drivers/cpuidle/governors/menu.c
> ===
> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> +++ linux-pm/drivers/cpuidle/governors/menu.c
> @@ -285,9 +285,8 @@ static int menu_select(struct cpuidle_dr
>  {
>   struct menu_device *data = this_cpu_ptr(_devices);
>   int latency_req = cpuidle_governor_latency_req(dev->cpu);
> - int i;
> - int first_idx;
> - int idx;
> + int first_idx = 0;
> + int idx, i;
>   unsigned int interactivity_req;
>   unsigned int expected_interval;
>   unsigned long nr_iowaiters, cpu_load;
> @@ -307,6 +306,18 @@ static int menu_select(struct cpuidle_dr
>   /* determine the expected residency time, round up */
>   data->next_timer_us = 
> ktime_to_us(tick_nohz_get_sleep_length(_next));
>  
> + /*
> +  * If the tick is already stopped, the cost of possible short idle
> +  * duration misprediction is much higher, because the CPU may be stuck
> +  * in a shallow idle state for a long time as a result of it.  In that
> +  * case say we might mispredict and use the known time till the closest
> +  * timer event for the idle state selection.
> +  */
> + if (tick_nohz_tick_stopped()) {
> + data->predicted_us = ktime_to_us(delta_next);
> + goto select;
> + }
> +

This introduce two potential issues:

- This will totally ignore the typical pattern in idle loop; I
  observed on the mmc driver can trigger multiple times (> 10 times)
  with consistent interval;  but I have no strong opinion to not
  use next timer event for this case.

- Will this break correction factors when the CPU exit from idle?
  data->bucket is stale value 

>   get_iowait_load(_iowaiters, _load);
>   data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
>  
> @@ -322,7 +333,6 @@ static int menu_select(struct cpuidle_dr
>   expected_interval = get_typical_interval(data);
>   expected_interval = min(expected_interval, data->next_timer_us);
>  
> - first_idx = 0;
>   if (drv->states[0].flags & CPUIDLE_FLAG_POLLING) {
>   struct cpuidle_state *s = >states[1];
>   unsigned int polling_threshold;
> @@ -344,29 +354,15 @@ static int menu_select(struct cpuidle_dr
>*/
>   data->predicted_us = min(data->predicted_us, expected_interval);
>  
> - if (tick_nohz_tick_stopped()) {
> - /*
> -  * If the tick is already stopped, the cost of possible short
> -  * idle duration misprediction is much higher, because the CPU
> -  * may be stuck in a shallow idle state for a long time as a
> -  * result of it.  In that case say we might mispredict and try
> -  * to force the CPU into a state for which we would have stopped
> -  * the tick, unless a timer is going to expire really soon
> -  * anyway.
> -  */
> - if (data->predicted_us < TICK_USEC)
> - data->predicted_us = min_t(unsigned int, TICK_USEC,
> -ktime_to_us(delta_next));
> - } else {
> - /*

Re: [PATCH v2] cpuidle: menu: Handle stopped tick more aggressively

[leo . yan]

On Fri, Aug 10, 2018 at 09:57:18AM +0200, Rafael J . Wysocki wrote:
> From: Rafael J. Wysocki 
> Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively
> 
> Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
> with stopped tick) missed the case when the target residencies of
> deep idle states of CPUs are above the tick boundary which may cause
> the CPU to get stuck in a shallow idle state for a long time.
> 
> Say there are two CPU idle states available: one shallow, with the
> target residency much below the tick boundary and one deep, with
> the target residency significantly above the tick boundary.  In
> that case, if the tick has been stopped already and the expected
> next timer event is relatively far in the future, the governor will
> assume the idle duration to be equal to TICK_USEC and it will select
> the idle state for the CPU accordingly.  However, that will cause the
> shallow state to be selected even though it would have been more
> energy-efficient to select the deep one.
> 
> To address this issue, modify the governor to always assume idle
> duration to be equal to the time till the closest timer event if
> the tick is not running which will cause the selected idle states
> to always match the known CPU wakeup time.
> 
> Also make it always indicate that the tick should be stopped in
> that case for consistency.
> 
> Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with 
> stopped tick)
> Reported-by: Leo Yan 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2: Initialize first_idx properly in the stopped tick case.
> 
> ---
>  drivers/cpuidle/governors/menu.c |   55 
> +--
>  1 file changed, 25 insertions(+), 30 deletions(-)
> 
> Index: linux-pm/drivers/cpuidle/governors/menu.c
> ===
> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> +++ linux-pm/drivers/cpuidle/governors/menu.c
> @@ -285,9 +285,8 @@ static int menu_select(struct cpuidle_dr
>  {
>   struct menu_device *data = this_cpu_ptr(_devices);
>   int latency_req = cpuidle_governor_latency_req(dev->cpu);
> - int i;
> - int first_idx;
> - int idx;
> + int first_idx = 0;
> + int idx, i;
>   unsigned int interactivity_req;
>   unsigned int expected_interval;
>   unsigned long nr_iowaiters, cpu_load;
> @@ -307,6 +306,18 @@ static int menu_select(struct cpuidle_dr
>   /* determine the expected residency time, round up */
>   data->next_timer_us = 
> ktime_to_us(tick_nohz_get_sleep_length(_next));
>  
> + /*
> +  * If the tick is already stopped, the cost of possible short idle
> +  * duration misprediction is much higher, because the CPU may be stuck
> +  * in a shallow idle state for a long time as a result of it.  In that
> +  * case say we might mispredict and use the known time till the closest
> +  * timer event for the idle state selection.
> +  */
> + if (tick_nohz_tick_stopped()) {
> + data->predicted_us = ktime_to_us(delta_next);
> + goto select;
> + }
> +

This introduce two potential issues:

- This will totally ignore the typical pattern in idle loop; I
  observed on the mmc driver can trigger multiple times (> 10 times)
  with consistent interval;  but I have no strong opinion to not
  use next timer event for this case.

- Will this break correction factors when the CPU exit from idle?
  data->bucket is stale value 

>   get_iowait_load(_iowaiters, _load);
>   data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
>  
> @@ -322,7 +333,6 @@ static int menu_select(struct cpuidle_dr
>   expected_interval = get_typical_interval(data);
>   expected_interval = min(expected_interval, data->next_timer_us);
>  
> - first_idx = 0;
>   if (drv->states[0].flags & CPUIDLE_FLAG_POLLING) {
>   struct cpuidle_state *s = >states[1];
>   unsigned int polling_threshold;
> @@ -344,29 +354,15 @@ static int menu_select(struct cpuidle_dr
>*/
>   data->predicted_us = min(data->predicted_us, expected_interval);
>  
> - if (tick_nohz_tick_stopped()) {
> - /*
> -  * If the tick is already stopped, the cost of possible short
> -  * idle duration misprediction is much higher, because the CPU
> -  * may be stuck in a shallow idle state for a long time as a
> -  * result of it.  In that case say we might mispredict and try
> -  * to force the CPU into a state for which we would have stopped
> -  * the tick, unless a timer is going to expire really soon
> -  * anyway.
> -  */
> - if (data->predicted_us < TICK_USEC)
> - data->predicted_us = min_t(unsigned int, TICK_USEC,
> -ktime_to_us(delta_next));
> - } else {
> - /*

Re: [PATCH v8 17/22] s390: vfio-ap: zeroize the AP queues.

[Cornelia Huck]

On Wed,  8 Aug 2018 10:44:27 -0400
Tony Krowiak  wrote:

> From: Tony Krowiak 
> 
> Let's call PAPQ(ZAPQ) to zeroize a queue:
> 
> * For each queue configured for a mediated matrix device
>   when it is released.
> 
> Zeroizing a queue resets the queue, clears all pending
> messages for the queue entries and disables adapter interruptions
> associated with the queue.
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Halil Pasic 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  drivers/s390/crypto/vfio_ap_ops.c |   29 -
>  drivers/s390/crypto/vfio_ap_private.h |   25 +
>  2 files changed, 53 insertions(+), 1 deletions(-)
> 

> @@ -788,7 +812,10 @@ static void vfio_ap_mdev_release(struct mdev_device 
> *mdev)
>  {
>   struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>  
> - kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> + if (matrix_mdev->kvm)
> + kvm_arch_crypto_clear_masks(matrix_mdev->kvm);

Confused. Why is the check for matrix_mdev->kvm added here?

> +
> + vfio_ap_mdev_reset_queues(mdev, true);
>   vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
>_mdev->group_notifier);
>   matrix_mdev->kvm = NULL;

Re: [PATCH v8 17/22] s390: vfio-ap: zeroize the AP queues.

[Cornelia Huck]

On Wed,  8 Aug 2018 10:44:27 -0400
Tony Krowiak  wrote:

> From: Tony Krowiak 
> 
> Let's call PAPQ(ZAPQ) to zeroize a queue:
> 
> * For each queue configured for a mediated matrix device
>   when it is released.
> 
> Zeroizing a queue resets the queue, clears all pending
> messages for the queue entries and disables adapter interruptions
> associated with the queue.
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Halil Pasic 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  drivers/s390/crypto/vfio_ap_ops.c |   29 -
>  drivers/s390/crypto/vfio_ap_private.h |   25 +
>  2 files changed, 53 insertions(+), 1 deletions(-)
> 

> @@ -788,7 +812,10 @@ static void vfio_ap_mdev_release(struct mdev_device 
> *mdev)
>  {
>   struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>  
> - kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> + if (matrix_mdev->kvm)
> + kvm_arch_crypto_clear_masks(matrix_mdev->kvm);

Confused. Why is the check for matrix_mdev->kvm added here?

> +
> + vfio_ap_mdev_reset_queues(mdev, true);
>   vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
>_mdev->group_notifier);
>   matrix_mdev->kvm = NULL;

[PATCH] spi: davinci: fix a NULL pointer dereference

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

On non-OF systems spi->controlled_data may be NULL. This causes a NULL
pointer derefence on dm365-evm.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/spi/spi-davinci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 577084bb911b..a02099c90c5c 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -217,7 +217,7 @@ static void davinci_spi_chipselect(struct spi_device *spi, 
int value)
pdata = >pdata;
 
/* program delay transfers if tx_delay is non zero */
-   if (spicfg->wdelay)
+   if (spicfg && spicfg->wdelay)
spidat1 |= SPIDAT1_WDEL;
 
/*
-- 
2.18.0

[PATCH] spi: davinci: fix a NULL pointer dereference

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

On non-OF systems spi->controlled_data may be NULL. This causes a NULL
pointer derefence on dm365-evm.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/spi/spi-davinci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 577084bb911b..a02099c90c5c 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -217,7 +217,7 @@ static void davinci_spi_chipselect(struct spi_device *spi, 
int value)
pdata = >pdata;
 
/* program delay transfers if tx_delay is non zero */
-   if (spicfg->wdelay)
+   if (spicfg && spicfg->wdelay)
spidat1 |= SPIDAT1_WDEL;
 
/*
-- 
2.18.0

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Quentin Perret]

On Friday 10 Aug 2018 at 10:41:56 (+0200), Rafael J. Wysocki wrote:
> On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
> > On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> > > I'm a bit concerned that the code here appears to be designed around the
> > > frequency domains concept which seems to be a limitation and which 
> > > probably
> > > is related to the properties of the current generation of hardware.
> > 
> > That's correct. I went for 'frequency domains' only because this is what
> > EAS and IPA are interested in, as of today at least. And both of them
> > are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
> > CPU-Perf after all :-)
> 
> Still, cpufreq manages CPU performance scaling really.
> 
> A cpufreq policy may represent a frequency domain or generally a group of
> related CPUs and what matters is that there is a coordination between them
> and not how that coordination happens at the hardware/firmware level etc.

Fair enough :-)

> 
> > > Assumptions like that tend to get tangled into the code tightly over time
> > > and they may be hard to untangle from it when new use cases arise later.
> > > 
> > > For example, there probably will be more firmware involvement in future
> > > systems and the firmware may not be willing to expose "raw" frequency
> > > domains to the OS.  That already is the case with P-states on Intel HW and
> > > with ACPI CPPC in general.
> > 
> > Agreed, and embedded/mobile systems are going in that direction too ...
> > 
> > > IMO, frequency domains in your current code could be replaced with 
> > > something
> > > more general, like "performance domains"
> > 
> > I don't mind using a more abstract name as long as we keep the same
> > assumptions, and especially that all CPUs in a perf. domain *must* have
> > the same micro-architecture.
> 
> That's fair enough I think.

Good.

> > From that assumption result several
> > properties that EAS (in its current) form needs. The first one is that
> > all CPUs of a performance domain have the same capacity at any possible
> > performance state. And the second is that they all consume the same
> > amount of (active) power.
> > 
> > I know it is theoretically possible to mix CPU types in the same perf
> > domain, but that becomes nightmare-ish to manage in EAS, and I don't
> > think there is a single platform like this on the market today. And I
> > hope nobody will build one. Peter wanted to mandate that too, I think.
> 
> There are departures, say, at least as far as the capacity is concerned.
> 
> The uarch is the same for all of them, but the max capacity may vary
> between them.

I assume you're thinking about ITMT and things like that for example ?
That's an interesting case indeed, but yes, being able to reach higher
freqs for single-threaded workloads shouldn't violate the assumption, I
think.

> > > providing the scheduler with the (relative) cost of running a task
> > 
> > What do you mean by relative ? That we should normalize the power costs ?
> > Or just use an abstract scale, without specifying the unit ?
> 
> I mean "relative with respect to the other choices"; not absolute.
> 
> > The main reason I'm a bit reluctant to do that just now is because IPA
> > needs to compare the power of CPUs with the power of other components
> > (GPUs, for example). And the power of those other components is specified
> > with a specific unit too. So, not imposing a comparable unit for the
> > power of CPUs will result in an unspecified behaviour in IPA, and that
> > will break things for sure. I would very much like to avoid that, of
> > course.
> 
> The absolute power numbers are generally hard to get though.
> 
> In the majority of cases you can figure out what the extra cost of X with
> respect to (alternative) Y is (in certain units), but you may not be able
> to say what X and Y are equal to in absolute terms (for example, there
> may be an unknown component in both X and Y that you cannot measure, but
> it may not be relevant for the outcome of the computation).

Agreed. EAS and IPA don't care about the absolute real power values, all
they care about is relative correctness. But what I really want to avoid
is having IPA getting the power of the GPUs in mW, and the power of CPUs
in an abstract scale without unit. That _will_ create problems eventually
IMO, because the behaviour is undefined. Specifying a unit everywhere is
an easy way to enforce a consistent design across sub-systems, that's
all.

> > What I am currently proposing is to keep the unit (mW) in the EM
> > framework so that migrating IPA to using it can be done in a (relatively)
> > painless way. On a system where drivers  don't know the exact wattage,
> > then they should just 'lie' to the EM framework, but it's their job to
> > lie coherently to all subsystems and keep things consistent, because all
> > subsystems have specified power in comparable units.
> 
> Alternatively, there could be a translation 

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Quentin Perret]

On Friday 10 Aug 2018 at 10:41:56 (+0200), Rafael J. Wysocki wrote:
> On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
> > On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> > > I'm a bit concerned that the code here appears to be designed around the
> > > frequency domains concept which seems to be a limitation and which 
> > > probably
> > > is related to the properties of the current generation of hardware.
> > 
> > That's correct. I went for 'frequency domains' only because this is what
> > EAS and IPA are interested in, as of today at least. And both of them
> > are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
> > CPU-Perf after all :-)
> 
> Still, cpufreq manages CPU performance scaling really.
> 
> A cpufreq policy may represent a frequency domain or generally a group of
> related CPUs and what matters is that there is a coordination between them
> and not how that coordination happens at the hardware/firmware level etc.

Fair enough :-)

> 
> > > Assumptions like that tend to get tangled into the code tightly over time
> > > and they may be hard to untangle from it when new use cases arise later.
> > > 
> > > For example, there probably will be more firmware involvement in future
> > > systems and the firmware may not be willing to expose "raw" frequency
> > > domains to the OS.  That already is the case with P-states on Intel HW and
> > > with ACPI CPPC in general.
> > 
> > Agreed, and embedded/mobile systems are going in that direction too ...
> > 
> > > IMO, frequency domains in your current code could be replaced with 
> > > something
> > > more general, like "performance domains"
> > 
> > I don't mind using a more abstract name as long as we keep the same
> > assumptions, and especially that all CPUs in a perf. domain *must* have
> > the same micro-architecture.
> 
> That's fair enough I think.

Good.

> > From that assumption result several
> > properties that EAS (in its current) form needs. The first one is that
> > all CPUs of a performance domain have the same capacity at any possible
> > performance state. And the second is that they all consume the same
> > amount of (active) power.
> > 
> > I know it is theoretically possible to mix CPU types in the same perf
> > domain, but that becomes nightmare-ish to manage in EAS, and I don't
> > think there is a single platform like this on the market today. And I
> > hope nobody will build one. Peter wanted to mandate that too, I think.
> 
> There are departures, say, at least as far as the capacity is concerned.
> 
> The uarch is the same for all of them, but the max capacity may vary
> between them.

I assume you're thinking about ITMT and things like that for example ?
That's an interesting case indeed, but yes, being able to reach higher
freqs for single-threaded workloads shouldn't violate the assumption, I
think.

> > > providing the scheduler with the (relative) cost of running a task
> > 
> > What do you mean by relative ? That we should normalize the power costs ?
> > Or just use an abstract scale, without specifying the unit ?
> 
> I mean "relative with respect to the other choices"; not absolute.
> 
> > The main reason I'm a bit reluctant to do that just now is because IPA
> > needs to compare the power of CPUs with the power of other components
> > (GPUs, for example). And the power of those other components is specified
> > with a specific unit too. So, not imposing a comparable unit for the
> > power of CPUs will result in an unspecified behaviour in IPA, and that
> > will break things for sure. I would very much like to avoid that, of
> > course.
> 
> The absolute power numbers are generally hard to get though.
> 
> In the majority of cases you can figure out what the extra cost of X with
> respect to (alternative) Y is (in certain units), but you may not be able
> to say what X and Y are equal to in absolute terms (for example, there
> may be an unknown component in both X and Y that you cannot measure, but
> it may not be relevant for the outcome of the computation).

Agreed. EAS and IPA don't care about the absolute real power values, all
they care about is relative correctness. But what I really want to avoid
is having IPA getting the power of the GPUs in mW, and the power of CPUs
in an abstract scale without unit. That _will_ create problems eventually
IMO, because the behaviour is undefined. Specifying a unit everywhere is
an easy way to enforce a consistent design across sub-systems, that's
all.

> > What I am currently proposing is to keep the unit (mW) in the EM
> > framework so that migrating IPA to using it can be done in a (relatively)
> > painless way. On a system where drivers  don't know the exact wattage,
> > then they should just 'lie' to the EM framework, but it's their job to
> > lie coherently to all subsystems and keep things consistent, because all
> > subsystems have specified power in comparable units.
> 
> Alternatively, there could be a translation 

Re: [RESEND PATCH v1 1/2] cpuidle: menu: Correct the criteria for stopping tick

[leo . yan]

On Fri, Aug 10, 2018 at 04:49:06PM +0800, Leo Yan wrote:
> On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> > On Fri, Aug 10, 2018 at 9:13 AM,   wrote:
> > > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> > >> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan  wrote:
> > 
> > [cut]
> > 
> > >> And that will cause the tick to be stopped unnecessarily in certain
> > >> situations, so why is this better?
> > >
> > > Let's see below two cases, the first one case we configure
> > > TICK_USEC=1000 (1ms) and the second case we configure TICK_USEC=4000
> > > (4ms).
> > >
> > > Let's assume we do the testing one the same platform and have two runs,
> > > in the Case 1 we configure HZ=1000 so TICK_USEC=1ms, expected_interval
> > > is 3ms and deepest idle state target residency is 2ms, finally the idle
> > > governor will choose the deepest state and skip to calibrate to shallow
> > > state caused by 'expected_interval' > TICK_USEC;
> > >
> > > In the Case 2 we configure HZ=250 so TICK_USE=4ms, expected_interval
> > > (3ms) and deepest idle state target residency (2ms) are same with the
> > > Case 1; but because expected_interval < TICK_USEC so the idle governor
> > > will do calibration to select a shallower state.  If we image on one
> > > platform, the deepest idle state's target residency is smaller value,
> > > then it has bigger gap with TICK_USEC, the deepest idle state is harder
> > > to be selected due 'expected_interval' can be easily hit the range
> > > [Deepest target residency..TICK_USEC).
> > >
> > > This patch has no any change for Case 1 and it wants to optimize for
> > > Case 2 so Case 2 has chance to stay in deepest idle state.  I
> > > understand from the performance pespective, we need to avoid to stop
> > > tick for shallow states; on the other hand we cannot prevent CPU run
> > > into deepest idle state just only we want to keep the tick running,
> > > especially the expected interval is longer than the deepest state
> > > target residency.
> > >
> > > Case 1:
> > >   Deepest idle state's target residency=2ms
> > >  |
> > >  V
> > > |> time (ms)
> > >   ^  ^
> > >   |  |
> > > TICK_USEC=1ms   expected_interval=3ms
> > >
> > >
> > > Case 2:
> > >   Deepest idle state's target residency = 2ms
> > >  |
> > >  V
> > > |> time (ms)
> > >  ^  ^
> > >  |  |
> > >   expected_interval = 3ms   TICK_USEC = 4ms
> > >
> > >
> > >
> > >> > unsigned int delta_next_us = ktime_to_us(delta_next);
> > >> >
> > >> > *stop_tick = false;
> > >> > --
> > 
> > Well, I don't quite agree with the approach here, then.
> > 
> > As I said in the previous reply, IMO restarting the stopped tick
> > before leaving the loop in do_idle() is pointless overhead.  It is not
> > necessary to do that to avoid leaving CPUs in shallow idle states for
> > too long (I'll send an alternative patch to fix this issue shortly).
> > 
> > While you may think that pointless overhead is not a problem, I don't
> > quite agree with that.
> 
> I disagree this patch will introduce any extra overhead.
> 
> Firstly, the idle loop doesn't support restarting tick even this patch
> tells idle loop to restart the tick; secondly this patch is mainly to
> resolve issue for the CPU cannot stay in deepest state in Case 2, as a
> side effect it also can tell idle loop to restart the tick for case 3
> in below, actually IMHO this makes sense to tell the idle loop to
> enable the tick but idle loop can ignore this info.
> 
> Furthermore, we have another thread for the patch to always stop
> tick after the the tick has been stopped in the idle loop.
> 
> So this patch is still valid.

Correct for Case 3 as below, actually this case will disappear if we
force to set expected_interval=ktime_to_us(delta_next) in another
proposaled patch.  If so, this patch will have no any chance to
introduce extra ticks.

 expected_interval Deepest idle state's
 = min(TICK_USEC,ktime_to_us(delta_next))  target residency = 2ms
 = TICK_USEC = 1ms|
  |   |
  V   V
|> time (ms)
  ^
  |
TICK_USEC=1ms

Re: [RESEND PATCH v1 1/2] cpuidle: menu: Correct the criteria for stopping tick

[leo . yan]

On Fri, Aug 10, 2018 at 04:49:06PM +0800, Leo Yan wrote:
> On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> > On Fri, Aug 10, 2018 at 9:13 AM,   wrote:
> > > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> > >> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan  wrote:
> > 
> > [cut]
> > 
> > >> And that will cause the tick to be stopped unnecessarily in certain
> > >> situations, so why is this better?
> > >
> > > Let's see below two cases, the first one case we configure
> > > TICK_USEC=1000 (1ms) and the second case we configure TICK_USEC=4000
> > > (4ms).
> > >
> > > Let's assume we do the testing one the same platform and have two runs,
> > > in the Case 1 we configure HZ=1000 so TICK_USEC=1ms, expected_interval
> > > is 3ms and deepest idle state target residency is 2ms, finally the idle
> > > governor will choose the deepest state and skip to calibrate to shallow
> > > state caused by 'expected_interval' > TICK_USEC;
> > >
> > > In the Case 2 we configure HZ=250 so TICK_USE=4ms, expected_interval
> > > (3ms) and deepest idle state target residency (2ms) are same with the
> > > Case 1; but because expected_interval < TICK_USEC so the idle governor
> > > will do calibration to select a shallower state.  If we image on one
> > > platform, the deepest idle state's target residency is smaller value,
> > > then it has bigger gap with TICK_USEC, the deepest idle state is harder
> > > to be selected due 'expected_interval' can be easily hit the range
> > > [Deepest target residency..TICK_USEC).
> > >
> > > This patch has no any change for Case 1 and it wants to optimize for
> > > Case 2 so Case 2 has chance to stay in deepest idle state.  I
> > > understand from the performance pespective, we need to avoid to stop
> > > tick for shallow states; on the other hand we cannot prevent CPU run
> > > into deepest idle state just only we want to keep the tick running,
> > > especially the expected interval is longer than the deepest state
> > > target residency.
> > >
> > > Case 1:
> > >   Deepest idle state's target residency=2ms
> > >  |
> > >  V
> > > |> time (ms)
> > >   ^  ^
> > >   |  |
> > > TICK_USEC=1ms   expected_interval=3ms
> > >
> > >
> > > Case 2:
> > >   Deepest idle state's target residency = 2ms
> > >  |
> > >  V
> > > |> time (ms)
> > >  ^  ^
> > >  |  |
> > >   expected_interval = 3ms   TICK_USEC = 4ms
> > >
> > >
> > >
> > >> > unsigned int delta_next_us = ktime_to_us(delta_next);
> > >> >
> > >> > *stop_tick = false;
> > >> > --
> > 
> > Well, I don't quite agree with the approach here, then.
> > 
> > As I said in the previous reply, IMO restarting the stopped tick
> > before leaving the loop in do_idle() is pointless overhead.  It is not
> > necessary to do that to avoid leaving CPUs in shallow idle states for
> > too long (I'll send an alternative patch to fix this issue shortly).
> > 
> > While you may think that pointless overhead is not a problem, I don't
> > quite agree with that.
> 
> I disagree this patch will introduce any extra overhead.
> 
> Firstly, the idle loop doesn't support restarting tick even this patch
> tells idle loop to restart the tick; secondly this patch is mainly to
> resolve issue for the CPU cannot stay in deepest state in Case 2, as a
> side effect it also can tell idle loop to restart the tick for case 3
> in below, actually IMHO this makes sense to tell the idle loop to
> enable the tick but idle loop can ignore this info.
> 
> Furthermore, we have another thread for the patch to always stop
> tick after the the tick has been stopped in the idle loop.
> 
> So this patch is still valid.

Correct for Case 3 as below, actually this case will disappear if we
force to set expected_interval=ktime_to_us(delta_next) in another
proposaled patch.  If so, this patch will have no any chance to
introduce extra ticks.

 expected_interval Deepest idle state's
 = min(TICK_USEC,ktime_to_us(delta_next))  target residency = 2ms
 = TICK_USEC = 1ms|
  |   |
  V   V
|> time (ms)
  ^
  |
TICK_USEC=1ms

[PATCH v6 0/6] iio: accel: Add adxl372 driver

[Stefan Popa]

Changes in v6:
Patch 1:
- nothing changed.
Patch 2, 3:
- added reviewed-by's which were lost when new versions were added.
Patch 4:
- fixed kbuild warning by adding a buffer overflow check in
  adxl372_buffer_postenable().
Patch 5, 6:
- nothing changed

Changes in v5:
Patch 1, 2:
- nothing changed
Patch 3:
- added a new readable_noinc operation based on feedback from
  Mark Brown
Patch 4:
- added a readable_noinc callback based on the changes from the
  previous patch.
Patch 5, 6:
- nothing changed

Changes in v4:
Patch 1:
- used a lookup table in adxl372_set_activity_threshold() instead
  of a switch(case).
Patch 2: 
- removed the interrupt-parent from the bindings.
Patch 3:
- renamed regmap_pipe_read() stub to regmap_noinc_read().
Patch 4:
- removed the adxl372_read_fifo() wrapper and directly called
  regmap_noinc_read().
- called iio_triggered_buffer_predisable() before doing the local
  changes.
Patch 5:
- nothing changed.
Patch 6:
- nothing changed.

Changes in v3:
Patch 1, 2:
- nothing changed
Patch 3:
- changed the name from regmap_pipe_read() to regmap_noinc_read()
- added a check for readable registers
Patch 4:
- dropped the fifo peak mode
- corrected the patch based on feedback from Peter Meerwald-Stadler.
Patch 5 and 6:
- nothing changed

Changes in v2:
Patch 1:
- removed ADXL372_RD_FLAG_MSK and ADXL372_WR_FLAG_MSK macros.
- handled regmap read/write by setting reg_bits and pad_bits
  fields in regmap_config struct.
- removed the buffer specifications when defining the channels.
- changed the activity and inactivity thresholds.
- added two new functions for setting the activity and inactivity
  timers: adxl372_set_inactivity_time_ms() and
  adxl372_set_activity_time_ms().
Patch 2:
- introduced all the DT bindings in a single patch.
Patch 3:
- backported the patch based on this discussion: 
  https://lkml.org/lkml/2016/6/16/548.
- this patch is required as the regmap_pipe_read() API will be used 
  to read the data from the FIFO.
Patch 4:
- removed DT bindings changes from this patch.
- removed the linux/gpio/consumer.h header.
- used regmap_pipe_read() instead of regmap_bulk_read() when
  reading data from the FIFO.
- used multiple regmap_write() calls instead of a single
  regmap_bulk_write() if there is no fast path.
- used be32_to_cpu() inside the adxl372_get_status() function.
- added a new in_accel_x_peak scan element which allows the
  user to set the FIFO into XYZ peak mode.
- used a adxl372_axis_lookup_table() to determine the fifo format
  from the active_scan_mask.
- made IRQ optional.
Patch 5 and 6:
- nothing changed

Crestez Dan Leonard (1):
  regmap: Add regmap_noinc_read API

Stefan Popa (5):
  iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer
  dt-bindings: iio: accel: Add docs for ADXL372
  iio:adxl372: Add FIFO and interrupts support
  iio:adxl372: Add sampling frequency support
  iio:adxl372: Add filter bandwidth support

 .../devicetree/bindings/iio/accel/adxl372.txt  |  22 +
 MAINTAINERS|   7 +
 drivers/base/regmap/internal.h |   3 +
 drivers/base/regmap/regmap.c   |  79 +-
 drivers/iio/accel/Kconfig  |  11 +
 drivers/iio/accel/Makefile |   1 +
 drivers/iio/accel/adxl372.c| 986 +
 include/linux/regmap.h |  19 +
 8 files changed, 1127 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt
 create mode 100644 drivers/iio/accel/adxl372.c

-- 
2.7.4

[PATCH v6 0/6] iio: accel: Add adxl372 driver

[Stefan Popa]

Changes in v6:
Patch 1:
- nothing changed.
Patch 2, 3:
- added reviewed-by's which were lost when new versions were added.
Patch 4:
- fixed kbuild warning by adding a buffer overflow check in
  adxl372_buffer_postenable().
Patch 5, 6:
- nothing changed

Changes in v5:
Patch 1, 2:
- nothing changed
Patch 3:
- added a new readable_noinc operation based on feedback from
  Mark Brown
Patch 4:
- added a readable_noinc callback based on the changes from the
  previous patch.
Patch 5, 6:
- nothing changed

Changes in v4:
Patch 1:
- used a lookup table in adxl372_set_activity_threshold() instead
  of a switch(case).
Patch 2: 
- removed the interrupt-parent from the bindings.
Patch 3:
- renamed regmap_pipe_read() stub to regmap_noinc_read().
Patch 4:
- removed the adxl372_read_fifo() wrapper and directly called
  regmap_noinc_read().
- called iio_triggered_buffer_predisable() before doing the local
  changes.
Patch 5:
- nothing changed.
Patch 6:
- nothing changed.

Changes in v3:
Patch 1, 2:
- nothing changed
Patch 3:
- changed the name from regmap_pipe_read() to regmap_noinc_read()
- added a check for readable registers
Patch 4:
- dropped the fifo peak mode
- corrected the patch based on feedback from Peter Meerwald-Stadler.
Patch 5 and 6:
- nothing changed

Changes in v2:
Patch 1:
- removed ADXL372_RD_FLAG_MSK and ADXL372_WR_FLAG_MSK macros.
- handled regmap read/write by setting reg_bits and pad_bits
  fields in regmap_config struct.
- removed the buffer specifications when defining the channels.
- changed the activity and inactivity thresholds.
- added two new functions for setting the activity and inactivity
  timers: adxl372_set_inactivity_time_ms() and
  adxl372_set_activity_time_ms().
Patch 2:
- introduced all the DT bindings in a single patch.
Patch 3:
- backported the patch based on this discussion: 
  https://lkml.org/lkml/2016/6/16/548.
- this patch is required as the regmap_pipe_read() API will be used 
  to read the data from the FIFO.
Patch 4:
- removed DT bindings changes from this patch.
- removed the linux/gpio/consumer.h header.
- used regmap_pipe_read() instead of regmap_bulk_read() when
  reading data from the FIFO.
- used multiple regmap_write() calls instead of a single
  regmap_bulk_write() if there is no fast path.
- used be32_to_cpu() inside the adxl372_get_status() function.
- added a new in_accel_x_peak scan element which allows the
  user to set the FIFO into XYZ peak mode.
- used a adxl372_axis_lookup_table() to determine the fifo format
  from the active_scan_mask.
- made IRQ optional.
Patch 5 and 6:
- nothing changed

Crestez Dan Leonard (1):
  regmap: Add regmap_noinc_read API

Stefan Popa (5):
  iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer
  dt-bindings: iio: accel: Add docs for ADXL372
  iio:adxl372: Add FIFO and interrupts support
  iio:adxl372: Add sampling frequency support
  iio:adxl372: Add filter bandwidth support

 .../devicetree/bindings/iio/accel/adxl372.txt  |  22 +
 MAINTAINERS|   7 +
 drivers/base/regmap/internal.h |   3 +
 drivers/base/regmap/regmap.c   |  79 +-
 drivers/iio/accel/Kconfig  |  11 +
 drivers/iio/accel/Makefile |   1 +
 drivers/iio/accel/adxl372.c| 986 +
 include/linux/regmap.h |  19 +
 8 files changed, 1127 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt
 create mode 100644 drivers/iio/accel/adxl372.c

-- 
2.7.4

Re: [PATCH v8 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework

[Cornelia Huck]

On Thu, 9 Aug 2018 18:27:16 +0200
Pierre Morel  wrote:

> On 09/08/2018 13:06, Cornelia Huck wrote:
> > On Wed,  8 Aug 2018 10:44:19 -0400
> > Tony Krowiak  wrote:
> >  
> >> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> >> b/drivers/s390/crypto/vfio_ap_drv.c
> >> index d7e39ad..6a827f3 100644
> >> --- a/drivers/s390/crypto/vfio_ap_drv.c
> >> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> >> @@ -12,6 +12,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include "vfio_ap_private.h"
> >>   
> >>   #define VFIO_AP_ROOT_NAME "vfio_ap"
> >> @@ -68,6 +69,18 @@ static int vfio_ap_matrix_dev_create(void)
> >>   {
> >>int ret;
> >>   
> >> +  mutex_init(_dev.lock);
> >> +  INIT_LIST_HEAD(_dev.mdev_list);
> >> +
> >> +  /* Test if PQAP(QCI) instruction is available */
> >> +  if (test_facility(12)) {
> >> +  ret = ap_qci(_dev.info);
> >> +  if (ret)
> >> +  return ret;
> >> +  }
> >> +
> >> +  atomic_set(_dev.available_instances, MAX_ZDEV_ENTRIES_EXT);
> >> +
> >>ret = misc_register(_dev.misc_dev);  
> > OK, you are adding more stuff other than the miscdevice after all...
> > still, I don't think that this is a good idea.
> >
> > I think I had already asked this for a previous version: Why has this
> > been turned into a miscdevice? (I think my reaction to the answer was
> > 'meh'... but I think more and more that we should not do that.)  
> 
> Following our off-line conversation...
> 
> I understand your concern, about the misc device and dynamically
> updating the misc device structure.
> 
> For it is your main point of contention and we do not currently have
> a use case for the misc device I propose we just let it go and
> rebase on the device design we had in V6 and did not seem to
> make any trouble to any one.
> 
> We will propose a v9 with the integration of all comment done
> so far soon as possible.

Sounds good to me!

Re: [PATCH v8 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework

[Cornelia Huck]

On Thu, 9 Aug 2018 18:27:16 +0200
Pierre Morel  wrote:

> On 09/08/2018 13:06, Cornelia Huck wrote:
> > On Wed,  8 Aug 2018 10:44:19 -0400
> > Tony Krowiak  wrote:
> >  
> >> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> >> b/drivers/s390/crypto/vfio_ap_drv.c
> >> index d7e39ad..6a827f3 100644
> >> --- a/drivers/s390/crypto/vfio_ap_drv.c
> >> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> >> @@ -12,6 +12,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include "vfio_ap_private.h"
> >>   
> >>   #define VFIO_AP_ROOT_NAME "vfio_ap"
> >> @@ -68,6 +69,18 @@ static int vfio_ap_matrix_dev_create(void)
> >>   {
> >>int ret;
> >>   
> >> +  mutex_init(_dev.lock);
> >> +  INIT_LIST_HEAD(_dev.mdev_list);
> >> +
> >> +  /* Test if PQAP(QCI) instruction is available */
> >> +  if (test_facility(12)) {
> >> +  ret = ap_qci(_dev.info);
> >> +  if (ret)
> >> +  return ret;
> >> +  }
> >> +
> >> +  atomic_set(_dev.available_instances, MAX_ZDEV_ENTRIES_EXT);
> >> +
> >>ret = misc_register(_dev.misc_dev);  
> > OK, you are adding more stuff other than the miscdevice after all...
> > still, I don't think that this is a good idea.
> >
> > I think I had already asked this for a previous version: Why has this
> > been turned into a miscdevice? (I think my reaction to the answer was
> > 'meh'... but I think more and more that we should not do that.)  
> 
> Following our off-line conversation...
> 
> I understand your concern, about the misc device and dynamically
> updating the misc device structure.
> 
> For it is your main point of contention and we do not currently have
> a use case for the misc device I propose we just let it go and
> rebase on the device design we had in V6 and did not seem to
> make any trouble to any one.
> 
> We will propose a v9 with the integration of all comment done
> so far soon as possible.

Sounds good to me!

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Cornelia Huck]

On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak  wrote:

> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
> > On 09.08.2018 11:06, Cornelia Huck wrote:  
> >> On Wed,  8 Aug 2018 10:44:14 -0400
> >> Tony Krowiak  wrote:
> >>  
> >>> From: Harald Freudenberger 
> >>>
> >>> Move all the inline functions from the ap bus header
> >>> file ap_asm.h into the in-kernel api header file
> >>> arch/s390/include/asm/ap.h so that KVM can make use
> >>> of all the low level AP functions.
> >>>
> >>> Signed-off-by: Harald Freudenberger 
> >>> Signed-off-by: Christian Borntraeger   
> >> You should add your own s-o-b if you are sending on patches written by
> >> others (even if it does not matter in the end, when they are merged
> >> through a different path anyway.)
> >>  
> >>> ---
> >>>   arch/s390/include/asm/ap.h |  284 
> >>> 
> >>>   drivers/s390/crypto/ap_asm.h   |  261 
> >>> 
> >>>   drivers/s390/crypto/ap_bus.c   |   21 +---
> >>>   drivers/s390/crypto/ap_bus.h   |1 +
> >>>   drivers/s390/crypto/ap_card.c  |1 -
> >>>   drivers/s390/crypto/ap_queue.c |1 -
> >>>   6 files changed, 259 insertions(+), 310 deletions(-)
> >>>   delete mode 100644 drivers/s390/crypto/ap_asm.h
> >>>
> >>> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> >>> index c1bedb4..046e044 100644
> >>> --- a/arch/s390/include/asm/ap.h
> >>> +++ b/arch/s390/include/asm/ap.h
> >>> @@ -47,6 +47,50 @@ struct ap_queue_status {
> >>>   };
> >>>   
> >>>   /**
> >>> + * ap_intructions_available() - Test if AP instructions are available.
> >>> + *
> >>> + * Returns 0 if the AP instructions are installed.  
> >> Stumbled over this when I was looking at the usage in patch 7: if I see
> >> a function called '_available' return 0, I'd assume that whatever the
> >> function tests for is *not* available.
> >>
> >> Rather call this function ap_instructions_check_availability() (and
> >> keep the return code convention), or switch this to return 0 if not
> >> available and !0 if available?  
> > Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
> > are available and 0 if not. However, this patch will come via Martin's pipe
> > to the Linus Torwald kernel sources.  
> 
> Is your intent to simply indicate whether the AP instructions are 
> available or
> not; or is the intention to indicate whether the AP instructions are 
> available
> and if not, they why? In the former, then I agree that a boolean should be
> returned; however, if the case is the latter, then what you have is fine but
> maybe the function name should be changed as Connie suggests.

So, can this actually fail for any reason other than "instructions not
installed"? Even if it did, the end result is that the instructions are
not usable -- I don't think the "why" would be interesting at that
point.

> 
> >>> + */
> >>> +static inline int ap_instructions_available(void)
> >>> +{
> >>> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> >>> + register unsigned long reg1 asm ("1") = -ENODEV;
> >>> + register unsigned long reg2 asm ("2");
> >>> +
> >>> + asm volatile(
> >>> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> >>> + "0: la%0,0\n"
> >>> + "1:\n"
> >>> + EX_TABLE(0b, 1b)
> >>> + : "+d" (reg1), "=d" (reg2)
> >>> + : "d" (reg0)
> >>> + : "cc");
> >>> + return reg1;
> >>> +}  

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Cornelia Huck]

On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak  wrote:

> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
> > On 09.08.2018 11:06, Cornelia Huck wrote:  
> >> On Wed,  8 Aug 2018 10:44:14 -0400
> >> Tony Krowiak  wrote:
> >>  
> >>> From: Harald Freudenberger 
> >>>
> >>> Move all the inline functions from the ap bus header
> >>> file ap_asm.h into the in-kernel api header file
> >>> arch/s390/include/asm/ap.h so that KVM can make use
> >>> of all the low level AP functions.
> >>>
> >>> Signed-off-by: Harald Freudenberger 
> >>> Signed-off-by: Christian Borntraeger   
> >> You should add your own s-o-b if you are sending on patches written by
> >> others (even if it does not matter in the end, when they are merged
> >> through a different path anyway.)
> >>  
> >>> ---
> >>>   arch/s390/include/asm/ap.h |  284 
> >>> 
> >>>   drivers/s390/crypto/ap_asm.h   |  261 
> >>> 
> >>>   drivers/s390/crypto/ap_bus.c   |   21 +---
> >>>   drivers/s390/crypto/ap_bus.h   |1 +
> >>>   drivers/s390/crypto/ap_card.c  |1 -
> >>>   drivers/s390/crypto/ap_queue.c |1 -
> >>>   6 files changed, 259 insertions(+), 310 deletions(-)
> >>>   delete mode 100644 drivers/s390/crypto/ap_asm.h
> >>>
> >>> diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
> >>> index c1bedb4..046e044 100644
> >>> --- a/arch/s390/include/asm/ap.h
> >>> +++ b/arch/s390/include/asm/ap.h
> >>> @@ -47,6 +47,50 @@ struct ap_queue_status {
> >>>   };
> >>>   
> >>>   /**
> >>> + * ap_intructions_available() - Test if AP instructions are available.
> >>> + *
> >>> + * Returns 0 if the AP instructions are installed.  
> >> Stumbled over this when I was looking at the usage in patch 7: if I see
> >> a function called '_available' return 0, I'd assume that whatever the
> >> function tests for is *not* available.
> >>
> >> Rather call this function ap_instructions_check_availability() (and
> >> keep the return code convention), or switch this to return 0 if not
> >> available and !0 if available?  
> > Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
> > are available and 0 if not. However, this patch will come via Martin's pipe
> > to the Linus Torwald kernel sources.  
> 
> Is your intent to simply indicate whether the AP instructions are 
> available or
> not; or is the intention to indicate whether the AP instructions are 
> available
> and if not, they why? In the former, then I agree that a boolean should be
> returned; however, if the case is the latter, then what you have is fine but
> maybe the function name should be changed as Connie suggests.

So, can this actually fail for any reason other than "instructions not
installed"? Even if it did, the end result is that the instructions are
not usable -- I don't think the "why" would be interesting at that
point.

> 
> >>> + */
> >>> +static inline int ap_instructions_available(void)
> >>> +{
> >>> + register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
> >>> + register unsigned long reg1 asm ("1") = -ENODEV;
> >>> + register unsigned long reg2 asm ("2");
> >>> +
> >>> + asm volatile(
> >>> + "   .long 0xb2af\n" /* PQAP(TAPQ) */
> >>> + "0: la%0,0\n"
> >>> + "1:\n"
> >>> + EX_TABLE(0b, 1b)
> >>> + : "+d" (reg1), "=d" (reg2)
> >>> + : "d" (reg0)
> >>> + : "cc");
> >>> + return reg1;
> >>> +}  

[PATCH v6 5/6] iio:adxl372: Add sampling frequency support

[Stefan Popa]

This patch adds the option for the user to select the sampling frequency.
Also, the user can read the available frequencies and read the currently
set frequency via the read_raw function. The frequency can be set via the
write_raw function.

When the frequency is set, the bandwidth is also checked and ensured
that it is constrained to at most half of the sampling frequency. Also, the
activity and inactivity timers have to be updated because they depend on
the selected ODR.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 74 -
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 1e2519a..fedb623 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -223,7 +223,8 @@ static const struct adxl372_axis_lookup 
adxl372_axis_lookup_table[] = {
.modified = 1,  \
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
-   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
+   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
.scan_index = index,\
.scan_type = {  \
.sign = 's',\
@@ -311,6 +312,19 @@ static int adxl372_set_odr(struct adxl372_state *st,
return ret;
 }
 
+static int adxl372_find_closest_match(const int *array,
+ unsigned int size, int val)
+{
+   int i;
+
+   for (i = 0; i < size; i++) {
+   if (val <= array[i])
+   return i;
+   }
+
+   return size - 1;
+}
+
 static int adxl372_set_bandwidth(struct adxl372_state *st,
 enum adxl372_bandwidth bw)
 {
@@ -631,6 +645,51 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
*val = 0;
*val2 = ADXL372_USCALE;
return IIO_VAL_INT_PLUS_MICRO;
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   *val = adxl372_samp_freq_tbl[st->odr];
+   return IIO_VAL_INT;
+   }
+
+   return -EINVAL;
+}
+
+static int adxl372_write_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int val, int val2, long info)
+{
+   struct adxl372_state *st = iio_priv(indio_dev);
+   int odr_index, ret;
+
+   switch (info) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   odr_index = adxl372_find_closest_match(adxl372_samp_freq_tbl,
+   ARRAY_SIZE(adxl372_samp_freq_tbl),
+   val);
+   ret = adxl372_set_odr(st, odr_index);
+   if (ret < 0)
+   return ret;
+   /*
+* The timer period depends on the ODR selected.
+* At 3200 Hz and below, it is 6.6 ms; at 6400 Hz, it is 3.3 ms
+*/
+   ret = adxl372_set_activity_time_ms(st, st->act_time_ms);
+   if (ret < 0)
+   return ret;
+   /*
+* The timer period depends on the ODR selected.
+* At 3200 Hz and below, it is 26 ms; at 6400 Hz, it is 13 ms
+*/
+   ret = adxl372_set_inactivity_time_ms(st, st->inact_time_ms);
+   if (ret < 0)
+   return ret;
+   /*
+* The maximum bandwidth is constrained to at most half of
+* the ODR to ensure that the Nyquist criteria is not violated
+*/
+   if (st->bw > odr_index)
+   ret = adxl372_set_bandwidth(st, odr_index);
+
+   return ret;
default:
return -EINVAL;
}
@@ -766,8 +825,21 @@ static const struct iio_trigger_ops adxl372_trigger_ops = {
.set_trigger_state = adxl372_dready_trig_set_state,
 };
 
+static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
+
+static struct attribute *adxl372_attributes[] = {
+   _const_attr_sampling_frequency_available.dev_attr.attr,
+   NULL,
+};
+
+static const struct attribute_group adxl372_attrs_group = {
+   .attrs = adxl372_attributes,
+};
+
 static const struct iio_info adxl372_info = {
+   .attrs = _attrs_group,
.read_raw = adxl372_read_raw,
+   .write_raw = adxl372_write_raw,
.debugfs_reg_access = _reg_access,
.hwfifo_set_watermark = adxl372_set_watermark,
 };
-- 
2.7.4

[PATCH v6 5/6] iio:adxl372: Add sampling frequency support

[Stefan Popa]

This patch adds the option for the user to select the sampling frequency.
Also, the user can read the available frequencies and read the currently
set frequency via the read_raw function. The frequency can be set via the
write_raw function.

When the frequency is set, the bandwidth is also checked and ensured
that it is constrained to at most half of the sampling frequency. Also, the
activity and inactivity timers have to be updated because they depend on
the selected ODR.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 74 -
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index 1e2519a..fedb623 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -223,7 +223,8 @@ static const struct adxl372_axis_lookup 
adxl372_axis_lookup_table[] = {
.modified = 1,  \
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
-   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
+   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
.scan_index = index,\
.scan_type = {  \
.sign = 's',\
@@ -311,6 +312,19 @@ static int adxl372_set_odr(struct adxl372_state *st,
return ret;
 }
 
+static int adxl372_find_closest_match(const int *array,
+ unsigned int size, int val)
+{
+   int i;
+
+   for (i = 0; i < size; i++) {
+   if (val <= array[i])
+   return i;
+   }
+
+   return size - 1;
+}
+
 static int adxl372_set_bandwidth(struct adxl372_state *st,
 enum adxl372_bandwidth bw)
 {
@@ -631,6 +645,51 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
*val = 0;
*val2 = ADXL372_USCALE;
return IIO_VAL_INT_PLUS_MICRO;
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   *val = adxl372_samp_freq_tbl[st->odr];
+   return IIO_VAL_INT;
+   }
+
+   return -EINVAL;
+}
+
+static int adxl372_write_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int val, int val2, long info)
+{
+   struct adxl372_state *st = iio_priv(indio_dev);
+   int odr_index, ret;
+
+   switch (info) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   odr_index = adxl372_find_closest_match(adxl372_samp_freq_tbl,
+   ARRAY_SIZE(adxl372_samp_freq_tbl),
+   val);
+   ret = adxl372_set_odr(st, odr_index);
+   if (ret < 0)
+   return ret;
+   /*
+* The timer period depends on the ODR selected.
+* At 3200 Hz and below, it is 6.6 ms; at 6400 Hz, it is 3.3 ms
+*/
+   ret = adxl372_set_activity_time_ms(st, st->act_time_ms);
+   if (ret < 0)
+   return ret;
+   /*
+* The timer period depends on the ODR selected.
+* At 3200 Hz and below, it is 26 ms; at 6400 Hz, it is 13 ms
+*/
+   ret = adxl372_set_inactivity_time_ms(st, st->inact_time_ms);
+   if (ret < 0)
+   return ret;
+   /*
+* The maximum bandwidth is constrained to at most half of
+* the ODR to ensure that the Nyquist criteria is not violated
+*/
+   if (st->bw > odr_index)
+   ret = adxl372_set_bandwidth(st, odr_index);
+
+   return ret;
default:
return -EINVAL;
}
@@ -766,8 +825,21 @@ static const struct iio_trigger_ops adxl372_trigger_ops = {
.set_trigger_state = adxl372_dready_trig_set_state,
 };
 
+static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
+
+static struct attribute *adxl372_attributes[] = {
+   _const_attr_sampling_frequency_available.dev_attr.attr,
+   NULL,
+};
+
+static const struct attribute_group adxl372_attrs_group = {
+   .attrs = adxl372_attributes,
+};
+
 static const struct iio_info adxl372_info = {
+   .attrs = _attrs_group,
.read_raw = adxl372_read_raw,
+   .write_raw = adxl372_write_raw,
.debugfs_reg_access = _reg_access,
.hwfifo_set_watermark = adxl372_set_watermark,
 };
-- 
2.7.4

[PATCH v6 3/6] regmap: Add regmap_noinc_read API

[Stefan Popa]

From: Crestez Dan Leonard 

The regmap API usually assumes that bulk read operations will read a
range of registers but some I2C/SPI devices have certain registers for
which a such a read operation will return data from an internal FIFO
instead. Add an explicit API to support bulk read without range semantics.

Some linux drivers use regmap_bulk_read or regmap_raw_read for such
registers, for example mpu6050 or bmi150 from IIO. This only happens to
work because when caching is disabled a single regmap read op will map
to a single bus read op (as desired). This breaks if caching is enabled and
reg+1 happens to be a cacheable register.

Without regmap support refactoring a driver to enable regmap caching
requires separate I2C and SPI paths. This is exactly what regmap is
supposed to help avoid.

Suggested-by: Jonathan Cameron 
Signed-off-by: Crestez Dan Leonard 
Signed-off-by: Stefan Popa 
Reviewed-by: Jonathan Cameron 
---
 drivers/base/regmap/internal.h |  3 ++
 drivers/base/regmap/regmap.c   | 79 +-
 include/linux/regmap.h | 19 ++
 3 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 53785e0..a6bf34d63 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -94,10 +94,12 @@ struct regmap {
bool (*readable_reg)(struct device *dev, unsigned int reg);
bool (*volatile_reg)(struct device *dev, unsigned int reg);
bool (*precious_reg)(struct device *dev, unsigned int reg);
+   bool (*readable_noinc_reg)(struct device *dev, unsigned int reg);
const struct regmap_access_table *wr_table;
const struct regmap_access_table *rd_table;
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
+   const struct regmap_access_table *rd_noinc_table;
 
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
@@ -181,6 +183,7 @@ bool regmap_writeable(struct regmap *map, unsigned int reg);
 bool regmap_readable(struct regmap *map, unsigned int reg);
 bool regmap_volatile(struct regmap *map, unsigned int reg);
 bool regmap_precious(struct regmap *map, unsigned int reg);
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg);
 
 int _regmap_write(struct regmap *map, unsigned int reg,
  unsigned int val);
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 3bc8488..0360a90 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -168,6 +168,17 @@ bool regmap_precious(struct regmap *map, unsigned int reg)
return false;
 }
 
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg)
+{
+   if (map->readable_noinc_reg)
+   return map->readable_noinc_reg(map->dev, reg);
+
+   if (map->rd_noinc_table)
+   return regmap_check_range_table(map, reg, map->rd_noinc_table);
+
+   return true;
+}
+
 static bool regmap_volatile_range(struct regmap *map, unsigned int reg,
size_t num)
 {
@@ -766,10 +777,12 @@ struct regmap *__regmap_init(struct device *dev,
map->rd_table = config->rd_table;
map->volatile_table = config->volatile_table;
map->precious_table = config->precious_table;
+   map->rd_noinc_table = config->rd_noinc_table;
map->writeable_reg = config->writeable_reg;
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+   map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
 
spin_lock_init(>async_lock);
@@ -1285,6 +1298,7 @@ int regmap_reinit_cache(struct regmap *map, const struct 
regmap_config *config)
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+   map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
 
regmap_debugfs_init(map, config->name);
@@ -2564,7 +2578,70 @@ int regmap_raw_read(struct regmap *map, unsigned int 
reg, void *val,
 EXPORT_SYMBOL_GPL(regmap_raw_read);
 
 /**
- * regmap_field_read() - Read a value to a single register field
+ * regmap_noinc_read(): Read data from a register without incrementing the
+ * register number
+ *
+ * @map: Register map to read from
+ * @reg: Register to read from
+ * @val: Pointer to data buffer
+ * @val_len: Length of output buffer in bytes.
+ *
+ * The regmap API usually assumes that bulk bus read operations will read a
+ * range of registers. Some devices have certain registers for which a read
+ * operation read will read from an internal FIFO.
+ *
+ * The target register must be volatile but registers after it can be
+ * 

[PATCH v6 6/6] iio:adxl372: Add filter bandwidth support

[Stefan Popa]

This patch adds the option for the user to select the filter bandwidth. The
user can also read the available bandwidths which are always adjusted to be
at most half of the sampling frequency. Furthermore, the currently selected
bandwidth can be read via the read_raw function, while the write_raw sets a
new bandwidth value.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index fedb623..7097775 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -202,6 +202,10 @@ static const int adxl372_samp_freq_tbl[5] = {
400, 800, 1600, 3200, 6400,
 };
 
+static const int adxl372_bw_freq_tbl[5] = {
+   200, 400, 800, 1600, 3200,
+};
+
 struct adxl372_axis_lookup {
unsigned int bits;
enum adxl372_fifo_format fifo_format;
@@ -224,7 +228,8 @@ static const struct adxl372_axis_lookup 
adxl372_axis_lookup_table[] = {
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
-   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |  \
+   BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY),   \
.scan_index = index,\
.scan_type = {  \
.sign = 's',\
@@ -648,6 +653,9 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SAMP_FREQ:
*val = adxl372_samp_freq_tbl[st->odr];
return IIO_VAL_INT;
+   case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
+   *val = adxl372_bw_freq_tbl[st->bw];
+   return IIO_VAL_INT;
}
 
return -EINVAL;
@@ -658,7 +666,7 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
 int val, int val2, long info)
 {
struct adxl372_state *st = iio_priv(indio_dev);
-   int odr_index, ret;
+   int odr_index, bw_index, ret;
 
switch (info) {
case IIO_CHAN_INFO_SAMP_FREQ:
@@ -690,11 +698,34 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
ret = adxl372_set_bandwidth(st, odr_index);
 
return ret;
+   case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
+   bw_index = adxl372_find_closest_match(adxl372_bw_freq_tbl,
+   ARRAY_SIZE(adxl372_bw_freq_tbl),
+   val);
+   return adxl372_set_bandwidth(st, bw_index);
default:
return -EINVAL;
}
 }
 
+static ssize_t adxl372_show_filter_freq_avail(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+   struct adxl372_state *st = iio_priv(indio_dev);
+   int i;
+   size_t len = 0;
+
+   for (i = 0; i <= st->odr; i++)
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+"%d ", adxl372_bw_freq_tbl[i]);
+
+   buf[len - 1] = '\n';
+
+   return len;
+}
+
 static ssize_t adxl372_get_fifo_enabled(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -826,9 +857,12 @@ static const struct iio_trigger_ops adxl372_trigger_ops = {
 };
 
 static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
+static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
+  0444, adxl372_show_filter_freq_avail, NULL, 0);
 
 static struct attribute *adxl372_attributes[] = {
_const_attr_sampling_frequency_available.dev_attr.attr,
+   
_dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH v6 3/6] regmap: Add regmap_noinc_read API

[Stefan Popa]

From: Crestez Dan Leonard 

The regmap API usually assumes that bulk read operations will read a
range of registers but some I2C/SPI devices have certain registers for
which a such a read operation will return data from an internal FIFO
instead. Add an explicit API to support bulk read without range semantics.

Some linux drivers use regmap_bulk_read or regmap_raw_read for such
registers, for example mpu6050 or bmi150 from IIO. This only happens to
work because when caching is disabled a single regmap read op will map
to a single bus read op (as desired). This breaks if caching is enabled and
reg+1 happens to be a cacheable register.

Without regmap support refactoring a driver to enable regmap caching
requires separate I2C and SPI paths. This is exactly what regmap is
supposed to help avoid.

Suggested-by: Jonathan Cameron 
Signed-off-by: Crestez Dan Leonard 
Signed-off-by: Stefan Popa 
Reviewed-by: Jonathan Cameron 
---
 drivers/base/regmap/internal.h |  3 ++
 drivers/base/regmap/regmap.c   | 79 +-
 include/linux/regmap.h | 19 ++
 3 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 53785e0..a6bf34d63 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -94,10 +94,12 @@ struct regmap {
bool (*readable_reg)(struct device *dev, unsigned int reg);
bool (*volatile_reg)(struct device *dev, unsigned int reg);
bool (*precious_reg)(struct device *dev, unsigned int reg);
+   bool (*readable_noinc_reg)(struct device *dev, unsigned int reg);
const struct regmap_access_table *wr_table;
const struct regmap_access_table *rd_table;
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
+   const struct regmap_access_table *rd_noinc_table;
 
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
@@ -181,6 +183,7 @@ bool regmap_writeable(struct regmap *map, unsigned int reg);
 bool regmap_readable(struct regmap *map, unsigned int reg);
 bool regmap_volatile(struct regmap *map, unsigned int reg);
 bool regmap_precious(struct regmap *map, unsigned int reg);
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg);
 
 int _regmap_write(struct regmap *map, unsigned int reg,
  unsigned int val);
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 3bc8488..0360a90 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -168,6 +168,17 @@ bool regmap_precious(struct regmap *map, unsigned int reg)
return false;
 }
 
+bool regmap_readable_noinc(struct regmap *map, unsigned int reg)
+{
+   if (map->readable_noinc_reg)
+   return map->readable_noinc_reg(map->dev, reg);
+
+   if (map->rd_noinc_table)
+   return regmap_check_range_table(map, reg, map->rd_noinc_table);
+
+   return true;
+}
+
 static bool regmap_volatile_range(struct regmap *map, unsigned int reg,
size_t num)
 {
@@ -766,10 +777,12 @@ struct regmap *__regmap_init(struct device *dev,
map->rd_table = config->rd_table;
map->volatile_table = config->volatile_table;
map->precious_table = config->precious_table;
+   map->rd_noinc_table = config->rd_noinc_table;
map->writeable_reg = config->writeable_reg;
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+   map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
 
spin_lock_init(>async_lock);
@@ -1285,6 +1298,7 @@ int regmap_reinit_cache(struct regmap *map, const struct 
regmap_config *config)
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+   map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
 
regmap_debugfs_init(map, config->name);
@@ -2564,7 +2578,70 @@ int regmap_raw_read(struct regmap *map, unsigned int 
reg, void *val,
 EXPORT_SYMBOL_GPL(regmap_raw_read);
 
 /**
- * regmap_field_read() - Read a value to a single register field
+ * regmap_noinc_read(): Read data from a register without incrementing the
+ * register number
+ *
+ * @map: Register map to read from
+ * @reg: Register to read from
+ * @val: Pointer to data buffer
+ * @val_len: Length of output buffer in bytes.
+ *
+ * The regmap API usually assumes that bulk bus read operations will read a
+ * range of registers. Some devices have certain registers for which a read
+ * operation read will read from an internal FIFO.
+ *
+ * The target register must be volatile but registers after it can be
+ * 

[PATCH v6 6/6] iio:adxl372: Add filter bandwidth support

[Stefan Popa]

This patch adds the option for the user to select the filter bandwidth. The
user can also read the available bandwidths which are always adjusted to be
at most half of the sampling frequency. Furthermore, the currently selected
bandwidth can be read via the read_raw function, while the write_raw sets a
new bandwidth value.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index fedb623..7097775 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -202,6 +202,10 @@ static const int adxl372_samp_freq_tbl[5] = {
400, 800, 1600, 3200, 6400,
 };
 
+static const int adxl372_bw_freq_tbl[5] = {
+   200, 400, 800, 1600, 3200,
+};
+
 struct adxl372_axis_lookup {
unsigned int bits;
enum adxl372_fifo_format fifo_format;
@@ -224,7 +228,8 @@ static const struct adxl372_axis_lookup 
adxl372_axis_lookup_table[] = {
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
-   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |  \
+   BIT(IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY),   \
.scan_index = index,\
.scan_type = {  \
.sign = 's',\
@@ -648,6 +653,9 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SAMP_FREQ:
*val = adxl372_samp_freq_tbl[st->odr];
return IIO_VAL_INT;
+   case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
+   *val = adxl372_bw_freq_tbl[st->bw];
+   return IIO_VAL_INT;
}
 
return -EINVAL;
@@ -658,7 +666,7 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
 int val, int val2, long info)
 {
struct adxl372_state *st = iio_priv(indio_dev);
-   int odr_index, ret;
+   int odr_index, bw_index, ret;
 
switch (info) {
case IIO_CHAN_INFO_SAMP_FREQ:
@@ -690,11 +698,34 @@ static int adxl372_write_raw(struct iio_dev *indio_dev,
ret = adxl372_set_bandwidth(st, odr_index);
 
return ret;
+   case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
+   bw_index = adxl372_find_closest_match(adxl372_bw_freq_tbl,
+   ARRAY_SIZE(adxl372_bw_freq_tbl),
+   val);
+   return adxl372_set_bandwidth(st, bw_index);
default:
return -EINVAL;
}
 }
 
+static ssize_t adxl372_show_filter_freq_avail(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+   struct adxl372_state *st = iio_priv(indio_dev);
+   int i;
+   size_t len = 0;
+
+   for (i = 0; i <= st->odr; i++)
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+"%d ", adxl372_bw_freq_tbl[i]);
+
+   buf[len - 1] = '\n';
+
+   return len;
+}
+
 static ssize_t adxl372_get_fifo_enabled(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -826,9 +857,12 @@ static const struct iio_trigger_ops adxl372_trigger_ops = {
 };
 
 static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
+static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
+  0444, adxl372_show_filter_freq_avail, NULL, 0);
 
 static struct attribute *adxl372_attributes[] = {
_const_attr_sampling_frequency_available.dev_attr.attr,
+   
_dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH v6 4/6] iio:adxl372: Add FIFO and interrupts support

[Stefan Popa]

This patch adds support for the adxl372 FIFO. In order to accomplish this,
triggered buffers were used.

The number of FIFO samples which trigger the watermark interrupt can be
configured by using the buffer watermark. The FIFO format is determined by
configuring the scan elements for each axis. The FIFO data is pushed to the
IIO device's buffer.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 357 +++-
 1 file changed, 356 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index db9ecd2..1e2519a 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -6,12 +6,19 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* ADXL372 registers definition */
 #define ADXL372_DEVID  0x00
@@ -123,6 +130,9 @@
 #define ADXL372_INT1_MAP_LOW_MSK   BIT(7)
 #define ADXL372_INT1_MAP_LOW_MODE(x)   (((x) & 0x1) << 7)
 
+/* The ADXL372 includes a deep, 512 sample FIFO buffer */
+#define ADXL372_FIFO_SIZE  512
+
 /*
  * At +/- 200g with 12-bit resolution, scale is computed as:
  * (200 + 200) * 9.81 / (2^12 - 1) = 0.958241
@@ -170,6 +180,43 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
[ADXL372_INACTIVITY] = ADXL372_X_THRESH_INACT_H,
 };
 
+enum adxl372_fifo_format {
+   ADXL372_XYZ_FIFO,
+   ADXL372_X_FIFO,
+   ADXL372_Y_FIFO,
+   ADXL372_XY_FIFO,
+   ADXL372_Z_FIFO,
+   ADXL372_XZ_FIFO,
+   ADXL372_YZ_FIFO,
+   ADXL372_XYZ_PEAK_FIFO,
+};
+
+enum adxl372_fifo_mode {
+   ADXL372_FIFO_BYPASSED,
+   ADXL372_FIFO_STREAMED,
+   ADXL372_FIFO_TRIGGERED,
+   ADXL372_FIFO_OLD_SAVED
+};
+
+static const int adxl372_samp_freq_tbl[5] = {
+   400, 800, 1600, 3200, 6400,
+};
+
+struct adxl372_axis_lookup {
+   unsigned int bits;
+   enum adxl372_fifo_format fifo_format;
+};
+
+static const struct adxl372_axis_lookup adxl372_axis_lookup_table[] = {
+   { BIT(0), ADXL372_X_FIFO },
+   { BIT(1), ADXL372_Y_FIFO },
+   { BIT(2), ADXL372_Z_FIFO },
+   { BIT(0) | BIT(1), ADXL372_XY_FIFO },
+   { BIT(0) | BIT(2), ADXL372_XZ_FIFO },
+   { BIT(1) | BIT(2), ADXL372_YZ_FIFO },
+   { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
+};
+
 #define ADXL372_ACCEL_CHANNEL(index, reg, axis) {  \
.type = IIO_ACCEL,  \
.address = reg, \
@@ -177,6 +224,13 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+   .scan_index = index,\
+   .scan_type = {  \
+   .sign = 's',\
+   .realbits = 12, \
+   .storagebits = 16,  \
+   .shift = 4, \
+   },  \
 }
 
 static const struct iio_chan_spec adxl372_channels[] = {
@@ -188,12 +242,29 @@ static const struct iio_chan_spec adxl372_channels[] = {
 struct adxl372_state {
struct spi_device   *spi;
struct regmap   *regmap;
+   struct iio_trigger  *dready_trig;
+   enum adxl372_fifo_mode  fifo_mode;
+   enum adxl372_fifo_formatfifo_format;
enum adxl372_op_modeop_mode;
enum adxl372_act_proc_mode  act_proc_mode;
enum adxl372_odrodr;
enum adxl372_bandwidth  bw;
u32 act_time_ms;
u32 inact_time_ms;
+   u8  fifo_set_size;
+   u8  int1_bitmask;
+   u8  int2_bitmask;
+   u16 watermark;
+   __be16  fifo_buf[ADXL372_FIFO_SIZE];
+};
+
+static const unsigned long adxl372_channel_masks[] = {
+   BIT(0), BIT(1), BIT(2),
+   BIT(0) | BIT(1),
+   BIT(0) | BIT(2),
+   BIT(1) | BIT(2),
+   BIT(0) | BIT(1) | BIT(2),
+   0
 };
 
 static int adxl372_read_axis(struct adxl372_state *st, u8 addr)
@@ -359,6 +430,112 @@ static int adxl372_set_inactivity_time_ms(struct 
adxl372_state *st,
return ret;
 }
 
+static int adxl372_set_interrupts(struct adxl372_state *st,
+ unsigned char int1_bitmask,
+  

[PATCH v6 4/6] iio:adxl372: Add FIFO and interrupts support

[Stefan Popa]

This patch adds support for the adxl372 FIFO. In order to accomplish this,
triggered buffers were used.

The number of FIFO samples which trigger the watermark interrupt can be
configured by using the buffer watermark. The FIFO format is determined by
configuring the scan elements for each axis. The FIFO data is pushed to the
IIO device's buffer.

Signed-off-by: Stefan Popa 
---
 drivers/iio/accel/adxl372.c | 357 +++-
 1 file changed, 356 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
index db9ecd2..1e2519a 100644
--- a/drivers/iio/accel/adxl372.c
+++ b/drivers/iio/accel/adxl372.c
@@ -6,12 +6,19 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* ADXL372 registers definition */
 #define ADXL372_DEVID  0x00
@@ -123,6 +130,9 @@
 #define ADXL372_INT1_MAP_LOW_MSK   BIT(7)
 #define ADXL372_INT1_MAP_LOW_MODE(x)   (((x) & 0x1) << 7)
 
+/* The ADXL372 includes a deep, 512 sample FIFO buffer */
+#define ADXL372_FIFO_SIZE  512
+
 /*
  * At +/- 200g with 12-bit resolution, scale is computed as:
  * (200 + 200) * 9.81 / (2^12 - 1) = 0.958241
@@ -170,6 +180,43 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
[ADXL372_INACTIVITY] = ADXL372_X_THRESH_INACT_H,
 };
 
+enum adxl372_fifo_format {
+   ADXL372_XYZ_FIFO,
+   ADXL372_X_FIFO,
+   ADXL372_Y_FIFO,
+   ADXL372_XY_FIFO,
+   ADXL372_Z_FIFO,
+   ADXL372_XZ_FIFO,
+   ADXL372_YZ_FIFO,
+   ADXL372_XYZ_PEAK_FIFO,
+};
+
+enum adxl372_fifo_mode {
+   ADXL372_FIFO_BYPASSED,
+   ADXL372_FIFO_STREAMED,
+   ADXL372_FIFO_TRIGGERED,
+   ADXL372_FIFO_OLD_SAVED
+};
+
+static const int adxl372_samp_freq_tbl[5] = {
+   400, 800, 1600, 3200, 6400,
+};
+
+struct adxl372_axis_lookup {
+   unsigned int bits;
+   enum adxl372_fifo_format fifo_format;
+};
+
+static const struct adxl372_axis_lookup adxl372_axis_lookup_table[] = {
+   { BIT(0), ADXL372_X_FIFO },
+   { BIT(1), ADXL372_Y_FIFO },
+   { BIT(2), ADXL372_Z_FIFO },
+   { BIT(0) | BIT(1), ADXL372_XY_FIFO },
+   { BIT(0) | BIT(2), ADXL372_XZ_FIFO },
+   { BIT(1) | BIT(2), ADXL372_YZ_FIFO },
+   { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
+};
+
 #define ADXL372_ACCEL_CHANNEL(index, reg, axis) {  \
.type = IIO_ACCEL,  \
.address = reg, \
@@ -177,6 +224,13 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
.channel2 = IIO_MOD_##axis, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
+   .scan_index = index,\
+   .scan_type = {  \
+   .sign = 's',\
+   .realbits = 12, \
+   .storagebits = 16,  \
+   .shift = 4, \
+   },  \
 }
 
 static const struct iio_chan_spec adxl372_channels[] = {
@@ -188,12 +242,29 @@ static const struct iio_chan_spec adxl372_channels[] = {
 struct adxl372_state {
struct spi_device   *spi;
struct regmap   *regmap;
+   struct iio_trigger  *dready_trig;
+   enum adxl372_fifo_mode  fifo_mode;
+   enum adxl372_fifo_formatfifo_format;
enum adxl372_op_modeop_mode;
enum adxl372_act_proc_mode  act_proc_mode;
enum adxl372_odrodr;
enum adxl372_bandwidth  bw;
u32 act_time_ms;
u32 inact_time_ms;
+   u8  fifo_set_size;
+   u8  int1_bitmask;
+   u8  int2_bitmask;
+   u16 watermark;
+   __be16  fifo_buf[ADXL372_FIFO_SIZE];
+};
+
+static const unsigned long adxl372_channel_masks[] = {
+   BIT(0), BIT(1), BIT(2),
+   BIT(0) | BIT(1),
+   BIT(0) | BIT(2),
+   BIT(1) | BIT(2),
+   BIT(0) | BIT(1) | BIT(2),
+   0
 };
 
 static int adxl372_read_axis(struct adxl372_state *st, u8 addr)
@@ -359,6 +430,112 @@ static int adxl372_set_inactivity_time_ms(struct 
adxl372_state *st,
return ret;
 }
 
+static int adxl372_set_interrupts(struct adxl372_state *st,
+ unsigned char int1_bitmask,
+  

Re: [RESEND PATCH v1 1/2] cpuidle: menu: Correct the criteria for stopping tick

[leo . yan]

On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> On Fri, Aug 10, 2018 at 9:13 AM,   wrote:
> > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan  wrote:
> 
> [cut]
> 
> >> And that will cause the tick to be stopped unnecessarily in certain
> >> situations, so why is this better?
> >
> > Let's see below two cases, the first one case we configure
> > TICK_USEC=1000 (1ms) and the second case we configure TICK_USEC=4000
> > (4ms).
> >
> > Let's assume we do the testing one the same platform and have two runs,
> > in the Case 1 we configure HZ=1000 so TICK_USEC=1ms, expected_interval
> > is 3ms and deepest idle state target residency is 2ms, finally the idle
> > governor will choose the deepest state and skip to calibrate to shallow
> > state caused by 'expected_interval' > TICK_USEC;
> >
> > In the Case 2 we configure HZ=250 so TICK_USE=4ms, expected_interval
> > (3ms) and deepest idle state target residency (2ms) are same with the
> > Case 1; but because expected_interval < TICK_USEC so the idle governor
> > will do calibration to select a shallower state.  If we image on one
> > platform, the deepest idle state's target residency is smaller value,
> > then it has bigger gap with TICK_USEC, the deepest idle state is harder
> > to be selected due 'expected_interval' can be easily hit the range
> > [Deepest target residency..TICK_USEC).
> >
> > This patch has no any change for Case 1 and it wants to optimize for
> > Case 2 so Case 2 has chance to stay in deepest idle state.  I
> > understand from the performance pespective, we need to avoid to stop
> > tick for shallow states; on the other hand we cannot prevent CPU run
> > into deepest idle state just only we want to keep the tick running,
> > especially the expected interval is longer than the deepest state
> > target residency.
> >
> > Case 1:
> >   Deepest idle state's target residency=2ms
> >  |
> >  V
> > |> time (ms)
> >   ^  ^
> >   |  |
> > TICK_USEC=1ms   expected_interval=3ms
> >
> >
> > Case 2:
> >   Deepest idle state's target residency = 2ms
> >  |
> >  V
> > |> time (ms)
> >  ^  ^
> >  |  |
> >   expected_interval = 3ms   TICK_USEC = 4ms
> >
> >
> >
> >> > unsigned int delta_next_us = ktime_to_us(delta_next);
> >> >
> >> > *stop_tick = false;
> >> > --
> 
> Well, I don't quite agree with the approach here, then.
> 
> As I said in the previous reply, IMO restarting the stopped tick
> before leaving the loop in do_idle() is pointless overhead.  It is not
> necessary to do that to avoid leaving CPUs in shallow idle states for
> too long (I'll send an alternative patch to fix this issue shortly).
> 
> While you may think that pointless overhead is not a problem, I don't
> quite agree with that.

I disagree this patch will introduce any extra overhead.

Firstly, the idle loop doesn't support restarting tick even this patch
tells idle loop to restart the tick; secondly this patch is mainly to
resolve issue for the CPU cannot stay in deepest state in Case 2, as a
side effect it also can tell idle loop to restart the tick for case 3
in below, actually IMHO this makes sense to tell the idle loop to
enable the tick but idle loop can ignore this info.

Furthermore, we have another thread for the patch to always stop
tick after the the tick has been stopped in the idle loop.

So this patch is still valid.

Case 3:
  Deepest idle state's target residency = 2ms
 |
 V
|> time (ms)
  ^`
  | \
TICK_USEC=1ms   expected_interval = 1.5ms

Re: [RESEND PATCH v1 1/2] cpuidle: menu: Correct the criteria for stopping tick

[leo . yan]

On Fri, Aug 10, 2018 at 09:22:10AM +0200, Rafael J. Wysocki wrote:
> On Fri, Aug 10, 2018 at 9:13 AM,   wrote:
> > On Thu, Aug 09, 2018 at 10:47:17PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Aug 9, 2018 at 7:20 PM, Leo Yan  wrote:
> 
> [cut]
> 
> >> And that will cause the tick to be stopped unnecessarily in certain
> >> situations, so why is this better?
> >
> > Let's see below two cases, the first one case we configure
> > TICK_USEC=1000 (1ms) and the second case we configure TICK_USEC=4000
> > (4ms).
> >
> > Let's assume we do the testing one the same platform and have two runs,
> > in the Case 1 we configure HZ=1000 so TICK_USEC=1ms, expected_interval
> > is 3ms and deepest idle state target residency is 2ms, finally the idle
> > governor will choose the deepest state and skip to calibrate to shallow
> > state caused by 'expected_interval' > TICK_USEC;
> >
> > In the Case 2 we configure HZ=250 so TICK_USE=4ms, expected_interval
> > (3ms) and deepest idle state target residency (2ms) are same with the
> > Case 1; but because expected_interval < TICK_USEC so the idle governor
> > will do calibration to select a shallower state.  If we image on one
> > platform, the deepest idle state's target residency is smaller value,
> > then it has bigger gap with TICK_USEC, the deepest idle state is harder
> > to be selected due 'expected_interval' can be easily hit the range
> > [Deepest target residency..TICK_USEC).
> >
> > This patch has no any change for Case 1 and it wants to optimize for
> > Case 2 so Case 2 has chance to stay in deepest idle state.  I
> > understand from the performance pespective, we need to avoid to stop
> > tick for shallow states; on the other hand we cannot prevent CPU run
> > into deepest idle state just only we want to keep the tick running,
> > especially the expected interval is longer than the deepest state
> > target residency.
> >
> > Case 1:
> >   Deepest idle state's target residency=2ms
> >  |
> >  V
> > |> time (ms)
> >   ^  ^
> >   |  |
> > TICK_USEC=1ms   expected_interval=3ms
> >
> >
> > Case 2:
> >   Deepest idle state's target residency = 2ms
> >  |
> >  V
> > |> time (ms)
> >  ^  ^
> >  |  |
> >   expected_interval = 3ms   TICK_USEC = 4ms
> >
> >
> >
> >> > unsigned int delta_next_us = ktime_to_us(delta_next);
> >> >
> >> > *stop_tick = false;
> >> > --
> 
> Well, I don't quite agree with the approach here, then.
> 
> As I said in the previous reply, IMO restarting the stopped tick
> before leaving the loop in do_idle() is pointless overhead.  It is not
> necessary to do that to avoid leaving CPUs in shallow idle states for
> too long (I'll send an alternative patch to fix this issue shortly).
> 
> While you may think that pointless overhead is not a problem, I don't
> quite agree with that.

I disagree this patch will introduce any extra overhead.

Firstly, the idle loop doesn't support restarting tick even this patch
tells idle loop to restart the tick; secondly this patch is mainly to
resolve issue for the CPU cannot stay in deepest state in Case 2, as a
side effect it also can tell idle loop to restart the tick for case 3
in below, actually IMHO this makes sense to tell the idle loop to
enable the tick but idle loop can ignore this info.

Furthermore, we have another thread for the patch to always stop
tick after the the tick has been stopped in the idle loop.

So this patch is still valid.

Case 3:
  Deepest idle state's target residency = 2ms
 |
 V
|> time (ms)
  ^`
  | \
TICK_USEC=1ms   expected_interval = 1.5ms

[PATCH v6 2/6] dt-bindings: iio: accel: Add docs for ADXL372

[Stefan Popa]

Add the device tree binding documentation for the ADXL372 3-axis digital
accelerometer.

Signed-off-by: Stefan Popa 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/iio/accel/adxl372.txt  | 22 ++
 MAINTAINERS|  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt

diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt 
b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
new file mode 100644
index 000..9409984
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
@@ -0,0 +1,22 @@
+Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
+
+http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
+
+Required properties:
+ - compatible : should be "adi,adxl372"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use
+
+Optional properties:
+ - interrupts: interrupt mapping for IRQ as documented in
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Example:
+
+   accelerometer@0 {
+   compatible = "adi,adxl372";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   interrupt-parent = <>;
+   interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ba47bb..c8dd09c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -548,6 +548,7 @@ M:  Stefan Popa 
 W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/iio/accel/adxl372.c
+F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
 
 AF9013 MEDIA DRIVER
 M: Antti Palosaari 
-- 
2.7.4

[PATCH v6 2/6] dt-bindings: iio: accel: Add docs for ADXL372

[Stefan Popa]

Add the device tree binding documentation for the ADXL372 3-axis digital
accelerometer.

Signed-off-by: Stefan Popa 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/iio/accel/adxl372.txt  | 22 ++
 MAINTAINERS|  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt

diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt 
b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
new file mode 100644
index 000..9409984
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
@@ -0,0 +1,22 @@
+Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
+
+http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
+
+Required properties:
+ - compatible : should be "adi,adxl372"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use
+
+Optional properties:
+ - interrupts: interrupt mapping for IRQ as documented in
+   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Example:
+
+   accelerometer@0 {
+   compatible = "adi,adxl372";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   interrupt-parent = <>;
+   interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2ba47bb..c8dd09c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -548,6 +548,7 @@ M:  Stefan Popa 
 W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/iio/accel/adxl372.c
+F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
 
 AF9013 MEDIA DRIVER
 M: Antti Palosaari 
-- 
2.7.4

[PATCH v6 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer

[Stefan Popa]

This patch adds basic support for Analog Devices ADXL372 SPI-Bus
Three-Axis Digital Accelerometer.

The device is probed and configured the with some initial default
values. With this basic driver, it is possible to read raw acceleration
data.

Datasheet:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL372.pdf

Signed-off-by: Stefan Popa 
---
 MAINTAINERS |   6 +
 drivers/iio/accel/Kconfig   |  11 +
 drivers/iio/accel/Makefile  |   1 +
 drivers/iio/accel/adxl372.c | 525 
 4 files changed, 543 insertions(+)
 create mode 100644 drivers/iio/accel/adxl372.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 60b1028..2ba47bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -543,6 +543,12 @@ W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/misc/adxl34x.c
 
+ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER
+M: Stefan Popa 
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/iio/accel/adxl372.c
+
 AF9013 MEDIA DRIVER
 M: Antti Palosaari 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 62ae7e5..1b496ef 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -60,6 +60,17 @@ config ADXL345_SPI
  will be called adxl345_spi and you will also get adxl345_core
  for the core module.
 
+config ADXL372
+   tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver"
+   depends on SPI
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to add support for the Analog Devices ADXL372 triaxial
+ acceleration sensor.
+ To compile this driver as a module, choose M here: the
+ module will be called adxl372.
+
 config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 636d4d1..5758ffc 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o
 obj-$(CONFIG_ADXL345) += adxl345_core.o
 obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
 obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
+obj-$(CONFIG_ADXL372) += adxl372.o
 obj-$(CONFIG_BMA180) += bma180.o
 obj-$(CONFIG_BMA220) += bma220_spi.o
 obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
new file mode 100644
index 000..db9ecd2
--- /dev/null
+++ b/drivers/iio/accel/adxl372.c
@@ -0,0 +1,525 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ADXL372 3-Axis Digital Accelerometer SPI driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* ADXL372 registers definition */
+#define ADXL372_DEVID  0x00
+#define ADXL372_DEVID_MST  0x01
+#define ADXL372_PARTID 0x02
+#define ADXL372_REVID  0x03
+#define ADXL372_STATUS_1   0x04
+#define ADXL372_STATUS_2   0x05
+#define ADXL372_FIFO_ENTRIES_2 0x06
+#define ADXL372_FIFO_ENTRIES_1 0x07
+#define ADXL372_X_DATA_H   0x08
+#define ADXL372_X_DATA_L   0x09
+#define ADXL372_Y_DATA_H   0x0A
+#define ADXL372_Y_DATA_L   0x0B
+#define ADXL372_Z_DATA_H   0x0C
+#define ADXL372_Z_DATA_L   0x0D
+#define ADXL372_X_MAXPEAK_H0x15
+#define ADXL372_X_MAXPEAK_L0x16
+#define ADXL372_Y_MAXPEAK_H0x17
+#define ADXL372_Y_MAXPEAK_L0x18
+#define ADXL372_Z_MAXPEAK_H0x19
+#define ADXL372_Z_MAXPEAK_L0x1A
+#define ADXL372_OFFSET_X   0x20
+#define ADXL372_OFFSET_Y   0x21
+#define ADXL372_OFFSET_Z   0x22
+#define ADXL372_X_THRESH_ACT_H 0x23
+#define ADXL372_X_THRESH_ACT_L 0x24
+#define ADXL372_Y_THRESH_ACT_H 0x25
+#define ADXL372_Y_THRESH_ACT_L 0x26
+#define ADXL372_Z_THRESH_ACT_H 0x27
+#define ADXL372_Z_THRESH_ACT_L 0x28
+#define ADXL372_TIME_ACT   0x29
+#define ADXL372_X_THRESH_INACT_H   0x2A
+#define ADXL372_X_THRESH_INACT_L   0x2B
+#define ADXL372_Y_THRESH_INACT_H   0x2C
+#define ADXL372_Y_THRESH_INACT_L   0x2D
+#define ADXL372_Z_THRESH_INACT_H   0x2E
+#define ADXL372_Z_THRESH_INACT_L   0x2F
+#define ADXL372_TIME_INACT_H   0x30
+#define ADXL372_TIME_INACT_L   0x31
+#define ADXL372_X_THRESH_ACT2_H0x32
+#define ADXL372_X_THRESH_ACT2_L0x33
+#define ADXL372_Y_THRESH_ACT2_H0x34
+#define ADXL372_Y_THRESH_ACT2_L0x35
+#define ADXL372_Z_THRESH_ACT2_H0x36
+#define ADXL372_Z_THRESH_ACT2_L0x37
+#define ADXL372_HPF0x38
+#define 

[PATCH v6 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer

[Stefan Popa]

This patch adds basic support for Analog Devices ADXL372 SPI-Bus
Three-Axis Digital Accelerometer.

The device is probed and configured the with some initial default
values. With this basic driver, it is possible to read raw acceleration
data.

Datasheet:
http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL372.pdf

Signed-off-by: Stefan Popa 
---
 MAINTAINERS |   6 +
 drivers/iio/accel/Kconfig   |  11 +
 drivers/iio/accel/Makefile  |   1 +
 drivers/iio/accel/adxl372.c | 525 
 4 files changed, 543 insertions(+)
 create mode 100644 drivers/iio/accel/adxl372.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 60b1028..2ba47bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -543,6 +543,12 @@ W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/misc/adxl34x.c
 
+ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER
+M: Stefan Popa 
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/iio/accel/adxl372.c
+
 AF9013 MEDIA DRIVER
 M: Antti Palosaari 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 62ae7e5..1b496ef 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -60,6 +60,17 @@ config ADXL345_SPI
  will be called adxl345_spi and you will also get adxl345_core
  for the core module.
 
+config ADXL372
+   tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver"
+   depends on SPI
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   help
+ Say yes here to add support for the Analog Devices ADXL372 triaxial
+ acceleration sensor.
+ To compile this driver as a module, choose M here: the
+ module will be called adxl372.
+
 config BMA180
tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
depends on I2C
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 636d4d1..5758ffc 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o
 obj-$(CONFIG_ADXL345) += adxl345_core.o
 obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
 obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
+obj-$(CONFIG_ADXL372) += adxl372.o
 obj-$(CONFIG_BMA180) += bma180.o
 obj-$(CONFIG_BMA220) += bma220_spi.o
 obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
new file mode 100644
index 000..db9ecd2
--- /dev/null
+++ b/drivers/iio/accel/adxl372.c
@@ -0,0 +1,525 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ADXL372 3-Axis Digital Accelerometer SPI driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/* ADXL372 registers definition */
+#define ADXL372_DEVID  0x00
+#define ADXL372_DEVID_MST  0x01
+#define ADXL372_PARTID 0x02
+#define ADXL372_REVID  0x03
+#define ADXL372_STATUS_1   0x04
+#define ADXL372_STATUS_2   0x05
+#define ADXL372_FIFO_ENTRIES_2 0x06
+#define ADXL372_FIFO_ENTRIES_1 0x07
+#define ADXL372_X_DATA_H   0x08
+#define ADXL372_X_DATA_L   0x09
+#define ADXL372_Y_DATA_H   0x0A
+#define ADXL372_Y_DATA_L   0x0B
+#define ADXL372_Z_DATA_H   0x0C
+#define ADXL372_Z_DATA_L   0x0D
+#define ADXL372_X_MAXPEAK_H0x15
+#define ADXL372_X_MAXPEAK_L0x16
+#define ADXL372_Y_MAXPEAK_H0x17
+#define ADXL372_Y_MAXPEAK_L0x18
+#define ADXL372_Z_MAXPEAK_H0x19
+#define ADXL372_Z_MAXPEAK_L0x1A
+#define ADXL372_OFFSET_X   0x20
+#define ADXL372_OFFSET_Y   0x21
+#define ADXL372_OFFSET_Z   0x22
+#define ADXL372_X_THRESH_ACT_H 0x23
+#define ADXL372_X_THRESH_ACT_L 0x24
+#define ADXL372_Y_THRESH_ACT_H 0x25
+#define ADXL372_Y_THRESH_ACT_L 0x26
+#define ADXL372_Z_THRESH_ACT_H 0x27
+#define ADXL372_Z_THRESH_ACT_L 0x28
+#define ADXL372_TIME_ACT   0x29
+#define ADXL372_X_THRESH_INACT_H   0x2A
+#define ADXL372_X_THRESH_INACT_L   0x2B
+#define ADXL372_Y_THRESH_INACT_H   0x2C
+#define ADXL372_Y_THRESH_INACT_L   0x2D
+#define ADXL372_Z_THRESH_INACT_H   0x2E
+#define ADXL372_Z_THRESH_INACT_L   0x2F
+#define ADXL372_TIME_INACT_H   0x30
+#define ADXL372_TIME_INACT_L   0x31
+#define ADXL372_X_THRESH_ACT2_H0x32
+#define ADXL372_X_THRESH_ACT2_L0x33
+#define ADXL372_Y_THRESH_ACT2_H0x34
+#define ADXL372_Y_THRESH_ACT2_L0x35
+#define ADXL372_Z_THRESH_ACT2_H0x36
+#define ADXL372_Z_THRESH_ACT2_L0x37
+#define ADXL372_HPF0x38
+#define 

Re: [PATCH] x86, kdump: Fix efi=noruntime NULL pointer dereference

[Dave Young]

On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> When booting with efi=noruntime, we call efi_runtime_map_copy() while
> loading the kdump kernel, and trip over a NULL efi.memmap.map.  Avoid
> that and a useless allocation when the only mapping we can use (1:1)
> is not available.
> 
> Signed-off-by: Mike Galbraith 
> ---
>  arch/x86/kernel/kexec-bzimage64.c |   22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -122,9 +122,6 @@ static int setup_efi_info_memmap(struct
>   unsigned long efi_map_phys_addr = params_load_addr + efi_map_offset;
>   struct efi_info *ei = >efi_info;
>  
> - if (!efi_map_sz)
> - return 0;
> -
>   efi_runtime_map_copy(efi_map, efi_map_sz);
>  
>   ei->efi_memmap = efi_map_phys_addr & 0x;
> @@ -176,7 +173,7 @@ setup_efi_state(struct boot_params *para
>* acpi_rsdp= on kernel command line to make second kernel boot
>* without efi.
>*/
> - if (efi_enabled(EFI_OLD_MEMMAP))
> + if (efi_enabled(EFI_OLD_MEMMAP) || !efi_enabled(EFI_MEMMAP))
>   return 0;
>  
>   ei->efi_loader_signature = current_ei->efi_loader_signature;
> @@ -338,7 +335,7 @@ static void *bzImage64_load(struct kimag
>   struct kexec_entry64_regs regs64;
>   void *stack;
>   unsigned int setup_hdr_offset = offsetof(struct boot_params, hdr);
> - unsigned int efi_map_offset, efi_map_sz, efi_setup_data_offset;
> + unsigned int efi_map_offset = 0, efi_map_sz = 0, efi_setup_data_offset 
> = 0;
>   struct kexec_buf kbuf = { .image = image, .buf_max = ULONG_MAX,
> .top_down = true };
>   struct kexec_buf pbuf = { .image = image, .buf_min = MIN_PURGATORY_ADDR,
> @@ -397,19 +394,22 @@ static void *bzImage64_load(struct kimag
>* have to create separate segment for each. Keeps things
>* little bit simple
>*/
> - efi_map_sz = efi_get_runtime_map_size();
>   params_cmdline_sz = sizeof(struct boot_params) + cmdline_len +
>   MAX_ELFCOREHDR_STR_LEN;
>   params_cmdline_sz = ALIGN(params_cmdline_sz, 16);
> - kbuf.bufsz = params_cmdline_sz + ALIGN(efi_map_sz, 16) +
> - sizeof(struct setup_data) +
> - sizeof(struct efi_setup_data);
> + kbuf.bufsz = params_cmdline_sz + sizeof(struct setup_data);
> +
> + /* Now add space for the efi stuff if we have a useable 1:1 mapping. */
> + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_MEMMAP)) {
> + efi_map_sz = efi_get_runtime_map_size();
> + kbuf.bufsz += ALIGN(efi_map_sz, 16) + sizeof(struct 
> efi_setup_data);
> + efi_map_offset = params_cmdline_sz;
> + efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
> + }
>  
>   params = kzalloc(kbuf.bufsz, GFP_KERNEL);
>   if (!params)
>   return ERR_PTR(-ENOMEM);
> - efi_map_offset = params_cmdline_sz;
> - efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
>  
>   /* Copy setup header onto bootparams. Documentation/x86/boot.txt */
>   setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;

BTW, this patch only fix the kexec load phase problem,  even if kexec
load successfully with the fix, the 2nd kernel can not boot because efi
memmap info is not correct and usable.

So we should go with some fix similar to below, and do the cleanup we
mentioned with a separate patch later.

Also user space kexec-tools need a similar patch to error out in case
no runtime maps.  It would be good to fix both userspace and kernel
load.

diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index 7326078eaa7a..e34ba2f53cfb 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -123,7 +123,7 @@ static int setup_efi_info_memmap(struct boot_params *params,
struct efi_info *ei = >efi_info;
 
if (!efi_map_sz)
-   return 0;
+   return -EINVAL;
 
efi_runtime_map_copy(efi_map, efi_map_sz);
 
@@ -166,9 +166,10 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
 {
struct efi_info *current_ei = _params.efi_info;
struct efi_info *ei = >efi_info;
+   int ret;
 
if (!current_ei->efi_memmap_size)
-   return 0;
+   return -EINVAL;
 
/*
 * If 1:1 mapping is not enabled, second kernel can not setup EFI
@@ -176,8 +177,8 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
 * acpi_rsdp= on kernel command line to make second kernel boot
 * without efi.
 */
-   if (efi_enabled(EFI_OLD_MEMMAP))
-   return 0;
+   if (efi_enabled(EFI_OLD_MEMMAP) || !efi_enabled(EFI_RUNTIME_SERVICES))
+   return 

Re: [PATCH] x86, kdump: Fix efi=noruntime NULL pointer dereference

[Dave Young]

On 08/08/18 at 04:03pm, Mike Galbraith wrote:
> When booting with efi=noruntime, we call efi_runtime_map_copy() while
> loading the kdump kernel, and trip over a NULL efi.memmap.map.  Avoid
> that and a useless allocation when the only mapping we can use (1:1)
> is not available.
> 
> Signed-off-by: Mike Galbraith 
> ---
>  arch/x86/kernel/kexec-bzimage64.c |   22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -122,9 +122,6 @@ static int setup_efi_info_memmap(struct
>   unsigned long efi_map_phys_addr = params_load_addr + efi_map_offset;
>   struct efi_info *ei = >efi_info;
>  
> - if (!efi_map_sz)
> - return 0;
> -
>   efi_runtime_map_copy(efi_map, efi_map_sz);
>  
>   ei->efi_memmap = efi_map_phys_addr & 0x;
> @@ -176,7 +173,7 @@ setup_efi_state(struct boot_params *para
>* acpi_rsdp= on kernel command line to make second kernel boot
>* without efi.
>*/
> - if (efi_enabled(EFI_OLD_MEMMAP))
> + if (efi_enabled(EFI_OLD_MEMMAP) || !efi_enabled(EFI_MEMMAP))
>   return 0;
>  
>   ei->efi_loader_signature = current_ei->efi_loader_signature;
> @@ -338,7 +335,7 @@ static void *bzImage64_load(struct kimag
>   struct kexec_entry64_regs regs64;
>   void *stack;
>   unsigned int setup_hdr_offset = offsetof(struct boot_params, hdr);
> - unsigned int efi_map_offset, efi_map_sz, efi_setup_data_offset;
> + unsigned int efi_map_offset = 0, efi_map_sz = 0, efi_setup_data_offset 
> = 0;
>   struct kexec_buf kbuf = { .image = image, .buf_max = ULONG_MAX,
> .top_down = true };
>   struct kexec_buf pbuf = { .image = image, .buf_min = MIN_PURGATORY_ADDR,
> @@ -397,19 +394,22 @@ static void *bzImage64_load(struct kimag
>* have to create separate segment for each. Keeps things
>* little bit simple
>*/
> - efi_map_sz = efi_get_runtime_map_size();
>   params_cmdline_sz = sizeof(struct boot_params) + cmdline_len +
>   MAX_ELFCOREHDR_STR_LEN;
>   params_cmdline_sz = ALIGN(params_cmdline_sz, 16);
> - kbuf.bufsz = params_cmdline_sz + ALIGN(efi_map_sz, 16) +
> - sizeof(struct setup_data) +
> - sizeof(struct efi_setup_data);
> + kbuf.bufsz = params_cmdline_sz + sizeof(struct setup_data);
> +
> + /* Now add space for the efi stuff if we have a useable 1:1 mapping. */
> + if (!efi_enabled(EFI_OLD_MEMMAP) && efi_enabled(EFI_MEMMAP)) {
> + efi_map_sz = efi_get_runtime_map_size();
> + kbuf.bufsz += ALIGN(efi_map_sz, 16) + sizeof(struct 
> efi_setup_data);
> + efi_map_offset = params_cmdline_sz;
> + efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
> + }
>  
>   params = kzalloc(kbuf.bufsz, GFP_KERNEL);
>   if (!params)
>   return ERR_PTR(-ENOMEM);
> - efi_map_offset = params_cmdline_sz;
> - efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
>  
>   /* Copy setup header onto bootparams. Documentation/x86/boot.txt */
>   setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;

BTW, this patch only fix the kexec load phase problem,  even if kexec
load successfully with the fix, the 2nd kernel can not boot because efi
memmap info is not correct and usable.

So we should go with some fix similar to below, and do the cleanup we
mentioned with a separate patch later.

Also user space kexec-tools need a similar patch to error out in case
no runtime maps.  It would be good to fix both userspace and kernel
load.

diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index 7326078eaa7a..e34ba2f53cfb 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -123,7 +123,7 @@ static int setup_efi_info_memmap(struct boot_params *params,
struct efi_info *ei = >efi_info;
 
if (!efi_map_sz)
-   return 0;
+   return -EINVAL;
 
efi_runtime_map_copy(efi_map, efi_map_sz);
 
@@ -166,9 +166,10 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
 {
struct efi_info *current_ei = _params.efi_info;
struct efi_info *ei = >efi_info;
+   int ret;
 
if (!current_ei->efi_memmap_size)
-   return 0;
+   return -EINVAL;
 
/*
 * If 1:1 mapping is not enabled, second kernel can not setup EFI
@@ -176,8 +177,8 @@ setup_efi_state(struct boot_params *params, unsigned long 
params_load_addr,
 * acpi_rsdp= on kernel command line to make second kernel boot
 * without efi.
 */
-   if (efi_enabled(EFI_OLD_MEMMAP))
-   return 0;
+   if (efi_enabled(EFI_OLD_MEMMAP) || !efi_enabled(EFI_RUNTIME_SERVICES))
+   return 

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Rafael J. Wysocki]

Hi Quentin,

On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
> Hi Rafael,
> 
> On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> > I'm a bit concerned that the code here appears to be designed around the
> > frequency domains concept which seems to be a limitation and which probably
> > is related to the properties of the current generation of hardware.
> 
> That's correct. I went for 'frequency domains' only because this is what
> EAS and IPA are interested in, as of today at least. And both of them
> are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
> CPU-Perf after all :-)

Still, cpufreq manages CPU performance scaling really.

A cpufreq policy may represent a frequency domain or generally a group of
related CPUs and what matters is that there is a coordination between them
and not how that coordination happens at the hardware/firmware level etc.

> > Assumptions like that tend to get tangled into the code tightly over time
> > and they may be hard to untangle from it when new use cases arise later.
> > 
> > For example, there probably will be more firmware involvement in future
> > systems and the firmware may not be willing to expose "raw" frequency
> > domains to the OS.  That already is the case with P-states on Intel HW and
> > with ACPI CPPC in general.
> 
> Agreed, and embedded/mobile systems are going in that direction too ...
> 
> > IMO, frequency domains in your current code could be replaced with something
> > more general, like "performance domains"
> 
> I don't mind using a more abstract name as long as we keep the same
> assumptions, and especially that all CPUs in a perf. domain *must* have
> the same micro-architecture.

That's fair enough I think.

> From that assumption result several
> properties that EAS (in its current) form needs. The first one is that
> all CPUs of a performance domain have the same capacity at any possible
> performance state. And the second is that they all consume the same
> amount of (active) power.
> 
> I know it is theoretically possible to mix CPU types in the same perf
> domain, but that becomes nightmare-ish to manage in EAS, and I don't
> think there is a single platform like this on the market today. And I
> hope nobody will build one. Peter wanted to mandate that too, I think.

There are departures, say, at least as far as the capacity is concerned.

The uarch is the same for all of them, but the max capacity may vary
between them.

> > providing the scheduler with the (relative) cost of running a task
> 
> What do you mean by relative ? That we should normalize the power costs ?
> Or just use an abstract scale, without specifying the unit ?

I mean "relative with respect to the other choices"; not absolute.

> The main reason I'm a bit reluctant to do that just now is because IPA
> needs to compare the power of CPUs with the power of other components
> (GPUs, for example). And the power of those other components is specified
> with a specific unit too. So, not imposing a comparable unit for the
> power of CPUs will result in an unspecified behaviour in IPA, and that
> will break things for sure. I would very much like to avoid that, of
> course.

The absolute power numbers are generally hard to get though.

In the majority of cases you can figure out what the extra cost of X with
respect to (alternative) Y is (in certain units), but you may not be able
to say what X and Y are equal to in absolute terms (for example, there
may be an unknown component in both X and Y that you cannot measure, but
it may not be relevant for the outcome of the computation).

> What I am currently proposing is to keep the unit (mW) in the EM
> framework so that migrating IPA to using it can be done in a (relatively)
> painless way. On a system where drivers  don't know the exact wattage,
> then they should just 'lie' to the EM framework, but it's their job to
> lie coherently to all subsystems and keep things consistent, because all
> subsystems have specified power in comparable units.

Alternatively, there could be a translation layer between EM and IPA.

>From my experience, if you want people to come up with some numbers,
they will just choose them to game the system this way or another
unless those numbers can be measured directly or are clearly documented.

And if that happens and then you want to make any significant changes,
you'll need to deal with "regressions" occuring because someone chose
the numbers to make the system behave in a specific way and your changes
break that.

As a rule, I rather avoid requesting unknown numbers from people. :-)

> Another solution to solve this problem could be to extend the EM
> framework introduced by this patch and make it manage the EM of any
> device, not just CPUs. Then we could just specify that all power costs
> must be in the same scale, regardless of the actual unit, and register
> the EM of CPUs, GPUs, ...
> However, I was hoping that this patch as-is was 

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Rafael J. Wysocki]

Hi Quentin,

On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote:
> Hi Rafael,
> 
> On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> > I'm a bit concerned that the code here appears to be designed around the
> > frequency domains concept which seems to be a limitation and which probably
> > is related to the properties of the current generation of hardware.
> 
> That's correct. I went for 'frequency domains' only because this is what
> EAS and IPA are interested in, as of today at least. And both of them
> are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
> CPU-Perf after all :-)

Still, cpufreq manages CPU performance scaling really.

A cpufreq policy may represent a frequency domain or generally a group of
related CPUs and what matters is that there is a coordination between them
and not how that coordination happens at the hardware/firmware level etc.

> > Assumptions like that tend to get tangled into the code tightly over time
> > and they may be hard to untangle from it when new use cases arise later.
> > 
> > For example, there probably will be more firmware involvement in future
> > systems and the firmware may not be willing to expose "raw" frequency
> > domains to the OS.  That already is the case with P-states on Intel HW and
> > with ACPI CPPC in general.
> 
> Agreed, and embedded/mobile systems are going in that direction too ...
> 
> > IMO, frequency domains in your current code could be replaced with something
> > more general, like "performance domains"
> 
> I don't mind using a more abstract name as long as we keep the same
> assumptions, and especially that all CPUs in a perf. domain *must* have
> the same micro-architecture.

That's fair enough I think.

> From that assumption result several
> properties that EAS (in its current) form needs. The first one is that
> all CPUs of a performance domain have the same capacity at any possible
> performance state. And the second is that they all consume the same
> amount of (active) power.
> 
> I know it is theoretically possible to mix CPU types in the same perf
> domain, but that becomes nightmare-ish to manage in EAS, and I don't
> think there is a single platform like this on the market today. And I
> hope nobody will build one. Peter wanted to mandate that too, I think.

There are departures, say, at least as far as the capacity is concerned.

The uarch is the same for all of them, but the max capacity may vary
between them.

> > providing the scheduler with the (relative) cost of running a task
> 
> What do you mean by relative ? That we should normalize the power costs ?
> Or just use an abstract scale, without specifying the unit ?

I mean "relative with respect to the other choices"; not absolute.

> The main reason I'm a bit reluctant to do that just now is because IPA
> needs to compare the power of CPUs with the power of other components
> (GPUs, for example). And the power of those other components is specified
> with a specific unit too. So, not imposing a comparable unit for the
> power of CPUs will result in an unspecified behaviour in IPA, and that
> will break things for sure. I would very much like to avoid that, of
> course.

The absolute power numbers are generally hard to get though.

In the majority of cases you can figure out what the extra cost of X with
respect to (alternative) Y is (in certain units), but you may not be able
to say what X and Y are equal to in absolute terms (for example, there
may be an unknown component in both X and Y that you cannot measure, but
it may not be relevant for the outcome of the computation).

> What I am currently proposing is to keep the unit (mW) in the EM
> framework so that migrating IPA to using it can be done in a (relatively)
> painless way. On a system where drivers  don't know the exact wattage,
> then they should just 'lie' to the EM framework, but it's their job to
> lie coherently to all subsystems and keep things consistent, because all
> subsystems have specified power in comparable units.

Alternatively, there could be a translation layer between EM and IPA.

>From my experience, if you want people to come up with some numbers,
they will just choose them to game the system this way or another
unless those numbers can be measured directly or are clearly documented.

And if that happens and then you want to make any significant changes,
you'll need to deal with "regressions" occuring because someone chose
the numbers to make the system behave in a specific way and your changes
break that.

As a rule, I rather avoid requesting unknown numbers from people. :-)

> Another solution to solve this problem could be to extend the EM
> framework introduced by this patch and make it manage the EM of any
> device, not just CPUs. Then we could just specify that all power costs
> must be in the same scale, regardless of the actual unit, and register
> the EM of CPUs, GPUs, ...
> However, I was hoping that this patch as-is was 

Re: [PATCH] riscv: Drop setup_initrd

[Christoph Hellwig]

On Thu, Aug 09, 2018 at 09:11:40PM -0700, Guenter Roeck wrote:
> setup_initrd() does not appear to serve a practical purpose other than
> preventing qemu boots with "-initrd" parameter, so let's drop it.
> 
> Signed-off-by: Guenter Roeck 

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH] riscv: Drop setup_initrd

[Christoph Hellwig]

On Thu, Aug 09, 2018 at 09:11:40PM -0700, Guenter Roeck wrote:
> setup_initrd() does not appear to serve a practical purpose other than
> preventing qemu boots with "-initrd" parameter, so let's drop it.
> 
> Signed-off-by: Guenter Roeck 

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Christoph Hellwig]

On Thu, Aug 09, 2018 at 03:19:51PM -0700, Palmer Dabbelt wrote:
> This would be necessary to make non-SMP builds work, but there is
> another error in the implementation of our syscall linkage that actually
> just causes sys_riscv_flush_icache to never build.  I've build tested
> this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
> normal.

Would't it make sense to use COND_SYSCALL to stub out the syscall
for !SMP builds?

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Christoph Hellwig]

On Thu, Aug 09, 2018 at 03:19:51PM -0700, Palmer Dabbelt wrote:
> This would be necessary to make non-SMP builds work, but there is
> another error in the implementation of our syscall linkage that actually
> just causes sys_riscv_flush_icache to never build.  I've build tested
> this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
> normal.

Would't it make sense to use COND_SYSCALL to stub out the syscall
for !SMP builds?

Re: a13c600e15 ("x86/mm/pti: Move user W+X check into .."): WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:283 note_page

[Joerg Roedel]

On Fri, Aug 10, 2018 at 06:33:42AM +0800, kernel test robot wrote:
> commit a13c600e15de44ccf03df28d3311ef3cb754ed9b
> Author: Joerg Roedel 
> AuthorDate: Wed Aug 8 13:16:40 2018 +0200
> Commit: Thomas Gleixner 
> CommitDate: Thu Aug 9 20:42:07 2018 +0200
> 
> x86/mm/pti: Move user W+X check into pti_finalize()

Okay, I found the problem and the diff below fixes it.

Ingo, Thomas, can you fold that diff into above commit or do you prefer
a separate patch?

Thanks and sorry for the hassle,


   Joerg

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 026a89aa16d7..d1435c78ae4f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -629,5 +629,6 @@ void pti_finalize(void)
pti_clone_entry_text();
pti_clone_kernel_text();
 
-   debug_checkwx_user();
+   if (__supported_pte_mask & _PAGE_NX)
+   debug_checkwx_user();
 }

Re: a13c600e15 ("x86/mm/pti: Move user W+X check into .."): WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:283 note_page

[Joerg Roedel]

On Fri, Aug 10, 2018 at 06:33:42AM +0800, kernel test robot wrote:
> commit a13c600e15de44ccf03df28d3311ef3cb754ed9b
> Author: Joerg Roedel 
> AuthorDate: Wed Aug 8 13:16:40 2018 +0200
> Commit: Thomas Gleixner 
> CommitDate: Thu Aug 9 20:42:07 2018 +0200
> 
> x86/mm/pti: Move user W+X check into pti_finalize()

Okay, I found the problem and the diff below fixes it.

Ingo, Thomas, can you fold that diff into above commit or do you prefer
a separate patch?

Thanks and sorry for the hassle,


   Joerg

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 026a89aa16d7..d1435c78ae4f 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -629,5 +629,6 @@ void pti_finalize(void)
pti_clone_entry_text();
pti_clone_kernel_text();
 
-   debug_checkwx_user();
+   if (__supported_pte_mask & _PAGE_NX)
+   debug_checkwx_user();
 }

Please respond urgently!

[Ahmed Hassan]

Dear Friend,

I know that this mail will come to you as a surprise as we have never met 
before, but need not to worry as I am contacting you independently of my 
investigation and no one is informed of this communication. I need your urgent 
assistance in transferring the sum of $11.3million immediately to your private 
account.The money has been here in our Bank lying dormant for years now without 
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased customer 
(the account owner) who died a long with his supposed NEXT OF KIN since 16th 
October 2005. The Banking laws here does not allow such money to stay more than 
13 years, because the money will be recalled to the Bank treasury account as 
unclaimed fund.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please respond urgently and delete if you are not interested.

Best Regards,
Mr. Ahmed Hassan.

Please respond urgently!

[Ahmed Hassan]

Dear Friend,

I know that this mail will come to you as a surprise as we have never met 
before, but need not to worry as I am contacting you independently of my 
investigation and no one is informed of this communication. I need your urgent 
assistance in transferring the sum of $11.3million immediately to your private 
account.The money has been here in our Bank lying dormant for years now without 
anybody coming for the claim of it.

I want to release the money to you as the relative to our deceased customer 
(the account owner) who died a long with his supposed NEXT OF KIN since 16th 
October 2005. The Banking laws here does not allow such money to stay more than 
13 years, because the money will be recalled to the Bank treasury account as 
unclaimed fund.

By indicating your interest I will send you the full details on how the 
business will be executed.

Please respond urgently and delete if you are not interested.

Best Regards,
Mr. Ahmed Hassan.

Re: [PATCH v3] resource: Merge resources on a node when hot-adding memory

[Vlastimil Babka]

On 08/10/2018 08:55 AM, Rashmica Gupta wrote:
> On Fri, Aug 10, 2018 at 11:12 AM, Andrew Morton
>  wrote:
>>
>> What is the end-user impact of this patch?
>>
> 
> Only architectures/setups that allow the user to remove and add memory of
> different sizes or different start addresses from the kernel at runtime will
> potentially encounter the resource fragmentation.
> 
> Trying to remove memory that overlaps iomem resources the first time
> gives us this warning: "Unable to release resource <%pa-%pa>".
> 
> Attempting a second time results in a kernel oops (on ppc at least).

An oops? I think that should be investigated and fixed, even if resource
merging prevents it. Do you have the details?

Thanks,
Vlastimil

Re: [PATCH v3] resource: Merge resources on a node when hot-adding memory

[Vlastimil Babka]

On 08/10/2018 08:55 AM, Rashmica Gupta wrote:
> On Fri, Aug 10, 2018 at 11:12 AM, Andrew Morton
>  wrote:
>>
>> What is the end-user impact of this patch?
>>
> 
> Only architectures/setups that allow the user to remove and add memory of
> different sizes or different start addresses from the kernel at runtime will
> potentially encounter the resource fragmentation.
> 
> Trying to remove memory that overlaps iomem resources the first time
> gives us this warning: "Unable to release resource <%pa-%pa>".
> 
> Attempting a second time results in a kernel oops (on ppc at least).

An oops? I think that should be investigated and fixed, even if resource
merging prevents it. Do you have the details?

Thanks,
Vlastimil

Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

[Marek Szyprowski]

Hi Ravi,

Just to let you know - I hope I've finally bisected all the issues related
to suspend/resume on Samsung Chromebooks with mainline kernel. I did my
tests on Linux next-20180809. The mentioned commit 38ba34a43dbc ("Input:
cros_ec_keyb - mark cros_ec_keyb driver as wake enabled device.") breaks
suspend/resume operation also on Samsung Exynos5420-based Peach-Pit
Chromebook. Here is some more information how to get suspend/resume
working with mainline on that board:
https://patchwork.kernel.org/patch/10562419/

Best regards
Marek Szyprowski, PhD
Samsung R Institute Poland

On 2018-08-08 07:03, Marek Szyprowski wrote:
> Hi Ravi,
>
> On 2018-08-07 23:59, Ravi Chandra Sadineni wrote:
>> hi Merek,
>>
>> I tried booting a snow device and could not get it to boot it to the
>> console. I assume i don't have right kernel config. Can you share your
>> config if possible.
>
> I use standard exynos_defconfig bundled with Linux kernel. I've followed
> this instruction to boot in on Snow:
>
> https://s-opensource.org/2016/03/24/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/
>  
>
>
>>
>> Thanks,
>> RaviOn Mon, Aug 6, 2018 at 4:05 PM Ravi Chandra Sadineni
>>  wrote:
>>> Hi Merek,
>>>
>>> Thanks for the info. Lemme understand what's going on. Will update the
>>> thread once I have more info.
>>>
>>> Thanks,
>>> Ravi
>>> On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
>>>  wrote:
 Hi Dmitry

 On 2018-08-06 08:16, Dmitry Torokhov wrote:
> On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
>  wrote:
>> Hi Ravi,
>>
>> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
>>> Understood. I am trying to reproduce this issue locally. Wanted to
>>> know the version of the kernel so I can give a try. Marek, can you
>>> please confirm the kernel version.
>>>
>> Yes, sorry for the missing context, I was in hurry writing the 
>> report and
>> I wanted to send it before leaving the office. I'm testing 
>> mainline on Snow
>> with exynos_defconfig.
>>
>> Suspend/resume is partially broken already with mainline, but if 
>> you disable
>> CPUfreq support, it works fine on Linux v4.17.
>>
>> I've posted CPUfreq related fixes here if you are interested:
>> https://patchwork.kernel.org/patch/10554607/
>> https://patchwork.kernel.org/patch/10554603/
>>
>> The issue with cros_ec_keyb patch appears first on Linux 
>> v4.18-rc1, which is
>> the first release with that patch.
> Marek, this patch should only be in -next, I do not believe I sent it
> to Linus just yet. If mainline is broken for you it can't be 
> caused by
> this patch.
 Aaahh. My fault then. The suspend/resume issue is cause by commit
 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
 enabled device."), which has been merged to v4.18-rc1.

 It looks that I've downloaded wrong patch from the patchwork to 
 reply it
 with a a bug report. :( I'm really sorry for the noise in the wrong 
 thread.

 Ravi: please let me know how can I help you to debug this issue.

>> Linux -next from 20180803, which has a few
>> more patches for cros_ec_keyb suffers from the same issue.
> Just to confirm, if you revert only this patch from -next you get
> suspend/resume back?
>
> Thanks.
 Best regards
 -- 
 Marek Szyprowski, PhD
 Samsung R Institute Poland

>>
>
> Best regards

Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

[Marek Szyprowski]

Hi Ravi,

Just to let you know - I hope I've finally bisected all the issues related
to suspend/resume on Samsung Chromebooks with mainline kernel. I did my
tests on Linux next-20180809. The mentioned commit 38ba34a43dbc ("Input:
cros_ec_keyb - mark cros_ec_keyb driver as wake enabled device.") breaks
suspend/resume operation also on Samsung Exynos5420-based Peach-Pit
Chromebook. Here is some more information how to get suspend/resume
working with mainline on that board:
https://patchwork.kernel.org/patch/10562419/

Best regards
Marek Szyprowski, PhD
Samsung R Institute Poland

On 2018-08-08 07:03, Marek Szyprowski wrote:
> Hi Ravi,
>
> On 2018-08-07 23:59, Ravi Chandra Sadineni wrote:
>> hi Merek,
>>
>> I tried booting a snow device and could not get it to boot it to the
>> console. I assume i don't have right kernel config. Can you share your
>> config if possible.
>
> I use standard exynos_defconfig bundled with Linux kernel. I've followed
> this instruction to boot in on Snow:
>
> https://s-opensource.org/2016/03/24/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/
>  
>
>
>>
>> Thanks,
>> RaviOn Mon, Aug 6, 2018 at 4:05 PM Ravi Chandra Sadineni
>>  wrote:
>>> Hi Merek,
>>>
>>> Thanks for the info. Lemme understand what's going on. Will update the
>>> thread once I have more info.
>>>
>>> Thanks,
>>> Ravi
>>> On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
>>>  wrote:
 Hi Dmitry

 On 2018-08-06 08:16, Dmitry Torokhov wrote:
> On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
>  wrote:
>> Hi Ravi,
>>
>> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
>>> Understood. I am trying to reproduce this issue locally. Wanted to
>>> know the version of the kernel so I can give a try. Marek, can you
>>> please confirm the kernel version.
>>>
>> Yes, sorry for the missing context, I was in hurry writing the 
>> report and
>> I wanted to send it before leaving the office. I'm testing 
>> mainline on Snow
>> with exynos_defconfig.
>>
>> Suspend/resume is partially broken already with mainline, but if 
>> you disable
>> CPUfreq support, it works fine on Linux v4.17.
>>
>> I've posted CPUfreq related fixes here if you are interested:
>> https://patchwork.kernel.org/patch/10554607/
>> https://patchwork.kernel.org/patch/10554603/
>>
>> The issue with cros_ec_keyb patch appears first on Linux 
>> v4.18-rc1, which is
>> the first release with that patch.
> Marek, this patch should only be in -next, I do not believe I sent it
> to Linus just yet. If mainline is broken for you it can't be 
> caused by
> this patch.
 Aaahh. My fault then. The suspend/resume issue is cause by commit
 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
 enabled device."), which has been merged to v4.18-rc1.

 It looks that I've downloaded wrong patch from the patchwork to 
 reply it
 with a a bug report. :( I'm really sorry for the noise in the wrong 
 thread.

 Ravi: please let me know how can I help you to debug this issue.

>> Linux -next from 20180803, which has a few
>> more patches for cros_ec_keyb suffers from the same issue.
> Just to confirm, if you revert only this patch from -next you get
> suspend/resume back?
>
> Thanks.
 Best regards
 -- 
 Marek Szyprowski, PhD
 Samsung R Institute Poland

>>
>
> Best regards

Re: [PATCH v2] perf ordered_events: fix crash in free_dup_event()

[Stephane Eranian]

On Thu, Aug 9, 2018 at 1:07 AM Jiri Olsa  wrote:
>
> On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> > This patch fixes a bug in ordered_event.c:alloc_event().
> > An ordered_event struct was not initialized properly potentially
> > causing crashes later on in free_dup_event() depending on the
> > content of the memory. If it was NULL, then it would work fine,
> > otherwise, it could cause crashes such as:
>
> I'm now little puzzled what do we use this first event for..
> I can't see anything special about it, other than it's added
> on the list uninitialized ;-)
>
> it seems to work properly when we ditch it.. might be some
> prehistoric leftover or I'm terribly missing something
>
You need to keep track of the buffers to free. You do not free the
ordered_event structs
individually. For each oe->buffer, you need one free(). Each buffer is
put in the to_free
list. But to link it into the list it needs a list_head. This is what
buffer[0] is used for.
But the logic is broken in  ordered_events__free(). It does not free individual
ordered_event structs, but a buffer with many. Yet, it is missing
freeing all of the duped
events.

 void ordered_events__free(struct ordered_events *oe)
{
while (!list_empty(>to_free)) {
struct ordered_event *buffer;

buffer = list_entry(oe->to_free.next, struct
ordered_event, list);
list_del(>list);
> free_dup_event(oe, event->event);
free(buffer);
}
}
This only frees the dup_event of buffer[0] which we know is NULL (well, now).
It needs to walk all the entries in buffer[] to free buffer[x].event.

I think the goal was likely to avoid adding another list_head field to
each ordered_event
and instead use one per allocated buffer.
This is very convoluted and prone to errors and we are seeing right
now. This should
be cleaned. So either you add a list_head to ordered_event or you
would buffer[x] in
ordered_events_free().

At this point, this is my understanding.
Do you agree?


>
> thanks,
> jirka
>
>
> ---
> diff --cc tools/perf/util/ordered-events.c
> index bad9e0296e9a,0e837b0b8582..
> --- a/tools/perf/util/ordered-events.c
> +++ b/tools/perf/util/ordered-events.c
> @@@ -119,12 -119,8 +119,9 @@@ static struct ordered_event *alloc_even
> pr("alloc size %" PRIu64 "B (+%zu), max %" PRIu64 "B\n",
>oe->cur_alloc_size, size, oe->max_alloc_size);
>
>  +  oe->cur_alloc_size += size;
> -   list_add(>buffer->list, >to_free);
> -
> -   /* First entry is abused to maintain the to_free list. */
> -   oe->buffer_idx = 2;
> -   new = oe->buffer + 1;
> +   oe->buffer_idx = 1;
> +   new = oe->buffer;
> } else {
> pr("allocation limit reached %" PRIu64 "B\n", 
> oe->max_alloc_size);
> }

Re: [PATCH v2] perf ordered_events: fix crash in free_dup_event()

[Stephane Eranian]

On Thu, Aug 9, 2018 at 1:07 AM Jiri Olsa  wrote:
>
> On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> > This patch fixes a bug in ordered_event.c:alloc_event().
> > An ordered_event struct was not initialized properly potentially
> > causing crashes later on in free_dup_event() depending on the
> > content of the memory. If it was NULL, then it would work fine,
> > otherwise, it could cause crashes such as:
>
> I'm now little puzzled what do we use this first event for..
> I can't see anything special about it, other than it's added
> on the list uninitialized ;-)
>
> it seems to work properly when we ditch it.. might be some
> prehistoric leftover or I'm terribly missing something
>
You need to keep track of the buffers to free. You do not free the
ordered_event structs
individually. For each oe->buffer, you need one free(). Each buffer is
put in the to_free
list. But to link it into the list it needs a list_head. This is what
buffer[0] is used for.
But the logic is broken in  ordered_events__free(). It does not free individual
ordered_event structs, but a buffer with many. Yet, it is missing
freeing all of the duped
events.

 void ordered_events__free(struct ordered_events *oe)
{
while (!list_empty(>to_free)) {
struct ordered_event *buffer;

buffer = list_entry(oe->to_free.next, struct
ordered_event, list);
list_del(>list);
> free_dup_event(oe, event->event);
free(buffer);
}
}
This only frees the dup_event of buffer[0] which we know is NULL (well, now).
It needs to walk all the entries in buffer[] to free buffer[x].event.

I think the goal was likely to avoid adding another list_head field to
each ordered_event
and instead use one per allocated buffer.
This is very convoluted and prone to errors and we are seeing right
now. This should
be cleaned. So either you add a list_head to ordered_event or you
would buffer[x] in
ordered_events_free().

At this point, this is my understanding.
Do you agree?


>
> thanks,
> jirka
>
>
> ---
> diff --cc tools/perf/util/ordered-events.c
> index bad9e0296e9a,0e837b0b8582..
> --- a/tools/perf/util/ordered-events.c
> +++ b/tools/perf/util/ordered-events.c
> @@@ -119,12 -119,8 +119,9 @@@ static struct ordered_event *alloc_even
> pr("alloc size %" PRIu64 "B (+%zu), max %" PRIu64 "B\n",
>oe->cur_alloc_size, size, oe->max_alloc_size);
>
>  +  oe->cur_alloc_size += size;
> -   list_add(>buffer->list, >to_free);
> -
> -   /* First entry is abused to maintain the to_free list. */
> -   oe->buffer_idx = 2;
> -   new = oe->buffer + 1;
> +   oe->buffer_idx = 1;
> +   new = oe->buffer;
> } else {
> pr("allocation limit reached %" PRIu64 "B\n", 
> oe->max_alloc_size);
> }

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Quentin Perret]

Hi Rafael,

On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> I'm a bit concerned that the code here appears to be designed around the
> frequency domains concept which seems to be a limitation and which probably
> is related to the properties of the current generation of hardware.

That's correct. I went for 'frequency domains' only because this is what
EAS and IPA are interested in, as of today at least. And both of them
are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
CPU-Perf after all :-)

> Assumptions like that tend to get tangled into the code tightly over time
> and they may be hard to untangle from it when new use cases arise later.
> 
> For example, there probably will be more firmware involvement in future
> systems and the firmware may not be willing to expose "raw" frequency
> domains to the OS.  That already is the case with P-states on Intel HW and
> with ACPI CPPC in general.

Agreed, and embedded/mobile systems are going in that direction too ...

> IMO, frequency domains in your current code could be replaced with something
> more general, like "performance domains"

I don't mind using a more abstract name as long as we keep the same
assumptions, and especially that all CPUs in a perf. domain *must* have
the same micro-architecture. From that assumption result several
properties that EAS (in its current) form needs. The first one is that
all CPUs of a performance domain have the same capacity at any possible
performance state. And the second is that they all consume the same
amount of (active) power.

I know it is theoretically possible to mix CPU types in the same perf
domain, but that becomes nightmare-ish to manage in EAS, and I don't
think there is a single platform like this on the market today. And I
hope nobody will build one. Peter wanted to mandate that too, I think.

> providing the scheduler with the (relative) cost of running a task

What do you mean by relative ? That we should normalize the power costs ?
Or just use an abstract scale, without specifying the unit ?

The main reason I'm a bit reluctant to do that just now is because IPA
needs to compare the power of CPUs with the power of other components
(GPUs, for example). And the power of those other components is specified
with a specific unit too. So, not imposing a comparable unit for the
power of CPUs will result in an unspecified behaviour in IPA, and that
will break things for sure. I would very much like to avoid that, of
course.

What I am currently proposing is to keep the unit (mW) in the EM
framework so that migrating IPA to using it can be done in a (relatively)
painless way. On a system where drivers  don't know the exact wattage,
then they should just 'lie' to the EM framework, but it's their job to
lie coherently to all subsystems and keep things consistent, because all
subsystems have specified power in comparable units.

Another solution to solve this problem could be to extend the EM
framework introduced by this patch and make it manage the EM of any
device, not just CPUs. Then we could just specify that all power costs
must be in the same scale, regardless of the actual unit, and register
the EM of CPUs, GPUs, ...
However, I was hoping that this patch as-is was enough for a first step,
and that this extension of the framework could be done in a second step ?
Thoughts ?

In any case, if we decide to keep the mW unit for now, I should at least
explain clearly why in the commit message.

> on a busy (non-idle) CPU (and, analogously,
> "idle domains" that would provide the scheduler with the - relative - cost
> of waking up an idle CPU to run a task on it or, the other way around, the
> possible relative gain from taking all tasks away from a CPU in order to make
> it go idle).

+1 for idle costs as a second type of 'domains' which could be managed
by the EM framework, alongside the 'perf' domains. I don't think we have
users of that just now (or providers of idle costs ?) so maybe that is
for later too ?

What do you think ?

Thank you very much for the feedback,
Quentin

linux-next: Tree for Aug 10

[Stephen Rothwell]

Hi all,

Changes since 20180809:

The vfs tree lost its build failure but I have still disabled
CONFIG_SAMPLE_STATX.

The ida tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 11708
 10596 files changed, 498456 insertions(+), 207143 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, an allmodconfig 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. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 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 (112cbae26d18 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5)
Merging arc-current/for-curr (7945121f56a2 ARC: [plat-axs*]: Enable SWAP)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (c7513c2a2714 crypto/arm64: aes-ce-gcm - add 
missing kernel_neon_begin/end pair)
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (112cbae26d18 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging bpf/master (9c9542011739 Merge branch 'bpf-fix-cpu-and-devmap-teardown')
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (16e98cec49a4 ipvs: don't show negative times in 
ip_vs_conn)
Merging ipvs/master (16e98cec49a4 ipvs: don't show negative times in ip_vs_conn)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (e31f6456c01c cfg80211: never ignore user regulatory 
hint)
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (627661ced824 ALSA: dice: fix wrong copy to rx 
parameters for Alesis iO26)
Merging sound-asoc-fixes/for-linus (6c0848398776 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (1ffaddd029c8 Linux 4.18-rc8)
Merging regulator-fixes/for-linus (685e0249e89c Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (a5e97ad82ebf Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (acb1872577b3 Linux 4.18-rc7)
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (acb1872577b3 Linux 4.18-rc7)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.18-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
status lines)
Merging staging.current/staging-linus (acb1872577b3 

Re: [PATCH 00/28] at24: remove at24_platform_data

[Sekhar Nori]

Hi Bart,

On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote:
> 2018-08-08 18:44 GMT+02:00 Andrew Lunn :
>> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
>>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang :
 On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
>
> This is a follow-up to the previously rejected series[1] which partially
> removed the at24_platform_data structure. After further development and
> taking reviews into account, this series finally removes that struct
> completely but not without touching many different parts of the code
> base.
>
> Since I took over maintainership of the at24 driver I've been working
> towards removing at24_platform_data in favor for device properties.

 Wooha, nice work. I can't really comment on it but wondered how you want
 to upstream it (after reviews)? Pull request of an immutable branch for
 nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
 it. Probably same situation for arm-soc...

>>>
>>> I initially wanted to merge small parts of it starting with v4.18, but
>>> there were some voices against merging APIs without users. I'm not
>>> sure how it should go in. There'll be a need for multiple immutable
>>> branches most probably...
>>
>> Hi Bartosz
>>
>> What this series does is show all the different parts are now
>> available, and can be reviewed as a whole. Once that review is
>> completed, merging in parts then becomes possible.
>>
>> It looks like you could probably merge the nvmem, mtd and net parts
>> independently via there maintainers for 4.20, since i don't think
>> there are any dependencies. The arm-soc changes in 4.21, and the
>> removal of the platform data in 4.22?
>>
>>  Andrew
> 
> We need the first batch of SoC changes for the net part and then the
> second batch depends on those net changes. Also: dragging the merge
> for this over a year is a bit overkill.
> 
> Sekhar: I know you're usually provided with immutable branches from
> framework maintainers for the SoC changes - is it ok for you to
> provide the net maintainers with an immutable branch after applying
> the first part of davinci board file changes?

Yeah, sure. I will be happy to do that to speed merging. Will take a
look at v2 you posted.

Thanks,
Sekhar

Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework

[Quentin Perret]

Hi Rafael,

On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote:
> I'm a bit concerned that the code here appears to be designed around the
> frequency domains concept which seems to be a limitation and which probably
> is related to the properties of the current generation of hardware.

That's correct. I went for 'frequency domains' only because this is what
EAS and IPA are interested in, as of today at least. And both of them
are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not
CPU-Perf after all :-)

> Assumptions like that tend to get tangled into the code tightly over time
> and they may be hard to untangle from it when new use cases arise later.
> 
> For example, there probably will be more firmware involvement in future
> systems and the firmware may not be willing to expose "raw" frequency
> domains to the OS.  That already is the case with P-states on Intel HW and
> with ACPI CPPC in general.

Agreed, and embedded/mobile systems are going in that direction too ...

> IMO, frequency domains in your current code could be replaced with something
> more general, like "performance domains"

I don't mind using a more abstract name as long as we keep the same
assumptions, and especially that all CPUs in a perf. domain *must* have
the same micro-architecture. From that assumption result several
properties that EAS (in its current) form needs. The first one is that
all CPUs of a performance domain have the same capacity at any possible
performance state. And the second is that they all consume the same
amount of (active) power.

I know it is theoretically possible to mix CPU types in the same perf
domain, but that becomes nightmare-ish to manage in EAS, and I don't
think there is a single platform like this on the market today. And I
hope nobody will build one. Peter wanted to mandate that too, I think.

> providing the scheduler with the (relative) cost of running a task

What do you mean by relative ? That we should normalize the power costs ?
Or just use an abstract scale, without specifying the unit ?

The main reason I'm a bit reluctant to do that just now is because IPA
needs to compare the power of CPUs with the power of other components
(GPUs, for example). And the power of those other components is specified
with a specific unit too. So, not imposing a comparable unit for the
power of CPUs will result in an unspecified behaviour in IPA, and that
will break things for sure. I would very much like to avoid that, of
course.

What I am currently proposing is to keep the unit (mW) in the EM
framework so that migrating IPA to using it can be done in a (relatively)
painless way. On a system where drivers  don't know the exact wattage,
then they should just 'lie' to the EM framework, but it's their job to
lie coherently to all subsystems and keep things consistent, because all
subsystems have specified power in comparable units.

Another solution to solve this problem could be to extend the EM
framework introduced by this patch and make it manage the EM of any
device, not just CPUs. Then we could just specify that all power costs
must be in the same scale, regardless of the actual unit, and register
the EM of CPUs, GPUs, ...
However, I was hoping that this patch as-is was enough for a first step,
and that this extension of the framework could be done in a second step ?
Thoughts ?

In any case, if we decide to keep the mW unit for now, I should at least
explain clearly why in the commit message.

> on a busy (non-idle) CPU (and, analogously,
> "idle domains" that would provide the scheduler with the - relative - cost
> of waking up an idle CPU to run a task on it or, the other way around, the
> possible relative gain from taking all tasks away from a CPU in order to make
> it go idle).

+1 for idle costs as a second type of 'domains' which could be managed
by the EM framework, alongside the 'perf' domains. I don't think we have
users of that just now (or providers of idle costs ?) so maybe that is
for later too ?

What do you think ?

Thank you very much for the feedback,
Quentin

linux-next: Tree for Aug 10

[Stephen Rothwell]

Hi all,

Changes since 20180809:

The vfs tree lost its build failure but I have still disabled
CONFIG_SAMPLE_STATX.

The ida tree gained a build failure for which I reverted a commit.

Non-merge commits (relative to Linus' tree): 11708
 10596 files changed, 498456 insertions(+), 207143 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, an allmodconfig 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. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 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 (112cbae26d18 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5)
Merging arc-current/for-curr (7945121f56a2 ARC: [plat-axs*]: Enable SWAP)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (c7513c2a2714 crypto/arm64: aes-ce-gcm - add 
missing kernel_neon_begin/end pair)
Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs 
for v4.18-rc6)
Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global 
invalidations when removing copro)
Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (112cbae26d18 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging bpf/master (9c9542011739 Merge branch 'bpf-fix-cpu-and-devmap-teardown')
Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for 
new entries)
Merging netfilter/master (16e98cec49a4 ipvs: don't show negative times in 
ip_vs_conn)
Merging ipvs/master (16e98cec49a4 ipvs: don't show negative times in ip_vs_conn)
Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in 
parsing NVRAM for multiple devices)
Merging mac80211/master (e31f6456c01c cfg80211: never ignore user regulatory 
hint)
Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV 
port checks)
Merging sound-current/for-linus (627661ced824 ALSA: dice: fix wrong copy to rx 
parameters for Alesis iO26)
Merging sound-asoc-fixes/for-linus (6c0848398776 Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (1ffaddd029c8 Linux 4.18-rc8)
Merging regulator-fixes/for-linus (685e0249e89c Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (a5e97ad82ebf Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race 
condition)
Merging driver-core.current/driver-core-linus (acb1872577b3 Linux 4.18-rc7)
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (acb1872577b3 Linux 4.18-rc7)
Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7)
Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.18-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for 
status lines)
Merging staging.current/staging-linus (acb1872577b3 

Re: [PATCH 00/28] at24: remove at24_platform_data

[Sekhar Nori]

Hi Bart,

On Wednesday 08 August 2018 10:22 PM, Bartosz Golaszewski wrote:
> 2018-08-08 18:44 GMT+02:00 Andrew Lunn :
>> On Wed, Aug 08, 2018 at 06:27:25PM +0200, Bartosz Golaszewski wrote:
>>> 2018-08-08 17:55 GMT+02:00 Wolfram Sang :
 On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
>
> This is a follow-up to the previously rejected series[1] which partially
> removed the at24_platform_data structure. After further development and
> taking reviews into account, this series finally removes that struct
> completely but not without touching many different parts of the code
> base.
>
> Since I took over maintainership of the at24 driver I've been working
> towards removing at24_platform_data in favor for device properties.

 Wooha, nice work. I can't really comment on it but wondered how you want
 to upstream it (after reviews)? Pull request of an immutable branch for
 nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
 it. Probably same situation for arm-soc...

>>>
>>> I initially wanted to merge small parts of it starting with v4.18, but
>>> there were some voices against merging APIs without users. I'm not
>>> sure how it should go in. There'll be a need for multiple immutable
>>> branches most probably...
>>
>> Hi Bartosz
>>
>> What this series does is show all the different parts are now
>> available, and can be reviewed as a whole. Once that review is
>> completed, merging in parts then becomes possible.
>>
>> It looks like you could probably merge the nvmem, mtd and net parts
>> independently via there maintainers for 4.20, since i don't think
>> there are any dependencies. The arm-soc changes in 4.21, and the
>> removal of the platform data in 4.22?
>>
>>  Andrew
> 
> We need the first batch of SoC changes for the net part and then the
> second batch depends on those net changes. Also: dragging the merge
> for this over a year is a bit overkill.
> 
> Sekhar: I know you're usually provided with immutable branches from
> framework maintainers for the SoC changes - is it ok for you to
> provide the net maintainers with an immutable branch after applying
> the first part of davinci board file changes?

Yeah, sure. I will be happy to do that to speed merging. Will take a
look at v2 you posted.

Thanks,
Sekhar

Re: [PATCH v2 08/18] serial: intel: Get serial id from dts

[Wu, Songjun]

On 8/8/2018 4:33 PM, Geert Uytterhoeven wrote:

Hi Songjun,

On Wed, Aug 8, 2018 at 6:05 AM Wu, Songjun  wrote:

On 8/7/2018 3:33 PM, Geert Uytterhoeven wrote:

On Fri, Aug 3, 2018 at 5:04 AM Songjun Wu  wrote:

Get serial id from dts.

"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.

arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h

If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.

Signed-off-by: Songjun Wu 

Thanks for your patch!


@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
  return -ENODEV;
  }

-   /* check if this is the console port */
-   if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
-   line = 1;
+   /* get serial id */
+   line = of_alias_get_id(node, "serial");
+   if (line < 0) {
+#ifdef CONFIG_LANTIQ
+   if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+   line = 0;
+   else
+   line = 1;
+#else
+   dev_err(>dev, "failed to get alias id, errno %d\n", line);
+   return line;

Please note that not providing a fallback here makes life harder when using
DT overlays.
See the description of commit 7678f4c20fa7670f ("serial: sh-sci: Add support
for dynamic instances") for background info.

Thanks for your comment.
The logic in commit 7678f4c20fa7670f is not suitable here.
We need to know which serial instance is used for console.
We cannot use dynamic serial instance here.

Why does the driver need to use which serial instance is used for the console?
Hardcoding that is not an option, as the board DTS may specify the console using
chosen/stdout-path.

In legacy platform in open source, it only defined asc1 in dts.
There's no asc0 in legacy dts.While in the new platform, asc0
is defined in dts. There's no asc1 in new platform dts.
To avoid hard code in driver, alias serial0 is used to unified
driver code. Actually only one serial is supported in SoC.

aliases {
        serial0 = 
};

chosen {
    bootargs = "earlycon  clk_ignore_unused";
    stdout-path = "serial0";
};

Re: [PATCH v2 08/18] serial: intel: Get serial id from dts

[Wu, Songjun]

On 8/8/2018 4:33 PM, Geert Uytterhoeven wrote:

Hi Songjun,

On Wed, Aug 8, 2018 at 6:05 AM Wu, Songjun  wrote:

On 8/7/2018 3:33 PM, Geert Uytterhoeven wrote:

On Fri, Aug 3, 2018 at 5:04 AM Songjun Wu  wrote:

Get serial id from dts.

"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.

arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h

If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.

Signed-off-by: Songjun Wu 

Thanks for your patch!


@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
  return -ENODEV;
  }

-   /* check if this is the console port */
-   if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
-   line = 1;
+   /* get serial id */
+   line = of_alias_get_id(node, "serial");
+   if (line < 0) {
+#ifdef CONFIG_LANTIQ
+   if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+   line = 0;
+   else
+   line = 1;
+#else
+   dev_err(>dev, "failed to get alias id, errno %d\n", line);
+   return line;

Please note that not providing a fallback here makes life harder when using
DT overlays.
See the description of commit 7678f4c20fa7670f ("serial: sh-sci: Add support
for dynamic instances") for background info.

Thanks for your comment.
The logic in commit 7678f4c20fa7670f is not suitable here.
We need to know which serial instance is used for console.
We cannot use dynamic serial instance here.

Why does the driver need to use which serial instance is used for the console?
Hardcoding that is not an option, as the board DTS may specify the console using
chosen/stdout-path.

In legacy platform in open source, it only defined asc1 in dts.
There's no asc0 in legacy dts.While in the new platform, asc0
is defined in dts. There's no asc1 in new platform dts.
To avoid hard code in driver, alias serial0 is used to unified
driver code. Actually only one serial is supported in SoC.

aliases {
        serial0 = 
};

chosen {
    bootargs = "earlycon  clk_ignore_unused";
    stdout-path = "serial0";
};

Re: [PATCH v3 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845

[Taniya Das]

On 7/24/2018 11:15 PM, Douglas Anderson wrote:

Add both the interface and core clock.

Signed-off-by: Douglas Anderson 
(am from https://lore.kernel.org/patchwork/patch/966680/mbox)

---

Changes in v3:
- Removed gcc_parent_names_9 which I had left in (doh!).

Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.

  drivers/clk/qcom/gcc-sdm845.c | 56 +++
  1 file changed, 56 insertions(+)

diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 0f694ed4238a..fc1c6658ad82 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -358,6 +358,28 @@ static struct clk_rcg2 gcc_pcie_phy_refgen_clk_src = {
},
  };
  
+static const struct freq_tbl ftbl_gcc_qspi_core_clk_src[] = {

+   F(1920, P_BI_TCXO, 1, 0, 0),
+   F(1, P_GPLL0_OUT_MAIN, 6, 0, 0),
+   F(15000, P_GPLL0_OUT_MAIN, 4, 0, 0),
+   F(3, P_GPLL0_OUT_MAIN, 2, 0, 0),
+   { }
+};
+
+static struct clk_rcg2 gcc_qspi_core_clk_src = {
+   .cmd_rcgr = 0x4b008,
+   .mnd_width = 0,
+   .hid_width = 5,
+   .parent_map = gcc_parent_map_0,
+   .freq_tbl = ftbl_gcc_qspi_core_clk_src,
+   .clkr.hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk_src",
+   .parent_names = gcc_parent_names_0,
+   .num_parents = 4,
+   .ops = _rcg2_floor_ops,
+   },
+};
+
  static const struct freq_tbl ftbl_gcc_pdm2_clk_src[] = {
F(960, P_BI_TCXO, 2, 0, 0),
F(1920, P_BI_TCXO, 1, 0, 0),
@@ -1935,6 +1957,37 @@ static struct clk_branch gcc_qmip_video_ahb_clk = {
},
  };
  
+static struct clk_branch gcc_qspi_cnoc_periph_ahb_clk = {

+   .halt_reg = 0x4b000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_cnoc_periph_ahb_clk",
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_qspi_core_clk = {
+   .halt_reg = 0x4b004,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b004,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk",
+   .parent_names = (const char *[]){
+   "gcc_qspi_core_clk_src",
+   },
+   .num_parents = 1,
+   .flags = CLK_SET_RATE_PARENT,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
  static struct clk_branch gcc_qupv3_wrap0_s0_clk = {
.halt_reg = 0x17030,
.halt_check = BRANCH_HALT_VOTED,
@@ -3383,6 +3436,9 @@ static struct clk_regmap *gcc_sdm845_clocks[] = {
[GPLL4] = ,
[GCC_CPUSS_DVM_BUS_CLK] = _cpuss_dvm_bus_clk.clkr,
[GCC_CPUSS_GNOC_CLK] = _cpuss_gnoc_clk.clkr,
+   [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
+   [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
+   [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
  };
  
  static const struct qcom_reset_map gcc_sdm845_resets[] = {




Reviewed-by: Taniya Das 

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH v3 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845

[Taniya Das]

On 7/24/2018 11:15 PM, Douglas Anderson wrote:

Add both the interface and core clock.

Signed-off-by: Douglas Anderson 
(am from https://lore.kernel.org/patchwork/patch/966680/mbox)

---

Changes in v3:
- Removed gcc_parent_names_9 which I had left in (doh!).

Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.

  drivers/clk/qcom/gcc-sdm845.c | 56 +++
  1 file changed, 56 insertions(+)

diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 0f694ed4238a..fc1c6658ad82 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -358,6 +358,28 @@ static struct clk_rcg2 gcc_pcie_phy_refgen_clk_src = {
},
  };
  
+static const struct freq_tbl ftbl_gcc_qspi_core_clk_src[] = {

+   F(1920, P_BI_TCXO, 1, 0, 0),
+   F(1, P_GPLL0_OUT_MAIN, 6, 0, 0),
+   F(15000, P_GPLL0_OUT_MAIN, 4, 0, 0),
+   F(3, P_GPLL0_OUT_MAIN, 2, 0, 0),
+   { }
+};
+
+static struct clk_rcg2 gcc_qspi_core_clk_src = {
+   .cmd_rcgr = 0x4b008,
+   .mnd_width = 0,
+   .hid_width = 5,
+   .parent_map = gcc_parent_map_0,
+   .freq_tbl = ftbl_gcc_qspi_core_clk_src,
+   .clkr.hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk_src",
+   .parent_names = gcc_parent_names_0,
+   .num_parents = 4,
+   .ops = _rcg2_floor_ops,
+   },
+};
+
  static const struct freq_tbl ftbl_gcc_pdm2_clk_src[] = {
F(960, P_BI_TCXO, 2, 0, 0),
F(1920, P_BI_TCXO, 1, 0, 0),
@@ -1935,6 +1957,37 @@ static struct clk_branch gcc_qmip_video_ahb_clk = {
},
  };
  
+static struct clk_branch gcc_qspi_cnoc_periph_ahb_clk = {

+   .halt_reg = 0x4b000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_cnoc_periph_ahb_clk",
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_qspi_core_clk = {
+   .halt_reg = 0x4b004,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b004,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk",
+   .parent_names = (const char *[]){
+   "gcc_qspi_core_clk_src",
+   },
+   .num_parents = 1,
+   .flags = CLK_SET_RATE_PARENT,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
  static struct clk_branch gcc_qupv3_wrap0_s0_clk = {
.halt_reg = 0x17030,
.halt_check = BRANCH_HALT_VOTED,
@@ -3383,6 +3436,9 @@ static struct clk_regmap *gcc_sdm845_clocks[] = {
[GPLL4] = ,
[GCC_CPUSS_DVM_BUS_CLK] = _cpuss_dvm_bus_clk.clkr,
[GCC_CPUSS_GNOC_CLK] = _cpuss_gnoc_clk.clkr,
+   [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
+   [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
+   [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
  };
  
  static const struct qcom_reset_map gcc_sdm845_resets[] = {




Reviewed-by: Taniya Das 

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Our Company Beijing Shougang Company Ltd., based in China is in search of a competent individual or firm that will be responsible in handling funds as our ''Representative Manager'' in the United Stat

[Beijing Shougang Company Ltd]

Note: It is a part time job that won't interrupt your present work or business. 

Looking forward to your response. 

Best Regards, 
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd. 
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn

Re: [PATCH v3 1/2] clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header

[Taniya Das]

On 7/25/2018 9:31 PM, Rob Herring wrote:

On Tue, Jul 24, 2018 at 10:45:12AM -0700, Douglas Anderson wrote:

These clocks will need to be defined in the clock driver and
referenced in device tree files.

Signed-off-by: Douglas Anderson 
---

Changes in v3: None
Changes in v2: None

  include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +++
  1 file changed, 3 insertions(+)


Acked-by: Rob Herring 

  Reviewed-by: Taniya Das 


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



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

[PATCH v2 12/29] ARM: davinci: da850-evm: use nvmem lookup for mac address

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now support nvmem lookups for machine code. Add a lookup for
mac-address.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da850-evm.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 6d5beb11bd96..5a634a04ec69 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -99,6 +100,19 @@ static struct mtd_partition da850evm_spiflash_part[] = {
},
 };
 
+static struct nvmem_cell_lookup da850evm_mac_address_cell = {
+   .info = {
+   .name = "mac-address",
+   .offset = 0x0,
+   .bytes = ETH_ALEN,
+   },
+   /*
+* The nvmem name differs from the partition name because of the
+* internal works of the nvmem framework.
+*/
+   .nvmem_name = "MAC-Address0",
+};
+
 static struct flash_platform_data da850evm_spiflash_data = {
.name   = "m25p80",
.parts  = da850evm_spiflash_part,
@@ -1447,6 +1461,8 @@ static __init void da850_evm_init(void)
pr_warn("%s: spi info registration failed: %d\n", __func__,
ret);
 
+   nvmem_add_lookup_table(_mac_address_cell, 1);
+
ret = da8xx_register_spi_bus(1, ARRAY_SIZE(da850evm_spi_info));
if (ret)
pr_warn("%s: SPI 1 registration failed: %d\n", __func__, ret);
-- 
2.18.0

Our Company Beijing Shougang Company Ltd., based in China is in search of a competent individual or firm that will be responsible in handling funds as our ''Representative Manager'' in the United Stat

[Beijing Shougang Company Ltd]

Note: It is a part time job that won't interrupt your present work or business. 

Looking forward to your response. 

Best Regards, 
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd. 
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn

Re: [PATCH v3 1/2] clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header

[Taniya Das]

On 7/25/2018 9:31 PM, Rob Herring wrote:

On Tue, Jul 24, 2018 at 10:45:12AM -0700, Douglas Anderson wrote:

These clocks will need to be defined in the clock driver and
referenced in device tree files.

Signed-off-by: Douglas Anderson 
---

Changes in v3: None
Changes in v2: None

  include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +++
  1 file changed, 3 insertions(+)


Acked-by: Rob Herring 

  Reviewed-by: Taniya Das 


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



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

[PATCH v2 12/29] ARM: davinci: da850-evm: use nvmem lookup for mac address

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now support nvmem lookups for machine code. Add a lookup for
mac-address.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da850-evm.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 6d5beb11bd96..5a634a04ec69 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -99,6 +100,19 @@ static struct mtd_partition da850evm_spiflash_part[] = {
},
 };
 
+static struct nvmem_cell_lookup da850evm_mac_address_cell = {
+   .info = {
+   .name = "mac-address",
+   .offset = 0x0,
+   .bytes = ETH_ALEN,
+   },
+   /*
+* The nvmem name differs from the partition name because of the
+* internal works of the nvmem framework.
+*/
+   .nvmem_name = "MAC-Address0",
+};
+
 static struct flash_platform_data da850evm_spiflash_data = {
.name   = "m25p80",
.parts  = da850evm_spiflash_part,
@@ -1447,6 +1461,8 @@ static __init void da850_evm_init(void)
pr_warn("%s: spi info registration failed: %d\n", __func__,
ret);
 
+   nvmem_add_lookup_table(_mac_address_cell, 1);
+
ret = da8xx_register_spi_bus(1, ARRAY_SIZE(da850evm_spi_info));
if (ret)
pr_warn("%s: SPI 1 registration failed: %d\n", __func__, ret);
-- 
2.18.0

[PATCH v2] cpuidle: menu: Handle stopped tick more aggressively

[Rafael J. Wysocki]

From: Rafael J. Wysocki 
Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively

Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
with stopped tick) missed the case when the target residencies of
deep idle states of CPUs are above the tick boundary which may cause
the CPU to get stuck in a shallow idle state for a long time.

Say there are two CPU idle states available: one shallow, with the
target residency much below the tick boundary and one deep, with
the target residency significantly above the tick boundary.  In
that case, if the tick has been stopped already and the expected
next timer event is relatively far in the future, the governor will
assume the idle duration to be equal to TICK_USEC and it will select
the idle state for the CPU accordingly.  However, that will cause the
shallow state to be selected even though it would have been more
energy-efficient to select the deep one.

To address this issue, modify the governor to always assume idle
duration to be equal to the time till the closest timer event if
the tick is not running which will cause the selected idle states
to always match the known CPU wakeup time.

Also make it always indicate that the tick should be stopped in
that case for consistency.

Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped 
tick)
Reported-by: Leo Yan 
Signed-off-by: Rafael J. Wysocki 
---

-> v2: Initialize first_idx properly in the stopped tick case.

---
 drivers/cpuidle/governors/menu.c |   55 +--
 1 file changed, 25 insertions(+), 30 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -285,9 +285,8 @@ static int menu_select(struct cpuidle_dr
 {
struct menu_device *data = this_cpu_ptr(_devices);
int latency_req = cpuidle_governor_latency_req(dev->cpu);
-   int i;
-   int first_idx;
-   int idx;
+   int first_idx = 0;
+   int idx, i;
unsigned int interactivity_req;
unsigned int expected_interval;
unsigned long nr_iowaiters, cpu_load;
@@ -307,6 +306,18 @@ static int menu_select(struct cpuidle_dr
/* determine the expected residency time, round up */
data->next_timer_us = 
ktime_to_us(tick_nohz_get_sleep_length(_next));
 
+   /*
+* If the tick is already stopped, the cost of possible short idle
+* duration misprediction is much higher, because the CPU may be stuck
+* in a shallow idle state for a long time as a result of it.  In that
+* case say we might mispredict and use the known time till the closest
+* timer event for the idle state selection.
+*/
+   if (tick_nohz_tick_stopped()) {
+   data->predicted_us = ktime_to_us(delta_next);
+   goto select;
+   }
+
get_iowait_load(_iowaiters, _load);
data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
 
@@ -322,7 +333,6 @@ static int menu_select(struct cpuidle_dr
expected_interval = get_typical_interval(data);
expected_interval = min(expected_interval, data->next_timer_us);
 
-   first_idx = 0;
if (drv->states[0].flags & CPUIDLE_FLAG_POLLING) {
struct cpuidle_state *s = >states[1];
unsigned int polling_threshold;
@@ -344,29 +354,15 @@ static int menu_select(struct cpuidle_dr
 */
data->predicted_us = min(data->predicted_us, expected_interval);
 
-   if (tick_nohz_tick_stopped()) {
-   /*
-* If the tick is already stopped, the cost of possible short
-* idle duration misprediction is much higher, because the CPU
-* may be stuck in a shallow idle state for a long time as a
-* result of it.  In that case say we might mispredict and try
-* to force the CPU into a state for which we would have stopped
-* the tick, unless a timer is going to expire really soon
-* anyway.
-*/
-   if (data->predicted_us < TICK_USEC)
-   data->predicted_us = min_t(unsigned int, TICK_USEC,
-  ktime_to_us(delta_next));
-   } else {
-   /*
-* Use the performance multiplier and the user-configurable
-* latency_req to determine the maximum exit latency.
-*/
-   interactivity_req = data->predicted_us / 
performance_multiplier(nr_iowaiters, cpu_load);
-   if (latency_req > interactivity_req)
-   latency_req = interactivity_req;
-   }
+   /*
+* Use the performance multiplier and the user-configurable latency_req
+* to determine the maximum exit latency.
+*/
+   

[PATCH v2] cpuidle: menu: Handle stopped tick more aggressively

[Rafael J. Wysocki]

From: Rafael J. Wysocki 
Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively

Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states
with stopped tick) missed the case when the target residencies of
deep idle states of CPUs are above the tick boundary which may cause
the CPU to get stuck in a shallow idle state for a long time.

Say there are two CPU idle states available: one shallow, with the
target residency much below the tick boundary and one deep, with
the target residency significantly above the tick boundary.  In
that case, if the tick has been stopped already and the expected
next timer event is relatively far in the future, the governor will
assume the idle duration to be equal to TICK_USEC and it will select
the idle state for the CPU accordingly.  However, that will cause the
shallow state to be selected even though it would have been more
energy-efficient to select the deep one.

To address this issue, modify the governor to always assume idle
duration to be equal to the time till the closest timer event if
the tick is not running which will cause the selected idle states
to always match the known CPU wakeup time.

Also make it always indicate that the tick should be stopped in
that case for consistency.

Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped 
tick)
Reported-by: Leo Yan 
Signed-off-by: Rafael J. Wysocki 
---

-> v2: Initialize first_idx properly in the stopped tick case.

---
 drivers/cpuidle/governors/menu.c |   55 +--
 1 file changed, 25 insertions(+), 30 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -285,9 +285,8 @@ static int menu_select(struct cpuidle_dr
 {
struct menu_device *data = this_cpu_ptr(_devices);
int latency_req = cpuidle_governor_latency_req(dev->cpu);
-   int i;
-   int first_idx;
-   int idx;
+   int first_idx = 0;
+   int idx, i;
unsigned int interactivity_req;
unsigned int expected_interval;
unsigned long nr_iowaiters, cpu_load;
@@ -307,6 +306,18 @@ static int menu_select(struct cpuidle_dr
/* determine the expected residency time, round up */
data->next_timer_us = 
ktime_to_us(tick_nohz_get_sleep_length(_next));
 
+   /*
+* If the tick is already stopped, the cost of possible short idle
+* duration misprediction is much higher, because the CPU may be stuck
+* in a shallow idle state for a long time as a result of it.  In that
+* case say we might mispredict and use the known time till the closest
+* timer event for the idle state selection.
+*/
+   if (tick_nohz_tick_stopped()) {
+   data->predicted_us = ktime_to_us(delta_next);
+   goto select;
+   }
+
get_iowait_load(_iowaiters, _load);
data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
 
@@ -322,7 +333,6 @@ static int menu_select(struct cpuidle_dr
expected_interval = get_typical_interval(data);
expected_interval = min(expected_interval, data->next_timer_us);
 
-   first_idx = 0;
if (drv->states[0].flags & CPUIDLE_FLAG_POLLING) {
struct cpuidle_state *s = >states[1];
unsigned int polling_threshold;
@@ -344,29 +354,15 @@ static int menu_select(struct cpuidle_dr
 */
data->predicted_us = min(data->predicted_us, expected_interval);
 
-   if (tick_nohz_tick_stopped()) {
-   /*
-* If the tick is already stopped, the cost of possible short
-* idle duration misprediction is much higher, because the CPU
-* may be stuck in a shallow idle state for a long time as a
-* result of it.  In that case say we might mispredict and try
-* to force the CPU into a state for which we would have stopped
-* the tick, unless a timer is going to expire really soon
-* anyway.
-*/
-   if (data->predicted_us < TICK_USEC)
-   data->predicted_us = min_t(unsigned int, TICK_USEC,
-  ktime_to_us(delta_next));
-   } else {
-   /*
-* Use the performance multiplier and the user-configurable
-* latency_req to determine the maximum exit latency.
-*/
-   interactivity_req = data->predicted_us / 
performance_multiplier(nr_iowaiters, cpu_load);
-   if (latency_req > interactivity_req)
-   latency_req = interactivity_req;
-   }
+   /*
+* Use the performance multiplier and the user-configurable latency_req
+* to determine the maximum exit latency.
+*/
+   

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Juri Lelli]

On 09/08/18 16:23, Patrick Bellasi wrote:
> On 09-Aug 11:50, Juri Lelli wrote:
> > On 09/08/18 10:14, Patrick Bellasi wrote:
> > > On 07-Aug 14:35, Juri Lelli wrote:
> > > > On 06/08/18 17:39, Patrick Bellasi wrote:
> 
> [...]
> 
> > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
> > >time parameter to relax this check
> > 
> > It seems to me that this might work well with that the intended usage of
> > the interface that you depict above. SMS only (or any privileged user)
> > will be in control of how groups are configured, so no problem for
> > normal users.
> 
> Yes, well... apart normal users still getting a -ENOSPC is they are
> requesting one of the not pre-configured clamp values. Which is why
> the following bits can be helpful.
> 
> > > 2) add discretization support to clamp groups allocation
> > 
> > And this might also work well if we feel that we don't want to restrict
> > usage of the interface to admin only, however...
> > 
> > > This second feature specifically, will ensure that clamp values are
> > > always mapped into one of the available clamp groups. While the exact
> > > clamp value can always be used for tasks placement biasing, when it
> > > comes to frequency selection biasing, depending on concurrently
> > > running tasks, you can end up with an effective clamp value which is a
> > > rounded up.
> > 
> > what I'm not so sure about is that we might lose in flexibility if the
> > number of available discrete clamp groups is too small compared to the
> > number of available OPP on the platform.
> 
> Regarding this concern, I would say that we should consider that, for
> frequency biasing, we are in general not interested in nailing down
> the single 1% difference and/or exact OPP capacities

True.

> A certain coarse grained resolution is usually acceptable for many
> different reasons:
> a) schedutil already uses a 20% margin which can potentially eclipse
>few OPP when we scale up/down
> b) tasks/CPUs utilization are good enough but never exact and precise
>values
> c) reducing the number of OPP switches could have some benefits on
>stability/latencies
> d) clamping is actually defining minimum/maximum preferred values, is
>not to be considered a tool for "precise control"
> 
> All that considered, I would say that maybe a 5% resolution could
> still be considered an acceptable _worst case_ rounding since we don't
> have always to round up to the next 5%.
> 
> For example, if we have:
>  - TaskA: util_min=41%
>  - TaskB: util_nin=44%
> they will be both accounted in the 40-45% clamp group but the clamp
> group value can be modulated at run-time depending on RUNNABLE
> tasks. When TaskA is running alone, we can still set util_min to
> 41%, while we will use 44% (not 45%) when TaskB is (also) running.
> 
> It's worth to notice that we pre-allocated at compile time 20 clamp
> groups, but not necessarily all of them will be used at run-time.
> Indeed, we will still use a policy where only the actual required
> values are allocated at the beginning of the clamps map, thus
> optimizing max updates.

OK, so you'll only still iterate over the groups that are actually in
use, which is hopefully less than 20 and should keep overhead low. Makes
sense to me.

Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping

[Juri Lelli]

On 09/08/18 16:23, Patrick Bellasi wrote:
> On 09-Aug 11:50, Juri Lelli wrote:
> > On 09/08/18 10:14, Patrick Bellasi wrote:
> > > On 07-Aug 14:35, Juri Lelli wrote:
> > > > On 06/08/18 17:39, Patrick Bellasi wrote:
> 
> [...]
> 
> > > 1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
> > >time parameter to relax this check
> > 
> > It seems to me that this might work well with that the intended usage of
> > the interface that you depict above. SMS only (or any privileged user)
> > will be in control of how groups are configured, so no problem for
> > normal users.
> 
> Yes, well... apart normal users still getting a -ENOSPC is they are
> requesting one of the not pre-configured clamp values. Which is why
> the following bits can be helpful.
> 
> > > 2) add discretization support to clamp groups allocation
> > 
> > And this might also work well if we feel that we don't want to restrict
> > usage of the interface to admin only, however...
> > 
> > > This second feature specifically, will ensure that clamp values are
> > > always mapped into one of the available clamp groups. While the exact
> > > clamp value can always be used for tasks placement biasing, when it
> > > comes to frequency selection biasing, depending on concurrently
> > > running tasks, you can end up with an effective clamp value which is a
> > > rounded up.
> > 
> > what I'm not so sure about is that we might lose in flexibility if the
> > number of available discrete clamp groups is too small compared to the
> > number of available OPP on the platform.
> 
> Regarding this concern, I would say that we should consider that, for
> frequency biasing, we are in general not interested in nailing down
> the single 1% difference and/or exact OPP capacities

True.

> A certain coarse grained resolution is usually acceptable for many
> different reasons:
> a) schedutil already uses a 20% margin which can potentially eclipse
>few OPP when we scale up/down
> b) tasks/CPUs utilization are good enough but never exact and precise
>values
> c) reducing the number of OPP switches could have some benefits on
>stability/latencies
> d) clamping is actually defining minimum/maximum preferred values, is
>not to be considered a tool for "precise control"
> 
> All that considered, I would say that maybe a 5% resolution could
> still be considered an acceptable _worst case_ rounding since we don't
> have always to round up to the next 5%.
> 
> For example, if we have:
>  - TaskA: util_min=41%
>  - TaskB: util_nin=44%
> they will be both accounted in the 40-45% clamp group but the clamp
> group value can be modulated at run-time depending on RUNNABLE
> tasks. When TaskA is running alone, we can still set util_min to
> 41%, while we will use 44% (not 45%) when TaskB is (also) running.
> 
> It's worth to notice that we pre-allocated at compile time 20 clamp
> groups, but not necessarily all of them will be used at run-time.
> Indeed, we will still use a policy where only the actual required
> values are allocated at the beginning of the clamps map, thus
> optimizing max updates.

OK, so you'll only still iterate over the groups that are actually in
use, which is hopefully less than 20 and should keep overhead low. Makes
sense to me.