date:20210107

Document the binding for enabling dvfsrc on MediaTek SoC.

Signed-off-by: Henry Chen 
---
 .../devicetree/bindings/soc/mediatek/dvfsrc.yaml   | 67 ++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml 
b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
new file mode 100644
index 000..0b746a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/dvfsrc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MediaTek dynamic voltage and frequency scaling resource collector 
(DVFSRC)
+
+description: |
+  The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
+  HW module which is used to collect all the requests from both software and
+  hardware and turn into the decision of minimum operating voltage and minimum
+  DRAM frequency to fulfill those requests.
+
+maintainers:
+  - henryc.chen 
+
+properties:
+  reg:
+description: DVFSRC common register address and length.
+
+  compatible:
+enum:
+  - mediatek,mt6873-dvfsrc
+  - mediatek,mt8183-dvfsrc
+  - mediatek,mt8192-dvfsrc
+
+  '#interconnect-cells':
+const: 1
+
+patternProperties:
+  dvfsrc-vcore:
+type: object
+description:
+  The DVFSRC regulator is modelled as a subdevice of the DVFSRC.
+  Because DVFSRC can request power directly via register read/write, likes
+  vcore which is a core power of mt8183. As such, the DVFSRC regulator
+  requires that DVFSRC nodes be present.
+$ref: /schemas/regulator/regulator.yaml#
+
+required:
+  - compatible
+  - reg
+  - "#interconnect-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+dvfsrc@10012000 {
+compatible = "mediatek,mt8183-dvfsrc";
+reg = <0 0x10012000 0 0x1000>;
+#interconnect-cells = <1>;
+dvfsrc_vcore: dvfsrc-vcore {
+regulator-name = "dvfsrc-vcore";
+regulator-min-microvolt = <725000>;
+regulator-max-microvolt = <80>;
+regulator-always-on;
+};
+};
+};
-- 
1.9.1

[PATCH V7 09/13] interconnect: mediatek: Add interconnect provider driver

Introduce Mediatek MT6873/MT8183/MT8192 specific provider driver
using the interconnect framework.

 ICC provider ICC Nodes
    
 -   |CPU |   |--- |VPU |
-   | |-  | 
   |DRAM |--|DRAM |   | 
   | |--|scheduler|- |GPU |   |--- |DISP|
   | |--|(EMI)|   | 
   | |--| |   -   | 
-   | |- |MMSYS|--|--- |VDEC|
 --   | 
   /|\| 
|change DRAM freq |--- |VENC|
 --   | 
|  DVFSR   |  |
|  |  | 
 --   |--- |IMG |
  | 
  | 
  |--- |CAM |


Signed-off-by: Henry Chen 
---
 drivers/interconnect/Kconfig|   1 +
 drivers/interconnect/Makefile   |   1 +
 drivers/interconnect/mediatek/Kconfig   |  13 ++
 drivers/interconnect/mediatek/Makefile  |   3 +
 drivers/interconnect/mediatek/mtk-emi.c | 331 
 5 files changed, 349 insertions(+)
 create mode 100644 drivers/interconnect/mediatek/Kconfig
 create mode 100644 drivers/interconnect/mediatek/Makefile
 create mode 100644 drivers/interconnect/mediatek/mtk-emi.c

diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index d637a89..da91f84 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -12,6 +12,7 @@ menuconfig INTERCONNECT
 if INTERCONNECT
 
 source "drivers/interconnect/imx/Kconfig"
+source "drivers/interconnect/mediatek/Kconfig"
 source "drivers/interconnect/qcom/Kconfig"
 source "drivers/interconnect/samsung/Kconfig"
 
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 97d393f..d697500 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -5,5 +5,6 @@ icc-core-objs   := core.o bulk.o
 
 obj-$(CONFIG_INTERCONNECT) += icc-core.o
 obj-$(CONFIG_INTERCONNECT_IMX) += imx/
+obj-$(CONFIG_INTERCONNECT_MTK) += mediatek/
 obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
 obj-$(CONFIG_INTERCONNECT_SAMSUNG) += samsung/
diff --git a/drivers/interconnect/mediatek/Kconfig 
b/drivers/interconnect/mediatek/Kconfig
new file mode 100644
index 000..ec98d6a
--- /dev/null
+++ b/drivers/interconnect/mediatek/Kconfig
@@ -0,0 +1,13 @@
+config INTERCONNECT_MTK
+   bool "Mediatek Network-on-Chip interconnect drivers"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ Support for Mediatek's Network-on-Chip interconnect hardware.
+
+config INTERCONNECT_MTK_EMI
+   tristate "Mediatek EMI interconnect driver"
+   depends on INTERCONNECT_MTK
+   depends on (MTK_DVFSRC && OF) || COMPILE_TEST
+   help
+ This is a driver for the Mediatek Network-on-Chip on DVFSRC-based
+ platforms.
diff --git a/drivers/interconnect/mediatek/Makefile 
b/drivers/interconnect/mediatek/Makefile
new file mode 100644
index 000..353842b
--- /dev/null
+++ b/drivers/interconnect/mediatek/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_INTERCONNECT_MTK_EMI) += mtk-emi.o
\ No newline at end of file
diff --git a/drivers/interconnect/mediatek/mtk-emi.c 
b/drivers/interconnect/mediatek/mtk-emi.c
new file mode 100644
index 000..8d650be
--- /dev/null
+++ b/drivers/interconnect/mediatek/mtk-emi.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum mtk_icc_name {
+   SLAVE_DDR_EMI,
+   MASTER_MCUSYS,
+   MASTER_GPUSYS,
+   MASTER_MMSYS,
+   MASTER_MM_VPU,
+   MASTER_MM_DISP,
+   MASTER_MM_VDEC,
+   MASTER_MM_VENC,
+   MASTER_MM_CAM,
+   MASTER_MM_IMG,
+   MASTER_MM_MDP,
+   MASTER_VPUSYS,
+   MASTER_VPU_PORT_0,
+   MASTER_VPU_PORT_1,
+   MASTER_MDLASYS,
+   MASTER_MDLA_PORT_0,
+   MASTER_UFS,
+   MASTER_PCIE,
+   MASTER_USB,
+   MASTER_WIFI,
+   MASTER_BT,
+   MASTER_NETSYS,
+   MASTER_DBGIF,
+
+   SLAVE_HRT_DDR_EMI,
+   MASTER_HRT_MMSYS,
+   MASTER_HRT_MM_DISP,
+   MASTER_HRT_MM_VDEC,
+   MASTER_HRT_MM_VENC,
+   MASTER_HRT_MM_CAM,
+   MASTER_HRT_MM_IMG,
+   MASTER_HRT_MM_MDP,
+   MASTER_HRT_DBGIF,
+};
+
+#define MT8183_MAX_LINKS   1
+
+/**
+ * struct mtk_icc_node - Mediatek specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @ep : the type of this endpoint
+ * @id: a

[PATCH V7 07/13] dt-bindings: interconnect: add MT8183 interconnect dt-bindings

Add interconnect provider dt-bindings for MT8183.

Signed-off-by: Henry Chen 
Reviewed-by: Rob Herring 
---
 include/dt-bindings/interconnect/mtk,mt8183-emi.h | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 include/dt-bindings/interconnect/mtk,mt8183-emi.h

diff --git a/include/dt-bindings/interconnect/mtk,mt8183-emi.h 
b/include/dt-bindings/interconnect/mtk,mt8183-emi.h
new file mode 100644
index 000..dfd143f
--- /dev/null
+++ b/include/dt-bindings/interconnect/mtk,mt8183-emi.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H
+#define __DT_BINDINGS_INTERCONNECT_MTK_MT8183_EMI_H
+
+#define MT8183_SLAVE_DDR_EMI   0
+#define MT8183_MASTER_MCUSYS   1
+#define MT8183_MASTER_GPU  2
+#define MT8183_MASTER_MMSYS3
+#define MT8183_MASTER_MM_VPU   4
+#define MT8183_MASTER_MM_DISP  5
+#define MT8183_MASTER_MM_VDEC  6
+#define MT8183_MASTER_MM_VENC  7
+#define MT8183_MASTER_MM_CAM   8
+#define MT8183_MASTER_MM_IMG   9
+#define MT8183_MASTER_MM_MDP   10
+
+#endif
-- 
1.9.1

[PATCH V7 05/13] arm64: dts: mt8183: add dvfsrc related nodes

Enable dvfsrc on mt8183 platform.

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5b782a4..062afe8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -497,6 +497,11 @@
#clock-cells = <1>;
};
 
+   ddr_emi: dvfsrc@10012000 {
+   compatible = "mediatek,mt8183-dvfsrc";
+   reg = <0 0x10012000 0 0x1000>;
+   };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt8183-pwrap";
reg = <0 0x1000d000 0 0x1000>;
-- 
1.9.1

[PATCH V7 08/13] dt-bindings: interconnect: add MT6873 interconnect dt-bindings

Add interconnect provider dt-bindings for MT6873.

Signed-off-by: Henry Chen 
---
 include/dt-bindings/interconnect/mtk,mt6873-emi.h | 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 include/dt-bindings/interconnect/mtk,mt6873-emi.h

diff --git a/include/dt-bindings/interconnect/mtk,mt6873-emi.h 
b/include/dt-bindings/interconnect/mtk,mt6873-emi.h
new file mode 100644
index 000..0b20011
--- /dev/null
+++ b/include/dt-bindings/interconnect/mtk,mt6873-emi.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_MTK_MT6873_EMI_H
+#define __DT_BINDINGS_INTERCONNECT_MTK_MT6873_EMI_H
+
+#define MT6873_SLAVE_DDR_EMI   0
+#define MT6873_MASTER_MCUSYS   1
+#define MT6873_MASTER_GPUSYS   2
+#define MT6873_MASTER_MMSYS3
+#define MT6873_MASTER_MM_VPU   4
+#define MT6873_MASTER_MM_DISP  5
+#define MT6873_MASTER_MM_VDEC  6
+#define MT6873_MASTER_MM_VENC  7
+#define MT6873_MASTER_MM_CAM   8
+#define MT6873_MASTER_MM_IMG   9
+#define MT6873_MASTER_MM_MDP   10
+#define MT6873_MASTER_VPUSYS   11
+#define MT6873_MASTER_VPU_012
+#define MT6873_MASTER_VPU_113
+#define MT6873_MASTER_MDLASYS  14
+#define MT6873_MASTER_MDLA_0   15
+#define MT6873_MASTER_UFS  16
+#define MT6873_MASTER_PCIE 17
+#define MT6873_MASTER_USB  18
+#define MT6873_MASTER_DBGIF19
+#define MT6873_SLAVE_HRT_DDR_EMI   20
+#define MT6873_MASTER_HRT_MMSYS21
+#define MT6873_MASTER_HRT_MM_DISP  22
+#define MT6873_MASTER_HRT_MM_VDEC  23
+#define MT6873_MASTER_HRT_MM_VENC  24
+#define MT6873_MASTER_HRT_MM_CAM   25
+#define MT6873_MASTER_HRT_MM_IMG   26
+#define MT6873_MASTER_HRT_MM_MDP   27
+#define MT6873_MASTER_HRT_DBGIF28
+#define MT6873_MASTER_WIFI 29
+#define MT6873_MASTER_BT   30
+#define MT6873_MASTER_NETSYS   31
+#endif
-- 
1.9.1

[PATCH V7 04/13] soc: mediatek: add support for mt6873

add support for mt6873

Signed-off-by: Henry Chen 
---
 drivers/soc/mediatek/mtk-dvfsrc.c | 114 ++
 1 file changed, 114 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c 
b/drivers/soc/mediatek/mtk-dvfsrc.c
index c0c6d91..a422680 100644
--- a/drivers/soc/mediatek/mtk-dvfsrc.c
+++ b/drivers/soc/mediatek/mtk-dvfsrc.c
@@ -102,6 +102,16 @@ enum dvfsrc_regs {
[DVFSRC_SW_BW] =0x160,
 };
 
+static const int mt6873_regs[] = {
+   [DVFSRC_SW_REQ] =   0xC,
+   [DVFSRC_LEVEL] =0xD44,
+   [DVFSRC_SW_PEAK_BW] =   0x278,
+   [DVFSRC_SW_BW] =0x26C,
+   [DVFSRC_SW_HRT_BW] =0x290,
+   [DVFSRC_TARGET_LEVEL] = 0xD48,
+   [DVFSRC_VCORE_REQUEST] =0x6C,
+};
+
 static const struct dvfsrc_opp *get_current_opp(struct mtk_dvfsrc *dvfsrc)
 {
int level;
@@ -127,6 +137,78 @@ static int dvfsrc_wait_for_vcore_level(struct mtk_dvfsrc 
*dvfsrc, u32 level)
 POLL_TIMEOUT);
 }
 
+static int mt6873_get_target_level(struct mtk_dvfsrc *dvfsrc)
+{
+   return dvfsrc_read(dvfsrc, DVFSRC_TARGET_LEVEL);
+}
+
+static int mt6873_get_current_level(struct mtk_dvfsrc *dvfsrc)
+{
+   u32 curr_level;
+
+   /* HW level 0 is begin from 0x1, and max opp is 0x1*/
+   curr_level = ffs(dvfsrc_read(dvfsrc, DVFSRC_LEVEL));
+   if (curr_level > dvfsrc->curr_opps->num_opp)
+   curr_level = 0;
+   else
+   curr_level = dvfsrc->curr_opps->num_opp - curr_level;
+
+   return curr_level;
+}
+
+static int mt6873_wait_for_opp_level(struct mtk_dvfsrc *dvfsrc, u32 level)
+{
+   const struct dvfsrc_opp *target, *curr;
+
+   target = >curr_opps->opps[level];
+   return readx_poll_timeout_atomic(get_current_opp, dvfsrc, curr,
+   curr->dram_opp >= target->dram_opp,
+   STARTUP_TIME, POLL_TIMEOUT);
+}
+
+static u32 mt6873_get_vcore_level(struct mtk_dvfsrc *dvfsrc)
+{
+   return (dvfsrc_read(dvfsrc, DVFSRC_SW_REQ) >> 4) & 0x7;
+}
+
+static u32 mt6873_get_vcp_level(struct mtk_dvfsrc *dvfsrc)
+{
+   return (dvfsrc_read(dvfsrc, DVFSRC_VCORE_REQUEST) >> 12) & 0x7;
+}
+
+static void mt6873_set_dram_bw(struct mtk_dvfsrc *dvfsrc, u64 bw)
+{
+   bw = div_u64(kbps_to_mbps(bw), 100);
+   bw = min_t(u64, bw, 0xFF);
+   dvfsrc_write(dvfsrc, DVFSRC_SW_BW, bw);
+}
+
+static void mt6873_set_dram_peak_bw(struct mtk_dvfsrc *dvfsrc, u64 bw)
+{
+   bw = div_u64(kbps_to_mbps(bw), 100);
+   bw = min_t(u64, bw, 0xFF);
+   dvfsrc_write(dvfsrc, DVFSRC_SW_PEAK_BW, bw);
+}
+
+static void mt6873_set_dram_hrtbw(struct mtk_dvfsrc *dvfsrc, u64 bw)
+{
+   bw = div_u64((kbps_to_mbps(bw) + 29), 30);
+   bw = min_t(u64, bw, 0x3FF);
+   dvfsrc_write(dvfsrc, DVFSRC_SW_HRT_BW, bw);
+}
+
+static void mt6873_set_vcore_level(struct mtk_dvfsrc *dvfsrc, u32 level)
+{
+   spin_lock(>req_lock);
+   dvfsrc_rmw(dvfsrc, DVFSRC_SW_REQ, level, 0x7, 4);
+   spin_unlock(>req_lock);
+}
+
+static void mt6873_set_vscp_level(struct mtk_dvfsrc *dvfsrc, u32 level)
+{
+   dvfsrc_rmw(dvfsrc, DVFSRC_VCORE_REQUEST, level, 0x7, 12);
+}
+
 static int mt8183_wait_for_opp_level(struct mtk_dvfsrc *dvfsrc, u32 level)
 {
const struct dvfsrc_opp *target, *curr;
@@ -377,6 +459,35 @@ static int mtk_dvfsrc_probe(struct platform_device *pdev)
.wait_for_vcore_level = dvfsrc_wait_for_vcore_level,
 };
 
+static const struct dvfsrc_opp dvfsrc_opp_mt6873_lp4[] = {
+   {0, 0}, {1, 0}, {2, 0}, {3, 0},
+   {0, 1}, {1, 1}, {2, 1}, {3, 1},
+   {0, 2}, {1, 2}, {2, 2}, {3, 2},
+   {1, 3}, {2, 3}, {3, 3}, {1, 4},
+   {2, 4}, {3, 4}, {2, 5}, {3, 5},
+   {3, 6},
+};
+
+static const struct dvfsrc_opp_desc dvfsrc_opp_mt6873_desc[] = {
+   DVFSRC_OPP_DESC(dvfsrc_opp_mt6873_lp4),
+};
+
+static const struct dvfsrc_soc_data mt6873_data = {
+   .opps_desc = dvfsrc_opp_mt6873_desc,
+   .regs = mt6873_regs,
+   .get_target_level = mt6873_get_target_level,
+   .get_current_level = mt6873_get_current_level,
+   .get_vcore_level = mt6873_get_vcore_level,
+   .get_vcp_level = mt6873_get_vcp_level,
+   .set_dram_bw = mt6873_set_dram_bw,
+   .set_dram_peak_bw = mt6873_set_dram_peak_bw,
+   .set_dram_hrtbw = mt6873_set_dram_hrtbw,
+   .set_vcore_level = mt6873_set_vcore_level,
+   .set_vscp_level = mt6873_set_vscp_level,
+   .wait_for_opp_level = mt6873_wait_for_opp_level,
+   .wait_for_vcore_level = dvfsrc_wait_for_vcore_level,
+};
+
 static int mtk_dvfsrc_remove(struct platform_device *pdev)
 {
struct mtk_dvfsrc *dvfsrc = platform_get_drvdata(pdev);
@@ -392,6 +503,9 @@ static int mtk_dvfsrc_remove(struct platform_device *pdev)
.compatible = "mediatek,mt8183-dvfsrc",
.data = _data,
}, {
+   .compatible = "mediatek,mt6873-dvfsrc",
+   .data = _data,
+

[PATCH V7 02/13] soc: mediatek: add header for mediatek SIP interface

Add a header to collect SIPs and add one SIP call to initialize power
management hardware for the SIP interface defined to access the SPM
handling vcore voltage and ddr rate changes on mt8183 (and most likely
later socs).

Signed-off-by: Henry Chen 
Signed-off-by: Arvin Wang 
---
 include/linux/soc/mediatek/mtk_sip_svc.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/soc/mediatek/mtk_sip_svc.h 
b/include/linux/soc/mediatek/mtk_sip_svc.h
index 082398e..079bbcb 100644
--- a/include/linux/soc/mediatek/mtk_sip_svc.h
+++ b/include/linux/soc/mediatek/mtk_sip_svc.h
@@ -22,4 +22,8 @@
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
   ARM_SMCCC_OWNER_SIP, fn_id)
 
+/* VCOREFS */
+#define MTK_SIP_VCOREFS_CONTROL \
+   MTK_SIP_SMC_CMD(0x506)
+
 #endif
-- 
1.9.1

[PATCH V7 12/13] arm64: dts: mt8183: add dvfsrc regulator nodes

Add dvfsrc regulator nodes which is for MT8183-based platforms

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index e862078..9fefc5e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -502,6 +502,12 @@
compatible = "mediatek,mt8183-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
#interconnect-cells = <1>;
+   dvfsrc_vcore: dvfsrc-vcore {
+   regulator-name = "dvfsrc-vcore";
+   regulator-min-microvolt = <725000>;
+   regulator-max-microvolt = <80>;
+   regulator-always-on;
+   };
};
 
pwrap: pwrap@1000d000 {
-- 
1.9.1

[PATCH V7 03/13] soc: mediatek: add driver for dvfsrc support

Add dvfsrc driver for MT6873/MT8183/MT8192

Signed-off-by: Henry Chen 
---
 drivers/soc/mediatek/Kconfig|  12 +
 drivers/soc/mediatek/Makefile   |   1 +
 drivers/soc/mediatek/mtk-dvfsrc.c   | 421 
 include/linux/soc/mediatek/mtk_dvfsrc.h |  35 +++
 4 files changed, 469 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
 create mode 100644 include/linux/soc/mediatek/mtk_dvfsrc.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc0..693a0ff 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -26,6 +26,18 @@ config MTK_DEVAPC
  The violation information is logged for further analysis or
  countermeasures.
 
+config MTK_DVFSRC
+   tristate "MediaTek DVFSRC Support"
+   depends on ARCH_MEDIATEK
+   depends on MTK_SCPSYS
+   help
+ Say yes here to add support for the MediaTek DVFSRC (dynamic voltage
+ and frequency scaling resource collector) found
+ on different MediaTek SoCs. The DVFSRC is a proprietary
+ hardware which is used to collect all the requests from
+ system and turn into the decision of minimum Vcore voltage
+ and minimum DRAM frequency to fulfill those requests.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index b6908db..4ead103 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
+obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c 
b/drivers/soc/mediatek/mtk-dvfsrc.c
new file mode 100644
index 000..c0c6d91
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-dvfsrc.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DVFSRC_IDLE 0x00
+#define DVFSRC_GET_TARGET_LEVEL(x)  (((x) >> 0) & 0x)
+#define DVFSRC_GET_CURRENT_LEVEL(x) (((x) >> 16) & 0x)
+#define kbps_to_mbps(x) ((x) / 1000)
+
+#define POLL_TIMEOUT1000
+#define STARTUP_TIME1
+
+#define MTK_SIP_DVFSRC_INIT0x00
+
+#define DVFSRC_OPP_DESC(_opp_table)\
+{  \
+   .opps = _opp_table, \
+   .num_opp = ARRAY_SIZE(_opp_table),  \
+}
+
+struct dvfsrc_opp {
+   u32 vcore_opp;
+   u32 dram_opp;
+};
+
+struct dvfsrc_opp_desc {
+   const struct dvfsrc_opp *opps;
+   u32 num_opp;
+};
+
+struct mtk_dvfsrc;
+struct dvfsrc_soc_data {
+   const int *regs;
+   const struct dvfsrc_opp_desc *opps_desc;
+   int (*get_target_level)(struct mtk_dvfsrc *dvfsrc);
+   int (*get_current_level)(struct mtk_dvfsrc *dvfsrc);
+   u32 (*get_vcore_level)(struct mtk_dvfsrc *dvfsrc);
+   u32 (*get_vcp_level)(struct mtk_dvfsrc *dvfsrc);
+   void (*set_dram_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+   void (*set_dram_peak_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+   void (*set_dram_hrtbw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
+   void (*set_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+   void (*set_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+   void (*set_vscp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+   int (*wait_for_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+   int (*wait_for_vcore_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
+};
+
+struct mtk_dvfsrc {
+   struct device *dev;
+   struct platform_device *icc;
+   struct platform_device *regulator;
+   const struct dvfsrc_soc_data *dvd;
+   int dram_type;
+   const struct dvfsrc_opp_desc *curr_opps;
+   void __iomem *regs;
+   spinlock_t req_lock;
+   struct mutex pstate_lock;
+   struct notifier_block scpsys_notifier;
+};
+
+static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset)
+{
+   return readl(dvfs->regs + dvfs->dvd->regs[offset]);
+}
+
+static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val)
+{
+   writel(val, dvfs->regs + dvfs->dvd->regs[offset]);
+}
+
+#define dvfsrc_rmw(dvfs, offset, val, mask, shift) \
+   dvfsrc_write(dvfs, offset, \
+   (dvfsrc_read(dvfs, offset) & ~(mask << shift)) | (val << shift))
+
+enum dvfsrc_regs {
+   DVFSRC_SW_REQ,
+   DVFSRC_SW_REQ2,
+   DVFSRC_LEVEL,
+   DVFSRC_TARGET_LEVEL,
+   DVFSRC_SW_BW,
+   DVFSRC_SW_PEAK_BW,
+   DVFSRC_SW_HRT_BW,
+   DVFSRC_VCORE_REQUEST,
+};
+
+static const int mt8183_regs[] = {
+   [DVFSRC_SW_REQ] =   0x4,
+   [DVFSRC_SW_REQ2] =  0x8,
+

[PATCH V7 11/13] arm64: dts: mt8192: add dvfsrc related nodes

Add DDR EMI provider dictating dram interconnect bus performance found on
MT8183-based platforms

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index dbefc0d..81d7d05 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -6,6 +6,7 @@
 
 /dts-v1/;
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -468,6 +469,7 @@
compatible = "mediatek,mt8192-dvfsrc",
 "mediatek,mt6873-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
+   #interconnect-cells = <1>;
};
 
systimer: timer@10017000 {
-- 
1.9.1

[PATCH V7 13/13] arm64: dts: mt8192: add dvfsrc regulator nodes

Add dvfsrc regulator nodes which is for MT8192-based platforms

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 81d7d05..1cf91a4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -470,6 +470,12 @@
 "mediatek,mt6873-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
#interconnect-cells = <1>;
+   dvfsrc_vcore: dvfsrc-vcore {
+   regulator-name = "dvfsrc-vcore";
+   regulator-min-microvolt = <575000>;
+   regulator-max-microvolt = <725000>;
+   regulator-always-on;
+   };
};
 
systimer: timer@10017000 {
-- 
1.9.1

[PATCH V7 10/13] arm64: dts: mt8183: add dvfsrc related nodes

Add DDR EMI provider dictating dram interconnect bus performance found on
MT8192-based platforms

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 062afe8..e862078 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -500,6 +501,7 @@
ddr_emi: dvfsrc@10012000 {
compatible = "mediatek,mt8183-dvfsrc";
reg = <0 0x10012000 0 0x1000>;
+   #interconnect-cells = <1>;
};
 
pwrap: pwrap@1000d000 {
-- 
1.9.1

[PATCH V7 00/13] Add driver for dvfsrc, support for active state of scpsys

This series is based on v5.11-rc1.

The patchsets add support for MediaTek hardware module named DVFSRC
(dynamic voltage and frequency scaling resource collector). The DVFSRC is
a HW module which is used to collect all the requests from both software
and hardware and turn into the decision of minimum operating voltage and
minimum DRAM frequency to fulfill those requests.

So, This series is to implement the dvfsrc driver to collect all the
requests of operating voltage or DRAM bandwidth from other device drivers
likes GPU/Camera through 3 frameworks basically:

1. interconnect framework: to aggregate the bandwidth
   requirements from different clients

[1] https://patchwork.kernel.org/cover/10766329/

There has a hw module "DRAM scheduler", which used to control the throughput.
The DVFSRC will collect forecast data of dram bandwidth from
SW consumers(camera/gpu...), and according the forecast to change the DRAM
frequency

2. Regualtor framework: to handle the operating voltage requirement from user or
   cosumer which not belong any power domain

Changes in V7:
* Fixed the dt_binding_check error of dvfsrc.yaml. (Rob)
* Fixed the checkpatch complains of "Signed-off-by: email name mismatch". 
(Georgi)
* Fixed coding style of interconnect driver. (Georgi)
* Upate comment of the years to 2021. (Georgi)

Changes in V6:
* Remove the performace state support, because the request from consumer can be
replaced by using interconnect and regulator framework.
* Update the DT patches and convert them to DT schema. (Georgi)
* Modify the comment format and coding style. (Mark)

Changes in V5:
* Support more platform mt6873/mt8192
* Drop the compatible and interconnect provider node and make the parent node an
interconnect provider. (Rob/Georgi)
* Make modification of interconnect driver from coding suggestion. (Georgi)
* Move interconnect diagram into the commit text of patch. (Georgi)
* Register the interconnect provider as a platform sub-device. (Georgi)

Changes in V4:
* Add acked TAG on dt-bindings patches. (Rob)
* Declaration of emi_icc_aggregate since the prototype of aggregate function
has changed meanwhile. (Georgi)
* Used emi_icc_remove instead of icc_provider_del on probe. (Georgi)
* Add dvfsrc regulator driver into series.
* Bug fixed of mt8183_get_current_level.
* Add mutex protection for pstate operation on dvfsrc_set_performance.

Changes in V3:
* Remove RFC from the subject prefix of the series
* Combine dt-binding patch and move interconnect dt-binding document into
dvfsrc. (Rob)
* Remove unused header, add unit descirption to the bandwidth, rename compatible
name on interconnect driver. (Georgi)
* Fixed some coding style: check flow, naming, used readx_poll_timeout
on dvfsrc driver. (Ryan)
* Rename interconnect driver mt8183.c to mtk-emi.c
* Rename interconnect header mtk,mt8183.h to mtk,emi.h
* mtk-scpsys.c: Add opp table check first to avoid OF runtime parse failed

Changes in RFC V2:
* Remove the DT property dram_type. (Rob)
* Used generic dts property 'opp-level' to get the performace state. (Stephen)
* Remove unecessary dependency config on Kconfig. (Stephen)
* Remove unused header file, fixed some coding style issue, typo,
error handling on dvfsrc driver. (Nicolas/Stephen)
* Remove irq handler on dvfsrc driver. (Stephen)
* Remove init table on dvfsrc driver, combine hw init on trustzone.
* Add interconnect support of mt8183 to aggregate the emi bandwidth.
(Georgi)

V6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=406077
V5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=348065
V4: https://lore.kernel.org/patchwork/cover/1209284/
V3: https://patchwork.kernel.org/cover/8867/
RFC V2: https://lore.kernel.org/patchwork/patch/1068113/
RFC V1: https://lore.kernel.org/patchwork/cover/1028535/

[PATCH V7 06/13] arm64: dts: mt8192: add dvfsrc related nodes

Enable dvfsrc on mt8192 platform.

Signed-off-by: Henry Chen 
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 8252143..dbefc0d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -464,6 +464,12 @@
#clock-cells = <1>;
};
 
+   ddr_emi: dvfsrc@10012000 {
+   compatible = "mediatek,mt8192-dvfsrc",
+"mediatek,mt6873-dvfsrc";
+   reg = <0 0x10012000 0 0x1000>;
+   };
+
systimer: timer@10017000 {
compatible = "mediatek,mt8192-timer",
 "mediatek,mt6765-timer";
-- 
1.9.1

[PATCH] perf test: Fix shadow stat test for non-bash shells

2021-01-07 Thread Namhyung Kim

It was using some bash-specific features and failed to parse when
running with a different shell like below:

  root@kbl-ppc:~/kbl-ws/perf-dev/lck-9077/acme.tmp/tools/perf# ./perf test 83 
-vv
  83: perf stat metrics (shadow stat) test:
  --- start ---
  test child forked, pid 3922
  ./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  (standard_in) 2: syntax error
  ./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 19: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 24: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 30: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  (standard_in) 2: syntax error
  ./tests/shell/stat+shadow_stat.sh: 36: ./tests/shell/stat+shadow_stat.sh: [[: 
not found
  ./tests/shell/stat+shadow_stat.sh: 45: ./tests/shell/stat+shadow_stat.sh: 
declare: not found
  test child finished with -1
   end 
  perf stat metrics (shadow stat) test: FAILED!

Reported-by: Jin Yao 
Signed-off-by: Namhyung Kim 
---
 tools/perf/tests/shell/stat+shadow_stat.sh | 24 --
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/tools/perf/tests/shell/stat+shadow_stat.sh 
b/tools/perf/tests/shell/stat+shadow_stat.sh
index 249dfe48cf6a..e2c7ac4ed91d 100755
--- a/tools/perf/tests/shell/stat+shadow_stat.sh
+++ b/tools/perf/tests/shell/stat+shadow_stat.sh
@@ -16,24 +16,24 @@ test_global_aggr()
while read num evt hash ipc rest
do
# skip not counted events
-   if [[ $num == "&1 | \
grep ^CPU | \
while read cpu num evt hash ipc rest
do
# skip not counted events
-   if [[ $num == "> $results
continue
fi
 
# skip if no cycles
-   local cyc=${results[$cpu]}
-   if [[ -z $cyc ]]; then
+   local cyc=$(grep $cpu $results | cut -d' ' -f2)
+   if [ -z "$cyc" ]; then
continue
fi
 
# use printf for rounding and a leading zero
local res=`printf "%.2f" $(echo "scale=6; $num / $cyc" | bc -q)`
-   if [[ $ipc != $res ]]; then
+   if [ "$ipc" != "$res" ]; then
echo "IPC is different for $cpu: $res != $ipc  ($num / 
$cyc)"
+   rm -f $results
exit 1
fi
done
+   rm -f $results
 }
 
 test_global_aggr
-- 
2.30.0.284.gd98b1dd5eaa7-goog

LTS: proc: fix lookup in /proc/net subdirectories after setns(2)

2021-01-07 Thread Rantala, Tommi T. (Nokia - FI/Espoo)

Hi Greg,

Can you cherry-pick these to 4.19.y & 5.4.y:

commit e06689bf57017ac022ccf0f2a5071f760821ce0f
Author: Alexey Dobriyan 
Date:   Wed Dec 4 16:49:59 2019 -0800

proc: change ->nlink under proc_subdir_lock

commit c6c75deda81344c3a95d1d1f606d5cee109e5d54
Author: Alexey Dobriyan 
Date:   Tue Dec 15 20:42:39 2020 -0800

proc: fix lookup in /proc/net subdirectories after setns(2)


-Tommi

Re: [RESEND PATCH 2/2] misc: add support for retimers interfaces on Intel MAX 10 BMC

2021-01-07 Thread Greg KH

On Fri, Jan 08, 2021 at 10:05:26AM +0800, Xu Yilun wrote:
> On Thu, Jan 07, 2021 at 10:26:12AM +0100, Greg KH wrote:
> > On Thu, Jan 07, 2021 at 02:07:08PM +0800, Xu Yilun wrote:
> > > This driver supports the ethernet retimers (C827) for the Intel PAC
> > > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> > > 
> > > C827 is an Intel(R) Ethernet serdes transceiver chip that supports
> > > up to 100G transfer. On Intel PAC N3000 there are 2 C827 chips
> > > managed by the Intel MAX 10 BMC firmware. They are configured in 4 ports
> > > 10G/25G retimer mode. Host could query their link states and firmware
> > > version information via retimer interfaces (Shared registers) on Intel
> > > MAX 10 BMC. The driver creates sysfs interfaces for users to query these
> > > information.
> > 
> > Networking people, please look at this sysfs file:
> > 
> > > +What:
> > > /sys/bus/platform/devices/n3000bmc-retimer.*.auto/link_statusX
> > > +Date:Jan 2021
> > > +KernelVersion:   5.12
> > > +Contact: Xu Yilun 
> > > +Description: Read only. Returns the status of each line side link. 
> > > "1" for
> > > + link up, "0" for link down.
> > > + Format: "%u".
> > 
> > as I need your approval to add it because it is not the "normal" way for
> > link status to be exported to userspace.
> > 
> > One code issue:
> > 
> > > +#define to_link_attr(dev_attr) \
> > > + container_of(dev_attr, struct link_attr, attr)
> > > +
> > > +static ssize_t
> > > +link_status_show(struct device *dev, struct device_attribute *attr, char 
> > > *buf)
> > > +{
> > > + struct m10bmc_retimer *retimer = dev_get_drvdata(dev);
> > > + struct link_attr *lattr = to_link_attr(attr);
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + ret = m10bmc_sys_read(retimer->m10bmc, M10BMC_PKVL_LSTATUS, );
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return sysfs_emit(buf, "%u\n",
> > > +   !!(val & BIT((retimer->id << 2) + lattr->index)));
> > > +}
> > > +
> > > +#define link_status_attr(_index) \
> > > + static struct link_attr link_attr_status##_index =  \
> > > + { .attr = __ATTR(link_status##_index, 0444, \
> > > +  link_status_show, NULL),   \
> > > +   .index = (_index) }
> > 
> > Why is this a "raw" attribute and not a device attribute?
> 
> It is actually a device_attribute. The device_attribute is embedded in
> link_attr, like:
> 
>   struct link_attr {
>   struct device_attribute attr;
>   u32 index;
>   };
> 
> An index for the link is appended along with the device_attribute, so we
> could identify which link is being queried on link_status_show(). There
> are 4 links and this is to avoid duplicated code like
> link_status_1_show(), link_status_2_show() ...

Duplicated code is better to read than complex code :)

> > Please just use a normal DEVICE_ATTR_RO() macro to make it simpler and
> 
> DEVICE_ATTR_RO() is to define a standalone device_attribute variable, but
> here we are initializing a field in struct link_attr.

Then use the correct initialization macro that is given to you for that,
do not roll your own.

greg k-h

Re: [PATCH v2] driver core: Fix device link device name collision

2021-01-07 Thread Greg Kroah-Hartman

On Fri, Jan 08, 2021 at 02:10:51AM +0100, Michael Walle wrote:
> Am 8. Januar 2021 02:00:32 MEZ schrieb Saravana Kannan :
> >On Thu, Jan 7, 2021 at 4:43 PM Saravana Kannan 
> >wrote:
> >Nevermind, I see it now. Also, in the future, if you can dump the logs
> >in some kind of pastebin site, that'd be nice. Avoid the emails
> >becoming unwieldy and also avoids the log lines from wrapping.
> 
> I thought about a pastebin. But then decided against it because they might be 
> deleted in the future. So if anyone looking at the mail archives he might 
> only get dead links. So.. 
> 
> dunno how this is handled on the LKML, tbh. 

Full logs are good, you did it right, Saravana can deal with long emails :)

drivers/gpu/drm/i915/i915_sw_fence.c:111:20: error: unused function 'debug_fence_free'

2021-01-07 Thread kernel test robot

Hi Nick,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f5e6c330254ae691f6d7befe61c786eb5056007e
commit: 9f4069b055d1508c833115df7493b6e0001e5c9b drm/i915: re-disable 
-Wframe-address
date:   9 months ago
config: x86_64-randconfig-r014-20210108 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
5c951623bc8965fa1e89660f2f5f4a2944e4981a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f4069b055d1508c833115df7493b6e0001e5c9b
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9f4069b055d1508c833115df7493b6e0001e5c9b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i915/i915_sw_fence.c:111:20: error: unused function 
>> 'debug_fence_free' [-Werror,-Wunused-function]
   static inline void debug_fence_free(struct i915_sw_fence *fence)
  ^
   1 error generated.


vim +/debug_fence_free +111 drivers/gpu/drm/i915/i915_sw_fence.c

fc1584059d6c438 Chris Wilson 2016-11-25  110  
fc1584059d6c438 Chris Wilson 2016-11-25 @111  static inline void 
debug_fence_free(struct i915_sw_fence *fence)
fc1584059d6c438 Chris Wilson 2016-11-25  112  {
fc1584059d6c438 Chris Wilson 2016-11-25  113  }
fc1584059d6c438 Chris Wilson 2016-11-25  114  

:: The code at line 111 was first introduced by commit
:: fc1584059d6c438b1febafa1c207ae1d3c6643e8 drm/i915: Integrate 
i915_sw_fence with debugobjects

:: TO: Chris Wilson 
:: CC: Chris Wilson 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [reiser4 SFRN 5.1.3] kernel [5.10.x] read not supported for file /test-exec \(pid: 10094 comm: debootstrap\)

2021-01-07 Thread Metztli Information Technology

On Fri, Dec 25, 2020 at 8:44 AM Metztli Information Technology 
 wrote:
>
> On Wed, Dec 23, 2020 at 3:40 PM Edward Shishkin  
> wrote:
> >
> > On 12/23/2020 05:01 PM, Metztli Information Technology wrote:
> > > Niltze [ÃâÃÂ´Ãâ¬ÃÂ°ÃÂ²Ã ÃâÃÂ²ÃÆÃÂ¹ÃâÃÂµ : Hello], Ed-
> > >
> > > I built Linux kernel 5.10.1-1 within the 'Debian way' -- as usual -- to 
> > > generate a kernel component for my Debian-Installer (d-i).
> > > The patch I applied is reiser4-for-5.10-rc3.patch.gz from v5-unstable.
> > >
> > > Once I built the proper reiser4progs-2.0.4.tar.gz and generated one set 
> > > of components for d-i I built the d-i image.
> > >
> > > Fact is, the installer throws an error in *both* bare metal and 
> > > VirtualBox 6.1.16:
> > > ...
> > > Dec 22 20:19:56 main-menu[330]: INFO: Menu item 'bootstrap-base' selected
> > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap --components=main 
> > > --debian-installer --resolve-deps 
> > > --keyring=/usr/share/keyrings/archive.gpg buster /target 
> > > http://deb.debian.org/debian/
> > > Dec 22 20:19:56 debootstrap: /usr/sbin/debootstrap: line 1596: 
> > > /target/test-exec: Invalid argument
> > > Dec 22 20:19:56 kernel: [ 1018.632648] kernel read not supported for file 
> > > /test-exec (pid: 10077 comm: debootstrap)
> > > Dec 22 20:19:56 debootstrap: E: NOEXEC
> > > Dec 22 20:19:56 debootstrap: EF: Cannot install into target '/target' 
> > > mounted with noexec or nodev
> > > Dec 22 20:20:12 base-installer: error: exiting on error 
> > > base-installer/debootstrap-failed
> > > Dec 22 20:20:14 main-menu[330]: WARNING **: Configuring 'bootstrap-base' 
> > > failed with error code 1
> > > Dec 22 20:20:14 main-menu[330]: WARNING **: Menu item 'bootstrap-base' 
> > > failed.
> > > Dec 22 20:20:15 main-menu[330]: INFO: Falling back to the package 
> > > description for brltty-udeb
> > >
> >
> > [...]
> >
> > >
> > > Apparently, d-i [Debian-installer] complains about being unable to set 
> > > the test file executable and causes the error when 1 is returned.
> > > Notwithstanding, I manually verified that I am able to touch a file and 
> > > set it +x executable.
> > >
> > > Furthermore, tricking the function return value to 0 I am able to make 
> > > d-i continue with the latest SFRN5 installation (see [*trick*] below); 
> > > yet, subsequently halts again with
> > > an apparently related error --can not proceed any further.
> > >
> > > Digging deeper with dmesg, we can see that apparently it is the kernel 
> > > which cannot 'read' properly. Please find a partial dmesg log with 
> > > relevant output
> > > from an attempt on my physical development machine.
> > > ...
> > > [ Â 508.614488] Loading Reiser4 (Software Framework Release: 5.1.3). See 
> > > reiser4.wiki.kernel.org for a description of Reiser4.
> > > [ Â 508.661951] SGI XFS with ACLs, security attributes, realtime, quota, 
> > > no debug enabled
> > > [ Â 509.326270] device-mapper: uevent: version 1.0.3
> > > [ Â 509.326505] device-mapper: ioctl: 4.43.0-ioctl (2020-10-01) 
> > > initialised: dm-de...@redhat.com
> > > [ Â 509.902828] Â sda: sda1 sda2 sda3 sda4 sda5 sda6
> > > [ Â 509.915300] Â sdb: sdb1 sdb2 sdb3
> > > [ Â 511.973360] Â sdb: sdb1 sdb2 sdb3
> > > [ Â 627.525371] Adding 9765884k swap on /dev/sda3. Â Priority:-2 
> > > extents:1 across:9765884k FS
> > > [ Â 636.240812] reiser4[mount(9430)]: reiser4_register_subvol 
> > > (fs/reiser4/init_volume.c:222)[edward-1932]:
> > > [ Â 636.240812] NOTICE: brick /dev/sda6 has been registered
> > > [ Â 636.243003] reiser4 (sda6): found disk format 5.1.3.
> > > [ Â 643.759971] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > > [ Â 643.759980] reiser4: brick /dev/sda6 activated
> > > [ Â 643.788537] EXT4-fs (sda1): mounting ext2 file system using the ext4 
> > > subsystem
> > > [ Â 643.813474] EXT4-fs (sda1): mounted filesystem without journal. Opts: 
> > > (null)
> > > [ Â 643.813488] ext2 filesystem being mounted at /target/boot supports 
> > > timestamps until 2038 (0x7fff)
> > > [ Â 648.168730] kernel read not supported for file /test-exec (pid: 9876 
> > > comm: debootstrap) [*trick*]
> > > [ Â 898.761385] reiser4: brick /dev/sda6 deactivated
> > > [ Â 991.001332] reiser4 (sda6): found disk format 5.1.3.
> > > [ Â 999.093471] reiser4 (/dev/sda6): using Hybrid Transaction Model.
> > > [ Â 999.093480] reiser4: brick /dev/sda6 activated
> > > [ 1009.340117] EXT4-fs (sda1): mounting ext2 file system using the ext4 
> > > subsystem
> > > [ 1009.362722] EXT4-fs (sda1): mounted filesystem without journal. Opts: 
> > > (null)
> > > [ 1009.362737] ext2 filesystem being mounted at /target/boot supports 
> > > timestamps until 2038 (0x7fff)
> > > [ 6373.748413] kernel read not supported for file /test-exec (pid: 10094 
> > > comm: debootstrap)
> > > [ 6413.169920] kernel read not supported for file /usr/bin/true (pid: 
> > > 15960 comm: chroot)
> >
> >
> > Hello.
> >
> > This is because of VFS changes in Linux-5.10.X.
> >

[PATCH for can-next] MAINTAINERS: adjust entry to tcan4x5x file split

2021-01-07 Thread Lukas Bulwahn

Commit 7813887ea972 ("can: tcan4x5x: rename tcan4x5x.c -> tcan4x5x-core.c")
and commit 67def4ef8bb9 ("can: tcan4x5x: move regmap code into seperate
file") split the file tcan4x5x.c into two files, but missed to adjust the
TI TCAN4X5X DEVICE DRIVER section in MAINTAINERS.

Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:

  warning: no file matchesF:drivers/net/can/m_can/tcan4x5x.c

Adjust the file entry in MAINTAINERS to the tcan4x5x file splitting.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on next-20210107, not for current master

Marc, please pick this for your -next tree on top of the tcan4x5x cleanup.

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8170b40d6236..0d75f07fc951 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17887,7 +17887,7 @@ M:  Dan Murphy 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/net/can/tcan4x5x.txt
-F: drivers/net/can/m_can/tcan4x5x.c
+F: drivers/net/can/m_can/tcan4x5x*
 
 TI TRF7970A NFC DRIVER
 M: Mark Greer 
-- 
2.17.1

Re: [PATCH 4.14 00/29] 4.14.214-rc1 review

2021-01-07 Thread Naresh Kamboju

On Thu, 7 Jan 2021 at 20:00, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.14.214 release.
> There are 29 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 09 Jan 2021 14:30:35 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.214-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 4.14.214-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 78e4e5e07ab0059bd4c96c117fb2a8e24bda7127
git describe: v4.14.213-30-g78e4e5e07ab0
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.213-30-g78e4e5e07ab0

No regressions (compared to build v4.14.213)

No fixes (compared to build v4.14.213)

Ran 40940 total tests in the following environments and test suites.

Environments
--
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- qemu-arm64-kasan
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- sparc
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* linux-log-parser
* igt-gpu-tools
* install-android-platform-tools-r2600
* kvm-unit-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* perf
* fwts
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* v4l2-compliance
* ltp-containers-tests
* ltp-open-posix-tests
* rcutorture

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH] neighbour: Disregard DEAD dst in neigh_update

2021-01-07 Thread Greg KH

On Thu, Jan 07, 2021 at 09:36:37PM -0500, Your Real Name wrote:
> On Tue, Jan 05, 2021 at 04:05:21PM -0800, David Miller wrote: 
> > 
> > 
> > From: Tong Zhu 
> > Date: Wed, 30 Dec 2020 17:54:23 -0500
> > 
> > > In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
> > > with loopback net_device and leads to loopback neighbour. It
> > > leads to an ethernet header with all zero addresses.
> > >
> > > A very troubling case is working with mac80211 and ath9k.
> > > A packet with all zero source MAC address to mac80211 will
> > > eventually fail ieee80211_find_sta_by_ifaddr in ath9k (xmit.c).
> > > As result, ath9k flushes tx queue (ath_tx_complete_aggr) without
> > > updating baw (block ack window), damages baw logic and disables
> > > transmission.
> > >
> > > Signed-off-by: Tong Zhu 
> > 
> > Please repost with an appropriate Fixes: tag.
> > 
> > Thanks.
> 
> I had a second thought on this. This fix should go mainline too. This is a 
> case we are sending out queued packets when arp reply from the neighbour 
> comes in. With 5.x kernel, a dst in DST_OBSOLETE_DEAD state leads to dropping
> of this packet. It is not as bad as with 4.x kernel that may end up with an
> all-zero mac address packet out to ethernet or choking up ath9k when using 
> block ack. Dropping the packet is still wrong. I’ll repost as a fix to
> mainline and target backport to 4.x LTS releases.

That's how kernel development works, please read
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how stable kernels are allowed to accept patches.

good luck!

greg k-h

[PATCH v2 2/2] Hyper-V: pci: x64: Moving the MSI entry definition to arch specific location

2021-01-07 Thread Sunil Muthuswamy

The Hyper-V MSI entry is architecture specific. Currently, it is
defined in an arch neutral location. This patch moves it to an
arch specific location.

Signed-off-by: Sunil Muthuswamy 
---
 arch/x86/include/asm/hyperv-tlfs.h | 7 +++
 include/asm-generic/hyperv-tlfs.h  | 8 
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index 6bf42aed387e..a15c17c7f019 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -523,6 +523,13 @@ struct hv_partition_assist_pg {
u32 tlb_lock_count;
 };
 
+union hv_msi_entry {
+   u64 as_uint64;
+   struct {
+   u32 address;
+   u32 data;
+   } __packed;
+};
 
 #include 
 
diff --git a/include/asm-generic/hyperv-tlfs.h 
b/include/asm-generic/hyperv-tlfs.h
index e73a11850055..6265f4494970 100644
--- a/include/asm-generic/hyperv-tlfs.h
+++ b/include/asm-generic/hyperv-tlfs.h
@@ -408,14 +408,6 @@ struct hv_tlb_flush_ex {
 } __packed;
 
 /* HvRetargetDeviceInterrupt hypercall */
-union hv_msi_entry {
-   u64 as_uint64;
-   struct {
-   u32 address;
-   u32 data;
-   } __packed;
-};
-
 struct hv_interrupt_entry {
u32 source; /* 1 for MSI(-X) */
u32 reserved1;
-- 
2.17.1

[PATCH v5 2/2] scsi: ufs-qcom: Fix ufs RST_n specs violation

2021-01-07 Thread Ziqi Chen

As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, RST_n signal should be between
VSS(Ground) and VCCQ/VCCQ2.

Signed-off-by: Ziqi Chen 
---
 drivers/scsi/ufs/ufs-qcom.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2206b1e..d8b896c 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -582,6 +582,10 @@ static int ufs_qcom_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
ufs_qcom_disable_lane_clks(host);
phy_power_off(phy);
 
+   /* reset the connected UFS device during power down */
+   if (host->device_reset)
+   gpiod_set_value_cansleep(host->device_reset, 1);
+
} else if (!ufs_qcom_is_link_active(hba)) {
ufs_qcom_disable_lane_clks(host);
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/2] Hyper-V: pci: x64: Generalize irq/msi set-up and handling

2021-01-07 Thread Sunil Muthuswamy

Currently, operations related to irq/msi in Hyper-V vPCI are
x86-specific code. In order to support virtual PCI on Hyper-V for
other architectures, introduce generic interfaces to replace the
x86-specific ones. There are no functional changes in this patch.

Co-developed-by: Boqun Feng (Microsoft) 
Signed-off-by: Boqun Feng (Microsoft) 
Signed-off-by: Sunil Muthuswamy 
---
In V2:
- Addressed feedback on SoB tab.
- Added a second patch to move the MSI entry definition.
---
 arch/x86/include/asm/mshyperv.h | 24 +
 drivers/pci/controller/pci-hyperv.c | 33 +
 2 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ffc289992d1b..05b32ef57e34 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -245,6 +245,30 @@ bool hv_vcpu_is_preempted(int vcpu);
 static inline void hv_apic_init(void) {}
 #endif
 
+#define hv_msi_handler handle_edge_irq
+#define hv_msi_handler_name"edge"
+#define hv_msi_prepare pci_msi_prepare
+
+/* Returns the Hyper-V PCI parent MSI vector domain. */
+static inline struct irq_domain *hv_msi_parent_vector_domain(void)
+{
+   return x86_vector_domain;
+}
+
+/* Returns the interrupt vector mapped to the given IRQ. */
+static inline unsigned int hv_msi_get_int_vector(struct irq_data *data)
+{
+   struct irq_cfg *cfg = irqd_cfg(data);
+
+   return cfg->vector;
+}
+
+/* Get the IRQ delivery mode. */
+static inline u8 hv_msi_irq_delivery_mode(void)
+{
+   return APIC_DELIVERY_MODE_FIXED;
+}
+
 static inline void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry,
  struct msi_desc *msi_desc)
 {
diff --git a/drivers/pci/controller/pci-hyperv.c 
b/drivers/pci/controller/pci-hyperv.c
index 6db8d96a78eb..9ca740d275d7 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -43,12 +43,11 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -1194,7 +1193,6 @@ static void hv_irq_mask(struct irq_data *data)
 static void hv_irq_unmask(struct irq_data *data)
 {
struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
-   struct irq_cfg *cfg = irqd_cfg(data);
struct hv_retarget_device_interrupt *params;
struct hv_pcibus_device *hbus;
struct cpumask *dest;
@@ -1223,7 +1221,7 @@ static void hv_irq_unmask(struct irq_data *data)
   (hbus->hdev->dev_instance.b[7] << 8) |
   (hbus->hdev->dev_instance.b[6] & 0xf8) |
   PCI_FUNC(pdev->devfn);
-   params->int_target.vector = cfg->vector;
+   params->int_target.vector = hv_msi_get_int_vector(data);
 
/*
 * Honoring apic->delivery_mode set to APIC_DELIVERY_MODE_FIXED by
@@ -1324,7 +1322,7 @@ static u32 hv_compose_msi_req_v1(
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
int_pkt->int_desc.vector_count = 1;
-   int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+   int_pkt->int_desc.delivery_mode = hv_msi_irq_delivery_mode();
 
/*
 * Create MSI w/ dummy vCPU set, overwritten by subsequent retarget in
@@ -1345,7 +1343,7 @@ static u32 hv_compose_msi_req_v2(
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
int_pkt->int_desc.vector_count = 1;
-   int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+   int_pkt->int_desc.delivery_mode = hv_msi_irq_delivery_mode();
 
/*
 * Create MSI w/ dummy vCPU set targeting just one vCPU, overwritten
@@ -1372,7 +1370,6 @@ static u32 hv_compose_msi_req_v2(
  */
 static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
-   struct irq_cfg *cfg = irqd_cfg(data);
struct hv_pcibus_device *hbus;
struct vmbus_channel *channel;
struct hv_pci_dev *hpdev;
@@ -1422,7 +1419,7 @@ static void hv_compose_msi_msg(struct irq_data *data, 
struct msi_msg *msg)
size = hv_compose_msi_req_v1(_pkts.v1,
dest,
hpdev->desc.win_slot.slot,
-   cfg->vector);
+   hv_msi_get_int_vector(data));
break;
 
case PCI_PROTOCOL_VERSION_1_2:
@@ -1430,7 +1427,7 @@ static void hv_compose_msi_msg(struct irq_data *data, 
struct msi_msg *msg)
size = hv_compose_msi_req_v2(_pkts.v2,
dest,
hpdev->desc.win_slot.slot,
-   cfg->vector);
+   hv_msi_get_int_vector(data));
break;
 
default:
@@ -1541,12 +1538,13 @@ static struct irq_chip

[PATCH v5 1/2] scsi: ufs: Fix ufs clk specs violation

2021-01-07 Thread Ziqi Chen

As per specs, e.g, JESD220E chapter 7.2, while powering
off/on the ufs device, REF_CLK signal should be between
VSS(Ground) and VCCQ/VCCQ2.

Signed-off-by: Ziqi Chen 
---
 drivers/scsi/ufs/ufshcd.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add..3f807f7 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8686,8 +8686,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
if (ret)
goto set_dev_active;
 
-   ufshcd_vreg_set_lpm(hba);
-
 disable_clks:
/*
 * Call vendor specific suspend callback. As these callbacks may access
@@ -8711,6 +8709,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
hba->clk_gating.state);
}
 
+   ufshcd_vreg_set_lpm(hba);
+
/* Put the host controller in low power mode if possible */
ufshcd_hba_vreg_set_lpm(hba);
goto out;
@@ -8778,18 +8778,18 @@ static int ufshcd_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
old_link_state = hba->uic_link_state;
 
ufshcd_hba_vreg_set_hpm(hba);
+   ret = ufshcd_vreg_set_hpm(hba);
+   if (ret)
+   goto out;
+
/* Make sure clocks are enabled before accessing controller */
ret = ufshcd_setup_clocks(hba, true);
if (ret)
-   goto out;
+   goto disable_vreg;
 
/* enable the host irq as host controller would be active soon */
ufshcd_enable_irq(hba);
 
-   ret = ufshcd_vreg_set_hpm(hba);
-   if (ret)
-   goto disable_irq_and_vops_clks;
-
/*
 * Call vendor specific resume callback. As these callbacks may access
 * vendor specific host controller register space call them when the
@@ -8797,7 +8797,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 */
ret = ufshcd_vops_resume(hba, pm_op);
if (ret)
-   goto disable_vreg;
+   goto disable_irq_and_vops_clks;
 
/* For DeepSleep, the only supported option is to have the link off */
WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8864,8 +8864,6 @@ static int ufshcd_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
ufshcd_vops_suspend(hba, pm_op);
-disable_vreg:
-   ufshcd_vreg_set_lpm(hba);
 disable_irq_and_vops_clks:
ufshcd_disable_irq(hba);
if (hba->clk_scaling.is_allowed)
@@ -8876,6 +8874,8 @@ static int ufshcd_resume(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
}
+disable_vreg:
+   ufshcd_vreg_set_lpm(hba);
 out:
hba->pm_op_in_progress = 0;
if (ret)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow

2021-01-07 Thread Dexuan Cui

Linux VM on Hyper-V crashes with the latest mainline:

[4.069624] detected buffer overflow in strcpy
[4.077733] kernel BUG at lib/string.c:1149!
..
[4.085819] RIP: 0010:fortify_panic+0xf/0x11
...
[4.085819] Call Trace:
[4.085819]  acpi_device_add.cold.15+0xf2/0xfb
[4.085819]  acpi_add_single_object+0x2a6/0x690
[4.085819]  acpi_bus_check_add+0xc6/0x280
[4.085819]  acpi_ns_walk_namespace+0xda/0x1aa
[4.085819]  acpi_walk_namespace+0x9a/0xc2
[4.085819]  acpi_bus_scan+0x78/0x90
[4.085819]  acpi_scan_init+0xfa/0x248
[4.085819]  acpi_init+0x2c1/0x321
[4.085819]  do_one_initcall+0x44/0x1d0
[4.085819]  kernel_init_freeable+0x1ab/0x1f4

This is because of the recent buffer overflow detection in the
commit 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified 
string functions")

Here acpi_device_bus_id->bus_id can only hold 14 characters, while the
the acpi_device_hid(device) returns a 22-char string
"HYPER_V_GEN_COUNTER_V1".

Per ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID), if the ID is a
string, it must be of the form AAA or , i.e. 7 chars or 8
chars.

The field bus_id in struct acpi_device_bus_id was originally defined as
char bus_id[9], and later was enlarged to char bus_id[15] in 2007 in the
commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices")

Fix the issue by changing the field bus_id to const char *, and use
kstrdup_const() to initialize it.

Signed-off-by: Dexuan Cui 
---

Changes in v2:
strlcpy -> kstrdup_const. Thanks Rafael J. Wysocki!
Change commit log accordingly.

 drivers/acpi/internal.h |  2 +-
 drivers/acpi/scan.c | 14 +-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index cb229e24c563..e6a5d997241c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -97,7 +97,7 @@ void acpi_scan_table_handler(u32 event, void *table, void 
*context);
 extern struct list_head acpi_bus_id_list;
 
 struct acpi_device_bus_id {
-   char bus_id[15];
+   const char *bus_id;
unsigned int instance_no;
struct list_head node;
 };
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index a1b226eb2ce2..8d49d192d1c1 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -486,6 +486,7 @@ static void acpi_device_del(struct acpi_device *device)
acpi_device_bus_id->instance_no--;
else {
list_del(_device_bus_id->node);
+   kfree_const(acpi_device_bus_id->bus_id);
kfree(acpi_device_bus_id);
}
break;
@@ -674,7 +675,14 @@ int acpi_device_add(struct acpi_device *device,
}
if (!found) {
acpi_device_bus_id = new_bus_id;
-   strcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device));
+   acpi_device_bus_id->bus_id =
+   kstrdup_const(acpi_device_hid(device), GFP_KERNEL);
+   if (!acpi_device_bus_id->bus_id) {
+   pr_err(PREFIX "Memory allocation error for bus id\n");
+   result = -ENOMEM;
+   goto err_free_new_bus_id;
+   }
+
acpi_device_bus_id->instance_no = 0;
list_add_tail(_device_bus_id->node, _bus_id_list);
}
@@ -709,6 +717,10 @@ int acpi_device_add(struct acpi_device *device,
if (device->parent)
list_del(>node);
list_del(>wakeup_list);
+
+ err_free_new_bus_id:
+   if (!found)
+   kfree(new_bus_id);
mutex_unlock(_device_lock);
 
  err_detach:
-- 
2.19.1

Re: [PATCH 4/4] Input: omap4-keypad - simplify probe with devm

2021-01-07 Thread Tony Lindgren

* Sebastian Reichel  [210106 13:44]:
> On Wed, Jan 06, 2021 at 02:58:22PM +0200, Tony Lindgren wrote:
> > -   struct resource *res;
> >  
> > dev_pm_clear_wake_irq(>dev);
> > -
> > -   free_irq(keypad_data->irq, keypad_data);
> > -
> > pm_runtime_dont_use_autosuspend(>dev);
> > pm_runtime_disable(>dev);
> > -
> > input_unregister_device(keypad_data->input);
> 
> not needed:
> 
>  * devm_input_allocate_device - allocate managed input device
>  * @dev: device owning the input device being created
>  *
>  * Returns prepared struct input_dev or %NULL.
>  *
>  * Managed input devices do not need to be explicitly unregistered or
>  * freed as it will be done automatically when owner device unbinds from
>  * its driver (or binding fails). [...]

OK thanks will drop and fix up the reported autobuild warnings
and repost. Looks like also the OMAP4_KEYPAD_AUTOIDLE_MS value
of 50 is too long, I recently changed it from 30 but now have
seen few stuck last pressed keys.

Regards,

Tony

[PATCH RESEND v3] venus: venc: set inband mode property to FW.

2021-01-07 Thread Dikshita Agarwal

set HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER to FW
to support inband sequence header mode.

Signed-off-by: Dikshita Agarwal 

Changes since v2:
- fixed Null pointer dereference (Stanimir, Fritz)
- added set property call at correct place.
---
 drivers/media/platform/qcom/venus/venc.c   | 14 ++
 drivers/media/platform/qcom/venus/venc_ctrls.c | 17 -
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 3a2e449..ae21a7c 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -536,6 +536,7 @@ static int venc_set_properties(struct venus_inst *inst)
struct hfi_idr_period idrp;
struct hfi_quantization quant;
struct hfi_quantization_range quant_range;
+   struct hfi_enable en;
u32 ptype, rate_control, bitrate;
u32 profile, level;
int ret;
@@ -655,6 +656,19 @@ static int venc_set_properties(struct venus_inst *inst)
if (ret)
return ret;
 
+   if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+   inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+   ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER;
+   if (ctr->header_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE)
+   en.enable = 0;
+   else
+   en.enable = 1;
+
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+   }
+
if (!ctr->bitrate_peak)
bitrate *= 2;
else
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c 
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index cf860e6..3ce02ad 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -158,6 +158,20 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
ctr->header_mode = ctrl->val;
+   mutex_lock(>lock);
+   if (inst->streamon_out && inst->streamon_cap) {
+   if (ctrl->val == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE)
+   en.enable = 0;
+   else
+   en.enable = 1;
+   ptype = 
HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER;
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret) {
+   mutex_unlock(>lock);
+   return ret;
+   }
+   }
+   mutex_unlock(>lock);
break;
case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB:
break;
@@ -289,7 +303,8 @@ int venc_ctrl_init(struct venus_inst *inst)
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
V4L2_CID_MPEG_VIDEO_HEADER_MODE,
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
-   1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
+   ~((1 << V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
+   (1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME)),
V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE);
 
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
-- 
2.7.4

Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430

2021-01-07 Thread Tony Lindgren

* H. Nikolaus Schaller  [201230 13:29]:
> > Am 30.12.2020 um 13:55 schrieb Adam Ford :
> > On Wed, Dec 30, 2020 at 2:43 AM Tony Lindgren  wrote:
> >> 
> >> At least for 4430, trying to use the single conversion mode eventually
> >> hangs the thermal sensor. This can be quite easily seen with errors:
> >> 
> >> thermal thermal_zone0: failed to read out thermal zone (-5)
...

> > I don't have an OMAP4, but if you want, I can test a DM3730.
> 
> Indeed I remember a similar discussion from the DM3730 [1]. temp values were
> always those from the last measurement. E.g. the first one was done
> during (cold) boot and the first request after 10 minutes did show a
> quite cold system... The next one did show a hot system independent
> of what had been between (suspend or high activity).
> 
> It seems as if it was even reproducible with a very old kernel on a 
> BeagleBoard.
> So it is quite fundamental.
> 
> We tried to fix it but did not come to a solution [2]. So we opened an issue
> in our tracker [3] and decided to stay with continuous conversion although 
> this
> raises idle mode processor load.

Hmm so maybe eocz high always times out in single mode since it also
triggers at least on dra7?

Yes it would be great if you guys can the $subject patch a try at
least on your omap36xx and omap5 boards and see if you see eocz
time out warnings in dmesg.

Regards,

Tony

Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430

2021-01-07 Thread Tony Lindgren

* Péter Ujfalusi  [201231 12:55]:
> On 12/30/20 10:43 AM, Tony Lindgren wrote:
> > @@ -58,7 +58,8 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE - 
> > OMAP4430_ADC_START_VALUE + 1] = {
> >  const struct ti_bandgap_data omap4430_data = {
> > .features = TI_BANDGAP_FEATURE_MODE_CONFIG |
> > TI_BANDGAP_FEATURE_CLK_CTRL |
> > -   TI_BANDGAP_FEATURE_POWER_SWITCH,
> > +   TI_BANDGAP_FEATURE_POWER_SWITCH |
> > +   TI_BANDGAP_FEATURE_CONT_MODE_ONLY,
> 
> Can we add a comment with the observations?

Sure, and I also noticed that the timeout triggers also on dra7
too. I need to recheck what all are affected.. At least we now
see warnings on the SoCs affected.

> > @@ -605,8 +606,10 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, 
> > int id)
> > u32 counter = 1000;
> > struct temp_sensor_registers *tsr;
> >  
> > -   /* Select single conversion mode */
> > -   if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> > +   /* Select continuous or single conversion mode */
> > +   if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY))
> > +   RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1);
> > +   else if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> > RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);
> 
> Would not be better to:
> if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
>   if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY))
>   RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1);
>   else
>   RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);
> }
> 
> One can only switch to cont/single mode if the mode config is possible.

Yup makes sense thanks for spotting that.

Regards,

Tony

RE: dmaengine : xilinx_dma two issues

2021-01-07 Thread Radhey Shyam Pandey

> -Original Message-
> From: Radhey Shyam Pandey
> Sent: Monday, January 4, 2021 10:50 AM
> To: Paul Thomas ; Dan Williams
> ; Vinod Koul ; Michal Simek
> ; Matthew Murrian ;
> Romain Perier ; Krzysztof Kozlowski
> ; Marc Ferland ; Sebastian von Ohr
> ; dmaeng...@vger.kernel.org; Linux ARM  arm-ker...@lists.infradead.org>; linux-kernel  ker...@vger.kernel.org>; Shravya Kumbham ; git
> 
> Subject: RE: dmaengine : xilinx_dma two issues
> 
> > -Original Message-
> > From: Paul Thomas 
> > Sent: Monday, December 28, 2020 10:14 AM
> > To: Dan Williams ; Vinod Koul
> > ; Michal Simek ; Radhey Shyam
> > Pandey ; Matthew Murrian
> > ; Romain Perier
> ;
> > Krzysztof Kozlowski ; Marc Ferland
> > ; Sebastian von Ohr ;
> > dmaeng...@vger.kernel.org; Linux ARM  > arm-ker...@lists.infradead.org>; linux-kernel  > ker...@vger.kernel.org>
> > Subject: dmaengine : xilinx_dma two issues
> >
> > Hello,
> >
> > I'm trying to get the 5.10 kernel up and running for our system, and
> > I'm running into a couple of issues with xilinx_dma.
> + (Xilinx mailing list)
> 
> Thanks for bringing the issues to our notice. Replies inline.
> 
> >
> > First, commit 14ccf0aab46e 'dmaengine: xilinx_dma: In dma channel
> > probe fix node order dependency' breaks our usage. Before this commit a
> call to:
> > dma_request_chan(_dev->dev, "axi_dma_0"); returns fine, but
> > after that commit it returns -19. The reason for this seems to be that
> > the only channel that is setup is channel 1 (chan->id is 1 in
> xilinx_dma_chan_probe()).
> > However in
> > of_dma_xilinx_xlate() chan_id is gets set to 0 (int chan_id =
> > dma_spec-
> > >args[0];), which causes the:
> > !xdev->chan[chan_id]
> > test to fail in of_dma_xilinx_xlate()
> 
> What is the channel number passed in
> dmaclient DT?

Any update on this issue?

> 
> dmas = <& axi_dma_0 1>
> dma-names = "axi_dma_0"
> 
> >
> > Our device-tree entry looks like this:
> > axi_dma_0: dma@80002000 {
> > status = "okay";
> > #dma-cells = <1>;
> > compatible = "xlnx,axi-dma-1.00.a";
> > interrupt-parent = <>;
> > interrupts = <0 89 4>;
> > reg = <0x0 0x80002000 0x0 0x1000>;
> > xlnx,addrwidth = <0x20>;
> > clocks = <_clk LPD_LSBUS>, <_clk LPD_LSBUS>,
> > <_clk LPD_LSBUS>, <_clk LPD_LSBUS>;
> > clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk",
> > "m_axi_mm2s_aclk", "m_axi_s2mm_aclk";
> > dma-channel@80002030 {
> > compatible = "xlnx,axi-dma-s2mm-channel";
> > dma-channels = <0x1>;
> > interrupts = <0 89 4>;
> > xlnx,datawidth = <0x20>;
> > xlnx,device-id = <0x0>;
> > };
> > };
> >
> > This is on a 5.10.1 kernel on arm64 zynqmp hardware.
> >
> > The second issue goes a little further back to commit e81274cd6b526
> > 'dmaengine: add support to dynamic register/unregister of channels'.
> > After this commit even just removing the module 'rmmod xilinx_dma',
> > without ever using it, results in a kernel oops like this:
> > [   37.214568] xilinx-vdma 80002000.dma: ch 0: SG disabled
> > [   37.219807] xilinx-vdma 80002000.dma: WARN: Device release is not
> > defined so it is not safe to unbind this driver while in use
> > [   37.231299] xilinx-vdma 80002000.dma: Xilinx AXI DMA Engine Driver
> > Probed!!
> > [   42.100660] Unable to handle kernel paging request at virtual
> > address dead0108
> > [   42.108598] Mem abort info:
> > [   42.111393]   ESR = 0x9644
> > [   42.114443]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [   42.119744]   SET = 0, FnV = 0
> > [   42.122794]   EA = 0, S1PTW = 0
> > [   42.125918] Data abort info:
> > [   42.128789]   ISV = 0, ISS = 0x0044
> > [   42.132617]   CM = 0, WnR = 1
> > [   42.135577] [dead0108] address between user and kernel
> > address ranges
> > [   42.142705] Internal error: Oops: 9644 [#1] SMP
> > [   42.147566] Modules linked in: xilinx_dma(-) clk_xlnx_clock_wizard
> > uio_pdrv_genirq
> > [   42.155139] CPU: 1 PID: 2075 Comm: rmmod Not tainted
> > 5.10.1-00026-g3a2e6dd7a05-dirty #192
> > [   42.163302] Hardware name: Enclustra XU5 SOM (DT)
> > [   42.167992] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
> > [   42.173996] pc : xilinx_dma_chan_remove+0x74/0xa0 [xilinx_dma]
> > [   42.179815] lr : xilinx_dma_chan_remove+0x70/0xa0 [xilinx_dma]
> > [   42.185636] sp : ffc01112bca0
> > [   42.188935] x29: ffc01112bca0 x28: ff80402ea640
> > [   42.194238] x27:  x26: 
> > [   42.199542] x25:  x24: 
> > [   42.204845] x23:  x22: 
> > [   42.210149] x21: ffc0088a2028 x20: ff8040c08410
> > [   42.215452] x19: ff80423fa480 x18: 
> > [   42.220756] x17:  x16: 
> > [   42.226059] x15: ffc010ce88c8 x14: 0040
> > [   42.231363] x13: ff00 x12: 
> > [

RE: [PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow

2021-01-07 Thread Dexuan Cui

> From: Rafael J. Wysocki 
> Sent: Thursday, January 7, 2021 5:48 AM
> > > > Linux VM on Hyper-V crashes with the latest mainline:
> > > > ...
> The root cause is a VM issue AFAICS, though.

Yes.
 
> It doesn't look like the right fix to me, though.
> 
> The problem appears to be that the string coming from _HID is too long
> (which is a spec violation). 

Yes. We have requested Hyper-V team to fix the buggy BIOS/firmware,
but we have to cope with the existing buggy Hyper-V hosts, at least
before the Hyper-V fix is deployed to the hosts, and some old versions
of the hosts may not get updated. :-(

> The patch truncates it to match the
> length of the target buffer, but that is not particularly useful.
> 
> It would be better to use something like kstrdup_const() to initialize
> acpi_device_bus_id->bus_id IMV.

Makes sense. I'll submit v2 shortly.

Thanks,
-- Dexuan

[PATCH v3] venus: venc: set inband mode property to FW.

2021-01-07 Thread Dikshita Agarwal

set HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER to FW
to support inband sequence header mode.

Signed-off-by: Dikshita Agarwal 

Changes since v2:
- fixed Null pointer dereference (Stanimir, Fritz)
- added set property call at correct place.
---
 drivers/media/platform/qcom/venus/venc.c   | 14 ++
 drivers/media/platform/qcom/venus/venc_ctrls.c | 17 -
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 3a2e449..bd6597c 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -536,6 +536,7 @@ static int venc_set_properties(struct venus_inst *inst)
struct hfi_idr_period idrp;
struct hfi_quantization quant;
struct hfi_quantization_range quant_range;
+   struct hfi_enable en;
u32 ptype, rate_control, bitrate;
u32 profile, level;
int ret;
@@ -655,6 +656,19 @@ static int venc_set_properties(struct venus_inst *inst)
if (ret)
return ret;
 
+   if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+   inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+   ptype = HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER;
+   if (ctr->header_mode == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE)
+   en.enable = 0;
+   else
+   en.enable = 1;
+
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+   }
+
if (!ctr->bitrate_peak)
bitrate *= 2;
else
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c 
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index cf860e6..3ce02ad 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -158,6 +158,20 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
ctr->header_mode = ctrl->val;
+   mutex_lock(>lock);
+   if (inst->streamon_out && inst->streamon_cap) {
+   if (ctrl->val == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE)
+   en.enable = 0;
+   else
+   en.enable = 1;
+   ptype = 
HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER;
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret) {
+   mutex_unlock(>lock);
+   return ret;
+   }
+   }
+   mutex_unlock(>lock);
break;
case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB:
break;
@@ -289,7 +303,8 @@ int venc_ctrl_init(struct venus_inst *inst)
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
V4L2_CID_MPEG_VIDEO_HEADER_MODE,
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
-   1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
+   ~((1 << V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
+   (1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME)),
V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE);
 
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
-- 
2.7.4

Re: [PATCH 1/1] arm64: make section size configurable for memory hotplug

2021-01-07 Thread Anshuman Khandual



On 1/7/21 6:00 PM, David Hildenbrand wrote:
> On 06.01.21 07:11, Anshuman Khandual wrote:
>> Hi Sudershan,
>>
>> This patch (and the cover letter) does not copy LAKML even though the
>> entire change here is arm64 specific. Please do copy all applicable
>> mailing lists for a given patch.
>>
>> On 1/6/21 6:58 AM, Sudarshan Rajagopalan wrote:
>>> Currently on arm64, memory section size is hard-coded to 1GB.
>>> Make this configurable if memory-hotplug is enabled, to support
>>> more finer granularity for hotplug-able memory.
>>
>> Section size has always been decided by the platform. It cannot be a
>> configurable option because the user would not know the constraints
>> for memory representation on the platform and besides it also cannot
>> be trusted.
>>
>>>
>>> Signed-off-by: Sudarshan Rajagopalan 
>>> ---
>>>  arch/arm64/Kconfig | 11 +++
>>>  arch/arm64/include/asm/sparsemem.h |  4 
>>>  2 files changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 6d232837cbee..34124eee65da 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -294,6 +294,17 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
>>>  config SMP
>>> def_bool y
>>>  
>>> +config HOTPLUG_SIZE_BITS
>>> +   int "Memory hotplug block size(29 => 512MB 30 => 1GB)"
> 
> "Memory hotplug block size" and "HOTPLUG_SIZE_BITS" is confusing. It's
> the section size. Please use that terminology.
> 
> (if at all, it would have to be "minimum memory hot(un)plug
> granularity", but even that is somewhat misleading)
> 
> "SECTION_SIZE_BITS"
> 
> But I agree that letting the user configure it is sub-optimal.
> 
>>> +   depends on SPARSEMEM
>>> +   depends on MEMORY_HOTPLUG
>>> +   range 28 30
>>
>> 28 would not work for 64K pages.
> 
> @Anshuman, what's your feeling about changing this to 128 MB for 4k/16k
> base pages (as we have on x86-64 right now) and 512 MB for 64k as
> default for now?

To summarize, the section size bits for each base page size config
should always

a. Avoid (MAX_ORDER - 1 + PAGE_SHIFT) > SECTION_SIZE_BITS

b. Provide minimum possible section size for a given base page config to
   have increased agility during memory hotplug operations and reduced
   vmemmap wastage for sections with holes.

c. Allow 4K base page configs to have PMD based vmemmap mappings

Because CONFIG_FORCE_MAX_ZONEORDER is always defined on arm64 platform,
the following would always avoid the condition (a)

SECTION_SIZE_BITS (CONFIG_FORCE_MAX_ZONEORDER - 1 + PAGE_SHIFT)

- 22 (11 - 1 + 12) for 4K pages
- 24 (11 - 1 + 14) for 16K pages without THP
- 25 (12 - 1 + 14) for 16K pages with THP
- 26 (11 - 1 + 16) for 64K pages without THP
- 29 (14 - 1 + 16) for 64K pages with THP

Apart from overriding 4K base page size config to have 27 as section size
bits, should not all other values be okay here ? But then wondering what
benefit 128MB (27 bits) section size for 16K config would have ? OR the
objective here is to match 16K page size config with default x86-64.

> 
> (If we worry about the number of section bits in page->flags, we could
> glue it to vmemmap support where that does not matter)

Could you please elaborate ? Could smaller section size bits numbers like
22 or 24 create problems in page->flags without changing other parameters
like NR_CPUS or NODES_SHIFT ? A quick test with 64K base page without THP
i.e 26 bits in section size, fails to boot.

As you have suggested, probably constant defaults (128MB for 4K/16K, 512MB
for 64K) might be better than depending on the CONFIG_FORCE_MAX_ZONEORDER,
at least for now.

Re: [PATCH v1 1/3] cpufreq: intel_pstate: Always read hwp_cap_cached with READ_ONCE()

2021-01-07 Thread Chen Yu

On Thu, Jan 07, 2021 at 07:42:15PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Because intel_pstate_get_hwp_max() which updates hwp_cap_cached
> may run in parallel with the readers of it, annotate all of the
> read accesses to it with READ_ONCE().
> 
> Signed-off-by: Rafael J. Wysocki 
Tested-by: Chen Yu 

thanks,
Chenyu

Re: [PATCH v1 2/3] cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument

2021-01-07 Thread Chen Yu

On Thu, Jan 07, 2021 at 07:43:30PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> All of the callers of intel_pstate_get_hwp_max() access the struct
> cpudata object that corresponds to the given CPU already and the
> function itself needs to access that object (in order to update
> hwp_cap_cached), so modify the code to pass a struct cpudata pointer
> to it instead of the CPU number.
> 
> Signed-off-by: Rafael J. Wysocki 
 Tested-by: Chen Yu 


 thanks,
 Chenyu

Re: drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function 'sg_free_table_chained'

2021-01-07 Thread Jinpu Wang

On Fri, Jan 8, 2021 at 7:46 AM kernel test robot  wrote:
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   f5e6c330254ae691f6d7befe61c786eb5056007e
> commit: 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc block/rnbd-clt: Dynamically 
> allocate sglist for rnbd_iu
> date:   3 weeks ago
> config: parisc-randconfig-r011-20210108 (attached as .config)
> compiler: hppa-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=parisc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All errors (new ones prefixed by >>):
>
>drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_softirq_done_fn':
> >> drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of 
> >> function 'sg_free_table_chained' [-Werror=implicit-function-declaration]
>  387 |  sg_free_table_chained(>sgt, RNBD_INLINE_SG_CNT);
>  |  ^
>drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_queue_rq':
> >> drivers/block/rnbd/rnbd-clt.c:1142:8: error: implicit declaration of 
> >> function 'sg_alloc_table_chained'; did you mean 'sg_alloc_table'? 
> >> [-Werror=implicit-function-declaration]
> 1142 |  err = sg_alloc_table_chained(>sgt,
>  |^~
>  |sg_alloc_table
>cc1: some warnings being treated as errors
>
>
> vim +/sg_free_table_chained +387 drivers/block/rnbd/rnbd-clt.c
Thanks for reporting, I've found the problem, we need to
select SG_POOL in Kconfig for RNBD client, will send out a fix soon today.

Regards!
Jack

Re: [PATCH v1 3/3] cpufreq: intel_pstate: Rename two functions

2021-01-07 Thread Chen Yu

On Thu, Jan 07, 2021 at 07:44:18PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Rename intel_cpufreq_adjust_hwp() and intel_cpufreq_adjust_perf_ctl()
> to intel_cpufreq_hwp_update() and intel_cpufreq_perf_ctl_update(),
> respectively, to avoid possible confusion with the ->adjist_perf()
> callback function, intel_cpufreq_adjust_perf().
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
Tested-by: Chen Yu

[RESEND v5 1/4] KVM: VMX: Convert vcpu_vmx.exit_reason to a union

From: Sean Christopherson 

Convert vcpu_vmx.exit_reason from a u32 to a union (of size u32).  The
full VM_EXIT_REASON field is comprised of a 16-bit basic exit reason in
bits 15:0, and single-bit modifiers in bits 31:16.

Historically, KVM has only had to worry about handling the "failed
VM-Entry" modifier, which could only be set in very specific flows and
required dedicated handling.  I.e. manually stripping the FAILED_VMENTRY
bit was a somewhat viable approach.  But even with only a single bit to
worry about, KVM has had several bugs related to comparing a basic exit
reason against the full exit reason store in vcpu_vmx.

Upcoming Intel features, e.g. SGX, will add new modifier bits that can
be set on more or less any VM-Exit, as opposed to the significantly more
restricted FAILED_VMENTRY, i.e. correctly handling everything in one-off
flows isn't scalable.  Tracking exit reason in a union forces code to
explicitly choose between consuming the full exit reason and the basic
exit, and is a convenient way to document and access the modifiers.

No functional change intended.

Cc: Xiaoyao Li 
Signed-off-by: Sean Christopherson 
Signed-off-by: Chenyi Qiang 
---
 arch/x86/kvm/vmx/nested.c | 42 +++-
 arch/x86/kvm/vmx/vmx.c| 68 ---
 arch/x86/kvm/vmx/vmx.h| 25 +-
 3 files changed, 86 insertions(+), 49 deletions(-)

diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index e2f26564a12d..57fe60c2cf34 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -3311,7 +3311,11 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
enum vm_entry_failure_code entry_failure_code;
bool evaluate_pending_interrupts;
-   u32 exit_reason, failed_index;
+   union vmx_exit_reason exit_reason = {
+   .basic = EXIT_REASON_INVALID_STATE,
+   .failed_vmentry = 1,
+   };
+   u32 failed_index;
 
if (kvm_check_request(KVM_REQ_TLB_FLUSH_CURRENT, vcpu))
kvm_vcpu_flush_tlb_current(vcpu);
@@ -3363,7 +3367,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
 
if (nested_vmx_check_guest_state(vcpu, vmcs12,
 _failure_code)) {
-   exit_reason = EXIT_REASON_INVALID_STATE;
+   exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit;
}
@@ -3374,7 +3378,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
vcpu->arch.tsc_offset += vmcs12->tsc_offset;
 
if (prepare_vmcs02(vcpu, vmcs12, _failure_code)) {
-   exit_reason = EXIT_REASON_INVALID_STATE;
+   exit_reason.basic = EXIT_REASON_INVALID_STATE;
vmcs12->exit_qualification = entry_failure_code;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3384,7 +3388,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
   
vmcs12->vm_entry_msr_load_addr,
   
vmcs12->vm_entry_msr_load_count);
if (failed_index) {
-   exit_reason = EXIT_REASON_MSR_LOAD_FAIL;
+   exit_reason.basic = EXIT_REASON_MSR_LOAD_FAIL;
vmcs12->exit_qualification = failed_index;
goto vmentry_fail_vmexit_guest_mode;
}
@@ -3452,7 +3456,7 @@ enum nvmx_vmentry_status 
nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
return NVMX_VMENTRY_VMEXIT;
 
load_vmcs12_host_state(vcpu, vmcs12);
-   vmcs12->vm_exit_reason = exit_reason | VMX_EXIT_REASONS_FAILED_VMENTRY;
+   vmcs12->vm_exit_reason = exit_reason.full;
if (enable_shadow_vmcs || vmx->nested.hv_evmcs)
vmx->nested.need_vmcs12_to_shadow_sync = true;
return NVMX_VMENTRY_VMEXIT;
@@ -5538,7 +5542,12 @@ static int handle_vmfunc(struct kvm_vcpu *vcpu)
return kvm_skip_emulated_instruction(vcpu);
 
 fail:
-   nested_vmx_vmexit(vcpu, vmx->exit_reason,
+   /*
+* This is effectively a reflected VM-Exit, as opposed to a synthesized
+* nested VM-Exit.  Pass the original exit reason, i.e. don't hardcode
+* EXIT_REASON_VMFUNC as the exit reason.
+*/
+   nested_vmx_vmexit(vcpu, vmx->exit_reason.full,
  vmx_get_intr_info(vcpu),
  vmx_get_exit_qual(vcpu));
return 1;
@@ -5606,7 +5615,8 @@ static bool nested_vmx_exit_handled_io(struct kvm_vcpu 
*vcpu,
  * MSR bitmap. This may be the case even when L0 doesn't use MSR bitmaps.
  */
 static bool

[RESEND v5 4/4] KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT

Introduce a new capability named KVM_CAP_X86_BUS_LOCK_EXIT, which is
used to handle bus locks detected in guest. It allows the userspace to
do custom throttling policies to mitigate the 'noisy neighbour' problem.

Signed-off-by: Chenyi Qiang 
---
 Documentation/virt/kvm/api.rst | 45 +++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 70254eaa5229..68bdefca5372 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -4887,9 +4887,11 @@ local APIC is not used.
__u16 flags;
 
 More architecture-specific flags detailing state of the VCPU that may
-affect the device's behavior.  The only currently defined flag is
-KVM_RUN_X86_SMM, which is valid on x86 machines and is set if the
-VCPU is in system management mode.
+affect the device's behavior. Current defined flags:
+  /* x86, set if the VCPU is in system management mode */
+  #define KVM_RUN_X86_SMM (1 << 0)
+  /* x86, set if bus lock detected in VM */
+  #define KVM_RUN_BUS_LOCK(1 << 1)
 
 ::
 
@@ -6032,6 +6034,43 @@ KVM_EXIT_X86_RDMSR and KVM_EXIT_X86_WRMSR exit 
notifications which user space
 can then handle to implement model specific MSR handling and/or user 
notifications
 to inform a user that an MSR was not handled.
 
+7.22 KVM_CAP_X86_BUS_LOCK_EXIT
+---
+
+:Architectures: x86
+:Target: VM
+:Parameters: args[0] defines the policy used when bus locks detected in guest
+:Returns: 0 on success, -EINVAL when args[0] contains invalid bits
+
+Valid bits in args[0] are::
+
+  #define KVM_BUS_LOCK_DETECTION_OFF  (1 << 0)
+  #define KVM_BUS_LOCK_DETECTION_EXIT (1 << 1)
+
+Enabling this capability on a VM provides userspace with a way to select
+a policy to handle the bus locks detected in guest. Userspace can obtain
+the supported modes from the result of KVM_CHECK_EXTENSION and define it
+through the KVM_ENABLE_CAP.
+
+KVM_BUS_LOCK_DETECTION_OFF and KVM_BUS_LOCK_DETECTION_EXIT are supported
+currently and mutually exclusive with each other. More bits can be added in
+the future.
+
+With KVM_BUS_LOCK_DETECTION_OFF set, bus locks in guest will not cause vm exits
+so that no additional actions are needed. This is the default mode.
+
+With KVM_BUS_LOCK_DETECTION_EXIT set, vm exits happen when bus lock detected
+in VM. KVM just exits to userspace when handling them. Userspace can enforce
+its own throttling or other policy based mitigations.
+
+This capability is aimed to address the thread that VM can exploit bus locks to
+degree the performance of the whole system. Once the userspace enable this
+capability and select the KVM_BUS_LOCK_DETECTION_EXIT mode, KVM will set the
+KVM_RUN_BUS_LOCK flag in vcpu-run->flags field and exit to userspace. 
Concerning
+the bus lock vm exit can be preempted by a higher priority VM exit, the exit
+notifications to userspace can be KVM_EXIT_BUS_LOCK or other reasons.
+KVM_RUN_BUS_LOCK flag is used to distinguish between them.
+
 8. Other capabilities.
 ==
 
-- 
2.17.1

[RESEND v5 2/4] KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run

Reset the vcpu->run->flags at the beginning of kvm_arch_vcpu_ioctl_run.
It can avoid every thunk of code that needs to set the flag clear it,
which increases the odds of missing a case and ending up with a flag in
an undefined state.

Signed-off-by: Chenyi Qiang 
---
 arch/x86/kvm/x86.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3f7c1fc7a3ce..ded2149497ba 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8189,12 +8189,14 @@ static void post_kvm_run_save(struct kvm_vcpu *vcpu)
kvm_run->if_flag = !vcpu->arch.guest_state_protected
&& (kvm_get_rflags(vcpu) & X86_EFLAGS_IF) != 0;
 
-   kvm_run->flags = is_smm(vcpu) ? KVM_RUN_X86_SMM : 0;
kvm_run->cr8 = kvm_get_cr8(vcpu);
kvm_run->apic_base = kvm_get_apic_base(vcpu);
kvm_run->ready_for_interrupt_injection =
pic_in_kernel(vcpu->kvm) ||
kvm_vcpu_ready_for_interrupt_injection(vcpu);
+
+   if (is_smm(vcpu))
+   kvm_run->flags |= KVM_RUN_X86_SMM;
 }
 
 static void update_cr8_intercept(struct kvm_vcpu *vcpu)
@@ -9305,6 +9307,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 
vcpu_load(vcpu);
kvm_sigset_activate(vcpu);
+   kvm_run->flags = 0;
kvm_load_guest_fpu(vcpu);
 
if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_UNINITIALIZED)) {
-- 
2.17.1

[RESEND v5 3/4] KVM: VMX: Enable bus lock VM exit

Virtual Machine can exploit bus locks to degrade the performance of
system. Bus lock can be caused by split locked access to writeback(WB)
memory or by using locks on uncacheable(UC) memory. The bus lock is
typically >1000 cycles slower than an atomic operation within a cache
line. It also disrupts performance on other cores (which must wait for
the bus lock to be released before their memory operations can
complete).

To address the threat, bus lock VM exit is introduced to notify the VMM
when a bus lock was acquired, allowing it to enforce throttling or other
policy based mitigations.

A VMM can enable VM exit due to bus locks by setting a new "Bus Lock
Detection" VM-execution control(bit 30 of Secondary Processor-based VM
execution controls). If delivery of this VM exit was preempted by a
higher priority VM exit (e.g. EPT misconfiguration, EPT violation, APIC
access VM exit, APIC write VM exit, exception bitmap exiting), bit 26 of
exit reason in vmcs field is set to 1.

In current implementation, the KVM exposes this capability through
KVM_CAP_X86_BUS_LOCK_EXIT. The user can get the supported mode bitmap
(i.e. off and exit) and enable it explicitly (disabled by default). If
bus locks in guest are detected by KVM, exit to user space even when
current exit reason is handled by KVM internally. Set a new field
KVM_RUN_BUS_LOCK in vcpu->run->flags to inform the user space that there
is a bus lock detected in guest.

Document for Bus Lock VM exit is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Chenyi Qiang 
---
 arch/x86/include/asm/kvm_host.h|  7 ++
 arch/x86/include/asm/vmx.h |  1 +
 arch/x86/include/asm/vmxfeatures.h |  1 +
 arch/x86/include/uapi/asm/kvm.h|  1 +
 arch/x86/include/uapi/asm/vmx.h|  4 +++-
 arch/x86/kvm/vmx/capabilities.h|  6 +
 arch/x86/kvm/vmx/vmx.c | 37 --
 arch/x86/kvm/vmx/vmx.h |  2 +-
 arch/x86/kvm/x86.c | 23 +++
 include/uapi/linux/kvm.h   |  5 
 10 files changed, 83 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3ab7b46087b7..17d882dfee4f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -52,6 +52,9 @@
 #define KVM_DIRTY_LOG_MANUAL_CAPS   (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
KVM_DIRTY_LOG_INITIALLY_SET)
 
+#define KVM_BUS_LOCK_DETECTION_VALID_MODE  (KVM_BUS_LOCK_DETECTION_OFF | \
+KVM_BUS_LOCK_DETECTION_EXIT)
+
 /* x86-specific vcpu->requests bit members */
 #define KVM_REQ_MIGRATE_TIMER  KVM_ARCH_REQ(0)
 #define KVM_REQ_REPORT_TPR_ACCESS  KVM_ARCH_REQ(1)
@@ -998,6 +1001,8 @@ struct kvm_arch {
struct msr_bitmap_range ranges[16];
} msr_filter;
 
+   bool bus_lock_detection_enabled;
+
struct kvm_pmu_event_filter *pmu_event_filter;
struct task_struct *nx_lpage_recovery_thread;
 
@@ -1407,6 +1412,8 @@ extern u8   kvm_tsc_scaling_ratio_frac_bits;
 extern u64  kvm_max_tsc_scaling_ratio;
 /* 1ull << kvm_tsc_scaling_ratio_frac_bits */
 extern u64  kvm_default_tsc_scaling_ratio;
+/* bus lock detection supported? */
+extern bool kvm_has_bus_lock_exit;
 
 extern u64 kvm_mce_cap_supported;
 
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 38ca445a8429..358707f60d99 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -73,6 +73,7 @@
 #define SECONDARY_EXEC_PT_USE_GPA  VMCS_CONTROL_BIT(PT_USE_GPA)
 #define SECONDARY_EXEC_TSC_SCALING  VMCS_CONTROL_BIT(TSC_SCALING)
 #define SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE   VMCS_CONTROL_BIT(USR_WAIT_PAUSE)
+#define SECONDARY_EXEC_BUS_LOCK_DETECTION  
VMCS_CONTROL_BIT(BUS_LOCK_DETECTION)
 
 #define PIN_BASED_EXT_INTR_MASK VMCS_CONTROL_BIT(INTR_EXITING)
 #define PIN_BASED_NMI_EXITING   VMCS_CONTROL_BIT(NMI_EXITING)
diff --git a/arch/x86/include/asm/vmxfeatures.h 
b/arch/x86/include/asm/vmxfeatures.h
index 9915990fd8cf..e80523346274 100644
--- a/arch/x86/include/asm/vmxfeatures.h
+++ b/arch/x86/include/asm/vmxfeatures.h
@@ -83,5 +83,6 @@
 #define VMX_FEATURE_TSC_SCALING( 2*32+ 25) /* Scale hardware 
TSC when read in guest */
 #define VMX_FEATURE_USR_WAIT_PAUSE ( 2*32+ 26) /* Enable TPAUSE, UMONITOR, 
UMWAIT in guest */
 #define VMX_FEATURE_ENCLV_EXITING  ( 2*32+ 28) /* "" VM-Exit on ENCLV 
(leaf dependent) */
+#define VMX_FEATURE_BUS_LOCK_DETECTION ( 2*32+ 30) /* VM-Exit when bus lock 
caused */
 
 #endif /* _ASM_X86_VMXFEATURES_H */
diff --git a/arch/x86/include/uapi/asm/kvm.h

[RESEND v5 0/4] Add bus lock VM exit support

Hi all,

Resend a rebased version. Hope to receive your comments.

---

This patch series add the support for bus lock VM exit in KVM. It is a
sub-feature of bus lock detection. When it is enabled by the VMM, the
processor generates a "Bus Lock" VM exit following execution of an
instruction if the processor detects that one or more bus locks were
caused the instruction was being executed (due to either direct access
by the instruction or stuffed accesses like through A/D updates).

Bus lock VM exit will introduce a new modifier bit (bit 26) in
exit_reason field in VMCS which indicates bus lock VM exit is preempted
by a higher priority VM exit. The first patch is to apply Sean's
refactor for vcpu_vmx.exit_reason as a preparation patch for bus lock
VM exit support.

The second patch is the refactor for vcpu->run->flags. Bus lock VM exit
will introduce a new field in the flags to inform the userspace that
there's a bus lock detected in guest. It's also a preparation patch.

The third patch is the concrete enabling working for bus lock VM exit.
Add the support to set the capability to enable bus lock VM exit. The
current implementation is just exiting to userspace when handling the
bus lock detected in guest.

The detail of throttling policy in user space is still to be discussed.
We may enforce ratelimit on bus lock in guest, inject some sleep time,
or... We hope to get more ideas on this.

Document for Bus Lock Detection is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

---

Changelogs

v5->v5:
- rebase on top of v5.11-rc1
- no difference compared with the last version
- v5:https://lore.kernel.org/lkml/20201106090315.18606-1-chenyi.qi...@intel.com/

v4->v5:
- rebase on top on v5.10-rc2
- add preparation patch that reset the vcpu->run->flags at the beginning
of the vcpu_run.(Suggested by Sean)
- set the KVM_RUN_BUS_LOCK for all bus lock exit to avoid checking both
exit_reason and run->flags
- add the document to introduce the new kvm capability
(KVM_CAP_X86_BUS_LOCK_EXIT)
- v4:https://lore.kernel.org/lkml/20201012033542.4696-1-chenyi.qi...@intel.com/

v3->v4:
- rebase on top of v5.9
- some code cleanup.
- v3:https://lore.kernel.org/lkml/20200910083751.26686-1-chenyi.qi...@intel.com/

v2->v3:
- use a bitmap to get/set the capability of bus lock detection. we support
exit and off mode currently.
- put the handle of exiting to userspace in vmx.c, thus no need to
define a shadow to track vmx->exit_reason.bus_lock_detected.
- remove the vcpu->stats.bus_locks since every bus lock exits to userspace.
- v2:https://lore.kernel.org/lkml/20200817033604.5836-1-chenyi.qi...@intel.com/

v1->v2:
- resolve Vitaly's comment to introduce the KVM_EXIT_BUS_LOCK and a
capability to enable it.
- add the support to exit to user space when handling bus locks.
- extend the vcpu->run->flags to indicate bus lock detected for other
exit reasons when exiting to user space.
- v1:https://lore.kernel.org/lkml/20200628085341.5107-1-chenyi.qi...@intel.com/

---

Chenyi Qiang (3):
KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run
KVM: VMX: Enable bus lock VM exit
KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT

Sean Christopherson (1):
KVM: VMX: Convert vcpu_vmx.exit_reason to a union

--
2.17.1

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote:
> On Fri, Jan 8, 2021 at 6:30 AM Al Viro  wrote:
> >
> > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > > it down to the below patch. Debugging this issue, turns out that the boot
> > > stalled when a task is waiting on a pipe being released. As we no longer
> > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> > > task goes idle without running the task_work. This prevents ->release()
> > > from being called on the pipe, which another boot task is waiting on.
> > >
> > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> > > goes idle.
> > >
> > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> > > Reported-by: Song Liu 
> > > Signed-off-by: Jens Axboe 
> > >
> > > ---
> > >
> > > The other alternative here is obviously to re-instate the:
> > >
> > > if (unlikely(current->task_works))
> > >   task_work_run();
> > >
> > > in get_signal() that we had before this change. Might be safer in case
> > > there are other cases that need to ensure the work is run in a timely
> > > fashion, though I do think it's cleaner to long term to correctly mark
> > > task_work with the needed notification type. Comments welcome...
> >
> > Interesting...  I think I've missed the discussion of that thing; could
> > you forward the relevant thread my way or give an archive link to it?
> 
> See [1].
> 
> - Sedat -
> 
> [1] https://marc.info/?t=16098715661=1=2

Wait, that's this very thread, starting with the posting I'd been replying
to.  Really confused now...  Was that a private bug report and an equally
private discussion?  That's what I wanted to see...

Anyway, I'm more than half-asleep right now; will get back to that in the
morning.

[RESEND v5 0/4] Add bus lock VM exit support

Hi all,

Resend a rebased version. Hope to receive your comments.

---

The detail of throttling policy in user space is still to be discussed.
We may enforce ratelimit on bus lock in guest, inject some sleep time,
or... We hope to get more ideas on this.

Document for Bus Lock Detection is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

---

Changelogs

v5->v5:
- rebase on top of v5.11-rc1
- no difference compared with the last version
- v5:https://lore.kernel.org/lkml/20201106090315.18606-1-chenyi.qi...@intel.com/

v3->v4:
- rebase on top of v5.9
- some code cleanup.
- v3:https://lore.kernel.org/lkml/20200910083751.26686-1-chenyi.qi...@intel.com/

---

Chenyi Qiang (3):
KVM: X86: Reset the vcpu->run->flags at the beginning of vcpu_run
KVM: VMX: Enable bus lock VM exit
KVM: X86: Add the Document for KVM_CAP_X86_BUS_LOCK_EXIT

Sean Christopherson (1):
KVM: VMX: Convert vcpu_vmx.exit_reason to a union

--
2.17.1

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote:
> On Fri, Jan 8, 2021 at 6:30 AM Al Viro  wrote:
> >
> > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > > it down to the below patch. Debugging this issue, turns out that the boot
> > > stalled when a task is waiting on a pipe being released. As we no longer
> > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> > > task goes idle without running the task_work. This prevents ->release()
> > > from being called on the pipe, which another boot task is waiting on.
> > >
> > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> > > goes idle.
> > >
> > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> > > Reported-by: Song Liu 
> > > Signed-off-by: Jens Axboe 
> > >
> > > ---
> > >
> > > The other alternative here is obviously to re-instate the:
> > >
> > > if (unlikely(current->task_works))
> > >   task_work_run();
> > >
> > > in get_signal() that we had before this change. Might be safer in case
> > > there are other cases that need to ensure the work is run in a timely
> > > fashion, though I do think it's cleaner to long term to correctly mark
> > > task_work with the needed notification type. Comments welcome...
> >
> > Interesting...  I think I've missed the discussion of that thing; could
> > you forward the relevant thread my way or give an archive link to it?
> 
> See [1].
> 
> - Sedat -
> 
> [1] https://marc.info/?t=16098715661=1=2

Thanks; will check tomorrow.

drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function 'sg_free_table_chained'

2021-01-07 Thread kernel test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f5e6c330254ae691f6d7befe61c786eb5056007e
commit: 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc block/rnbd-clt: Dynamically 
allocate sglist for rnbd_iu
date:   3 weeks ago
config: parisc-randconfig-r011-20210108 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5a1328d0c3a757cdd8c65f4dfe0a02502a5810bc
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_softirq_done_fn':
>> drivers/block/rnbd/rnbd-clt.c:387:2: error: implicit declaration of function 
>> 'sg_free_table_chained' [-Werror=implicit-function-declaration]
 387 |  sg_free_table_chained(>sgt, RNBD_INLINE_SG_CNT);
 |  ^
   drivers/block/rnbd/rnbd-clt.c: In function 'rnbd_queue_rq':
>> drivers/block/rnbd/rnbd-clt.c:1142:8: error: implicit declaration of 
>> function 'sg_alloc_table_chained'; did you mean 'sg_alloc_table'? 
>> [-Werror=implicit-function-declaration]
1142 |  err = sg_alloc_table_chained(>sgt,
 |^~
 |sg_alloc_table
   cc1: some warnings being treated as errors


vim +/sg_free_table_chained +387 drivers/block/rnbd/rnbd-clt.c

   379  
   380  static void rnbd_softirq_done_fn(struct request *rq)
   381  {
   382  struct rnbd_clt_dev *dev= rq->rq_disk->private_data;
   383  struct rnbd_clt_session *sess   = dev->sess;
   384  struct rnbd_iu *iu;
   385  
   386  iu = blk_mq_rq_to_pdu(rq);
 > 387  sg_free_table_chained(>sgt, RNBD_INLINE_SG_CNT);
   388  rnbd_put_permit(sess, iu->permit);
   389  blk_mq_end_request(rq, errno_to_blk_status(iu->errno));
   390  }
   391  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

On Fri, Jan 08, 2021 at 05:26:51AM +, Al Viro wrote:
> On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > it down to the below patch. Debugging this issue, turns out that the boot
> > stalled when a task is waiting on a pipe being released. As we no longer
> > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> > task goes idle without running the task_work. This prevents ->release()
> > from being called on the pipe, which another boot task is waiting on.
> > 
> > Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> > goes idle.
> > 
> > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> > Reported-by: Song Liu 
> > Signed-off-by: Jens Axboe 
> > 
> > ---
> > 
> > The other alternative here is obviously to re-instate the:
> > 
> > if (unlikely(current->task_works))
> > task_work_run();
> > 
> > in get_signal() that we had before this change. Might be safer in case
> > there are other cases that need to ensure the work is run in a timely
> > fashion, though I do think it's cleaner to long term to correctly mark
> > task_work with the needed notification type. Comments welcome...
> 
> Interesting...  I think I've missed the discussion of that thing; could
> you forward the relevant thread my way or give an archive link to it?

Actually, why do we need TWA_RESUME at all?  OK, a while ago you've added
a way for task_work_add() to do wake_up_signal().  Fine, so if the sucker
had been asleep in get_signal(), it gets woken up and the work gets run
fast.  Irrelevant for those who did task_work_add() for themselves.
With that commit, though, you've suddenly changed the default behaviour -
now if you do that task_work_add() for current *and* get asleep in
get_signal(), task_work_add() gets delayed - potentially for a very
long time.

Now the default (TWA_RESUME) has changed semantics; matter of fact,
TWA_SIGNAL seems to be a lot closer than what we used to have.  I'm
too sleepy right now to check if there are valid usecases for your
new TWA_RESUME behaviour, but I very much doubt that old callers
(before the TWA_RESUME/TWA_SIGNAL split) want that.

In particular, for mntput_no_expire() we definitely do *not* want
that, same as with fput().  Same, AFAICS, for YAMA report_access().
And for binder_deferred_fd_close().  And task_tick_numa() looks
that way as well...

Anyway, bedtime for me; right now it looks like at least for task == current
we always want TWA_SIGNAL.  I'll look into that more tomorrow when I get
up, but so far it smells like switching everything to TWA_SIGNAL would
be the right thing to do, if not going back to bool notify for
task_work_add()...

[RESEND PATCH 2/2] KVM: X86: Expose bus lock debug exception to guest

Bus lock debug exception is an ability to notify the kernel by an #DB
trap after the instruction acquires a bus lock and is executed when
CPL>0. This allows the kernel to enforce user application throttling or
mitigations.

Existence of bus lock debug exception is enumerated via
CPUID.(EAX=7,ECX=0).ECX[24]. Software can enable these exceptions by
setting bit 2 of the MSR_IA32_DEBUGCTL. Expose the CPUID to guest and
emulate the MSR handling when guest enables it.

Since SVM already has specific handlers of MSR_IA32_DEBUGMSR in the
svm_get/set_msr, move x86 commmon part to VMX and add the bus lock debug
exception support.

Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Chenyi Qiang 
---
 arch/x86/kvm/cpuid.c   |  3 ++-
 arch/x86/kvm/vmx/vmx.c | 23 +--
 arch/x86/kvm/x86.c | 16 ++--
 arch/x86/kvm/x86.h |  2 ++
 4 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 13036cf0b912..ea7c593794d2 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -402,7 +402,8 @@ void kvm_set_cpu_caps(void)
F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | F(RDPID) |
F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) |
F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) |
-   F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/
+   F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/ |
+   F(BUS_LOCK_DETECT)
);
/* Set LA57 based on hardware capability. */
if (cpuid_ecx(7) & F(LA57))
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 13c9bcc4d9d9..39f28f90bbb4 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -147,6 +147,9 @@ module_param(allow_smaller_maxphyaddr, bool, S_IRUGO);
RTIT_STATUS_ERROR | RTIT_STATUS_STOPPED | \
RTIT_STATUS_BYTECNT))
 
+#define MSR_VMX_SUPPORTED_DEBUGCTL (DEBUGCTLMSR_LBR | \
+   DEBUGCTLMSR_BTF | DEBUGCTLMSR_BUS_LOCK_DETECT)
+
 /*
  * List of MSRs that can be directly passed to the guest.
  * In addition to these x2apic and PT MSRs are handled specially.
@@ -1924,6 +1927,9 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
!guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP))
return 1;
goto find_uret_msr;
+   case MSR_IA32_DEBUGCTLMSR:
+   msr_info->data = vmcs_read64(GUEST_IA32_DEBUGCTL);
+   break;
default:
find_uret_msr:
msr = vmx_find_uret_msr(vmx, msr_info->index);
@@ -2002,9 +2008,22 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
VM_EXIT_SAVE_DEBUG_CONTROLS)
get_vmcs12(vcpu)->guest_ia32_debugctl = data;
 
-   ret = kvm_set_msr_common(vcpu, msr_info);
-   break;
+   if (data & ~MSR_VMX_SUPPORTED_DEBUGCTL)
+   return 1;
 
+   if (!msr_info->host_initiated &&
+   (data & DEBUGCTLMSR_BUS_LOCK_DETECT) &&
+   !guest_cpuid_has(vcpu, X86_FEATURE_BUS_LOCK_DETECT))
+   return 1;
+
+   if (data & (DEBUGCTLMSR_BTF|DEBUGCTLMSR_LBR)) {
+   if (report_ignored_msrs)
+   vcpu_unimpl(vcpu, "%s: BTF|LBR in 
IA32_DEBUGCTLMSR 0x%llx, nop\n",
+   __func__, data);
+   data &= ~(DEBUGCTLMSR_BTF|DEBUGCTLMSR_LBR);
+   }
+   vmcs_write64(GUEST_IA32_DEBUGCTL, data);
+   return 0;
case MSR_IA32_BNDCFGS:
if (!kvm_mpx_supported() ||
(!msr_info->host_initiated &&
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 06de2b9e57f3..d4a601482794 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -116,8 +116,9 @@ EXPORT_SYMBOL_GPL(kvm_x86_ops);
 static bool __read_mostly ignore_msrs = 0;
 module_param(ignore_msrs, bool, S_IRUGO | S_IWUSR);
 
-static bool __read_mostly report_ignored_msrs = true;
+bool __read_mostly report_ignored_msrs = true;
 module_param(report_ignored_msrs, bool, S_IRUGO | S_IWUSR);
+EXPORT_SYMBOL_GPL(report_ignored_msrs);
 
 unsigned int min_timer_period_us = 200;
 module_param(min_timer_period_us, uint, S_IRUGO | S_IWUSR);
@@ -3067,18 +3068,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
return 1;
}
break;
-   case MSR_IA32_DEBUGCTLMSR:
-   if (!data) {
-   /* We support the non-activated case already */
-   break;
-   } else if (data & ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_BTF)) {
-   /* Values other than LBR and BTF are vendor-specific,
-  thus

[RESEND PATCH 1/2] KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit

To avoid breaking the CPUs without bus lock detection, activate the
DR6_BUS_LOCK bit (bit 11) conditionally in DR6_FIXED_1 bits.

The set/clear of DR6_BUS_LOCK is similar to the DR6_RTM in DR6
register. The processor clears DR6_BUS_LOCK when bus lock debug
exception is generated. (For all other #DB the processor sets this bit
to 1.) Software #DB handler should set this bit before returning to the
interrupted task.

For VM exit caused by debug exception, bit 11 of the exit qualification
is set to indicate that a bus lock debug exception condition was
detected. The VMM should emulate the exception by clearing bit 11 of the
guest DR6.

Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Chenyi Qiang 
---
 arch/x86/include/asm/kvm_host.h |  5 +++--
 arch/x86/kvm/emulate.c  |  2 +-
 arch/x86/kvm/svm/svm.c  |  6 +++---
 arch/x86/kvm/vmx/nested.c   |  2 +-
 arch/x86/kvm/vmx/vmx.c  |  6 --
 arch/x86/kvm/x86.c  | 28 +---
 6 files changed, 29 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 3ab7b46087b7..826fd1e87352 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -196,13 +196,14 @@ enum x86_intercept_stage;
 
 #define KVM_NR_DB_REGS 4
 
+#define DR6_BUS_LOCK   (1 << 11)
 #define DR6_BD (1 << 13)
 #define DR6_BS (1 << 14)
 #define DR6_BT (1 << 15)
 #define DR6_RTM(1 << 16)
-#define DR6_FIXED_10xfffe0ff0
+#define DR6_FIXED_10xfffe07f0
 #define DR6_INIT   0x0ff0
-#define DR6_VOLATILE   0x0001e00f
+#define DR6_VOLATILE   0x0001e80f
 
 #define DR7_BP_EN_MASK 0x00ff
 #define DR7_GE (1 << 9)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 56cae1ff9e3f..882598da20f0 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4327,7 +4327,7 @@ static int check_dr_read(struct x86_emulate_ctxt *ctxt)
 
ctxt->ops->get_dr(ctxt, 6, );
dr6 &= ~DR_TRAP_BITS;
-   dr6 |= DR6_BD | DR6_RTM;
+   dr6 |= DR6_BD | DR6_RTM | DR6_BUS_LOCK;
ctxt->ops->set_dr(ctxt, 6, dr6);
return emulate_db(ctxt);
}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index cce0143a6f80..3d8a0e30314f 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1860,7 +1860,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu 
*vcpu)
get_debugreg(vcpu->arch.db[2], 2);
get_debugreg(vcpu->arch.db[3], 3);
/*
-* We cannot reset svm->vmcb->save.dr6 to DR6_FIXED_1|DR6_RTM here,
+* We cannot reset svm->vmcb->save.dr6 to 
DR6_FIXED_1|DR6_RTM|DR6_BUS_LOCK here,
 * because db_interception might need it.  We can do it before vmentry.
 */
vcpu->arch.dr6 = svm->vmcb->save.dr6;
@@ -1911,7 +1911,7 @@ static int db_interception(struct vcpu_svm *svm)
if (!(svm->vcpu.guest_debug &
  (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP)) &&
!svm->nmi_singlestep) {
-   u32 payload = (svm->vmcb->save.dr6 ^ DR6_RTM) & ~DR6_FIXED_1;
+   u32 payload = (svm->vmcb->save.dr6 ^ (DR6_RTM|DR6_BUS_LOCK)) & 
~DR6_FIXED_1;
kvm_queue_exception_p(>vcpu, DB_VECTOR, payload);
return 1;
}
@@ -3778,7 +3778,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu 
*vcpu)
if (unlikely(svm->vcpu.arch.switch_db_regs & KVM_DEBUGREG_WONT_EXIT))
svm_set_dr6(svm, vcpu->arch.dr6);
else
-   svm_set_dr6(svm, DR6_FIXED_1 | DR6_RTM);
+   svm_set_dr6(svm, DR6_FIXED_1 | DR6_RTM | DR6_BUS_LOCK);
 
clgi();
kvm_load_guest_xsave_state(vcpu);
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index e2f26564a12d..c5d71a9b3729 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -412,7 +412,7 @@ static int nested_vmx_check_exception(struct kvm_vcpu 
*vcpu, unsigned long *exit
if (!has_payload) {
payload = vcpu->arch.dr6;
payload &= ~(DR6_FIXED_1 | DR6_BT);
-   payload ^= DR6_RTM;
+   payload ^= DR6_RTM | DR6_BUS_LOCK;
}
*exit_qual = payload;
} else
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 75c9c6a0a3a4..13c9bcc4d9d9 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4824,7 +4824,8 @@ static int handle_exception_nmi(struct kvm_vcpu *vcpu)
kvm_queue_exception_p(vcpu, DB_VECTOR, dr6);
return 1;
}
-   kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1 | DR6_RTM;
+   kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1 | DR6_RTM |
+

[RESEND PATCH 0/2] Add KVM support for bus lock debug exception

Hi all,

Any comment on this rebased version? I'd appreciate it if anyone has
time to review this short series.

---

A bus lock is acquired either through split locked access to writeback
(WB) memory or by using locks to uncacheable (UC) memory. This is
typically > 1000 cycles slower than atomic opertaion within a cache
line. It also disrupts performance on other cores.

Bus lock debug exception is a sub-feature of bus lock detection. It is
an ability to notify the kernel by an #DB trap after the instruction
acquires a bus lock when CPL>0. This allows the kernel to enforce user
application throttling or mitigatioins.

Expose the bus lock debug exception to guest by the enumeration of
CPUID.(EAX=7,ECX=0).ECX[24]. Software in guest can enable these
exceptions by setting the DEBUGCTLMSR_BUS_LOCK_DETECT(bit 2) of
MSR_IA32_DEBUTCTL.

The bus lock #DB exception can also be intercepted by the VMM and
identified through the bit 11 of the exit qualification at VM exit. The
bit 11 (DR6_BUS_LOCK) of DR6 register is introduced to indicate a bus
lock #DB exception. DR6_BUS_LOCK has formerly always been 1 and delivery
of a bus lock #DB clears it. The VMM should emulate the exceptions by
clearing the bit 11 of the guest DR6.

The kernel support patches for bus lock debug exception is available at
https://lore.kernel.org/lkml/20201124205245.4164633-1-fenghua...@intel.com/

Document for Bus Lock Detection is now available at the latest "Intel
Architecture Instruction Set Extensions Programming Reference".

Document Link:
https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

---

Changelogs

RFC->v1:
- rebase on top of v5.11-rc1, no difference compared with the last version
- v1:https://lore.kernel.org/lkml/20201119092957.16940-1-chenyi.qi...@intel.com/

Chenyi Qiang (2):
KVM: X86: Add support for the emulation of DR6_BUS_LOCK bit
KVM: X86: Expose bus lock debug exception to guest

--
2.17.1

Re: [PATCH 2/2] watchdog: BD70528: conditionally allow BD70528 module

2021-01-07 Thread Matti Vaittinen

On Thu, Jan 7, 2021 at 5:12 PM Guenter Roeck  wrote:
>
> On Thu, Jan 07, 2021 at 08:37:25AM +0200, Matti Vaittinen wrote:
> > The BD70528 watchdog module provides start/stop interface for RTC
> > driver because the BD70528 watchdog must be stopped when RTC time
> > is set. (WDG uses RTC counter and setting RTC may accidentally trigger
> > WDG if WDG is enabled). The BD71828 use same RTC driver as BD70528 but
> > don't share same WDG logic. When BD70528 is not configured a stub call
> > to "stop WDG" is implemented and in case when BD71828 is used, this
> > stub function should be called. Prevent configuring in the BD70528
> > watchdog when BD71828 is configured to avoid access to real WDG
> > functions when WDG does not exist in HW.
> >
> > Signed-off-by: Matti Vaittinen 
>
> As mentioned in my response to the other patch, I think this is the
> wrong solution.

I agree. Please forget this :)
Thanks for the review!

Best Regards
Matti

-- 
~~
-Matti Vaittinen

When you feel blue, no one sees your tears...
When your down, no one understands your struggle...
When you feel happy, no one notices your smile...
But fart just once...
~~

Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data

2021-01-07 Thread Chunfeng Yun

On Tue, 2020-12-29 at 14:24 +0800, Ikjoon Jang wrote:
> xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
> to handle its own sw bandwidth managements and stores bandwidth data
> into internal table every time add_endpoint() is called,
> so when bandwidth allocation fails at one endpoint, all earlier
> allocation from the same interface could still remain at the table.
If failed to add an endpoint, will cause failure of its interface
config, then the other endpoints in the same interface will be dropped
later? you mean some endpoints in an interface may fail but without
affecting its function?

> 
> This patch adds two more hooks from check_bandwidth() and
> reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
> from reset_bandwidth().
> 
> Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with 
> multi-TT")
> Signed-off-by: Ikjoon Jang

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

2021-01-07 Thread Sedat Dilek

On Fri, Jan 8, 2021 at 6:30 AM Al Viro  wrote:
>
> On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> > Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> > it down to the below patch. Debugging this issue, turns out that the boot
> > stalled when a task is waiting on a pipe being released. As we no longer
> > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> > task goes idle without running the task_work. This prevents ->release()
> > from being called on the pipe, which another boot task is waiting on.
> >
> > Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> > goes idle.
> >
> > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> > Reported-by: Song Liu 
> > Signed-off-by: Jens Axboe 
> >
> > ---
> >
> > The other alternative here is obviously to re-instate the:
> >
> > if (unlikely(current->task_works))
> >   task_work_run();
> >
> > in get_signal() that we had before this change. Might be safer in case
> > there are other cases that need to ensure the work is run in a timely
> > fashion, though I do think it's cleaner to long term to correctly mark
> > task_work with the needed notification type. Comments welcome...
>
> Interesting...  I think I've missed the discussion of that thing; could
> you forward the relevant thread my way or give an archive link to it?

See [1].

- Sedat -

[1] https://marc.info/?t=16098715661=1=2

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

2021-01-07 Thread Sedat Dilek

On Fri, Jan 8, 2021 at 4:56 AM Jens Axboe  wrote:
>
> On 1/7/21 3:17 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Jan 5, 2021 at 10:30 AM Jens Axboe  wrote:
> >>
> >> Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> >> it down to the below patch. Debugging this issue, turns out that the boot
> >> stalled when a task is waiting on a pipe being released. As we no longer
> >> run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> >> task goes idle without running the task_work. This prevents ->release()
> >> from being called on the pipe, which another boot task is waiting on.
> >>
> >> Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> >> goes idle.
> >>
> >> Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> >> Reported-by: Song Liu 
> >> Signed-off-by: Jens Axboe 
> >
> > I just spend a bit of time bisecting and landed on commit 98b89b649fce
> > ("signal: kill JOBCTL_TASK_WORK") causing my failure to bootup
> > mainline.  Your patch fixes my problem.  I haven't done any analysis
> > of the code--just testing, thus:
> >
> > Tested-by: Douglas Anderson 
>
> Thanks, adding your Tested-by.
>

I have this in my patch-series since it appeared in [1].

Feel free to add my:

   Tested-by: Sedat Dilek  # LLVM/Clang version 11.0.1

- Sedat -

[1] https://git.kernel.dk/cgit/linux-block/log/?h=task_work

- Sedat -

RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

2021-01-07 Thread Chatradhi, Naveen Krishna

[AMD Official Use Only - Approved for External Use]

Hi Guenter,

>> No, because you are not in the approval path (you did not send the patch to 
>> me). Reviewed-by: or Acked-by: would be more appropriate.

Got it, my mistake, please use 
Acked-by: Naveen Krishna Chatradhi 

Regards,
Naveenk

-Original Message-
From: Guenter Roeck  On Behalf Of Guenter Roeck
Sent: Friday, January 8, 2021 11:47 AM
To: Chatradhi, Naveen Krishna ; David Arcari 
; linux-hw...@vger.kernel.org
Cc: Jean Delvare ; linux-kernel@vger.kernel.org; 
sta...@vger.kernel.org
Subject: Re: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info 
config

[CAUTION: External Email]

On 1/7/21 9:49 PM, Chatradhi, Naveen Krishna wrote:
> [AMD Official Use Only - Approved for External Use]
>
> Hi David,
>
> Thank you for noticing and submitting a fix. You may use
> Signed-off-by: Naveen Krishna Chatradhi 
>

No, because you are not in the approval path (you did not send the patch to 
me). Reviewed-by: or Acked-by: would be more appropriate.

Genter

> Regards,
> Naveenk
>
> -Original Message-
> From: David Arcari 
> Sent: Thursday, January 7, 2021 8:17 PM
> To: linux-hw...@vger.kernel.org
> Cc: David Arcari ; Chatradhi, Naveen Krishna 
> ; Jean Delvare ; 
> Guenter Roeck ; linux-kernel@vger.kernel.org; 
> sta...@vger.kernel.org
> Subject: [PATCH] hwmon: (amd_energy) fix allocation of 
> hwmon_channel_info config
>
> [CAUTION: External Email]
>
> hwmon, specifically hwmon_num_channel_attrs, expects the config array in the 
> hwmon_channel_info structure to be terminated by a zero entry.  amd_energy 
> does not honor this convention.  As result, a KASAN warning is possible.  Fix 
> this by adding an additional entry and setting it to zero.
>
> Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy 
> counters")
>
> Signed-off-by: David Arcari 
> Cc: Naveen Krishna Chatradhi  [naveenk:] 
> Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Jean Delvare 
> Cc: Guenter Roeck 
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hwmon/amd_energy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c 
> index 9b306448b7a0..822c2e74b98d 100644
> --- a/drivers/hwmon/amd_energy.c
> +++ b/drivers/hwmon/amd_energy.c
> @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev,
>  */
> cpus = num_present_cpus() / num_siblings;
>
> -   s_config = devm_kcalloc(dev, cpus + sockets,
> +   s_config = devm_kcalloc(dev, cpus + sockets + 1,
> sizeof(u32), GFP_KERNEL);
> if (!s_config)
> return -ENOMEM;
> @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev,
> scnprintf(label_l[i], 10, "Esocket%u", (i - cpus));
> }
>
> +   s_config[i] = 0;
> return 0;
>  }
>
> --
> 2.18.1
>

Re: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

2021-01-07 Thread Guenter Roeck

On 1/7/21 9:49 PM, Chatradhi, Naveen Krishna wrote:
> [AMD Official Use Only - Approved for External Use]
> 
> Hi David,
> 
> Thank you for noticing and submitting a fix. You may use
> Signed-off-by: Naveen Krishna Chatradhi 
> 

No, because you are not in the approval path (you did not send the patch
to me). Reviewed-by: or Acked-by: would be more appropriate.

Genter

> Regards,
> Naveenk
> 
> -Original Message-
> From: David Arcari  
> Sent: Thursday, January 7, 2021 8:17 PM
> To: linux-hw...@vger.kernel.org
> Cc: David Arcari ; Chatradhi, Naveen Krishna 
> ; Jean Delvare ; Guenter 
> Roeck ; linux-kernel@vger.kernel.org; 
> sta...@vger.kernel.org
> Subject: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info 
> config
> 
> [CAUTION: External Email]
> 
> hwmon, specifically hwmon_num_channel_attrs, expects the config array in the 
> hwmon_channel_info structure to be terminated by a zero entry.  amd_energy 
> does not honor this convention.  As result, a KASAN warning is possible.  Fix 
> this by adding an additional entry and setting it to zero.
> 
> Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")
> 
> Signed-off-by: David Arcari 
> Cc: Naveen Krishna Chatradhi 
> [naveenk:] Signed-off-by: Naveen Krishna Chatradhi 
> Cc: Jean Delvare 
> Cc: Guenter Roeck 
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/hwmon/amd_energy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c index 
> 9b306448b7a0..822c2e74b98d 100644
> --- a/drivers/hwmon/amd_energy.c
> +++ b/drivers/hwmon/amd_energy.c
> @@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev,
>  */
> cpus = num_present_cpus() / num_siblings;
> 
> -   s_config = devm_kcalloc(dev, cpus + sockets,
> +   s_config = devm_kcalloc(dev, cpus + sockets + 1,
> sizeof(u32), GFP_KERNEL);
> if (!s_config)
> return -ENOMEM;
> @@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev,
> scnprintf(label_l[i], 10, "Esocket%u", (i - cpus));
> }
> 
> +   s_config[i] = 0;
> return 0;
>  }
> 
> --
> 2.18.1
>

Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data

2021-01-07 Thread Chunfeng Yun

On Thu, 2021-01-07 at 13:09 +0200, Mathias Nyman wrote:
> On 29.12.2020 8.24, Ikjoon Jang wrote:
> > xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
> > to handle its own sw bandwidth managements and stores bandwidth data
> > into internal table every time add_endpoint() is called,
> > so when bandwidth allocation fails at one endpoint, all earlier
> > allocation from the same interface could still remain at the table.
> > 
> > This patch adds two more hooks from check_bandwidth() and
> > reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
> > from reset_bandwidth().
> > 
> > Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with 
> > multi-TT")
> > Signed-off-by: Ikjoon Jang 
> > 
> 
> ...
> 
> > 
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index d4a8d0efbbc4..e1fcd3cf723f 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -2882,6 +2882,12 @@ static int xhci_check_bandwidth(struct usb_hcd *hcd, 
> > struct usb_device *udev)
> > xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev);
> > virt_dev = xhci->devs[udev->slot_id];
> >  
> > +   if (xhci->quirks & XHCI_MTK_HOST) {
> > +   ret = xhci_mtk_check_bandwidth(hcd, udev);
> > +   if (ret < 0)
> > +   return ret;
> > +   }
> > +
> 
> Just noticed that XHCI_MTK_HOST quirk is only set in xhci-mtk.c.
> xhci-mtk.c calls xhci_init_driver(..., xhci_mtk_overrides) with a .reset 
> override function.
> 
> why not add override functions for .check_bandwidth and .reset_bandwidth to 
> xhci_mtk_overrides instead?
> 
> Another patch to add similar overrides for .add_endpoint and .drop_endpoint 
> should probably be
> done so that we can get rid of the xhci_mtk_add/drop_ep_quirk() calls in 
> xhci.c as well
You mean, we can export xhci_add/drop_endpoint()?

> 
> Thanks
> -Mathias
>

Re: [PATCH 1/2] watchdog: bd70528: don't crash if WDG is confiured with BD71828

2021-01-07 Thread Vaittinen, Matti


On Thu, 2021-01-07 at 20:15 +0200, Matti Vaittinen wrote:
> Thanks a lot for taking a careful look at this Guenter!
> 
> On Thu, 2021-01-07 at 07:12 -0800, Guenter Roeck wrote:
> > On Thu, Jan 07, 2021 at 08:37:03AM +0200, Matti Vaittinen wrote:
> > > If config for BD70528 watchdog is enabled when BD71828 or BD71815
> > > are used the RTC module will issue call to BD70528 watchdog with
> > > NULL data. Ignore this call and don't crash.
> > > 
> > > Signed-off-by: Matti Vaittinen  > > >
> > 
> > I really think this should be handled in the calling code.
> > Also, I am curious how this is supposed to work.
> > 
> > The code is called with
> > 
> > ret = bd70528_wdt_set(r->parent, new_state &
> > BD70528_WDT_STATE_BIT,
> >   old_state);
> 
> My brainfart.
> The bd70528_wdt_set is not called as it is protected in RTC by
> has_rtc_timers flag.
> 
> I inserted this check in wrong function. The bd70528_wdt_lock()
> is where we may hit the problem as it is not protected.

Actually, after a fresh look - it seems the bd70528_wdt_lock() is also
just fine. The RTC is not grabbing the lock on other PMICs but the
BD70528. I'm not really sure what I have been thinking of. @_@ I
should've been more careful. Thanks for spotting this in the review!

Best Regards
Matti

Re: [PATCHv4 0/4] perf tools: Allow to enable/disable events via control pipe

2021-01-07 Thread Namhyung Kim

Hi Jiri,

On Thu, Jan 7, 2021 at 9:12 PM Jiri Olsa  wrote:
>
> On Sun, Dec 27, 2020 at 12:20:34AM +0100, Jiri Olsa wrote:
> > hi,
> > adding support to enable/disable specific events via control
> > file via following commands:
> >
> > # echo 'enable sched:sched_process_fork' > control
> > # echo 'disabled sched:sched_process_fork' > control
> >
> > v4 changes:
> >   - some of the patches got merged
> >   - rebased to latest perf/core
> >   - fixed changelogs
> >   - added 'ping' command
>
> any reviews?

Acked-by: Namhyung Kim 

Thanks,
Namhyung

Re: [PATCH v4] ovl: fix dentry leak in ovl_get_redirect

2021-01-07 Thread Liangyan


ping

On 20/12/22 上午11:06, Liangyan wrote:

We need to lock d_parent->d_lock before dget_dlock, or this may
have d_lockref updated parallelly like calltrace below which will
cause dentry->d_lockref leak and risk a crash.

  CPU 0CPU 1
ovl_set_redirect   lookup_fast
   ovl_get_redirect   __d_lookup
 dget_dlock
   //no lock protection herespin_lock(>d_lock)
   dentry->d_lockref.count++dentry->d_lockref.count++

[   49.799059] PGD 80061fed7067 P4D 80061fed7067 PUD 61fec5067 PMD 0
[   49.799689] Oops: 0002 [#1] SMP PTI
[   49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 
#1
[   49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 
04/01/2014
[   49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
[   49.803470] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[   49.803949] RAX:  RBX: 93b8da3446c0 RCX: 000a
[   49.804600] RDX: 0001 RSI: 000a RDI: 0088
[   49.805252] RBP:  R08:  R09: 993cf040
[   49.805898] R10: 93b92292e580 R11: d27f188a4b80 R12: 
[   49.806548] R13: ff9c R14: fffe R15: 93b8da3446c0
[   49.807200] FS:  7ffbedffb700() GS:93b92788() 
knlGS:
[   49.807935] CS:  0010 DS:  ES:  CR0: 80050033
[   49.808461] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[   49.809113] DR0:  DR1:  DR2: 
[   49.809758] DR3:  DR6: fffe0ff0 DR7: 0400
[   49.810410] Call Trace:
[   49.810653]  d_delete+0x2c/0xb0
[   49.810951]  vfs_rmdir+0xfd/0x120
[   49.811264]  do_rmdir+0x14f/0x1a0
[   49.811573]  do_syscall_64+0x5b/0x190
[   49.811917]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   49.812385] RIP: 0033:0x7ffbf505ffd7
[   49.814404] RSP: 002b:7ffbedffada8 EFLAGS: 0297 ORIG_RAX: 
0054
[   49.815098] RAX: ffda RBX: 7ffbedffb640 RCX: 7ffbf505ffd7
[   49.815744] RDX: 04449700 RSI:  RDI: 06c8cd50
[   49.816394] RBP: 7ffbedffaea0 R08:  R09: 00017d0b
[   49.817038] R10:  R11: 0297 R12: 0012
[   49.817687] R13: 072823d8 R14: 7ffbedffb700 R15: 072823d8
[   49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd 
libps2 i8042
[   49.819052] CR2: 0088
[   49.819368] ---[ end trace 4e652b8aa299aa2d ]---
[   49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
[   49.821880] RSP: 0018:ac6fc5417e98 EFLAGS: 00010246
[   49.822363] RAX:  RBX: 93b8da3446c0 RCX: 000a
[   49.823008] RDX: 0001 RSI: 000a RDI: 0088
[   49.823658] RBP:  R08:  R09: 993cf040
[   49.825404] R10: 93b92292e580 R11: d27f188a4b80 R12: 
[   49.827147] R13: ff9c R14: fffe R15: 93b8da3446c0
[   49.828890] FS:  7ffbedffb700() GS:93b92788() 
knlGS:
[   49.830725] CS:  0010 DS:  ES:  CR0: 80050033
[   49.832359] CR2: 0088 CR3: 0005e3f74006 CR4: 003606a0
[   49.834085] DR0:  DR1:  DR2: 
[   49.835792] DR3:  DR6: fffe0ff0 DR7: 0400

Cc: 
Fixes: a6c606551141 ("ovl: redirect on rename-dir")
Signed-off-by: Liangyan 
Reviewed-by: Joseph Qi 
Suggested-by: Al Viro 
---
  fs/overlayfs/dir.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 28a075b5f5b2..d1efa3a5a503 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -992,8 +992,8 @@ static char *ovl_get_redirect(struct dentry *dentry, bool 
abs_redirect)
  
  		buflen -= thislen;

memcpy([buflen], name, thislen);
-   tmp = dget_dlock(d->d_parent);
spin_unlock(>d_lock);
+   tmp = dget_parent(d);
  
  		dput(d);

d = tmp;

Re: [PATCH] arm64: dts: qcom: sdm845: Reserve LPASS clocks in gcc

2021-01-07 Thread Vinod Koul

On 21-12-20, 16:11, Bjorn Andersson wrote:
> The GCC_LPASS_Q6_AXI_CLK and GCC_LPASS_SWAY_CLK clocks may not be
> touched on a typical UEFI based SDM845 device, but when the kernel is
> built with CONFIG_SDM_LPASSCC_845 this happens, unless they are marked
> as protected-clocks in the DT.
> 
> This was done for the MTP and the Pocophone, but not for DB845c and the
> Lenovo Yoga C630 - causing these to fail to boot if the LPASS clock
> controller is enabled (which it typically isn't).

Reviewed-by: Vinod Koul 
Tested-by: Vinod Koul  #on db845c

-- 
~Vinod

[PATCH v5] power: suspend: Move dpm_watchdog to suspend.c and enhance it

2021-01-07 Thread Joseph Jang

Since dpm_watchdog just cover two functions __device_suspend() and
device_resume(), we proposed to move it to core power suspend.c to extend
its coverage and monitor more devices suspend hand issues.

We propose to use new name suspend watchdog and new timeout handler to
cover more sleep hang issues. The new timeout handler will dump disk
sleep task call trace at first round timeout and trigger kernel panic
at second round timeout.
The default timer for each round is defined in
CONFIG_PM_SUSPEND_WATCHDOG_TIMEOUT.

Signed-off-by: Joseph Jang 
---
Changes since v4:
 - Change #define PM_SUSPEND_WATCHDOG to CONFIG_PM_SUSPEND_WATCHDOG in 
suspend_watchdog.c
   to make sure we compile all suspend watchdog functions.
 - Add suspend watchdog functions declared in suspend_watchdog.h to prevent 
compile errors.

Changes since v3:
 - Change the naming from sleep timer to suspend watchdog.
 - Remove console_is_suspended() from console.h and printk.c
 - Add static declaration for suspend_watchdog struct since we use it in 
suspend.c only.
 - Move suspend watchdog real logic to suspend_watchdog.c.
 - Put the function prototypes in suspend_watchdog.h
 - Use inline functions for function prototypes definition.

Changes since v2:
 - Add kernel/power/suspend_timer.h in MAINTAINERS
 - Share some corner cases that dpm_watchdog cannot cover.
  Case#A: dpm_watchdog cannot cover suspend hang in suspend_enter().
  File: kernel/power/suspend.c
  int suspend_devices_and_enter(suspend_state_t state)
  {
   ... 

 suspend_test_start();
 error = dpm_suspend_start(PMSG_SUSPEND);  <== dpm_watchdog will be 
enabled/disabled in this fucntion ...
 if (error) {
 pr_err("Some devices failed to suspend, or early wake event 
detected\n");
 goto Recover_platform;
 }
 suspend_test_finish("suspend devices");
 if (suspend_test(TEST_DEVICES))
 goto Recover_platform;

 do {
 error = suspend_enter(state, );  <== but we encounter 
hang inside function suspend_enter() ...
 } while (!error && !wakeup && platform_suspend_again(state));

  Case#B: dpm_watchdog cannot cover resume hang in dpm_resume_early() because 
it enable/disable in device_resume().
  Call trace:
   __switch_to+0x174/0x194
   __schedule+0xa60/0x1464
   __cancel_work_timer+0x120/0x234
   chg_pm_resume+0x2c/0xd8
   dpm_run_callback+0x27c/0x624
   device_resume_early+0x1e4/0x1f8
   dpm_resume_early+0x350/0x8f4
   suspend_devices_and_enter+0xffc/0x168c
   pm_suspend+0xb54/0xdac

  File: drivers/base/power/main.c.
  static int device_resume(struct device *dev, pm_message_t state, bool async)
  if (!dpm_wait_for_superior(dev, async))
  goto Complete;
  
  dpm_watchdog_set(, dev);
  device_lock(dev);
  
  /*
   ... 
 
  Unlock:
  device_unlock(dev);
  dpm_watchdog_clear();

  Case#C: dpm_watchdog cannot cover suspend hang in ksys_sync().
   Call trace:
__switch_to+0x1b0/0x1cc
__schedule+0xac8/0x1314
io_schedule+0x94/0xc8
wait_on_page_bit+0x1f8/0x3a4
__filemap_fdatawait_range+0x134/0x150
sync_inodes_sb+0x368/0x584
sync_inodes_one_sb+0x18/0x24
iterate_supers+0x12c/0x2b8
ksys_sync+0x48/0x12c
enter_state+0x294/0x7bc
pm_suspend+0x164/0x2a8

 - Explain some enhancement by following.
  Q1: Why not use the existing one?
  struct dpm_watchdog {
  struct device   *dev;
  struct task_struct  *tsk;
  struct timer_list   timer;
  };
  
  A1: In kernel/power/suspend.c, we don't have "struct device " because 
suspend.c is for core PM instead of device PM.
  So we propose to use sleep_timer struct.
  
  struct sleep_timer {
  struct task_struct*tsk;
  struct timer_list timer;
  };
  
  
  Q2: Why not use stack memory for timer struct?
  static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
  {
  ...   
  timer_setup_on_stack(timer, dpm_watchdog_handler, 0);  <== dpm_watchdog 
use stack memory for timer struct.
  /* use same timeout value for both suspend and resume */
  timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT;
  add_timer(timer);
  }
  
  A2: dpm_watchdog use stack memory has limitation.
  It cannot support starting watchdog at end of function like s2idle_enter().
  We cannot use stack memory for this case because the timer struct will be 
free when go back to caller.
  
  File: kernel/power/suspend.c
  static void s2idle_enter(void)
{
  trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, 
true);
  
  +   stop_sleep_timer();
  +
  raw_spin_lock_irq(_lock);
  if (pm_wakeup_pending())
  goto out;
  ... 
  s2idle_state = S2IDLE_STATE_NONE;
  raw_spin_unlock_irq(_lock);
  
  +   start_sleep_timer();
  +
  trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, 
false);
}
  
  So we propose to

Re: [PATCH 3/3] tools/lib/fs: Cache cgroupfs mount point

2021-01-07 Thread Namhyung Kim

On Wed, Jan 6, 2021 at 10:33 AM Namhyung Kim  wrote:
>
> Hi Arnaldo,
>
> On Tue, Dec 29, 2020 at 8:51 PM Arnaldo Carvalho de Melo
>  wrote:
> >
> > Em Wed, Dec 16, 2020 at 06:05:56PM +0900, Namhyung Kim escreveu:
> > > Currently it parses the /proc file everytime it opens a file in the
> > > cgroupfs.  Save the last result to avoid it (assuming it won't be
> > > changed between the accesses).
> >
> > Which is the most likely case, but can't we use something like inotify
> > to detect that and bail out or warn the user?
>
> Hmm.. looks doable.  Will check.

So I've played with inotify a little bit, and it seems it needs to monitor
changes on the file or the directory.  I didn't get any notification from
the /proc/mounts file even if I did some mount/umount.

Instead, I could get IN_UNMOUNT when the cgroup filesystem was
unmounted.  But for the monitoring, we need to do one of a) select-like
syscall to wait for the events, b) signal-driven IO notification or c) read
the inotify file with non-block mode everytime.

In a library code, I don't think we can do a) or b) since it can affect
user program behaviors.  Then we should go with c) but I think
it's opposite to the purpose of this patch. :)

As you said, I think mostly we don't care as the accesses will happen
in a short period of time.  But if you really care, maybe for the upcoming
perf daemon changes, I think we can add an API to invalidate the cache
or internal time-based invalidation logic (like remove it after 10 sec.).

Thoughts?

Thanks,
Namhyung

RE: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

2021-01-07 Thread Chatradhi, Naveen Krishna

[AMD Official Use Only - Approved for External Use]

Hi David,

Thank you for noticing and submitting a fix. You may use
Signed-off-by: Naveen Krishna Chatradhi 

Regards,
Naveenk

-Original Message-
From: David Arcari  
Sent: Thursday, January 7, 2021 8:17 PM
To: linux-hw...@vger.kernel.org
Cc: David Arcari ; Chatradhi, Naveen Krishna 
; Jean Delvare ; Guenter 
Roeck ; linux-kernel@vger.kernel.org; sta...@vger.kernel.org
Subject: [PATCH] hwmon: (amd_energy) fix allocation of hwmon_channel_info config

[CAUTION: External Email]

hwmon, specifically hwmon_num_channel_attrs, expects the config array in the 
hwmon_channel_info structure to be terminated by a zero entry.  amd_energy does 
not honor this convention.  As result, a KASAN warning is possible.  Fix this 
by adding an additional entry and setting it to zero.

Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters")

Signed-off-by: David Arcari 
Cc: Naveen Krishna Chatradhi 
[naveenk:] Signed-off-by: Naveen Krishna Chatradhi 
Cc: Jean Delvare 
Cc: Guenter Roeck 
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
 drivers/hwmon/amd_energy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/amd_energy.c b/drivers/hwmon/amd_energy.c index 
9b306448b7a0..822c2e74b98d 100644
--- a/drivers/hwmon/amd_energy.c
+++ b/drivers/hwmon/amd_energy.c
@@ -222,7 +222,7 @@ static int amd_create_sensor(struct device *dev,
 */
cpus = num_present_cpus() / num_siblings;

-   s_config = devm_kcalloc(dev, cpus + sockets,
+   s_config = devm_kcalloc(dev, cpus + sockets + 1,
sizeof(u32), GFP_KERNEL);
if (!s_config)
return -ENOMEM;
@@ -254,6 +254,7 @@ static int amd_create_sensor(struct device *dev,
scnprintf(label_l[i], 10, "Esocket%u", (i - cpus));
}

+   s_config[i] = 0;
return 0;
 }

--
2.18.1

Re: [PATCH] iommu/io-pgtable-arm: Allow non-coherent masters to use system cache

2021-01-07 Thread Sai Prakash Ranjan


On 2021-01-07 22:27, isa...@codeaurora.org wrote:

On 2021-01-06 03:56, Will Deacon wrote:

On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY 
flag")

removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went
the memory type setting required for the non-coherent masters to use
system cache. Now that system cache support for GPU is added, we will
need to mark the memory as normal sys-cached for GPU to use system 
cache.
Without this, the system cache lines are not allocated for GPU. We 
use
the IO_PGTABLE_QUIRK_ARM_OUTER_WBWA quirk instead of a page 
protection

flag as the flag cannot be exposed via DMA api because of no in-tree
users.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/io-pgtable-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/io-pgtable-arm.c 
b/drivers/iommu/io-pgtable-arm.c

index 7c9ea9d7874a..3fb7de8304a2 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -415,6 +415,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct 
arm_lpae_io_pgtable *data,

else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
+   else if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+   pte |= (ARM_LPAE_MAIR_ATTR_IDX_INC_OCACHE
+   << ARM_LPAE_PTE_ATTRINDX_SHIFT);
}



While this approach of enabling system cache globally for both page
tables and other buffers
works for the GPU usecase, this isn't ideal for other clients that use
system cache. For example,
video clients only want to cache a subset of their buffers in the
system cache, due to the sizing constraint
imposed by how much of the system cache they can use. So, it would be
ideal to have
a way of expressing the desire to use the system cache on a per-buffer
basis. Additionally,
our video clients use the DMA layer, and since the requirement is for
caching in the system cache
to be a per buffer attribute, it seems like we would have to have a
DMA attribute to express
this on a per-buffer basis.



I did bring this up initially [1], also where is this video client
in upstream? AFAIK, only system cache user in upstream is GPU.
We cannot add any DMA attribute unless there is any user upstream
as per [2], so when the support for such a client is added, wouldn't
((data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA) || PROT_FLAG)
work?

[1] 
https://lore.kernel.org/dri-devel/ecfda7ca80f6d7b4ff3d89b8758f4...@codeaurora.org/

[2] https://lore.kernel.org/linux-iommu/20191026053026.ga14...@lst.de/T/

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] staging: mt7621-dts: remove obsolete switch node

2021-01-07 Thread Sergio Paracuellos

On Fri, Jan 8, 2021 at 3:52 AM DENG Qingfang  wrote:
>
> This was for OpenWrt's swconfig driver, which never made it upstream,
> and was also superseded by MT7530 DSA driver.
>
> Signed-off-by: DENG Qingfang 
> ---
>  drivers/staging/mt7621-dts/mt7621.dtsi | 7 ---
>  1 file changed, 7 deletions(-)

Reviewed-by: Sergio Paracuellos

Re: [PATCH v6 1/5] dt-bindings: vendor-prefixes: Add an entry for Kverneland Group

2021-01-07 Thread Oleksij Rempel

On Thu, Jan 07, 2021 at 07:23:23PM -0700, Rob Herring wrote:
> On Thu, 07 Jan 2021 11:08:27 +0100, Oleksij Rempel wrote:
> > Add "kvg" entry for Kverneland Group: https://ien.kvernelandgroup.com/
> > 
> > Signed-off-by: Oleksij Rempel 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> 
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.

Sorry, nothing is changed.

Regards,
Oleksij
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH v14 2/4] fs: add LSM-supporting anon-inode interface

From: Daniel Colascione 

This change adds a new function, anon_inode_getfd_secure, that creates
anonymous-node file with individual non-S_PRIVATE inode to which security
modules can apply policy. Existing callers continue using the original
singleton-inode kind of anonymous-inode file. We can transition anonymous
inode users to the new kind of anonymous inode in individual patches for
the sake of bisection and review.

The new function accepts an optional context_inode parameter that callers
can use to provide additional contextual information to security modules.
For example, in case of userfaultfd, the created inode is a 'logical child'
of the context_inode (userfaultfd inode of the parent process) in the sense
that it provides the security context required during creation of the child
process' userfaultfd inode.

Signed-off-by: Daniel Colascione 

[LG: Delete obsolete comments to alloc_anon_inode()]
[LG: Add context_inode description in comments to anon_inode_getfd_secure()]
[LG: Remove definition of anon_inode_getfile_secure() as there are no callers]
[LG: Make __anon_inode_getfile() static]
[LG: Use correct error cast in __anon_inode_getfile()]
[LG: Fix error handling in __anon_inode_getfile()]

Signed-off-by: Lokesh Gidra 
Reviewed-by: Eric Biggers 
---
 fs/anon_inodes.c| 150 ++--
 fs/libfs.c  |   5 --
 include/linux/anon_inodes.h |   5 ++
 3 files changed, 115 insertions(+), 45 deletions(-)

diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 89714308c25b..023337d65a03 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -55,61 +55,79 @@ static struct file_system_type anon_inode_fs_type = {
.kill_sb= kill_anon_super,
 };
 
-/**
- * anon_inode_getfile - creates a new file instance by hooking it up to an
- *  anonymous inode, and a dentry that describe the "class"
- *  of the file
- *
- * @name:[in]name of the "class" of the new file
- * @fops:[in]file operations for the new file
- * @priv:[in]private data for the new file (will be file's 
private_data)
- * @flags:   [in]flags
- *
- * Creates a new file by hooking it on a single inode. This is useful for files
- * that do not need to have a full-fledged inode in order to operate correctly.
- * All the files created with anon_inode_getfile() will share a single inode,
- * hence saving memory and avoiding code duplication for the file/inode/dentry
- * setup.  Returns the newly created file* or an error pointer.
- */
-struct file *anon_inode_getfile(const char *name,
-   const struct file_operations *fops,
-   void *priv, int flags)
+static struct inode *anon_inode_make_secure_inode(
+   const char *name,
+   const struct inode *context_inode)
 {
-   struct file *file;
+   struct inode *inode;
+   const struct qstr qname = QSTR_INIT(name, strlen(name));
+   int error;
+
+   inode = alloc_anon_inode(anon_inode_mnt->mnt_sb);
+   if (IS_ERR(inode))
+   return inode;
+   inode->i_flags &= ~S_PRIVATE;
+   error = security_inode_init_security_anon(inode, , context_inode);
+   if (error) {
+   iput(inode);
+   return ERR_PTR(error);
+   }
+   return inode;
+}
 
-   if (IS_ERR(anon_inode_inode))
-   return ERR_PTR(-ENODEV);
+static struct file *__anon_inode_getfile(const char *name,
+const struct file_operations *fops,
+void *priv, int flags,
+const struct inode *context_inode,
+bool secure)
+{
+   struct inode *inode;
+   struct file *file;
 
if (fops->owner && !try_module_get(fops->owner))
return ERR_PTR(-ENOENT);
 
-   /*
-* We know the anon_inode inode count is always greater than zero,
-* so ihold() is safe.
-*/
-   ihold(anon_inode_inode);
-   file = alloc_file_pseudo(anon_inode_inode, anon_inode_mnt, name,
+   if (secure) {
+   inode = anon_inode_make_secure_inode(name, context_inode);
+   if (IS_ERR(inode)) {
+   file = ERR_CAST(inode);
+   goto err;
+   }
+   } else {
+   inode = anon_inode_inode;
+   if (IS_ERR(inode)) {
+   file = ERR_PTR(-ENODEV);
+   goto err;
+   }
+   /*
+* We know the anon_inode inode count is always
+* greater than zero, so ihold() is safe.
+*/
+   ihold(inode);
+   }
+
+   file = alloc_file_pseudo(inode, anon_inode_mnt, name,
 flags & (O_ACCMODE | O_NONBLOCK), fops);
if (IS_ERR(file))
-   goto err;
+

[PATCH v14 4/4] userfaultfd: use secure anon inodes for userfaultfd

From: Daniel Colascione 

This change gives userfaultfd file descriptors a real security
context, allowing policy to act on them.

Signed-off-by: Daniel Colascione 

[LG: Remove owner inode from userfaultfd_ctx]
[LG: Use anon_inode_getfd_secure() instead of anon_inode_getfile_secure()
 in userfaultfd syscall]
[LG: Use inode of file in userfaultfd_read() in resolve_userfault_fork()]

Signed-off-by: Lokesh Gidra 
Reviewed-by: Eric Biggers 
---
 fs/userfaultfd.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 894cc28142e7..0be8cdd4425a 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -979,14 +979,14 @@ static __poll_t userfaultfd_poll(struct file *file, 
poll_table *wait)
 
 static const struct file_operations userfaultfd_fops;
 
-static int resolve_userfault_fork(struct userfaultfd_ctx *ctx,
- struct userfaultfd_ctx *new,
+static int resolve_userfault_fork(struct userfaultfd_ctx *new,
+ struct inode *inode,
  struct uffd_msg *msg)
 {
int fd;
 
-   fd = anon_inode_getfd("[userfaultfd]", _fops, new,
- O_RDWR | (new->flags & UFFD_SHARED_FCNTL_FLAGS));
+   fd = anon_inode_getfd_secure("[userfaultfd]", _fops, new,
+   O_RDWR | (new->flags & UFFD_SHARED_FCNTL_FLAGS), inode);
if (fd < 0)
return fd;
 
@@ -996,7 +996,7 @@ static int resolve_userfault_fork(struct userfaultfd_ctx 
*ctx,
 }
 
 static ssize_t userfaultfd_ctx_read(struct userfaultfd_ctx *ctx, int no_wait,
-   struct uffd_msg *msg)
+   struct uffd_msg *msg, struct inode *inode)
 {
ssize_t ret;
DECLARE_WAITQUEUE(wait, current);
@@ -1107,7 +1107,7 @@ static ssize_t userfaultfd_ctx_read(struct 
userfaultfd_ctx *ctx, int no_wait,
spin_unlock_irq(>fd_wqh.lock);
 
if (!ret && msg->event == UFFD_EVENT_FORK) {
-   ret = resolve_userfault_fork(ctx, fork_nctx, msg);
+   ret = resolve_userfault_fork(fork_nctx, inode, msg);
spin_lock_irq(>event_wqh.lock);
if (!list_empty(_event)) {
/*
@@ -1167,6 +1167,7 @@ static ssize_t userfaultfd_read(struct file *file, char 
__user *buf,
ssize_t _ret, ret = 0;
struct uffd_msg msg;
int no_wait = file->f_flags & O_NONBLOCK;
+   struct inode *inode = file_inode(file);
 
if (ctx->state == UFFD_STATE_WAIT_API)
return -EINVAL;
@@ -1174,7 +1175,7 @@ static ssize_t userfaultfd_read(struct file *file, char 
__user *buf,
for (;;) {
if (count < sizeof(msg))
return ret ? ret : -EINVAL;
-   _ret = userfaultfd_ctx_read(ctx, no_wait, );
+   _ret = userfaultfd_ctx_read(ctx, no_wait, , inode);
if (_ret < 0)
return ret ? ret : _ret;
if (copy_to_user((__u64 __user *) buf, , sizeof(msg)))
@@ -1999,8 +2000,8 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)
/* prevent the mm struct to be freed */
mmgrab(ctx->mm);
 
-   fd = anon_inode_getfd("[userfaultfd]", _fops, ctx,
- O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS));
+   fd = anon_inode_getfd_secure("[userfaultfd]", _fops, ctx,
+   O_RDWR | (flags & UFFD_SHARED_FCNTL_FLAGS), NULL);
if (fd < 0) {
mmdrop(ctx->mm);
kmem_cache_free(userfaultfd_ctx_cachep, ctx);
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH v14 3/4] selinux: teach SELinux about anonymous inodes

From: Daniel Colascione 

This change uses the anon_inodes and LSM infrastructure introduced in
the previous patches to give SELinux the ability to control
anonymous-inode files that are created using the new
anon_inode_getfd_secure() function.

A SELinux policy author detects and controls these anonymous inodes by
adding a name-based type_transition rule that assigns a new security
type to anonymous-inode files created in some domain. The name used
for the name-based transition is the name associated with the
anonymous inode for file listings --- e.g., "[userfaultfd]" or
"[perf_event]".

Example:

type uffd_t;
type_transition sysadm_t sysadm_t : anon_inode uffd_t "[userfaultfd]";
allow sysadm_t uffd_t:anon_inode { create };

(The next patch in this series is necessary for making userfaultfd
support this new interface.  The example above is just
for exposition.)

Signed-off-by: Daniel Colascione 
Signed-off-by: Lokesh Gidra 
---
 security/selinux/hooks.c| 59 +
 security/selinux/include/classmap.h |  2 +
 2 files changed, 61 insertions(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 644b17ec9e63..8b4e155b2930 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2934,6 +2933,63 @@ static int selinux_inode_init_security(struct inode 
*inode, struct inode *dir,
return 0;
 }
 
+static int selinux_inode_init_security_anon(struct inode *inode,
+   const struct qstr *name,
+   const struct inode *context_inode)
+{
+   const struct task_security_struct *tsec = selinux_cred(current_cred());
+   struct common_audit_data ad;
+   struct inode_security_struct *isec;
+   int rc;
+
+   if (unlikely(!selinux_initialized(_state)))
+   return 0;
+
+   isec = selinux_inode(inode);
+
+   /*
+* We only get here once per ephemeral inode.  The inode has
+* been initialized via inode_alloc_security but is otherwise
+* untouched.
+*/
+   isec->initialized = LABEL_INITIALIZED;
+   isec->sclass = SECCLASS_ANON_INODE;
+
+   if (context_inode) {
+   struct inode_security_struct *context_isec =
+   selinux_inode(context_inode);
+   if (context_isec->initialized != LABEL_INITIALIZED)
+   return -EACCES;
+   if (context_isec->sclass != SECCLASS_ANON_INODE) {
+   pr_err("SELinux:  initializing anonymous inode with 
non-anonymous inode");
+   return -EACCES;
+   }
+
+   isec->sid = context_isec->sid;
+   } else {
+   rc = security_transition_sid(
+   _state, tsec->sid, tsec->sid,
+   isec->sclass, name, >sid);
+   if (rc)
+   return rc;
+   }
+
+   /*
+* Now that we've initialized security, check whether we're
+* allowed to actually create this type of anonymous inode.
+*/
+
+   ad.type = LSM_AUDIT_DATA_INODE;
+   ad.u.inode = inode;
+
+   return avc_has_perm(_state,
+   tsec->sid,
+   isec->sid,
+   isec->sclass,
+   ANON_INODE__CREATE,
+   );
+}
+
 static int selinux_inode_create(struct inode *dir, struct dentry *dentry, 
umode_t mode)
 {
return may_create(dir, dentry, SECCLASS_FILE);
@@ -7000,6 +7057,7 @@ static struct security_hook_list selinux_hooks[] 
__lsm_ro_after_init = {
 
LSM_HOOK_INIT(inode_free_security, selinux_inode_free_security),
LSM_HOOK_INIT(inode_init_security, selinux_inode_init_security),
+   LSM_HOOK_INIT(inode_init_security_anon, 
selinux_inode_init_security_anon),
LSM_HOOK_INIT(inode_create, selinux_inode_create),
LSM_HOOK_INIT(inode_link, selinux_inode_link),
LSM_HOOK_INIT(inode_unlink, selinux_inode_unlink),
diff --git a/security/selinux/include/classmap.h 
b/security/selinux/include/classmap.h
index 40cebde62856..ba2e01a6955c 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -249,6 +249,8 @@ struct security_class_mapping secclass_map[] = {
  {"open", "cpu", "kernel", "tracepoint", "read", "write"} },
{ "lockdown",
  { "integrity", "confidentiality", NULL } },
+   { "anon_inode",
+ { COMMON_FILE_PERMS, NULL } },
{ NULL }
   };
 
-- 
2.30.0.284.gd98b1dd5eaa7-goog

[PATCH v14 0/4] SELinux support for anonymous inodes and UFFD

Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor.  SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.

With SELinux managed userfaultfd, an admin can control creation and
movement of the file descriptors. In particular, handling of
a userfaultfd descriptor by a different process is essentially a
ptrace access into the process, without any of the corresponding
security_ptrace_access_check() checks. For privacy, the admin may
want to deny such accesses, which is possible with SELinux support.

Inside the kernel, a new anon_inode interface, anon_inode_getfd_secure,
allows callers to opt into this SELinux management. In this new "secure"
mode, anon_inodes create new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.

This patch series is one of two fork of [1] and is an
alternative to [2].

The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.

I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.

The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].

This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.

Changes from the first version of the patch:

  - Removed some error checks
  - Defined a new anon_inode SELinux class to resolve the
ambiguity in [3]
  - Inherit sclass as well as descriptor from context inode

Changes from the second version of the patch:

  - Fixed example policy in the commit message to reflect the use of
the new anon_inode class.

Changes from the third version of the patch:

  - Dropped the fops parameter to the LSM hook
  - Documented hook parameters
  - Fixed incorrect class used for SELinux transition
  - Removed stray UFFD changed early in the series
  - Removed a redundant ERR_PTR(PTR_ERR())

Changes from the fourth version of the patch:

  - Removed an unused parameter from an internal function
  - Fixed function documentation

Changes from the fifth version of the patch:

  - Fixed function documentation in fs/anon_inodes.c and
include/linux/lsm_hooks.h
  - Used anon_inode_getfd_secure() in userfaultfd() syscall and removed
owner from userfaultfd_ctx.

Changes from the sixth version of the patch:

  - Removed definition of anon_inode_getfile_secure() as there are no
callers.
  - Simplified function description of anon_inode_getfd_secure().
  - Elaborated more on the purpose of 'context_inode' in commit message.

Changes from the seventh version of the patch:

  - Fixed error handling in _anon_inode_getfile().
  - Fixed minor comment and indentation related issues.

Changes from the eighth version of the patch:

  - Replaced selinux_state.initialized with selinux_state.initialized

Changes from the ninth version of the patch:

  - Fixed function names in fs/anon_inodes.c
  - Fixed comment of anon_inode_getfd_secure()
  - Fixed name of the patch wherein userfaultfd code uses
anon_inode_getfd_secure()

Changes from the tenth version of the patch:

  - Split first patch into VFS and LSM specific patches
  - Fixed comments in fs/anon_inodes.c
  - Fixed comment of alloc_anon_inode()

Changes from the eleventh version of the patch:

  - Removed comment of alloc_anon_inode() for consistency with the code
  - Fixed explanation of LSM hook in the commit message

Changes from the twelfth version of the patch:
  - Replaced FILE__CREATE with ANON_INODE__CREATE while initializing
anon-inode's SELinux security struct.
  - Check context_inode's SELinux label and return -EACCES if

[PATCH v14 1/4] security: add inode_init_security_anon() LSM hook

This change adds a new LSM hook, inode_init_security_anon(), that will
be used while creating secure anonymous inodes. The hook allows/denies
its creation and assigns a security context to the inode.

The new hook accepts an optional context_inode parameter that callers
can use to provide additional contextual information to security modules
for granting/denying permission to create an anon-inode of the same type.
This context_inode's security_context can also be used to initialize the
newly created anon-inode's security_context.

Signed-off-by: Lokesh Gidra 
Reviewed-by: Eric Biggers 
---
 include/linux/lsm_hook_defs.h |  2 ++
 include/linux/lsm_hooks.h |  9 +
 include/linux/security.h  | 10 ++
 security/security.c   |  8 
 4 files changed, 29 insertions(+)

diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 7aaa753b8608..dfd261dcbcb0 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -113,6 +113,8 @@ LSM_HOOK(void, LSM_RET_VOID, inode_free_security, struct 
inode *inode)
 LSM_HOOK(int, 0, inode_init_security, struct inode *inode,
 struct inode *dir, const struct qstr *qstr, const char **name,
 void **value, size_t *len)
+LSM_HOOK(int, 0, inode_init_security_anon, struct inode *inode,
+const struct qstr *name, const struct inode *context_inode)
 LSM_HOOK(int, 0, inode_create, struct inode *dir, struct dentry *dentry,
 umode_t mode)
 LSM_HOOK(int, 0, inode_link, struct dentry *old_dentry, struct inode *dir,
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index a19adef1f088..bdfc8a76a4f7 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -233,6 +233,15 @@
  * Returns 0 if @name and @value have been successfully set,
  * -EOPNOTSUPP if no security attribute is needed, or
  * -ENOMEM on memory allocation failure.
+ * @inode_init_security_anon:
+ *  Set up the incore security field for the new anonymous inode
+ *  and return whether the inode creation is permitted by the security
+ *  module or not.
+ *  @inode contains the inode structure
+ *  @name name of the anonymous inode class
+ *  @context_inode optional related inode
+ * Returns 0 on success, -EACCES if the security module denies the
+ * creation of this inode, or another -errno upon other errors.
  * @inode_create:
  * Check permission to create a regular file.
  * @dir contains inode structure of the parent of the new file.
diff --git a/include/linux/security.h b/include/linux/security.h
index c35ea0ffccd9..b0d14f04b16d 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -324,6 +324,9 @@ void security_inode_free(struct inode *inode);
 int security_inode_init_security(struct inode *inode, struct inode *dir,
 const struct qstr *qstr,
 initxattrs initxattrs, void *fs_data);
+int security_inode_init_security_anon(struct inode *inode,
+ const struct qstr *name,
+ const struct inode *context_inode);
 int security_old_inode_init_security(struct inode *inode, struct inode *dir,
 const struct qstr *qstr, const char **name,
 void **value, size_t *len);
@@ -738,6 +741,13 @@ static inline int security_inode_init_security(struct 
inode *inode,
return 0;
 }
 
+static inline int security_inode_init_security_anon(struct inode *inode,
+   const struct qstr *name,
+   const struct inode 
*context_inode)
+{
+   return 0;
+}
+
 static inline int security_old_inode_init_security(struct inode *inode,
   struct inode *dir,
   const struct qstr *qstr,
diff --git a/security/security.c b/security/security.c
index 7b09cfbae94f..401663b5b70e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1059,6 +1059,14 @@ int security_inode_init_security(struct inode *inode, 
struct inode *dir,
 }
 EXPORT_SYMBOL(security_inode_init_security);
 
+int security_inode_init_security_anon(struct inode *inode,
+ const struct qstr *name,
+ const struct inode *context_inode)
+{
+   return call_int_hook(inode_init_security_anon, 0, inode, name,
+context_inode);
+}
+
 int security_old_inode_init_security(struct inode *inode, struct inode *dir,
 const struct qstr *qstr, const char **name,
 void **value, size_t *len)
-- 
2.30.0.284.gd98b1dd5eaa7-goog

Re: [PATCH v7 net-next 2/2] net: dsa: qca: ar9331: export stats64

2021-01-07 Thread Oleksij Rempel

On Thu, Jan 07, 2021 at 03:36:45PM +0100, Andrew Lunn wrote:
> > +static void ar9331_get_stats64(struct dsa_switch *ds, int port,
> > +  struct rtnl_link_stats64 *s)
> > +{
> > +   struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> > +   struct ar9331_sw_port *p = >port[port];
> > +
> > +   spin_lock(>stats_lock);
> > +   memcpy(s, >stats, sizeof(*s));
> > +   spin_unlock(>stats_lock);
> > +}
> 
> This should probably wait until Vladimir's changes for stat64 are
> merged, so this call can sleep. You can then return up to date
> statistics.

Ack, no problem. Beside, i forgot to collect all the Reviewed-by tags.
Will resend all needed changes after Vladimirs patches are accepted.
May be the "net: dsa: add optional stats64 support" can already be
taken?

Regards,
Oleksij
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] fs: process fput task_work with TWA_SIGNAL

On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
> Song reported a boot regression in a kvm image with 5.11-rc, and bisected
> it down to the below patch. Debugging this issue, turns out that the boot
> stalled when a task is waiting on a pipe being released. As we no longer
> run task_work from get_signal() unless it's queued with TWA_SIGNAL, the
> task goes idle without running the task_work. This prevents ->release()
> from being called on the pipe, which another boot task is waiting on.
> 
> Use TWA_SIGNAL for the file fput work to ensure it's run before the task
> goes idle.
> 
> Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK")
> Reported-by: Song Liu 
> Signed-off-by: Jens Axboe 
> 
> ---
> 
> The other alternative here is obviously to re-instate the:
> 
> if (unlikely(current->task_works))
>   task_work_run();
> 
> in get_signal() that we had before this change. Might be safer in case
> there are other cases that need to ensure the work is run in a timely
> fashion, though I do think it's cleaner to long term to correctly mark
> task_work with the needed notification type. Comments welcome...

Interesting...  I think I've missed the discussion of that thing; could
you forward the relevant thread my way or give an archive link to it?

Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

2021-01-07 Thread Vineet Gupta


On 1/7/21 7:48 PM, Sergey Senozhatsky wrote:

On (21/01/07 09:58), Vineet Gupta wrote:

On 1/7/21 9:04 AM, Petr Mladek wrote:

On Thu 2021-01-07 08:43:16, Vineet Gupta wrote:

Hi John,

On 1/7/21 1:02 AM, John Ogness wrote:

Hi Vineet,

On 2021-01-06, Vineet Gupta  wrote:

This breaks ARC booting (no output on console).


Could you provide the kernel boot arguments that you use? This series is
partly about addressing users that have used boot arguments that are
technically incorrect (even if had worked). Seeing the boot arguments of
users that are not experiencing problems may help to reveal some of the
unusual console usages until now.



Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8
console=ttyS0,115200n8 debug print-fatal-signals=1


This is strange, the problematic patch should use ttynull
only as a fallback. It should not be used when a particular console
is defined on the command line.


What happens in my case is console_on_rootfs() doesn't find /dev/console and
switching to ttynull. /dev is not present because devtmpfs doesn't automount
for initramfs.


I wonder if we'll move the nulltty fallback logic into printk code [1]
will it fix the problem?

[1] https://lore.kernel.org/lkml/X6x%2FAxD1qanC6evJ@jagdpanzerIV.localdomain/


Your reasoning in the post above makes total sense.

I tired the patch: adding register_ttynull_console() call in 
console_device(), removing from console_on_rootfs() band that works too.



| Warning: unable to open an initial console. Fallback to ttynull.
| Warning: Failed to add ttynull console. No stdin, stdout, and stderr 
for the init process!

| Freeing unused kernel memory: 3096K
| This architecture does not have kernel memory protection.
| Run /init as init process
| with arguments:
|/init
|  with environment:
|HOME=/
|TERM=linux
| Starting System logger (syslogd)
| Bringing up loopback device
| Starting inetd
| Mounting Posix Mqueue filesys
| 
CONFIG_INITRAMFS_SOURCE="~/arc/RAMFS/archs/ramfs_2011-GNU-2020-03-glibc-2.32-tiny"

| **
|   Welcome to ARCLinux
| **
| [ARCLinux]#

[GIT PULL] Networking for 5.11-rc3

2021-01-07 Thread Jakub Kicinski

Hi!

Slightly lighter PR to get back into the Thu cadence.
The HighMem fixes not here yet, but I didn't think they
were urgent so no point delaying.

The following changes since commit f6e7a024bfe5e11d91ccff46bb576e3fb5a516ea:

  Merge tag 'arc-5.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2021-01-05 12:46:27 
-0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git 
tags/net-5.11-rc3-2

for you to fetch changes up to 220efcf9caf755bdf92892afd37484cb6859e0d2:

  Merge tag 'mlx5-fixes-2021-01-07' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2021-01-07 19:13:30 
-0800)


Networking fixes for 5.11-rc3 (part 2), including fixes from bpf and
can trees.

Current release - always broken:

 - can: mcp251xfd: fix Tx/Rx ring buffer driver race conditions

 - dsa: hellcreek: fix led_classdev build errors

Previous releases - regressions:

 - ipv6: fib: flush exceptions when purging route to avoid netdev
  reference leak

 - ip_tunnels: fix pmtu check in nopmtudisc mode

 - ip: always refragment ip defragmented packets to avoid MTU issues
   when forwarding through tunnels, correct "packet too big"
   message is prohibitively tricky to generate

 - s390/qeth: fix locking for discipline setup / removal and during
  recovery to prevent both deadlocks and races

 - mlx5: Use port_num 1 instead of 0 when delete a RoCE address

Previous releases - always broken:

 - cdc_ncm: correct overhead calculation in delayed_ndp_size to prevent
out of bound accesses with Huawei 909s-120 LTE module

 - stmmac: dwmac-sun8i: fix suspend/resume:
   - PHY being left powered off
   - MAC syscon configuration being reset
   - reference to the reset controller being improperly dropped

 - qrtr: fix null-ptr-deref in qrtr_ns_remove

 - can: tcan4x5x: fix bittiming const, use common bittiming from m_can
  driver

 - mlx5e: CT: Use per flow counter when CT flow accounting is enabled

 - mlx5e: Fix SWP offsets when vlan inserted by driver

Misc:

 - bpf: Fix a task_iter bug caused by a bpf -> net merge conflict
resolution

And the usual many fixes to various error paths.

Signed-off-by: Jakub Kicinski 


Alaa Hleihel (1):
  net/mlx5: E-Switch, fix changing vf VLANID

Alan Maguire (1):
  bpftool: Fix compilation failure for net.o with older glibc

Aleksander Jan Bajkowski (1):
  net: dsa: lantiq_gswip: Exclude RMII from modes that report 1 GbE

Arnd Bergmann (7):
  qed: select CONFIG_CRC32
  phy: dp83640: select CONFIG_CRC32
  can: kvaser_pciefd: select CONFIG_CRC32
  wil6210: select CONFIG_CRC32
  cfg80211: select CONFIG_CRC32
  misdn: dsp: select CONFIG_BITREVERSE
  wan: ds26522: select CONFIG_BITREVERSE

Aya Levin (2):
  net/mlx5e: Add missing capability check for uplink follow
  net/mlx5e: ethtool, Fix restriction of autoneg with 56G

Ayush Sawal (7):
  chtls: Fix hardware tid leak
  chtls: Remove invalid set_tcb call
  chtls: Fix panic when route to peer not configured
  chtls: Avoid unnecessary freeing of oreq pointer
  chtls: Replace skb_dequeue with skb_peek
  chtls: Added a check to avoid NULL pointer dereference
  chtls: Fix chtls resources release sequence

Christophe JAILLET (1):
  net/sonic: Fix some resource leaks in error handling paths

Colin Ian King (1):
  octeontx2-af: fix memory leak of lmac and lmac->name

David S. Miller (2):
  Merge branch 'stmmac-fixes'
  Merge branch 'hns3-fixes'

Dinghao Liu (2):
  net/mlx5e: Fix two double free cases
  net/mlx5e: Fix memleak in mlx5e_create_l2_table_groups

Florian Westphal (3):
  selftests: netfilter: add selftest for ipip pmtu discovery with enabled 
connection tracking
  net: fix pmtu check in nopmtudisc mode
  net: ip: always refragment ip defragmented packets

Ido Schimmel (3):
  nexthop: Fix off-by-one error in error path
  nexthop: Unlink nexthop group entry in error path
  selftests: fib_nexthops: Fix wrong mausezahn invocation

Jakub Kicinski (11):
  net: suggest L2 discards be counted towards rx_dropped
  net: vlan: avoid leaks on register_vlan_dev() failures
  docs: net: fix documentation on .ndo_get_stats
  net: bareudp: add missing error handling for bareudp_link_config()
  Merge tag 'linux-can-fixes-for-5.11-20210107' of 
git://git.kernel.org/.../mkl/linux-can
  Merge branch 'net-fix-netfilter-defrag-ip-tunnel-pmtu-blackhole'
  Merge https://git.kernel.org/.../bpf/bpf
  Merge branch 'bug-fixes-for-chtls-driver'
  Merge branch 'nexthop-various-fixes'
  Merge branch 's390-qeth-fixes-2021-01-07'
  Merge tag 'mlx5-fixes-2021-01-07' of git://git.kernel.org/.../saeed/linux

Jian She

linux-next: Tree for Jan 8

2021-01-07 Thread Stephen Rothwell

Hi all,

Changes since 20210107:

The net-next tree gained conflict against the net tree.

The drm tree gained a build failure so I used the version from
next-20210107.

The amdgpu tree gained conflict against Linus' tree and a build failure
so I used the version from next-20210107.

The drm-misc tree gained a build failure from merging the drm tree,
so I have used the version from next-20210107.

Non-merge commits (relative to Linus' tree): 1770
 1804 files changed, 62353 insertions(+), 28668 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 htmldocs. 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 330 trees (counting Linus' and 85 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 (f5e6c330254a Merge tag 'spi-fix-v5.11-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (9bba03d4473d kconfig: remove 'kvmconfig' and 
'xenconfig' shorthands)
Merging arc-current/for-curr (bb12433bf56e ARC: unbork 5.11 bootup: fix snafu 
in _TIF_NOTIFY_SIGNAL handling)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten 
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (462a1b17f8ef arm64: Move PSTATE.TCO setting 
to separate functions)
Merging arm-soc-fixes/arm/fixes (7887cc89d585 ARM: dts: ux500/golden: Set 
display max brightness)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (3ce47d95b734 powerpc: Handle 
.text.{hot,unlikely}.* in linker script)
Merging s390-fixes/fixes (129975e75b9a s390/Kconfig: sort config S390 select 
list once again)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (f3562f5e00bb docs: octeontx2: tune rst markup)
Merging bpf/master (6f02b540d759 bpftool: Fix compilation failure for net.o 
with older glibc)
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in 
xfrm_policy_addr_delta())
Merging netfilter/master (a8f33c038f4e Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (b4e70d8dd9ea netfilter: nftables: add set expression flags)
Merging wireless-drivers/master (bfe55584713b MAINTAINERS: switch to different 
email address)
Merging mac80211/master (3503ee6c0bec selftests: fix the return value for UDP 
GRO test)
Merging rdma-fixes/for-rc (e71ba9452f0b Linux 5.11-rc2)
Merging sound-current/for-linus (7b6227550723 Merge tag 'asoc-fix-v5.11-rc2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging sound-asoc-fixes/for-linus (abe845f315b9 Merge remote-tracking branch 
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (72962ebcdd45 Merge remote-tracking branch 
'regmap/for-5.11' into regmap-linus)
Merging regulator-fixes/for-linus (cd66a1589b7c Merge remote-tracking branch 
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (02b3446f68d5 Merge remote-tracking branch 
'spi/for-5.11' into spi-linus)
Merging pci-current/for-linus (e71ba9452f0b Linux 5.11-rc2)
Merging driver-core.current/driver-core-linus (e71ba9452f0b Lin

Re: [PATCH 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET

2021-01-07 Thread Yu-Hsuan Hsu

Mark Brown  於 2021年1月7日 週四 下午9:55寫道：
>
> On Thu, Jan 07, 2021 at 04:59:41PM +0800, Yu-Hsuan Hsu wrote:
> > Add the new command EC_CODEC_I2S_RX_RESET in ec_codec_i2s_rx_subcmd,
> > which is used for resetting the EC codec.
>
> I think the request was to sync over all the commands that are supported
> in the EC rather than just split this one addition into a separate
> patch.
Got it. However, after running make_linux_ec_commands_h.sh to create
the new cros_ec_commands.h, I found there are lots of difference (1092
insertions(+), 66 deletions(-)). In addition, there are also some
redefined variables(most are in ./include/linux/usb/pd.h) causing the
compile error.

It seems not easy to sync cros_ec_commands.h. I'm afraid of breaking
something. Does anyone have any suggestion? Thanks.

Re: [PATCH] crypto: omap-sham - Fix link error without crypto-engine

2021-01-07 Thread Herbert Xu

On Sun, Jan 03, 2021 at 03:03:04PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> The driver was converted to use the crypto engine helper
> but is missing the corresponding Kconfig statement to ensure
> it is available:
> 
> arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function 
> `omap_sham_probe':
> omap-sham.c:(.text+0x374): undefined reference to `crypto_engine_alloc_init'
> arm-linux-gnueabi-ld: omap-sham.c:(.text+0x384): undefined reference to 
> `crypto_engine_start'
> arm-linux-gnueabi-ld: omap-sham.c:(.text+0x510): undefined reference to 
> `crypto_engine_exit'
> arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function 
> `omap_sham_finish_req':
> omap-sham.c:(.text+0x98c): undefined reference to 
> `crypto_finalize_hash_request'
> arm-linux-gnueabi-ld: omap-sham.c:(.text+0x9a0): undefined reference to 
> `crypto_transfer_hash_request_to_engine'
> arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function 
> `omap_sham_update':
> omap-sham.c:(.text+0xf24): undefined reference to 
> `crypto_transfer_hash_request_to_engine'
> arm-linux-gnueabi-ld: drivers/crypto/omap-sham.o: in function 
> `omap_sham_final':
> omap-sham.c:(.text+0x1020): undefined reference to 
> `crypto_transfer_hash_request_to_engine'
> 
> Fixes: 133c3d434d91 ("crypto: omap-sham - convert to use crypto engine")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/crypto/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v4] power: suspend: Move dpm_watchdog to suspend.c and enhance it

2021-01-07 Thread Joseph Jang

Since dpm_watchdog just cover two functions __device_suspend() and
device_resume(), we proposed to move it to core power suspend.c to extend
its coverage and monitor more devices suspend hand issues.

We propose to use new name suspend watchdog and new timeout handler to
cover more sleep hang issues. The new timeout handler will dump disk
sleep task call trace at first round timeout and trigger kernel panic
at second round timeout.
The default timer for each round is defined in
CONFIG_PM_SUSPEND_WATCHDOG_TIMEOUT.

Signed-off-by: Joseph Jang 
---
Changes since v3:
 - Change the naming from sleep timer to suspend watchdog.
 - Remove console_is_suspended() from console.h and printk.c
 - Add static declaration for suspend_watchdog struct since we use it in 
suspend.c only.
 - Move suspend watchdog real logic to suspend_watchdog.c.
 - Put the function prototypes in suspend_watchdog.h
 - Use inline functions for function prototypes definition.

Changes since v2:
 - Add kernel/power/suspend_timer.h in MAINTAINERS
 - Share some corner cases that dpm_watchdog cannot cover.
  Case#A: dpm_watchdog cannot cover suspend hang in suspend_enter().
  File: kernel/power/suspend.c
  int suspend_devices_and_enter(suspend_state_t state)
  {
   ... 

 suspend_test_start();
 error = dpm_suspend_start(PMSG_SUSPEND);  <== dpm_watchdog will be 
enabled/disabled in this fucntion ...
 if (error) {
 pr_err("Some devices failed to suspend, or early wake event 
detected\n");
 goto Recover_platform;
 }
 suspend_test_finish("suspend devices");
 if (suspend_test(TEST_DEVICES))
 goto Recover_platform;

 do {
 error = suspend_enter(state, );  <== but we encounter 
hang inside function suspend_enter() ...
 } while (!error && !wakeup && platform_suspend_again(state));

  Case#B: dpm_watchdog cannot cover resume hang in dpm_resume_early() because 
it enable/disable in device_resume().
  Call trace:
   __switch_to+0x174/0x194
   __schedule+0xa60/0x1464
   __cancel_work_timer+0x120/0x234
   chg_pm_resume+0x2c/0xd8
   dpm_run_callback+0x27c/0x624
   device_resume_early+0x1e4/0x1f8
   dpm_resume_early+0x350/0x8f4
   suspend_devices_and_enter+0xffc/0x168c
   pm_suspend+0xb54/0xdac

  File: drivers/base/power/main.c.
  static int device_resume(struct device *dev, pm_message_t state, bool async)
  if (!dpm_wait_for_superior(dev, async))
  goto Complete;
  
  dpm_watchdog_set(, dev);
  device_lock(dev);
  
  /*
   ... 
 
  Unlock:
  device_unlock(dev);
  dpm_watchdog_clear();

  Case#C: dpm_watchdog cannot cover suspend hang in ksys_sync().
   Call trace:
__switch_to+0x1b0/0x1cc
__schedule+0xac8/0x1314
io_schedule+0x94/0xc8
wait_on_page_bit+0x1f8/0x3a4
__filemap_fdatawait_range+0x134/0x150
sync_inodes_sb+0x368/0x584
sync_inodes_one_sb+0x18/0x24
iterate_supers+0x12c/0x2b8
ksys_sync+0x48/0x12c
enter_state+0x294/0x7bc
pm_suspend+0x164/0x2a8

 - Explain some enhancement by following.
  Q1: Why not use the existing one?
  struct dpm_watchdog {
  struct device   *dev;
  struct task_struct  *tsk;
  struct timer_list   timer;
  };
  
  A1: In kernel/power/suspend.c, we don't have "struct device " because 
suspend.c is for core PM instead of device PM.
  So we propose to use sleep_timer struct.
  
  struct sleep_timer {
  struct task_struct*tsk;
  struct timer_list timer;
  };
  
  
  Q2: Why not use stack memory for timer struct?
  static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
  {
  ...   
  timer_setup_on_stack(timer, dpm_watchdog_handler, 0);  <== dpm_watchdog 
use stack memory for timer struct.
  /* use same timeout value for both suspend and resume */
  timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT;
  add_timer(timer);
  }
  
  A2: dpm_watchdog use stack memory has limitation.
  It cannot support starting watchdog at end of function like s2idle_enter().
  We cannot use stack memory for this case because the timer struct will be 
free when go back to caller.
  
  File: kernel/power/suspend.c
  static void s2idle_enter(void)
{
  trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, 
true);
  
  +   stop_sleep_timer();
  +
  raw_spin_lock_irq(_lock);
  if (pm_wakeup_pending())
  goto out;
  ... 
  s2idle_state = S2IDLE_STATE_NONE;
  raw_spin_unlock_irq(_lock);
  
  +   start_sleep_timer();
  +
  trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, 
false);
}
  
  So we propose to declare a global sleep timer struct in suspend.c like 
following.
  
  File: kernel/power/suspend.c
   static DEFINE_RAW_SPINLOCK(s2idle_lock);
   
  +DECLARE_SLEEP_TIMER(st);
  +
   /**
* pm_suspend_default_s2idle - Check if suspend-to-idle is the default

Re: [PATCH v2] crypto: Fix divide error in do_xor_speed()

2021-01-07 Thread Herbert Xu

On Tue, Jan 05, 2021 at 01:24:18PM -0800, Doug Anderson wrote:
>
> ...so while I think your fix will avoid the crash and could land as a
> stopgap, it's a sign that we need to run more repetitions on your
> particular setup to get accurate timings.  Your patch will probably
> cause it to just randomly pick one of the implementations.

We can always do a follow-up patch.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: Fix divide error in do_xor_speed()

2021-01-07 Thread Herbert Xu

On Thu, Dec 31, 2020 at 12:33:18AM +0300, Kirill Tkhai wrote:
> crypto: Fix divide error in do_xor_speed()
> 
> From: Kirill Tkhai 
> 
> Latest (but not only latest) linux-next panics with divide
> error on my QEMU setup.
> 
> The patch at the bottom of this message fixes the problem.
> 
> xor: measuring software checksum speed
> divide error:  [#1] PREEMPT SMP KASAN
> PREEMPT SMP KASAN
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.10.0-next-20201223+ #2177
> RIP: 0010:do_xor_speed+0xbb/0xf3
> Code: 41 ff cc 75 b5 bf 01 00 00 00 e8 3d 23 8b fe 65 8b 05 f6 49 83 7d 85 c0 
> 75 05 e8
>  84 70 81 fe b8 00 00 50 c3 31 d2 48 8d 7b 10  f5 41 89 c4 e8 58 07 a2 fe 
> 44 89 63 10 48 8d 7b 08
>  e8 cb 07 a2
> RSP: :888100137dc8 EFLAGS: 00010246
> RAX: c350 RBX: 823f0160 RCX: 
> RDX:  RSI: 0808 RDI: 823f0170
> RBP:  R08: 8109c50f R09: 824bb6f7
> R10: fbfff04976de R11: 0001 R12: 
> R13: 888101997000 R14: 888101994000 R15: 823f0178
> FS:  () GS:8881f778() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0220e000 CR4: 06a0
> Call Trace:
>  calibrate_xor_blocks+0x13c/0x1c4
>  ? do_xor_speed+0xf3/0xf3
>  do_one_initcall+0xc1/0x1b7
>  ? start_kernel+0x373/0x373
>  ? unpoison_range+0x3a/0x60
>  kernel_init_freeable+0x1dd/0x238
>  ? rest_init+0xc6/0xc6
>  kernel_init+0x8/0x10a
>  ret_from_fork+0x1f/0x30
> ---[ end trace 5bd3c1d0b2da ]---
> 
> Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
> Signed-off-by: Kirill Tkhai 
> Acked-by: Ard Biesheuvel 
> ---
> 
> v2: New Year resend :) Added fixes tag.
>  crypto/xor.c |2 ++
>  1 file changed, 2 insertions(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] of: property: Add device link support for interrupts

2021-01-07 Thread Saravana Kannan

On Thu, Jan 7, 2021 at 7:36 PM Rob Herring  wrote:
>
> On Thu, Jan 7, 2021 at 4:13 PM Saravana Kannan  wrote:
> >
> > On Thu, Jan 7, 2021 at 11:33 AM Rob Herring  wrote:
> > >
> > > On Thu, Jan 7, 2021 at 12:09 PM Saravana Kannan  
> > > wrote:
> > > >
> > > > On Thu, Jan 7, 2021 at 10:39 AM Rob Herring  wrote:
> > > > >
> > > > > On Wed, Jan 6, 2021 at 11:53 AM Saravana Kannan 
> > > > >  wrote:
> > > > > >
> > > > > > On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier  wrote:
> > > > > > >
> > > > > > > On Thu, 31 Dec 2020 21:12:40 +,
> > > > > > > Rob Herring  wrote:
> > > > > > > >
> > > > > > > > On Mon, Dec 21, 2020 at 09:30:45AM +, Marc Zyngier wrote:
> > > > > > > > > On 2020-12-18 21:07, Saravana Kannan wrote:
> > > > > > > > > > Add support for creating device links out of interrupts 
> > > > > > > > > > property.
> > > > > > > > > >
> > > > > > > > > > Cc: Marc Zyngier 
> > > > > > > > > > Cc: Kevin Hilman 
> > > > > > > > > > Signed-off-by: Saravana Kannan 
> > > > > > > > > > ---
> > > > > > > > > > Rob/Greg,
> > > > > > > > > >
> > > > > > > > > > This might need to go into driver-core to avoid conflict
> > > > > > > > > > due to fw_devlink refactor series that merged there.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Saravana
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >  drivers/of/property.c | 17 +
> > > > > > > > > >  1 file changed, 17 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > > > > > > index 5f9eed79a8aa..e56a5eae0a0b 100644
> > > > > > > > > > --- a/drivers/of/property.c
> > > > > > > > > > +++ b/drivers/of/property.c
> > > > > > > > > > @@ -1271,6 +1271,22 @@ static struct device_node
> > > > > > > > > > *parse_iommu_maps(struct device_node *np,
> > > > > > > > > >   return of_parse_phandle(np, prop_name, (index * 4) + 1);
> > > > > > > > > >  }
> > > > > > > > > >
> > > > > > > > > > +static struct device_node *parse_interrupts(struct 
> > > > > > > > > > device_node *np,
> > > > > > > > > > + const char 
> > > > > > > > > > *prop_name, int index)
> > > > > > > > > > +{
> > > > > > > > > > + struct device_node *sup;
> > > > > > > > > > +
> > > > > > > > > > + if (strcmp(prop_name, "interrupts") || index)
> > > > > > > > > > + return NULL;
> > > > > > > > > > +
> > > > > > > > > > + of_node_get(np);
> > > > > > > > > > + while (np && !(sup = of_parse_phandle(np, 
> > > > > > > > > > "interrupt-parent", 0)))
> > > > > > > > > > + np = of_get_next_parent(np);
> > > > > > > > > > + of_node_put(np);
> > > > > > > > > > +
> > > > > > > > > > + return sup;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > >  static const struct supplier_bindings 
> > > > > > > > > > of_supplier_bindings[] = {
> > > > > > > > > >   { .parse_prop = parse_clocks, },
> > > > > > > > > >   { .parse_prop = parse_interconnects, },
> > > > > > > > > > @@ -1296,6 +1312,7 @@ static const struct supplier_bindings
> > > > > > > > > > of_supplier_bindings[] = {
> > > > > > > > > >   { .parse_prop = parse_pinctrl6, },
> > > > > > > > > >   { .parse_prop = parse_pinctrl7, },
> > > > > > > > > >   { .parse_prop = parse_pinctrl8, },
> > > > > > > > > > + { .parse_prop = parse_interrupts, },
> > > > > > > > > >   { .parse_prop = parse_regulators, },
> > > > > > > > > >   { .parse_prop = parse_gpio, },
> > > > > > > > > >   { .parse_prop = parse_gpios, },
> > > > > > > > >
> > > > > > > > > You don't really describe what this is for so I'm only 
> > > > > > > > > guessing
> > > > > > > > > from the context. If you want to follow the interrupt 
> > > > > > > > > hierarchy,
> > > > > > > > > "interrupt-parent" isn't enough. You also need to track
> > > > > > > > > things like interrupt-map, or anything that carries a phandle
> > > > > > > > > to an interrupt controller.
> > > > > > > >
> > > > > > > > We don't need to follow the hierarchy, we just need the 
> > > > > > > > immediate
> > > > > > > > dependencies.
> > > > > > >
> > > > > > > Indeed. I also wonder why this isn't just a irq_find_parent() 
> > > > > > > call, TBH.
> > > > > >
> > > > > > Thanks Rob for explaining it.
> > > > > >
> > > > > > Marc, I wasn't sure if Rob would be okay with including of_irq.h 
> > > > > > here.
> > > > > > Also, I'm trying to keep of/property.c independent of the framework
> > > > > > code for now. The long term goal is to see if I can move out most of
> > > > > > this into the frameworks. But I want to do that after I sort of some
> > > > > > of the larger problems (like getting fw_devlink=on to work on all
> > > > > > devices  first). Let me know if you have a strong preference for 
> > > > > > right
> > > > > > now, if not, I'd rather keep property.c independent for now.
> > > > > >
> > > > > > I wasn't aware of interrupt-map until a few weeks ago and didn't 
> > > > > > know
> > > > > > it carried phandles. I can add support for that

Re: [PATCH] mpt3sas: fix spelling mistake in Kconfig: "compatiblity" -> "compatibility"

On Thu, 17 Dec 2020 17:20:19 +, Colin King wrote:

> There is a spelling mistake in the Kconfig help text. Fix it.

Applied to 5.11/scsi-fixes, thanks!

[1/1] mpt3sas: fix spelling mistake in Kconfig: "compatiblity" -> 
"compatibility"
  https://git.kernel.org/mkp/scsi/c/39718fe7adb1

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH V2] docs: ABI: sysfs-driver-ufs: Add DeepSleep power mode

On Mon, 4 Jan 2021 17:50:26 +0200, Adrian Hunter wrote:

> Update sysfs documentation for addition of DeepSleep power mode.

Applied to 5.11/scsi-fixes, thanks!

[1/1] docs: ABI: sysfs-driver-ufs: Add DeepSleep power mode
  https://git.kernel.org/mkp/scsi/c/0b2894cd0fdf

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2 0/2] scsi: ufs: Fix power drain and hci quirk for WriteBooster

On Tue, 22 Dec 2020 15:29:03 +0800, Stanley Chu wrote:

> This series fixes two WriteBooster issues,
> 1. Fix a corner case that device flush capability is not disabled during 
> system suspend
> 2. Fix the checking of UFSHCI quirk UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
> 
> Stanley Chu (2):
>   scsi: ufs: Fix possible power drain during system suspend
>   scsi: ufs: Relax the condition of
> UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
> 
> [...]

Applied to 5.11/scsi-fixes, thanks!

[1/2] scsi: ufs: Fix possible power drain during system suspend
  https://git.kernel.org/mkp/scsi/c/1d53864c3617
[2/2] scsi: ufs: Relax the condition of UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL
  https://git.kernel.org/mkp/scsi/c/21acf4601cc6

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle

On Wed, 6 Jan 2021 14:37:21 -0600, Tyrel Datwyler wrote:

> Commit 2aa0102c6688 ("scsi: ibmvfc: Use correlation token to tag
> commands") sets the vfcFrame correlation token to the pointer handle of
> the associated ibmvfc_event. However, that commit failed to cast the
> pointer to an appropriate type which in this case is a u64. As such
> sparse warnings are generated for both correlation token assignments.
> 
>  ibmvfc.c:2375:36: sparse: incorrect type in argument 1 (different base types)
>  ibmvfc.c:2375:36: sparse: expected unsigned long long [usertype] val
>  ibmvfc.c:2375:36: sparse: got struct ibmvfc_event *[assigned] evt
> 
> [...]

Applied to 5.11/scsi-fixes, thanks!

[1/1] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle
  https://git.kernel.org/mkp/scsi/c/901d01c8e50c

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v5 0/2] Two UFS fixes

On Thu, 7 Jan 2021 10:53:14 -0800, Jaegeuk Kim wrote:

> Change log from v4:
>  - remove RESERVE tag for tm command
>  - remove waiting IOs and let full reset handle it
>  - avoid verbose error log which causes cpu lock up

Applied to 5.11/scsi-fixes, thanks!

[1/2] scsi: ufs: fix livelock of ufshcd_clear_ua_wluns
  https://git.kernel.org/mkp/scsi/c/4ee7ee530bc2
[2/2] scsi: ufs: fix tm request correctly when non-fatal error happens
  https://git.kernel.org/mkp/scsi/c/eeb1b55b6e25

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: ufs: ufshcd-pltfrm depends on HAS_IOMEM

On Tue, 5 Jan 2021 20:08:22 -0800, Randy Dunlap wrote:

> Building ufshcd-pltfrm.c on arch/s390/ has a linker error since
> S390 does not support IOMEM, so add a dependency on HAS_IOMEM.
> 
> s390-linux-ld: drivers/scsi/ufs/ufshcd-pltfrm.o: in function 
> `ufshcd_pltfrm_init':
> ufshcd-pltfrm.c:(.text+0x38e): undefined reference to 
> `devm_platform_ioremap_resource'
> 
> where that devm_ function is inside an #ifdef CONFIG_HAS_IOMEM/#endif block.

Applied to 5.11/scsi-fixes, thanks!

[1/1] scsi: ufs: ufshcd-pltfrm depends on HAS_IOMEM
  https://git.kernel.org/mkp/scsi/c/5e6ddadf7637

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression

On Tue, 5 Jan 2021 00:41:04 +0100, Arnd Bergmann wrote:

> Phil Oester reported that a fix for a possible buffer overrun that I
> sent caused a regression that manifests in this output:
> 
>  Event Message: A PCI parity error was detected on a component at bus 0 
> device 5 function 0.
>  Severity: Critical
>  Message ID: PCI1308
> 
> [...]

Applied to 5.11/scsi-fixes, thanks!

[1/1] scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression
  https://git.kernel.org/mkp/scsi/c/b112036535ed

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback

On Mon, 28 Dec 2020 04:04:36 -0800, Can Guo wrote:

> Users can initiate resets to specific SCSI device/target/host through
> IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host
> _reset_handler() callbacks is initialized with a request whose tag is -1.
> So, in this case, it is not right for eh_device_reset_handler() callback
> to count on the lun get from hba->lrb[-1]. Fix it by getting lun from the
> SCSI device associated with the SCSI cmd.

Applied to 5.11/scsi-fixes, thanks!

[1/1] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback
  https://git.kernel.org/mkp/scsi/c/35fc4cd34426

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] scsi: sd: remove obsolete variable in sd_remove()

On Mon, 14 Dec 2020 10:54:24 +0100, Lukas Bulwahn wrote:

> Commit 140ea3bbf39a ("sd: use __register_blkdev to avoid a modprobe for an
> unregistered dev_t") removed blk_register_region(devt, ...) in sd_remove()
> and since then, devt is unused in sd_remove().
> 
> Hence, make W=1 warns:
> 
>   drivers/scsi/sd.c:3516:8:
>   warning: variable 'devt' set but not used [-Wunused-but-set-variable]
> 
> [...]

Applied to 5.11/scsi-fixes, thanks!

[1/1] scsi: sd: remove obsolete variable in sd_remove()
  https://git.kernel.org/mkp/scsi/c/be2553358cd4

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] [v2] scsi: scsi_debug: Fix memleak in scsi_debug_init