[PATCH 09/11] phy: phy-mtk-tphy: remove unused u3phya_ref clock
The u3phya_ref clock is already moved into sub-node, and
renamed as ref clock, no used anymore now, so remove it,
this can avoid confusion when support new platforms
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-tphy.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 96c62e3a3300..c6424fd2a06d 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -312,8 +312,6 @@ struct mtk_phy_instance {
struct mtk_tphy {
struct device *dev;
void __iomem *sif_base; /* only shared sif */
- /* deprecated, use @ref_clk instead in phy instance */
- struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mtk_phy_pdata *pdata;
struct mtk_phy_instance **phys;
int nphys;
@@ -921,12 +919,6 @@ static int mtk_phy_init(struct phy *phy)
struct mtk_tphy *tphy = dev_get_drvdata(phy->dev.parent);
int ret;
- ret = clk_prepare_enable(tphy->u3phya_ref);
- if (ret) {
- dev_err(tphy->dev, "failed to enable u3phya_ref\n");
- return ret;
- }
-
ret = clk_prepare_enable(instance->ref_clk);
if (ret) {
dev_err(tphy->dev, "failed to enable ref_clk\n");
@@ -992,7 +984,6 @@ static int mtk_phy_exit(struct phy *phy)
u2_phy_instance_exit(tphy, instance);
clk_disable_unprepare(instance->ref_clk);
- clk_disable_unprepare(tphy->u3phya_ref);
return 0;
}
@@ -1127,11 +1118,6 @@ static int mtk_tphy_probe(struct platform_device *pdev)
}
}
- /* it's deprecated, make it optional for backward compatibility */
- tphy->u3phya_ref = devm_clk_get_optional(dev, "u3phya_ref");
- if (IS_ERR(tphy->u3phya_ref))
- return PTR_ERR(tphy->u3phya_ref);
-
tphy->src_ref_clk = U3P_REF_CLK;
tphy->src_coef = U3P_SLEW_RATE_COEF;
/* update parameters of slew rate calibrate if exist */
@@ -1178,10 +1164,6 @@ static int mtk_tphy_probe(struct platform_device *pdev)
phy_set_drvdata(phy, instance);
port++;
- /* if deprecated clock is provided, ignore instance's one */
- if (tphy->u3phya_ref)
- continue;
-
instance->ref_clk = devm_clk_get_optional(&phy->dev, "ref");
if (IS_ERR(instance->ref_clk)) {
dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
--
2.23.0
[PATCH 04/11] dt-bindings: phy-mtk-tphy: add a new reference clock
Usually the digital and anolog phys use the same reference clock, but on some platforms, they are separated, so add another optional clock to support it. In order to keep the clock names consistent with PHY IP's, use the da_ref for anolog phy and ref clock for digital phy. Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index dbc143ed5999..ed9a2641f204 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -41,9 +41,12 @@ Optional properties (PHY_TYPE_USB2 port (child) node): - clocks : a list of phandle + clock-specifier pairs, one for each entry in clock-names - clock-names : may contain - "ref": 48M reference clock for HighSpeed anolog phy; and 26M - reference clock for SuperSpeed anolog phy, sometimes is + "ref": 48M reference clock for HighSpeed (digital) phy; and 26M + reference clock for SuperSpeed (digital) phy, sometimes is 24M, 25M or 27M, depended on platform. + "da_ref": the reference clock of anolog phy, used if the clocks + of anolog and digital phys are separated, otherwise uses + "ref" clock only if need. - mediatek,eye-src : u32, the value of slew rate calibrate - mediatek,eye-vrt : u32, the selection of VRT reference voltage -- 2.23.0
[PATCH 08/11] phy: phy-mtk-tphy: make the ref clock optional
Sometimes the reference clock of USB3 PHY comes from oscillator
directly, and no need refer to a fixed-clock in DTS anymore
if make it optional.
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-tphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 4a2dc92f10f5..96c62e3a3300 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1182,7 +1182,7 @@ static int mtk_tphy_probe(struct platform_device *pdev)
if (tphy->u3phya_ref)
continue;
- instance->ref_clk = devm_clk_get(&phy->dev, "ref");
+ instance->ref_clk = devm_clk_get_optional(&phy->dev, "ref");
if (IS_ERR(instance->ref_clk)) {
dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
retval = PTR_ERR(instance->ref_clk);
--
2.23.0
[PATCH 06/11] phy: phy-mtk-tphy: add a property for disconnect threshold
This is used to tune the threshold of disconnect
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-tphy.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index cb2ed3b25068..5afe33621dbc 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -60,6 +60,8 @@
#define U3P_USBPHYACR6 0x018
#define PA6_RG_U2_BC11_SW_EN BIT(23)
#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20)
+#define PA6_RG_U2_DISCTH GENMASK(7, 4)
+#define PA6_RG_U2_DISCTH_VAL(x)((0xf & (x)) << 4)
#define PA6_RG_U2_SQTH GENMASK(3, 0)
#define PA6_RG_U2_SQTH_VAL(x) (0xf & (x))
@@ -300,6 +302,7 @@ struct mtk_phy_instance {
int eye_src;
int eye_vrt;
int eye_term;
+ int discth;
bool bc12_en;
};
@@ -850,9 +853,12 @@ static void phy_parse_property(struct mtk_tphy *tphy,
&instance->eye_vrt);
device_property_read_u32(dev, "mediatek,eye-term",
&instance->eye_term);
- dev_dbg(dev, "bc12:%d, src:%d, vrt:%d, term:%d\n",
+ device_property_read_u32(dev, "mediatek,discth",
+&instance->discth);
+ dev_dbg(dev, "bc12:%d, src:%d, vrt:%d, term:%d, disc:%d\n",
instance->bc12_en, instance->eye_src,
- instance->eye_vrt, instance->eye_term);
+ instance->eye_vrt, instance->eye_term,
+ instance->discth);
}
static void u2_phy_props_set(struct mtk_tphy *tphy,
@@ -888,6 +894,13 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
tmp |= PA1_RG_TERM_SEL_VAL(instance->eye_term);
writel(tmp, com + U3P_USBPHYACR1);
}
+
+ if (instance->discth) {
+ tmp = readl(com + U3P_USBPHYACR6);
+ tmp &= ~PA6_RG_U2_DISCTH;
+ tmp |= PA6_RG_U2_DISCTH_VAL(instance->discth);
+ writel(tmp, com + U3P_USBPHYACR6);
+ }
}
static int mtk_phy_init(struct phy *phy)
--
2.23.0
[PATCH 02/11] dt-bindings: phy-mtk-tphy: make the ref clock optional
Make the ref clock optional, then we no need refer to a fixed-clock in DTS anymore when the clock of USB3 PHY comes from oscillator directly Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/phy/phy-mtk-tphy.txt| 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index d5b327f85fa2..1c18bf10b2fe 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -34,12 +34,6 @@ Optional properties (controller (parent) node): Required properties (port (child) node): - reg : address and length of the register set for the port. -- clocks : a list of phandle + clock-specifier pairs, one for each - entry in clock-names -- clock-names : must contain - "ref": 48M reference clock for HighSpeed analog phy; and 26M - reference clock for SuperSpeed analog phy, sometimes is - 24M, 25M or 27M, depended on platform. - #phy-cells : should be 1 (See second example) cell after port phandle is phy type from: - PHY_TYPE_USB2 @@ -48,6 +42,13 @@ Required properties (port (child) node): - PHY_TYPE_SATA Optional properties (PHY_TYPE_USB2 port (child) node): +- clocks : a list of phandle + clock-specifier pairs, one for each + entry in clock-names +- clock-names : may contain + "ref": 48M reference clock for HighSpeed anolog phy; and 26M + reference clock for SuperSpeed anolog phy, sometimes is + 24M, 25M or 27M, depended on platform. + - mediatek,eye-src : u32, the value of slew rate calibrate - mediatek,eye-vrt : u32, the selection of VRT reference voltage - mediatek,eye-term: u32, the selection of HS_TX TERM reference voltage -- 2.23.0
[PATCH 05/11] dt-bindings: phy-mtk-tphy: add the properties about address mapping
Add three required properties about the address mapping, including '#address-cells', '#size-cells' and 'ranges' Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index ed9a2641f204..e162af66741e 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -14,6 +14,16 @@ Required properties (controller (parent) node): make use of "mediatek,generic-tphy-v1" on mt2701 instead and "mediatek,generic-tphy-v2" on mt2712 instead. +- #address-cells: the number of cells used to represent physical + base addresses. +- #size-cells: the number of cells used to represent the size of an address. +- ranges: the address mapping relationship to the parent, defined with + - empty value: if optional 'reg' is used. + - non-empty value: if optional 'reg' is not used. should set + the child's base address to 0, the physical address + within parent's address space, and the length of + the address map. + Required nodes : a sub-node is required for each port the controller provides. Address range information including the usual 'reg' property is used inside these nodes to describe -- 2.23.0
[PATCH 01/11] dt-bindings: phy-mtk-tphy: add two optional properties for u2phy
Add two optional properties, one for J-K test, another for disconnect threshold, both of them can be used to debug disconnection issues. Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index a5f7a4f0dbc1..d5b327f85fa2 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -52,6 +52,8 @@ Optional properties (PHY_TYPE_USB2 port (child) node): - mediatek,eye-vrt : u32, the selection of VRT reference voltage - mediatek,eye-term: u32, the selection of HS_TX TERM reference voltage - mediatek,bc12: bool, enable BC12 of u2phy if support it +- mediatek,discth : u32, the voltage of disconnect threshold +- mediatek,intr: u32, the value of internal R (resistance) Example: -- 2.23.0
[PATCH 07/11] phy: phy-mtk-tphy: add a property for internal resistance
This is used to tune internal resistance for J-K test
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-tphy.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 5afe33621dbc..4a2dc92f10f5 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -43,6 +43,8 @@
#define PA0_RG_USB20_INTR_EN BIT(5)
#define U3P_USBPHYACR1 0x004
+#define PA1_RG_INTR_CALGENMASK(23, 19)
+#define PA1_RG_INTR_CAL_VAL(x) ((0x1f & (x)) << 19)
#define PA1_RG_VRT_SEL GENMASK(14, 12)
#define PA1_RG_VRT_SEL_VAL(x) ((0x7 & (x)) << 12)
#define PA1_RG_TERM_SELGENMASK(10, 8)
@@ -302,6 +304,7 @@ struct mtk_phy_instance {
int eye_src;
int eye_vrt;
int eye_term;
+ int intr;
int discth;
bool bc12_en;
};
@@ -853,12 +856,14 @@ static void phy_parse_property(struct mtk_tphy *tphy,
&instance->eye_vrt);
device_property_read_u32(dev, "mediatek,eye-term",
&instance->eye_term);
+ device_property_read_u32(dev, "mediatek,intr",
+&instance->intr);
device_property_read_u32(dev, "mediatek,discth",
&instance->discth);
- dev_dbg(dev, "bc12:%d, src:%d, vrt:%d, term:%d, disc:%d\n",
+ dev_dbg(dev, "bc12:%d, src:%d, vrt:%d, term:%d, intr:%d, disc:%d\n",
instance->bc12_en, instance->eye_src,
instance->eye_vrt, instance->eye_term,
- instance->discth);
+ instance->intr, instance->discth);
}
static void u2_phy_props_set(struct mtk_tphy *tphy,
@@ -895,6 +900,13 @@ static void u2_phy_props_set(struct mtk_tphy *tphy,
writel(tmp, com + U3P_USBPHYACR1);
}
+ if (instance->intr) {
+ tmp = readl(com + U3P_USBPHYACR1);
+ tmp &= ~PA1_RG_INTR_CAL;
+ tmp |= PA1_RG_INTR_CAL_VAL(instance->intr);
+ writel(tmp, com + U3P_USBPHYACR1);
+ }
+
if (instance->discth) {
tmp = readl(com + U3P_USBPHYACR6);
tmp &= ~PA6_RG_U2_DISCTH;
--
2.23.0
[PATCH 10/11] phy: phy-mtk-tphy: add a new reference clock
Usually the digital and anolog phys use the same reference clock,
but some platforms have two separate reference clocks for each of
them, so add another optional clock to support them.
In order to keep the clock names consistent with PHY IP's, change
the da_ref for anolog phy and ref clock for digital phy.
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-tphy.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c
b/drivers/phy/mediatek/phy-mtk-tphy.c
index c6424fd2a06d..237e2c3fd4dc 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -298,7 +298,8 @@ struct mtk_phy_instance {
struct u2phy_banks u2_banks;
struct u3phy_banks u3_banks;
};
- struct clk *ref_clk;/* reference clock of anolog phy */
+ struct clk *ref_clk;/* reference clock of (digital) phy */
+ struct clk *da_ref_clk; /* reference clock of anolog phy */
u32 index;
u8 type;
int eye_src;
@@ -925,6 +926,13 @@ static int mtk_phy_init(struct phy *phy)
return ret;
}
+ ret = clk_prepare_enable(instance->da_ref_clk);
+ if (ret) {
+ dev_err(tphy->dev, "failed to enable da_ref\n");
+ clk_disable_unprepare(instance->ref_clk);
+ return ret;
+ }
+
switch (instance->type) {
case PHY_TYPE_USB2:
u2_phy_instance_init(tphy, instance);
@@ -984,6 +992,7 @@ static int mtk_phy_exit(struct phy *phy)
u2_phy_instance_exit(tphy, instance);
clk_disable_unprepare(instance->ref_clk);
+ clk_disable_unprepare(instance->da_ref_clk);
return 0;
}
@@ -1170,6 +1179,14 @@ static int mtk_tphy_probe(struct platform_device *pdev)
retval = PTR_ERR(instance->ref_clk);
goto put_child;
}
+
+ instance->da_ref_clk =
+ devm_clk_get_optional(&phy->dev, "da_ref");
+ if (IS_ERR(instance->da_ref_clk)) {
+ dev_err(dev, "failed to get da_ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(instance->da_ref_clk);
+ goto put_child;
+ }
}
provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
--
2.23.0
[PATCH 03/11] dt-bindings: phy-mtk-tphy: remove unused u3phya_ref clock
The u3phya_ref clock is already moved into sub-node, and renamed as ref clock, no used anymore now, so remove it to avoid confusion Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt | 4 1 file changed, 4 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt index 1c18bf10b2fe..dbc143ed5999 100644 --- a/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt @@ -13,10 +13,6 @@ Required properties (controller (parent) node): "mediatek,mt8173-u3phy"; make use of "mediatek,generic-tphy-v1" on mt2701 instead and "mediatek,generic-tphy-v2" on mt2712 instead. - - clocks : (deprecated, use port's clocks instead) a list of phandle + - clock-specifier pairs, one for each entry in clock-names - - clock-names : (deprecated, use port's one instead) must contain - "u3phya_ref": for reference clock of usb3.0 analog phy. Required nodes : a sub-node is required for each port the controller provides. Address range information including the usual -- 2.23.0
[PATCH 11/11] arm64: dts: mt2712: use non-empty ranges for usb-phy
Use non-empty ranges for usb-phy to make the layout of
its registers clearer
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 36 +++
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 43307bad3f0d..37a6443b658e 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -698,29 +698,29 @@
u3phy0: usb-phy@1129 {
compatible = "mediatek,mt2712-u3phy";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x1129 0x9000>;
status = "okay";
- u2port0: usb-phy@1129 {
- reg = <0 0x1129 0 0x700>;
+ u2port0: usb-phy@0 {
+ reg = <0x0 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- u2port1: usb-phy@11298000 {
- reg = <0 0x11298000 0 0x700>;
+ u2port1: usb-phy@8000 {
+ reg = <0x8000 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- u3port0: usb-phy@11298700 {
- reg = <0 0x11298700 0 0x900>;
+ u3port0: usb-phy@8700 {
+ reg = <0x8700 0x900>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
@@ -761,29 +761,29 @@
u3phy1: usb-phy@112e {
compatible = "mediatek,mt2712-u3phy";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x112e 0x9000>;
status = "okay";
- u2port2: usb-phy@112e {
- reg = <0 0x112e 0 0x700>;
+ u2port2: usb-phy@0 {
+ reg = <0x0 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- u2port3: usb-phy@112e8000 {
- reg = <0 0x112e8000 0 0x700>;
+ u2port3: usb-phy@8000 {
+ reg = <0x8000 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- u3port1: usb-phy@112e8700 {
- reg = <0 0x112e8700 0 0x900>;
+ u3port1: usb-phy@8700 {
+ reg = <0x8700 0x900>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
--
2.23.0
[RESEND PATCH v2 11/14] arm64: dts: meson-g12a-x96-max: fix compatible
This fixes the following DT schemas check errors:
meson-g12a-x96-max.dt.yaml: /: compatible: ['amediatech,x96-max',
'amlogic,u200', 'amlogic,g12a'] is not valid under any of the given schemas
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
index c1e58a69d434..4770ecac3d85 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
@@ -11,7 +11,7 @@
#include
/ {
- compatible = "amediatech,x96-max", "amlogic,u200", "amlogic,g12a";
+ compatible = "amediatech,x96-max", "amlogic,g12a";
model = "Shenzhen Amediatech Technology Co., Ltd X96 Max";
aliases {
--
2.22.0
[RESEND PATCH v2 05/14] arm64: dts: meson-gx: fix watchdog compatible
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: watchdog@98d0: compatible:0:
'amlogic,meson-gx-wdt' is not one of ['amlogic,meson-gxbb-wdt']
meson-gxl-s805x-libretech-ac.dt.yaml: watchdog@98d0: compatible:0:
'amlogic,meson-gx-wdt' is not one of ['amlogic,meson-gxbb-wdt']
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 1c580f42e818..b3fe3268af3e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -325,7 +325,7 @@
};
watchdog@98d0 {
- compatible = "amlogic,meson-gx-wdt",
"amlogic,meson-gxbb-wdt";
+ compatible = "amlogic,meson-gxbb-wdt";
reg = <0x0 0x098d0 0x0 0x10>;
clocks = <&xtal>;
};
--
2.22.0
[RESEND PATCH v2 13/14] arm64: dts: meson-gxbb-p201: fix snps, reset-delays-us format
This fixes the following DT schemas check errors: meson-gxbb-p201.dt.yaml: ethernet@c941: snps,reset-delays-us: [[0, 1, 100]] is too short Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl --- arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts index 56e0dd1ff55c..150a82f3b2d7 100644 --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts @@ -21,6 +21,6 @@ phy-mode = "rmii"; snps,reset-gpio = <&gpio GPIOZ_14 0>; - snps,reset-delays-us = <0 1 100>; + snps,reset-delays-us = <0>, <1>, <100>; snps,reset-active-low; }; -- 2.22.0
[RESEND PATCH v2 10/14] arm64: dts: meson-g12a: fix reset controller compatible
This fixes the following DT schemas check errors:
meson-g12a-u200.dt.yaml: reset-controller@1004: compatible:0:
'amlogic,meson-g12a-reset' is not one of ['amlogic,meson8b-reset',
'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
meson-g12a-sei510.dt.yaml: reset-controller@1004: compatible:0:
'amlogic,meson-g12a-reset' is not one of ['amlogic,meson8b-reset',
'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 1a5efa2e16c5..d09c7a5cccb4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2187,8 +2187,7 @@
ranges = <0x0 0x0 0x0 0xffd0 0x0 0x10>;
reset: reset-controller@1004 {
- compatible = "amlogic,meson-g12a-reset",
-"amlogic,meson-axg-reset";
+ compatible = "amlogic,meson-axg-reset";
reg = <0x0 0x1004 0x0 0x9c>;
#reset-cells = <1>;
};
--
2.22.0
[RESEND PATCH v2 08/14] arm64: dts: meson-gxl: fix internal phy compatible
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: ethernet-phy@8: compatible:
['ethernet-phy-id0181.4400', 'ethernet-phy-ieee802.3-c22'] is not valid under
any of the given schemas
Signed-off-by: Neil Armstrong
Acked-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 7a3b674db11f..49ff0a7d0210 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -709,7 +709,7 @@
#size-cells = <0>;
internal_phy: ethernet-phy@8 {
- compatible = "ethernet-phy-id0181.4400",
"ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0181.4400";
interrupts = ;
reg = <8>;
max-speed = <100>;
--
2.22.0
[RESEND PATCH v2 09/14] arm64: dts: meson-axg: fix MHU compatible
This fixes the following DT schemas check errors:
meson-axg-s400.dt.yaml: mailbox@ff63c404: compatible:0: 'amlogic,meson-gx-mhu'
is not one of ['amlogic,meson-gxbb-mhu']
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index acc2feb8fd89..82919b106010 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1118,7 +1118,7 @@
};
mailbox: mailbox@ff63c404 {
- compatible = "amlogic,meson-gx-mhu",
"amlogic,meson-gxbb-mhu";
+ compatible = "amlogic,meson-gxbb-mhu";
reg = <0 0xff63c404 0 0x4c>;
interrupts = ,
,
--
2.22.0
[RESEND PATCH v2 07/14] arm64: dts: meson-gx: fix periphs bus node name
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: periphs@c8834000: $nodename:0: 'periphs@c8834000'
does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
meson-gxl-s805x-libretech-ac.dt.yaml: periphs@c8834000: $nodename:0:
'periphs@c8834000' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 74a2cdff0563..6733050d735f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -451,7 +451,7 @@
amlogic,canvas = <&canvas>;
};
- periphs: periphs@c8834000 {
+ periphs: bus@c8834000 {
compatible = "simple-bus";
reg = <0x0 0xc8834000 0x0 0x2000>;
#address-cells = <2>;
--
2.22.0
[RESEND PATCH v2 14/14] arm64: dts: meson: fix boards regulators states format
This fixes the following DT schemas check errors:
meson-gxbb-odroidc2.dt.yaml: gpio-regulator-tf_io: states:0: Additional items
are not allowed (180, 1 were unexpected)
meson-gxbb-odroidc2.dt.yaml: gpio-regulator-tf_io: states:0: [330, 0,
180, 1] is too long
meson-gxbb-nexbox-a95x.dt.yaml: gpio-regulator: states:0: Additional items are
not allowed (330, 1 were unexpected)
meson-gxbb-nexbox-a95x.dt.yaml: gpio-regulator: states:0: [180, 0, 330,
1] is too long
meson-gxbb-p200.dt.yaml: gpio-regulator: states:0: Additional items are not
allowed (330, 1 were unexpected)
meson-gxbb-p200.dt.yaml: gpio-regulator: states:0: [180, 0, 330, 1] is
too long
meson-gxl-s905x-hwacom-amazetv.dt.yaml: gpio-regulator: states:0: Additional
items are not allowed (330, 1 were unexpected)
meson-gxl-s905x-hwacom-amazetv.dt.yaml: gpio-regulator: states:0: [180, 0,
330, 1] is too long
meson-gxbb-p201.dt.yaml: gpio-regulator: states:0: Additional items are not
allowed (330, 1 were unexpected)
meson-gxbb-p201.dt.yaml: gpio-regulator: states:0: [180, 0, 330, 1] is
too long
meson-g12b-odroid-n2.dt.yaml: gpio-regulator-tf_io: states:0: Additional items
are not allowed (180, 1 were unexpected)
meson-g12b-odroid-n2.dt.yaml: gpio-regulator-tf_io: states:0: [330, 0,
180, 1] is too long
meson-gxl-s905x-nexbox-a95x.dt.yaml: gpio-regulator: states:0: Additional items
are not allowed (330, 1 were unexpected)
meson-gxl-s905x-nexbox-a95x.dt.yaml: gpio-regulator: states:0: [180, 0,
330, 1] is too long
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 ++--
.../arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 4 ++--
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 6cfc2c69bb4f..7c0cf510fd16 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -66,8 +66,8 @@
gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
- states = <330 0
- 180 1>;
+ states = <330 0>,
+<180 1>;
};
flash_1v8: regulator-flash_1v8 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index b636912a2715..afcf8a9f667b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -75,8 +75,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <180 0
- 330 1>;
+ states = <180 0>,
+<330 1>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 9972b1515da6..6039adda12ee 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -77,8 +77,8 @@
gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
gpios-states = <0>;
- states = <330 0
- 180 1>;
+ states = <330 0>,
+<180 1>;
};
vcc1v8: regulator-vcc1v8 {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index e8f925871edf..89f7b41b0e9e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -46,8 +46,8 @@
gpios-states = <1>;
/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
- states = <180 0
- 330 1>;
+ states = <180 0>,
+<330 1>;
regulator-settling-time-up-us = <1>;
regulator-settling-time-down-us = <15>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
index 796baea7a0bf..c8d74e61dec1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-hwacom-amazetv.dts
@@ -38,8 +38,8 @@
gpios-states = <1>;
[RESEND PATCH v2 12/14] arm64: dts: meson-gxbb-nanopi-k2: add missing model
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: /: 'model' is a required property
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
index c34c1c90ccb6..233eb1cd7967 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
@@ -10,6 +10,7 @@
/ {
compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb";
+ model = "FriendlyARM NanoPi K2";
aliases {
serial0 = &uart_AO;
--
2.22.0
[RESEND PATCH v2 02/14] arm64: dts: meson-gx: drop the vpu dmc memory cell
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: vpu@d010: reg-names: Additional items
are not allowed ('dmc' was unexpected)
meson-gxl-s805x-libretech-ac.dt.yaml: vpu@d010: reg-names: ['vpu', 'hhi',
'dmc'] is too long
The 'dmc' register area was replaced by the amlogic,canvas property
which was introduced in commit f1726043426c73 ("arm64: dts: meson-gx:
add dmcbus and canvas nodes.") and commit cf34287986d0b6 ("arm64: dts:
meson-gx: Add canvas provider node to the vpu")
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index f3ae5a3685f9..239ec08b3023 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -544,9 +544,8 @@
vpu: vpu@d010 {
compatible = "amlogic,meson-gx-vpu";
reg = <0x0 0xd010 0x0 0x10>,
- <0x0 0xc883c000 0x0 0x1000>,
- <0x0 0xc8838000 0x0 0x1000>;
- reg-names = "vpu", "hhi", "dmc";
+ <0x0 0xc883c000 0x0 0x1000>;
+ reg-names = "vpu", "hhi";
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
--
2.22.0
[RESEND PATCH v2 01/14] arm64: dts: meson: fix ethernet mac reg format
This fixes the following DT schemas check errors:
meson-axg-s400.dt.yaml: soc: ethernet@ff3f:reg:0: [0, 4282318848, 0, 65536,
0, 4284695872, 0, 8] is too long
meson-axg-s400.dt.yaml: ethernet@ff3f: reg: [[0, 4282318848, 0, 65536, 0,
4284695872, 0, 8]] is too short
meson-g12a-u200.dt.yaml: soc: ethernet@ff3f:reg:0: [0, 4282318848, 0,
65536, 0, 4284695872, 0, 8] is too long
meson-g12a-u200.dt.yaml: ethernet@ff3f: reg: [[0, 4282318848, 0, 65536, 0,
4284695872, 0, 8]] is too short
meson-gxbb-nanopi-k2.dt.yaml: soc: ethernet@c941:reg:0: [0, 3376480256, 0,
65536, 0, 3364046144, 0, 4] is too long
meson-gxl-s805x-libretech-ac.dt.yaml: soc: ethernet@c941:reg:0: [0,
3376480256, 0, 65536, 0, 3364046144, 0, 4] is too lon
while here, also drop the redundant reg property from meson-gxl.dtsi
because it had the same value as meson-gx.dtsi from which it inherits.
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi| 4 ++--
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi| 3 ---
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 12bf959c17a7..acc2feb8fd89 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -174,8 +174,8 @@
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xff3f 0x0 0x1
- 0x0 0xff634540 0x0 0x8>;
+ reg = <0x0 0xff3f 0x0 0x1>,
+ <0x0 0xff634540 0x0 0x8>;
interrupts = ;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index c643411aabff..1a5efa2e16c5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -98,8 +98,8 @@
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xff3f 0x0 0x1
- 0x0 0xff634540 0x0 0x8>;
+ reg = <0x0 0xff3f 0x0 0x1>,
+ <0x0 0xff634540 0x0 0x8>;
interrupts = ;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index ca4b834c65d8..f3ae5a3685f9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -503,8 +503,8 @@
compatible = "amlogic,meson-gxbb-dwmac",
"snps,dwmac-3.70a",
"snps,dwmac";
- reg = <0x0 0xc941 0x0 0x1
- 0x0 0xc8834540 0x0 0x4>;
+ reg = <0x0 0xc941 0x0 0x1>,
+ <0x0 0xc8834540 0x0 0x4>;
interrupts = ;
interrupt-names = "macirq";
rx-fifo-depth = <4096>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index a09c53aaa0e8..7a3b674db11f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -80,9 +80,6 @@
};
ðmac {
- reg = <0x0 0xc941 0x0 0x1
- 0x0 0xc8834540 0x0 0x4>;
-
clocks = <&clkc CLKID_ETH>,
<&clkc CLKID_FCLK_DIV2>,
<&clkc CLKID_MPLL2>;
--
2.22.0
[RESEND PATCH v2 06/14] arm64: dts: meson-gx: fix mhu compatible
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: mailbox@404: compatible:0: 'amlogic,meson-gx-mhu'
is not one of ['amlogic,meson-gxbb-mhu']
meson-gxl-s805x-libretech-ac.dt.yaml: mailbox@404: compatible:0:
'amlogic,meson-gx-mhu' is not one of ['amlogic,meson-gxbb-mhu']
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index b3fe3268af3e..74a2cdff0563 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -490,7 +490,7 @@
};
mailbox: mailbox@404 {
- compatible = "amlogic,meson-gx-mhu",
"amlogic,meson-gxbb-mhu";
+ compatible = "amlogic,meson-gxbb-mhu";
reg = <0 0x404 0 0x4c>;
interrupts = ,
,
--
2.22.0
[RESEND PATCH v2 00/14] arm64: dts: meson: fixes following YAML bindings schemas conversion
This is the first set of DT fixes following the first YAML bindings conversion at [1], [2] and [3]. After this set of fixes, the remaining errors are : meson-axg-s400.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' meson-g12a-sei510.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' meson-g12b-odroid-n2.dt.yaml: usb-hub: gpios:0:0: 20 is not valid under any of the given schemas meson-g12b-odroid-n2.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' meson-g12a-x96-max.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks' These are only cosmetic changes, and should not break drivers implementation following the bindings. Changes since v2 at [5]: - Rebased on khilman's v5.4/dt64 tree - Collected Acked-by and Reviewed-by tags from martin Changes since v1 at [4]: - Added suggested commit text from Martin in patches 1 & 2 - Fixed NanoPi K2 model name [1] https://patchwork.kernel.org/cover/11083597/ [2] https://patchwork.kernel.org/cover/11103229/ [3] https://patchwork.kernel.org/cover/11083649/ [4] https://patchwork.kernel.org/cover/11094063/ [5] https://patchwork.kernel.org/cover/11106927/ Neil Armstrong (14): arm64: dts: meson: fix ethernet mac reg format arm64: dts: meson-gx: drop the vpu dmc memory cell arm64: dts: meson-gx: fix reset controller compatible arm64: dts: meson-gx: fix spifc compatible arm64: dts: meson-gx: fix watchdog compatible arm64: dts: meson-gx: fix mhu compatible arm64: dts: meson-gx: fix periphs bus node name arm64: dts: meson-gxl: fix internal phy compatible arm64: dts: meson-axg: fix MHU compatible arm64: dts: meson-g12a: fix reset controller compatible arm64: dts: meson-g12a-x96-max: fix compatible arm64: dts: meson-gxbb-nanopi-k2: add missing model arm64: dts: meson-gxbb-p201: fix snps, reset-delays-us format arm64: dts: meson: fix boards regulators states format arch/arm64/boot/dts/amlogic/meson-axg.dtsi| 6 +++--- .../boot/dts/amlogic/meson-g12-common.dtsi| 7 +++ .../boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +- .../boot/dts/amlogic/meson-g12b-odroid-n2.dts | 4 ++-- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +-- .../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 + .../dts/amlogic/meson-gxbb-nexbox-a95x.dts| 4 ++-- .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++-- .../boot/dts/amlogic/meson-gxbb-p201.dts | 2 +- .../boot/dts/amlogic/meson-gxbb-p20x.dtsi | 4 ++-- .../meson-gxl-s905x-hwacom-amazetv.dts| 4 ++-- .../amlogic/meson-gxl-s905x-nexbox-a95x.dts | 4 ++-- arch/arm64/boot/dts/amlogic/meson-gxl.dtsi| 5 + 13 files changed, 31 insertions(+), 35 deletions(-) -- 2.22.0
[RESEND PATCH v2 04/14] arm64: dts: meson-gx: fix spifc compatible
This fixes the following DT schemas check errors:
meson-gxl-s805x-libretech-ac.dt.yaml: spi@8c80: compatible:0:
'amlogic,meson-gx-spifc' is not one of ['amlogic,meson6-spifc',
'amlogic,meson-gxbb-spifc']
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 08c01e11ba1b..1c580f42e818 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -317,7 +317,7 @@
};
spifc: spi@8c80 {
- compatible = "amlogic,meson-gx-spifc",
"amlogic,meson-gxbb-spifc";
+ compatible = "amlogic,meson-gxbb-spifc";
reg = <0x0 0x08c80 0x0 0x80>;
#address-cells = <1>;
#size-cells = <0>;
--
2.22.0
[RESEND PATCH v2 03/14] arm64: dts: meson-gx: fix reset controller compatible
This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: reset-controller@4404: compatible:0:
'amlogic,meson-gx-reset' is not one of ['amlogic,meson8b-reset',
'amlogic,meson-gxbb-reset', 'amlogic,meson-axg-reset']
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 239ec08b3023..08c01e11ba1b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -220,7 +220,7 @@
};
reset: reset-controller@4404 {
- compatible = "amlogic,meson-gx-reset",
"amlogic,meson-gxbb-reset";
+ compatible = "amlogic,meson-gxbb-reset";
reg = <0x0 0x04404 0x0 0x9c>;
#reset-cells = <1>;
};
--
2.22.0
Re: [PATCH -next] phy: tegra: Use PTR_ERR_OR_ZERO in tegra_p2u_probe()
On 8/22/2019 12:04 PM, YueHaibing wrote:
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: YueHaibing
---
drivers/phy/tegra/phy-tegra194-p2u.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/tegra/phy-tegra194-p2u.c
b/drivers/phy/tegra/phy-tegra194-p2u.c
index 7042bed9feaa..42394d27f4cb 100644
--- a/drivers/phy/tegra/phy-tegra194-p2u.c
+++ b/drivers/phy/tegra/phy-tegra194-p2u.c
@@ -92,10 +92,7 @@ static int tegra_p2u_probe(struct platform_device *pdev)
phy_set_drvdata(generic_phy, phy);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- if (IS_ERR(phy_provider))
- return PTR_ERR(phy_provider);
-
- return 0;
+ return PTR_ERR_OR_ZERO(phy_provider);
}
Since PTR_ERR_OR_ZERO macro returns zero if input is valid, if some more code
gets added in
future after this, then, they might have to change this back to what it is now.
So I ended up continuing with if(IS_ERR(...)) + PTR_ERR towards the end also.
Having said that, I'm fine with this change as well.
Reviewed-by: Vidya Sagar
static const struct of_device_id tegra_p2u_id_table[] = {
[PATCH net-next v2 0/2] Save EEE
v2: Adjust patch #1. The EEE has been disabled in the beginning of r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if it is necessary to enable EEE. Add the patch #2 for the helper function. v1: Saving the settings of EEE to avoid they become the default settings after reset_resume(). Hayes Wang (2): r8152: saving the settings of EEE r8152: add a helper function about setting EEE drivers/net/usb/r8152.c | 182 +--- 1 file changed, 95 insertions(+), 87 deletions(-) -- 2.21.0
[PATCH net-next v2 1/2] r8152: saving the settings of EEE
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 80 +
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev,
u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee
[PATCH net-next v2 2/2] r8152: add a helper function about setting EEE
Add a helper funtcion "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 166 +++-
1 file changed, 77 insertions(+), 89 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..220079a8882f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool
enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,7 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
if (tp->version == RTL_VER_03) {
@@ -3502,10 +3533,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
-
Re: [PATCH] PCI: Add missing link delays required by the PCIe spec
On Thu, Aug 22, 2019 at 08:29:09PM +0200, Matthias Andree wrote: > Am 21.08.19 um 14:45 schrieb Mika Westerberg: > > Hi all, > > > > As the changelog says this is reworked version that tries to avoid reported > > issues while at the same time fix the missing delays so we can get ICL > > systems and at least the one system with Titan Ridge controller working > > properly. > > > > @Matthias, @Paul and @Nicholas: it would be great if you could try the > > patch on top of v5.4-rc5+ and verify that it does not cause any issues on > > your systems. > > > > drivers/pci/pci-driver.c | 19 ++ > > drivers/pci/pci.c| 127 --- > > drivers/pci/pci.h| 1 + > > 3 files changed, 137 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > > index a8124e47bf6e..9aec78ed8907 100644 > > ... > > Mika, Bjorn, Rafael, > > quick smoke test, this test applied with git-am on top > v5.3-rc5-149-gbb7ba8069de9, reboot, suspend, wake, suspend, wake, > hibernate, wake, looks good to me. The top of git log --pretty-short is > shown below. Thanks for testing! > Couldn't test on v5.4-rc5 though as I've handed off my time machine for > repairs, > I seem to recall they said something about the flux compensator. :)
[RFC 0/3] New idle device-tree format and support for versioned stop state
Background
--
Previously if a older kernel runs on a newer firmware, it may enable
all available states irrespective of its capability of handling it.
Consider a case that some stop state has a bug, we end up disabling all
the stop states. This patch introduces selective control to solve this
problem.
Previous version of these patches can be found at:
https://lkml.org/lkml/2018/10/11/544
These patch however also had patches for support of opal save-restore
which now I am decoupling and will take them seperately.
I have posted the corresponding skiboot patches for this kernel patchset
here : https://patchwork.ozlabs.org/cover/1144587/
What's new?
Add stop states under ibm,idle-states in addition to the current array
based device tree properties.
New device tree format adds a compatible flag which has version
corresponding to every state, so that only kernel which has the capability
to handle the version of stop state will enable it. Drawback of the array
based dt node is that versioning of idle states is not possible.
Older kernel will still see stop0 and stop0_lite in older format and we
will deprecate it after some time.
Consider a case that stop4 has a bug. We take the following steps to
mitigate the problem.
1) Change compatible string for stop4 in OPAL to "stop4,v2" from
"stop4,v1", i.e. basicallly bump up the previous version and ship the
new firmware.
2) The kernel will ignore stop4 as it won't be able to recognize this
new version. Kernel will also ignore all the deeper states because its
possible that a cpu have requested for a deeper state but was never able
to enter into it. But we will still have shallower states that are there
before stop 4. This, thus prevents from completely disabling stop states.
Linux kernel can now look at the version string and decide if it has the
ability to handle that idle state. Henceforth, if kernel does not know
about a version, it will skip that state and all the deeper state.
Once when the workaround are implemented into the kernel, we can bump up
the known version in kernel for that state, so that support can be
enabled once again in kernel.
New Device-tree :
Final output
power-mgt {
...
ibm,enabled-stop-levels = <0xec00>;
ibm,cpu-idle-state-psscr-mask = <0x0 0x3003ff 0x0 0x3003ff>;
ibm,cpu-idle-state-latencies-ns = <0x3e8 0x7d0>;
ibm,cpu-idle-state-psscr = <0x0 0x330 0x0 0x300330>;
ibm,cpu-idle-state-flags = <0x10 0x101000>;
ibm,cpu-idle-state-residency-ns = <0x2710 0x4e20>;
ibm,idle-states {
stop4 {
flags = <0x207000>;
compatible = "stop4,v1",
psscr-mask = <0x0 0x3003ff>;
latency-ns = <0x186a0>;
residency-ns = <0x989680>;
psscr = <0x0 0x300374>;
...
};
...
stop11 {
...
compatible = "stop11,v1",
...
};
};
Abhishek Goel (3):
cpuidle/powernv : Pass state pointer instead of values to stop loop
cpuidle/powernv: Add support for versioned stop states
cpuidle/powernv : Add flags to identify stop state type
arch/powerpc/include/asm/cpuidle.h| 8 +-
arch/powerpc/include/asm/opal-api.h | 7 +
arch/powerpc/include/asm/processor.h | 5 +-
arch/powerpc/platforms/powernv/idle.c | 371 +-
drivers/cpuidle/cpuidle-powernv.c | 81 +++---
5 files changed, 363 insertions(+), 109 deletions(-)
--
2.17.1
[RFC 3/3] cpuidle/powernv : Add flags to identify stop state type
Removed threshold latency which was being used to decide if a state
is cpuidle type or not. This decision can be taken using flags, as this
information has been encapsulated in the state->flags and being read
from idle device-tree.
Signed-off-by: Abhishek Goel
---
arch/powerpc/include/asm/opal-api.h | 7 +++
drivers/cpuidle/cpuidle-powernv.c | 16 +---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 383242eb0dea..b9068fee21d8 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -233,6 +233,13 @@
#define OPAL_PM_STOP_INST_FAST 0x0010
#define OPAL_PM_STOP_INST_DEEP 0x0020
+/*
+ * Flags for stop states to distinguish between cpuidle and
+ * cpuoffline type of states.
+ */
+#define OPAL_PM_STOP_CPUIDLE 0x0100
+#define OPAL_PM_STOP_CPUHOTPLUG0x0200
+
/*
* OPAL_CONFIG_CPU_IDLE_STATE parameters
*/
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 1b6c84d4ac77..1a33a548b769 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -270,8 +270,13 @@ static int powernv_add_idle_states(void)
goto out;
}
- /* TODO: Count only states which are eligible for cpuidle */
- dt_idle_states = nr_pnv_idle_states;
+ /* Count only cpuidle states*/
+ for (i = 0; i < nr_pnv_idle_states; i++) {
+ if (pnv_idle_states[i].flags & OPAL_PM_STOP_CPUIDLE)
+ dt_idle_states++;
+ }
+ pr_info("idle states in dt = %d , states with idle flag = %d",
+ nr_pnv_idle_states, dt_idle_states);
/*
* Since snooze is used as first idle state, max idle states allowed is
@@ -300,11 +305,8 @@ static int powernv_add_idle_states(void)
continue;
}
- /*
-* If an idle state has exit latency beyond
-* POWERNV_THRESHOLD_LATENCY_NS then don't use it in cpu-idle.
-*/
- if (state->latency_ns > POWERNV_THRESHOLD_LATENCY_NS) {
+ /* Check whether a state is of cpuidle type */
+ if ((state->flags & OPAL_PM_STOP_CPUIDLE) != state->flags) {
pr_info("State %d is not idletype\n", i);
continue;
}
--
2.17.1
[RFC 2/3] cpuidle/powernv: Add support for versioned stop states
New device tree format adds a compatible flag which has version
corresponding to every state, so that only kernel which has the capability
to handle the version of stop state will enable it. Drawback of the array
based dt node is that versioning of idle states is not possible.
Older kernel will still see stop0 and stop0_lite in older format and we
will deprecate it after some time.
Consider a case that stop4 has a bug. We take the following steps to
mitigate the problem.
1) Change compatible string for stop4 in OPAL to "stop4,v2" from
"stop4,v1", i.e. basicallly bump up the previous version and ship the
new firmware.
2) The kernel will ignore stop4 as it won't be able to recognize this
new version. Kernel will also ignore all the deeper states because its
possible that a cpu have requested for a deeper state but was never able
to enter into it. But we will still have shallower states that are there
before stop 4. This, thus prevents from completely disabling stop states.
Linux kernel can now look at the version string and decide if it has the
ability to handle that idle state. Henceforth, if kernel does not know
about a version, it will skip that state and all the deeper state.
Once when the workaround are implemented into the kernel, we can bump up
the known version in kernel for that state, so that support can be
enabled once again in kernel.
New Device-tree :
Final output
power-mgt {
...
ibm,enabled-stop-levels = <0xec00>;
ibm,cpu-idle-state-psscr-mask = <0x0 0x3003ff 0x0 0x3003ff>;
ibm,cpu-idle-state-latencies-ns = <0x3e8 0x7d0>;
ibm,cpu-idle-state-psscr = <0x0 0x330 0x0 0x300330>;
ibm,cpu-idle-state-flags = <0x10 0x101000>;
ibm,cpu-idle-state-residency-ns = <0x2710 0x4e20>;
ibm,idle-states {
stop4 {
flags = <0x207000>;
compatible = "stop4,v1",
psscr-mask = <0x0 0x3003ff>;
latency-ns = <0x186a0>;
residency-ns = <0x989680>;
psscr = <0x0 0x300374>;
...
};
...
stop11 {
...
compatible = "stop11,v1",
...
};
};
Since state pointer is being passed to stop loop, I have separated idle
fast path for lite, shallow and deep states. This improves the
readability of the code and also future maintainability of the code.
Stop handle corresponding to each state can be called directly since
state pointer is being passed now.
Signed-off-by: Abhishek Goel
---
arch/powerpc/include/asm/cpuidle.h| 8 +-
arch/powerpc/platforms/powernv/idle.c | 331 +++---
2 files changed, 299 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/include/asm/cpuidle.h
b/arch/powerpc/include/asm/cpuidle.h
index 9844b3ded187..5eb9a98fcb86 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -70,15 +70,19 @@
#ifndef __ASSEMBLY__
-#define PNV_IDLE_NAME_LEN16
+#define PNV_VERSION_LEN25
+#define PNV_IDLE_NAME_LEN 16
struct pnv_idle_states_t {
char name[PNV_IDLE_NAME_LEN];
+ char compat_version[PNV_VERSION_LEN];
u32 latency_ns;
u32 residency_ns;
u64 psscr_val;
u64 psscr_mask;
- u32 flags;
+ u64 flags;
bool valid;
+ unsigned long (*stop_handle)(struct pnv_idle_states_t *state,
+bool mmu_on);
};
extern struct pnv_idle_states_t *pnv_idle_states;
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index db810c0a16e1..7398a66e1ddb 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -49,6 +49,12 @@ static bool default_stop_found;
static u64 pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
static u64 pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
+struct stop_version_t {
+ const char compat_version[PNV_VERSION_LEN];
+ unsigned long (*stop_handle)(struct pnv_idle_states_t *state,
+bool mmu_on);
+};
+
/*
* psscr value and mask of the deepest stop idle state.
* Used when a cpu is offlined.
@@ -599,40 +605,152 @@ struct p9_sprs {
u64 uamor;
};
-static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
+/* Splitting the previous power9_idle_stop into three functions
+ * to separately handle lite, shallow and deep states.
+ */
+
+static unsigned long power9_stop_lite(struct pnv_idle_states_t *state,
+ bool mmu_on)
{
- int cpu = raw_smp_processor_id();
- int first = cpu_first_thread_sibling(cpu);
- unsigned long *state = &paca_ptrs[first]->idle_state;
- unsigned long core_thread_ma
[RFC 1/3] cpuidle/powernv : Pass state pointer instead of values to stop loop
Instead of passing psscr_val and psscr_mask, we will pass state pointer
to stop loop. This will help to figure out the method to enter/exit idle
state. Removed psscr_mask and psscr_val from driver idle code. Same has
also been done in platform idle code.
Also, added some cleanups and debugging info.
Signed-off-by: Abhishek Goel
---
arch/powerpc/include/asm/processor.h | 5 +-
arch/powerpc/platforms/powernv/idle.c | 50 ---
drivers/cpuidle/cpuidle-powernv.c | 69 +--
3 files changed, 55 insertions(+), 69 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index a9993e7a443b..855666e8d271 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/* We do _not_ want to define new machine types at all, those must die
* in favor of using the device-tree
@@ -419,9 +420,7 @@ enum idle_boot_override {IDLE_NO_OVERRIDE = 0,
IDLE_POWERSAVE_OFF};
extern int powersave_nap; /* set if nap mode can be used in idle loop */
extern void power7_idle_type(unsigned long type);
-extern void power9_idle_type(unsigned long stop_psscr_val,
- unsigned long stop_psscr_mask);
-
+extern void power9_idle_type(struct pnv_idle_states_t *state);
extern void flush_instruction_cache(void);
extern void hard_reset_now(void);
extern void poweroff_now(void);
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 09f49eed7fb8..db810c0a16e1 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -40,8 +40,7 @@ int nr_pnv_idle_states;
* The default stop state that will be used by ppc_md.power_save
* function on platforms that support stop instruction.
*/
-static u64 pnv_default_stop_val;
-static u64 pnv_default_stop_mask;
+struct pnv_idle_states_t *pnv_default_state;
static bool default_stop_found;
/*
@@ -54,9 +53,7 @@ static u64 pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
* psscr value and mask of the deepest stop idle state.
* Used when a cpu is offlined.
*/
-static u64 pnv_deepest_stop_psscr_val;
-static u64 pnv_deepest_stop_psscr_mask;
-static u64 pnv_deepest_stop_flag;
+static struct pnv_idle_states_t *pnv_deepest_state;
static bool deepest_stop_found;
static unsigned long power7_offline_type;
@@ -78,7 +75,7 @@ static int pnv_save_sprs_for_deep_states(void)
uint64_t hid5_val = mfspr(SPRN_HID5);
uint64_t hmeer_val = mfspr(SPRN_HMEER);
uint64_t msr_val = MSR_IDLE;
- uint64_t psscr_val = pnv_deepest_stop_psscr_val;
+ uint64_t psscr_val = pnv_deepest_state->psscr_val;
for_each_present_cpu(cpu) {
uint64_t pir = get_hard_smp_processor_id(cpu);
@@ -804,9 +801,13 @@ static unsigned long power9_idle_stop(unsigned long psscr,
bool mmu_on)
}
#ifdef CONFIG_HOTPLUG_CPU
-static unsigned long power9_offline_stop(unsigned long psscr)
+static unsigned long power9_offline_stop(struct pnv_idle_states_t *state)
{
unsigned long srr1;
+ unsigned long psscr;
+
+ psscr = mfspr(SPRN_PSSCR);
+ psscr = (psscr & ~state->psscr_mask) | state->psscr_val;
#ifndef CONFIG_KVM_BOOK3S_HV_POSSIBLE
__ppc64_runlatch_off();
@@ -841,8 +842,7 @@ static unsigned long power9_offline_stop(unsigned long
psscr)
}
#endif
-void power9_idle_type(unsigned long stop_psscr_val,
- unsigned long stop_psscr_mask)
+void power9_idle_type(struct pnv_idle_states_t *state)
{
unsigned long psscr;
unsigned long srr1;
@@ -851,7 +851,7 @@ void power9_idle_type(unsigned long stop_psscr_val,
return;
psscr = mfspr(SPRN_PSSCR);
- psscr = (psscr & ~stop_psscr_mask) | stop_psscr_val;
+ psscr = (psscr & ~state->psscr_mask) | state->psscr_val;
__ppc64_runlatch_off();
srr1 = power9_idle_stop(psscr, true);
@@ -867,7 +867,7 @@ void power9_idle_type(unsigned long stop_psscr_val,
*/
void power9_idle(void)
{
- power9_idle_type(pnv_default_stop_val, pnv_default_stop_mask);
+ power9_idle_type(pnv_default_state);
}
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
@@ -970,12 +970,7 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
__ppc64_runlatch_off();
if (cpu_has_feature(CPU_FTR_ARCH_300) && deepest_stop_found) {
- unsigned long psscr;
-
- psscr = mfspr(SPRN_PSSCR);
- psscr = (psscr & ~pnv_deepest_stop_psscr_mask) |
- pnv_deepest_stop_psscr_val;
- srr1 = power9_offline_stop(psscr);
+ srr1 = power9_offline_stop(pnv_deepest_state);
} else if (cpu_has_feature(CPU_FTR_ARCH_206) && power7_offline_type) {
srr1 = power7_offline();
} else {
@@ -1124,16 +1119,13 @@ static void __init pnv_
Re: [PATCH v2 16/20] ARM: mmp: add SMP support
On Thu, 2019-08-22 at 09:36 -0700, Florian Fainelli wrote:
> On 8/22/19 2:26 AM, Lubomir Rintel wrote:
> > Used to bring up the second core on MMP3.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v1:
> > - Wrap SW_BRANCH_VIRT_ADDR with __pa_symbol()
> >
> > arch/arm/mach-mmp/Makefile | 3 +++
> > arch/arm/mach-mmp/platsmp.c | 33 +
> > 2 files changed, 36 insertions(+)
> > create mode 100644 arch/arm/mach-mmp/platsmp.c
> >
> > diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
> > index 322c1c97dc900..7b3a7f979eece 100644
> > --- a/arch/arm/mach-mmp/Makefile
> > +++ b/arch/arm/mach-mmp/Makefile
> > @@ -22,6 +22,9 @@ ifeq ($(CONFIG_PM),y)
> > obj-$(CONFIG_CPU_PXA910) += pm-pxa910.o
> > obj-$(CONFIG_CPU_MMP2) += pm-mmp2.o
> > endif
> > +ifeq ($(CONFIG_SMP),y)
> > +obj-$(CONFIG_MACH_MMP3_DT) += platsmp.o
> > +endif
> >
> > # board support
> > obj-$(CONFIG_MACH_ASPENITE)+= aspenite.o
> > diff --git a/arch/arm/mach-mmp/platsmp.c b/arch/arm/mach-mmp/platsmp.c
> > new file mode 100644
> > index 0..98d5ef23623cb
> > --- /dev/null
> > +++ b/arch/arm/mach-mmp/platsmp.c
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2019 Lubomir Rintel
> > + */
> > +#include
> > +#include
> > +#include
> > +#include "addr-map.h"
> > +
> > +#define SW_BRANCH_VIRT_ADDRCIU_REG(0x24)
> > +
> > +static int mmp3_boot_secondary(unsigned int cpu, struct task_struct *idle)
> > +{
> > + /*
> > +* Apparently, the boot ROM on the second core spins on this
> > +* register becoming non-zero and then jumps to the address written
> > +* there. No IPIs involved.
> > +*/
> > + __raw_writel(virt_to_phys(secondary_startup),
> > + __pa_symbol(SW_BRANCH_VIRT_ADDR));
>
> That looks wrong, the __pa_symbol() is applicable to secondary_startup,
> while SW_BRANCH_VIRT_ADDR does not need that.
Whoops, sorry for that. Will fix in the next patch version in a few
days.
Thanks
Lubo
[PATCH v7 0/7] iommu: Bounce page for untrusted devices
The Thunderbolt vulnerabilities are public and have a nice name as Thunderclap [1] [3] nowadays. This patch series aims to mitigate those concerns. An external PCI device is a PCI peripheral device connected to the system through an external bus, such as Thunderbolt. What makes it different is that it can't be trusted to the same degree as the devices build into the system. Generally, a trusted PCIe device will DMA into the designated buffers and not overrun or otherwise write outside the specified bounds. But it's different for an external device. The minimum IOMMU mapping granularity is one page (4k), so for DMA transfers smaller than that a malicious PCIe device can access the whole page of memory even if it does not belong to the driver in question. This opens a possibility for DMA attack. For more information about DMA attacks imposed by an untrusted PCI/PCIe device, please refer to [2]. This implements bounce buffer for the untrusted external devices. The transfers should be limited in isolated pages so the IOMMU window does not cover memory outside of what the driver expects. Previously (v3 and before), we proposed an optimisation to only copy the head and tail of the buffer if it spans multiple pages, and directly map the ones in the middle. Figure 1 gives a big picture about this solution. swiotlb System IOVA bounce page Memory .-. .-..-. | | | || | | | | || | buffer_start .-. .-..-. | |->| |***>| | | | | | swiotlb| | | | | | mapping| | IOMMU Page '-' '-''-' Boundary | | | | | | | | | | | | | |>| | | |IOMMU mapping| | | | | | IOMMU Page .-. .-. Boundary | | | | | | | | | |>| | | | IOMMU mapping | | | | | | | | | | IOMMU Page .-. .-..-. Boundary | | | || | | | | || | | |->| |***>| | buffer_end '-' '-' swiotlb'-' | | | | mapping| | | | | || | '-' '-''-' Figure 1: A big view of iommu bounce page As Robin Murphy pointed out, this ties us to using strict mode for TLB maintenance, which may not be an overall win depending on the balance between invalidation bandwidth vs. memcpy bandwidth. If we use standard SWIOTLB logic to always copy the whole thing, we should be able to release the bounce pages via the flush queue to allow 'safe' lazy unmaps. So since v4 we start to use the standard swiotlb logic. swiotlb System IOVA bounce page Memory buffer_start .-. .-..-. | | | || | | | | || | | | | |.-.physical | |->| | -->| |_start | |iommu | | swiotlb| | | | map | | map | | IOMMU Page .-. .-.'-' Boundary | | | || | | | | || | | |->| || | | |iommu | || | | | map | || | | | | || | IOMMU Page .-. .-..-. Boundary | | | || | | |->| || | | |iommu | || | | | map | || | | |
Re: [PATCH 6/9] dm crypt: support diskcipher
On Fri, Aug 23, 2019 at 01:28:37PM +0900, Herbert Xu wrote: > > No. If you're after total offload then the crypto API is not for > you. What we can support is the offloading of encryption/decryption > over many sectors. > > Cheers, FMP doesn't use encrypt/decrypt of crypto API because it doesn't expose cipher-text to DRAM. But, Crypto API has many useful features such as cipher management, cipher allocation with cipher name, key management and test manager. All these features are useful for FMP. FMP has been cerified with FIPS as below by using test vectors and test manager of Crypto API. https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certi ficate/3255 https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-pr ogram/documents/security-policies/140sp3255.pdf Can't I use crypto APIs to take advantage of this? I want to find a good way that FMP can use crypto API. Thanks Boojin Kim.
[PATCH v7 2/7] PCI: Add dev_is_untrusted helper
There are several places in the kernel where it is necessary to
check whether a device is a pci untrusted device. Add a helper
to simplify the callers.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
---
include/linux/pci.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 82e4cd1b7ac3..6c107eb381ac 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1029,6 +1029,7 @@ void pcibios_setup_bridge(struct pci_bus *bus, unsigned
long type);
void pci_sort_breadthfirst(void);
#define dev_is_pci(d) ((d)->bus == &pci_bus_type)
#define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
+#define dev_is_untrusted(d) ((dev_is_pci(d) ? to_pci_dev(d)->untrusted :
false))
/* Generic PCI functions exported to card drivers */
@@ -1768,6 +1769,7 @@ static inline struct pci_dev *pci_dev_get(struct pci_dev
*dev) { return NULL; }
#define dev_is_pci(d) (false)
#define dev_is_pf(d) (false)
+#define dev_is_untrusted(d) (false)
static inline bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
{ return false; }
static inline int pci_irqd_intx_xlate(struct irq_domain *d,
--
2.17.1
[PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use direct dma
The direct dma implementation depends on swiotlb. Hence, don't switch off swiotlb since direct dma interfaces are used in this driver. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Signed-off-by: Lu Baolu Reviewed-by: Christoph Hellwig --- drivers/iommu/Kconfig | 1 + drivers/iommu/intel-iommu.c | 6 -- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index e15cdcd8cb3c..a4ddeade8ac4 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -182,6 +182,7 @@ config INTEL_IOMMU select IOMMU_IOVA select NEED_DMA_MAP_STATE select DMAR_TABLE + select SWIOTLB help DMA remapping (DMAR) devices support enables independent address translations for Direct Memory Access (DMA) from devices. diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 12d094d08c0a..8316e57f047c 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void) iommu_identity_mapping |= IDENTMAP_ALL; dmar_disabled = 0; -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB) - swiotlb = 0; -#endif no_iommu = 0; return 1; @@ -4710,9 +4707,6 @@ int __init intel_iommu_init(void) } up_write(&dmar_global_lock); -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB) - swiotlb = 0; -#endif dma_ops = &intel_dma_ops; init_iommu_pm_ops(); -- 2.17.1
[PATCH v7 3/7] swiotlb: Split size parameter to map/unmap APIs
This splits the size parameter to swiotlb_tbl_map_single() and
swiotlb_tbl_unmap_single() into an alloc_size and a mapping_size
parameter, where the latter one is rounded up to the iommu page
size.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 8
include/linux/swiotlb.h | 8 ++--
kernel/dma/direct.c | 2 +-
kernel/dma/swiotlb.c | 30 +++---
4 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ae1df496bf38..adcabd9473eb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -386,8 +386,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
*/
trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force);
- map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir,
-attrs);
+ map = swiotlb_tbl_map_single(dev, start_dma_addr, phys,
+size, size, dir, attrs);
if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
@@ -397,7 +397,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
* Ensure that the address returned is DMA'ble
*/
if (unlikely(!dma_capable(dev, dev_addr, size))) {
- swiotlb_tbl_unmap_single(dev, map, size, dir,
+ swiotlb_tbl_unmap_single(dev, map, size, size, dir,
attrs | DMA_ATTR_SKIP_CPU_SYNC);
return DMA_MAPPING_ERROR;
}
@@ -433,7 +433,7 @@ static void xen_unmap_single(struct device *hwdev,
dma_addr_t dev_addr,
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr))
- swiotlb_tbl_unmap_single(hwdev, paddr, size, dir, attrs);
+ swiotlb_tbl_unmap_single(hwdev, paddr, size, size, dir, attrs);
}
static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 361f62bb4a8e..cde3dc18e21a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -46,13 +46,17 @@ enum dma_sync_target {
extern phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
dma_addr_t tbl_dma_addr,
- phys_addr_t phys, size_t size,
+ phys_addr_t phys,
+ size_t mapping_size,
+ size_t alloc_size,
enum dma_data_direction dir,
unsigned long attrs);
extern void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
-size_t size, enum dma_data_direction dir,
+size_t mapping_size,
+size_t alloc_size,
+enum dma_data_direction dir,
unsigned long attrs);
extern void swiotlb_tbl_sync_single(struct device *hwdev,
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 795c9b095d75..a7f2a0163426 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -297,7 +297,7 @@ void dma_direct_unmap_page(struct device *dev, dma_addr_t
addr,
dma_direct_sync_single_for_cpu(dev, addr, size, dir);
if (unlikely(is_swiotlb_buffer(phys)))
- swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
+ swiotlb_tbl_unmap_single(dev, phys, size, size, dir, attrs);
}
EXPORT_SYMBOL(dma_direct_unmap_page);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9de232229063..89066efa3840 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -444,7 +444,9 @@ static void swiotlb_bounce(phys_addr_t orig_addr,
phys_addr_t tlb_addr,
phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
dma_addr_t tbl_dma_addr,
- phys_addr_t orig_addr, size_t size,
+ phys_addr_t orig_addr,
+ size_t mapping_size,
+ size_t alloc_size,
enum dma_data_direction dir,
unsigned long attrs)
{
@@ -464,6 +466,9 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
pr_warn_once("%s is active and system is using DMA bounce
buffers\n",
sme_active() ? "SME" : "SEV");
+ if (WARN_ON(mapping_size > alloc_size))
+ return (phys_addr_t)DMA_MAPPING_ERROR;
+
mask = dma_get_seg_boundary(hwdev);
[PATCH v7 4/7] swiotlb: Zero out bounce buffer for untrusted device
This is necessary to avoid exposing valid kernel data to any
malicious device.
Suggested-by: Christoph Hellwig
Signed-off-by: Lu Baolu
---
kernel/dma/swiotlb.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 89066efa3840..04bea5a87462 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DEBUG_FS
#include
#endif
@@ -458,6 +459,8 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
unsigned long offset_slots;
unsigned long max_slots;
unsigned long tmp_io_tlb_used;
+ void *zero_addr;
+ size_t zero_size;
if (no_iotlb_memory)
panic("Can not allocate SWIOTLB buffer earlier and can't now
provide you with the DMA bounce buffer");
@@ -565,9 +568,20 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
*/
for (i = 0; i < nslots; i++)
io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
+
+ zero_addr = phys_to_virt(tlb_addr);
+ zero_size = alloc_size;
+
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
+ (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) {
swiotlb_bounce(orig_addr, tlb_addr, mapping_size,
DMA_TO_DEVICE);
+ zero_addr += mapping_size;
+ zero_size -= mapping_size;
+ }
+
+ /* Zero out the bounce buffer if the consumer is untrusted. */
+ if (dev_is_untrusted(hwdev) && zero_size)
+ memset(zero_addr, 0, zero_size);
return tlb_addr;
}
--
2.17.1
[PATCH net-next v3 2/2] r8152: add a helper function about setting EEE
Add a helper funtion "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 166 +++-
1 file changed, 77 insertions(+), 89 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..a003591c3078 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool
enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,7 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
+ rtl_eee_enable(tp, false);
ocp_reg_write(tp, OCP_EEE_ADV, 0);
if (tp->version == RTL_VER_03) {
@@ -3502,10 +3533,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
-
[PATCH net-next v3 1/2] r8152: saving the settings of EEE
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 80 +
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev,
u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee
[PATCH net-next v3 0/2] r8152: save EEE
v3: For patch #2, fix the mistake caused by copying and pasting. v2: Adjust patch #1. The EEE has been disabled in the beginning of r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if it is necessary to enable EEE. Add the patch #2 for the helper function. v1: Saving the settings of EEE to avoid they become the default settings after reset_resume(). Hayes Wang (2): r8152: saving the settings of EEE r8152: add a helper function about setting EEE drivers/net/usb/r8152.c | 182 +--- 1 file changed, 95 insertions(+), 87 deletions(-) -- 2.21.0
[PATCH v7 6/7] iommu/vt-d: Add trace events for device dma map/unmap
This adds trace support for the Intel IOMMU driver. It
also declares some events which could be used to trace
the events when an IOVA is being mapped or unmapped in
a domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Mika Westerberg
Signed-off-by: Lu Baolu
Reviewed-by: Steven Rostedt (VMware)
---
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-trace.c| 14 +
include/trace/events/intel_iommu.h | 84 ++
3 files changed, 99 insertions(+)
create mode 100644 drivers/iommu/intel-trace.c
create mode 100644 include/trace/events/intel_iommu.h
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index f13f36ae1af6..bfe27b2755bd 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
+obj-$(CONFIG_INTEL_IOMMU) += intel-trace.o
obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += intel-iommu-debugfs.o
obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
diff --git a/drivers/iommu/intel-trace.c b/drivers/iommu/intel-trace.c
new file mode 100644
index ..bfb6a6e37a88
--- /dev/null
+++ b/drivers/iommu/intel-trace.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel IOMMU trace support
+ *
+ * Copyright (C) 2019 Intel Corporation
+ *
+ * Author: Lu Baolu
+ */
+
+#include
+#include
+
+#define CREATE_TRACE_POINTS
+#include
diff --git a/include/trace/events/intel_iommu.h
b/include/trace/events/intel_iommu.h
new file mode 100644
index ..9c28e6cae86f
--- /dev/null
+++ b/include/trace/events/intel_iommu.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Intel IOMMU trace support
+ *
+ * Copyright (C) 2019 Intel Corporation
+ *
+ * Author: Lu Baolu
+ */
+#ifdef CONFIG_INTEL_IOMMU
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM intel_iommu
+
+#if !defined(_TRACE_INTEL_IOMMU_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_INTEL_IOMMU_H
+
+#include
+#include
+
+DECLARE_EVENT_CLASS(dma_map,
+ TP_PROTO(struct device *dev, dma_addr_t dev_addr, phys_addr_t phys_addr,
+size_t size),
+
+ TP_ARGS(dev, dev_addr, phys_addr, size),
+
+ TP_STRUCT__entry(
+ __string(dev_name, dev_name(dev))
+ __field(dma_addr_t, dev_addr)
+ __field(phys_addr_t, phys_addr)
+ __field(size_t, size)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name(dev));
+ __entry->dev_addr = dev_addr;
+ __entry->phys_addr = phys_addr;
+ __entry->size = size;
+ ),
+
+ TP_printk("dev=%s dev_addr=0x%llx phys_addr=0x%llx size=%zu",
+ __get_str(dev_name),
+ (unsigned long long)__entry->dev_addr,
+ (unsigned long long)__entry->phys_addr,
+ __entry->size)
+);
+
+DEFINE_EVENT(dma_map, bounce_map_single,
+ TP_PROTO(struct device *dev, dma_addr_t dev_addr, phys_addr_t phys_addr,
+size_t size),
+ TP_ARGS(dev, dev_addr, phys_addr, size)
+);
+
+DECLARE_EVENT_CLASS(dma_unmap,
+ TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
+
+ TP_ARGS(dev, dev_addr, size),
+
+ TP_STRUCT__entry(
+ __string(dev_name, dev_name(dev))
+ __field(dma_addr_t, dev_addr)
+ __field(size_t, size)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name(dev));
+ __entry->dev_addr = dev_addr;
+ __entry->size = size;
+ ),
+
+ TP_printk("dev=%s dev_addr=0x%llx size=%zu",
+ __get_str(dev_name),
+ (unsigned long long)__entry->dev_addr,
+ __entry->size)
+);
+
+DEFINE_EVENT(dma_unmap, bounce_unmap_single,
+ TP_PROTO(struct device *dev, dma_addr_t dev_addr, size_t size),
+ TP_ARGS(dev, dev_addr, size)
+);
+
+#endif /* _TRACE_INTEL_IOMMU_H */
+
+/* This part must be outside protection */
+#include
+#endif /* CONFIG_INTEL_IOMMU */
--
2.17.1
[PATCH v7 5/7] iommu/vt-d: Check whether device requires bounce buffer
This adds a helper to check whether a device needs to
use bounce buffer. It also provides a boot time option
to disable the bounce buffer. Users can use this to
prevent the iommu driver from using the bounce buffer
for performance gain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
Tested-by: Xu Pengfei
Tested-by: Mika Westerberg
---
Documentation/admin-guide/kernel-parameters.txt | 5 +
drivers/iommu/intel-iommu.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 47d981a86e2f..aaca73080097 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1732,6 +1732,11 @@
Note that using this option lowers the security
provided by tboot because it makes the system
vulnerable to DMA attacks.
+ nobounce [Default off]
+ Disable bounce buffer for unstrusted devices such as
+ the Thunderbolt devices. This will treat the untrusted
+ devices as the trusted ones, hence might expose security
+ risks of DMA attacks.
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
0 disables intel_idle and fall back on acpi_idle.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 8316e57f047c..b1ab3526e6fa 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -360,6 +360,7 @@ static int dmar_forcedac;
static int intel_iommu_strict;
static int intel_iommu_superpage = 1;
static int iommu_identity_mapping;
+static int intel_no_bounce;
#define IDENTMAP_ALL 1
#define IDENTMAP_GFX 2
@@ -373,6 +374,8 @@ EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
static DEFINE_SPINLOCK(device_domain_lock);
static LIST_HEAD(device_domain_list);
+#define device_needs_bounce(d) (!intel_no_bounce && dev_is_untrusted(d))
+
/*
* Iterate over elements in device_domain_list and call the specified
* callback @fn against each element.
@@ -455,6 +458,9 @@ static int __init intel_iommu_setup(char *str)
printk(KERN_INFO
"Intel-IOMMU: not forcing on after tboot. This
could expose security risk for tboot\n");
intel_iommu_tboot_noforce = 1;
+ } else if (!strncmp(str, "nobounce", 8)) {
+ pr_info("Intel-IOMMU: No bounce buffer. This could
expose security risks of DMA attacks\n");
+ intel_no_bounce = 1;
}
str += strcspn(str, ",");
--
2.17.1
[PATCH v7 7/7] iommu/vt-d: Use bounce buffer for untrusted devices
The Intel VT-d hardware uses paging for DMA remapping.
The minimum mapped window is a page size. The device
drivers may map buffers not filling the whole IOMMU
window. This allows the device to access to possibly
unrelated memory and a malicious device could exploit
this to perform DMA attacks. To address this, the
Intel IOMMU driver will use bounce pages for those
buffers which don't fill whole IOMMU pages.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
Tested-by: Xu Pengfei
Tested-by: Mika Westerberg
---
drivers/iommu/intel-iommu.c | 256
1 file changed, 256 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index b1ab3526e6fa..1f15c6f5880f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -41,9 +41,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "irq_remapping.h"
#include "intel-pasid.h"
@@ -3746,6 +3748,252 @@ static const struct dma_map_ops intel_dma_ops = {
.dma_supported = dma_direct_supported,
};
+static inline phys_addr_t
+iova_to_tlb_addr(struct dmar_domain *domain, dma_addr_t addr)
+{
+ struct dma_pte *pte;
+ int level = 0;
+ u64 phys = 0;
+
+ pte = pfn_to_dma_pte(domain, addr >> VTD_PAGE_SHIFT, &level);
+ if (pte)
+ phys = dma_pte_addr(pte);
+
+ return phys;
+}
+
+static void
+bounce_sync_single(struct device *dev, dma_addr_t addr, size_t size,
+ enum dma_data_direction dir, enum dma_sync_target target)
+{
+ struct dmar_domain *domain;
+ phys_addr_t tlb_addr;
+
+ domain = find_domain(dev);
+ if (WARN_ON(!domain))
+ return;
+
+ tlb_addr = iova_to_tlb_addr(domain, addr);
+ if (is_swiotlb_buffer(tlb_addr))
+ swiotlb_tbl_sync_single(dev, tlb_addr, size, dir, target);
+}
+
+static dma_addr_t
+bounce_map_single(struct device *dev, phys_addr_t paddr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs,
+ u64 dma_mask)
+{
+ size_t aligned_size = ALIGN(size, VTD_PAGE_SIZE);
+ struct dmar_domain *domain;
+ struct intel_iommu *iommu;
+ unsigned long iova_pfn;
+ unsigned long nrpages;
+ phys_addr_t tlb_addr;
+ int prot = 0;
+ int ret;
+
+ domain = find_domain(dev);
+ if (WARN_ON(dir == DMA_NONE || !domain))
+ return DMA_MAPPING_ERROR;
+
+ iommu = domain_get_iommu(domain);
+ if (WARN_ON(!iommu))
+ return DMA_MAPPING_ERROR;
+
+ nrpages = aligned_nrpages(0, size);
+ iova_pfn = intel_alloc_iova(dev, domain,
+ dma_to_mm_pfn(nrpages), dma_mask);
+ if (!iova_pfn)
+ return DMA_MAPPING_ERROR;
+
+ /*
+* Check if DMAR supports zero-length reads on write only
+* mappings..
+*/
+ if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL ||
+ !cap_zlr(iommu->cap))
+ prot |= DMA_PTE_READ;
+ if (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)
+ prot |= DMA_PTE_WRITE;
+
+ /*
+* If both the physical buffer start address and size are
+* page aligned, we don't need to use a bounce page.
+*/
+ if (!IS_ALIGNED(paddr | size, VTD_PAGE_SIZE)) {
+ tlb_addr = swiotlb_tbl_map_single(dev,
+ __phys_to_dma(dev, io_tlb_start),
+ paddr, size, aligned_size, dir, attrs);
+ if (tlb_addr == DMA_MAPPING_ERROR)
+ goto swiotlb_error;
+ } else {
+ tlb_addr = paddr;
+ }
+
+ ret = domain_pfn_mapping(domain, mm_to_dma_pfn(iova_pfn),
+tlb_addr >> VTD_PAGE_SHIFT, nrpages, prot);
+ if (ret)
+ goto mapping_error;
+
+ trace_bounce_map_single(dev, iova_pfn << PAGE_SHIFT, paddr, size);
+
+ return (phys_addr_t)iova_pfn << PAGE_SHIFT;
+
+mapping_error:
+ if (is_swiotlb_buffer(tlb_addr))
+ swiotlb_tbl_unmap_single(dev, tlb_addr, size,
+aligned_size, dir, attrs);
+swiotlb_error:
+ free_iova_fast(&domain->iovad, iova_pfn, dma_to_mm_pfn(nrpages));
+ dev_err(dev, "Device bounce map: %zx@%llx dir %d --- failed\n",
+ size, (unsigned long long)paddr, dir);
+
+ return DMA_MAPPING_ERROR;
+}
+
+static void
+bounce_unmap_single(struct device *dev, dma_addr_t dev_addr, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ size_t aligned_size = ALIGN(size, VTD_PAGE_SIZE);
+ struct dmar_domain *domain;
+ phys_addr_t tlb_addr;
+
+ domain = find_domain(dev);
+ if (WARN_ON(!domain))
+ return;
+
+ tlb_addr = iova_to_tlb_addr(domain, dev_addr);
+
Re: [PATCH v2 00/20] Initial support for Marvell MMP3 SoC
On Thu, 2019-08-22 at 11:31 +0100, Marc Zyngier wrote: > On 22/08/2019 10:26, Lubomir Rintel wrote: > > Hi, > > > > this is a second spin of a patch set that adds support for the Marvell > > MMP3 processor. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad > > FZ-A1 tablet and Dell Wyse 3020 Tx0D thin clients. > > > > Compared to v1, there's a handful of fixes in response to reviews. Patch > > 02/20 is new. Details in individual patches. > > > > Apart from the adjustments in mach-mmp/, the patch makes necessary > > changes to the irqchip driver and adds an USB2 PHY driver. The latter > > has a dependency on the mach-mmp/ changes, so it can't be submitted > > separately. > > > > The patch set has been tested to work on Wyse Tx0D and not ruin MMP2 > > support on XO-1.75. > > How do you want this series to be merged? I'm happy to take the irqchip > related patches as well as the corresponding DT change (once reviewed) > through my tree. I was hoping for the Arm SoC tree, because there are some dependencies (MMP3 USB PHY depends on MMP3 SoC). That said, the irqchip patches are rather independent and the only downside of them going in via a different tree will be that the other tree that will lack them won't boot on MMP3 (things will compile though). I don't know if that's okay. What's typically done in cases like these? > Thanks, > > M. Thank you Lubo
Re: [PATCH v2 0/3] PCI: Add PCI_ERROR_RESPONSE, check for errors
On Thu, Aug 22, 2019 at 03:05:48PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Reads from a PCI device may fail if the device has been turned off (put > into D3cold), removed, or if some other error occurs. The PCI host bridge > typically fabricates ~0 data to complete the CPU's read. > > We check for that in a few places, but not in a consistent way. This > series adds a PCI_ERROR_RESPONSE definition to make the checks more > consistent and easier to find. Note that ~0 may indicate a PCI error, but > it may also be valid read data, so you need more information (such as > knowing that a register can never contain ~0) before concluding that it's > an error. > > This series also adds a new check for PCI_ERROR_RESPONSE in the power > management code because that code frequently encounters devices in D3cold, > where we previously misinterpreted ~0 data. It also uses pci_power_name() > to print D-state names more consistently. > > Rafael, I didn't add your Reviewed-by to "PCI / PM: Return error when > changing power state from D3cold" because I made small changes to try to > make the messages more consistent, and I didn't want to presume they'd be > OK with you. > > Changes since v1: > - Add Rafael's Reviewed-By to the first two patches > - Drop "PCI / PM: Check for error when reading PME status" because Rafael > pointed out that some devices can signal PME even when in D3cold, so > this would require additional rework > - Drop "PCI / PM: Check for error when reading Power State" because > Rafael thinks it's mostly redundant > > Bjorn Helgaas (3): > PCI: Add PCI_ERROR_RESPONSE definition > PCI / PM: Decode D3cold power state correctly > PCI / PM: Return error when changing power state from D3cold For the whole series, Reviewed-by: Mika Westerberg
Re: [PATCH] sched/fair: Add missing unthrottle_cfs_rq()
Resend.
Sorry that my previous email has format issue.
On 19/8/23 上午2:48, bseg...@google.com wrote:
Valentin Schneider writes:
Turns out a cfs_rq->runtime_remaining can become positive in
assign_cfs_rq_runtime(), but this codepath has no call to
unthrottle_cfs_rq().
This can leave us in a situation where we have a throttled cfs_rq with
positive ->runtime_remaining, which breaks the math in
distribute_cfs_runtime(): this function expects a negative value so that
it may safely negate it into a positive value.
Add the missing unthrottle_cfs_rq(). While at it, add a WARN_ON where
we expect negative values, and pull in a comment from the mailing list
that didn't make it in [1].
[1]:
https://lkml.kernel.org/r/BANLkTi=nmcxkx6ebdqcjydj5kkyg2n1...@mail.gmail.com
Cc:
Fixes: ec12cb7f31e2 ("sched: Accumulate per-cfs_rq cpu usage and charge against
bandwidth")
Reported-by: Liangyan
Signed-off-by: Valentin Schneider
Having now seen the rest of the thread:
Could you send the repro, as it doesn't seem to have reached lkml, so
that I can confirm my guess as to what's going on?
It seems most likely we throttle during one of the remove-change-adds in
set_cpus_allowed and friends or during the put half of pick_next_task
followed by idle balance to drop the lock. Then distribute races with a
later assign_cfs_rq_runtime so that the account finds runtime in the
cfs_b.
pick_next_task_fair calls update_curr but get zero runtime because of
cfs_b->runtime=0, then throttle current cfs_rq because of
cfs_rq->runtime_remaining=0, then call put_prev_entity to
__account_cfs_rq_runtime to assign new runtime since dequeue_entity on
another cpu just call return_cfs_rq_runtime to return some runtime to
cfs_b->runtime.
Please check below debug log to trace this logic.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f35930f..0da556c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4395,6 +4395,12 @@ static void __account_cfs_rq_runtime(struct
cfs_rq *cfs_rq, u64 delta_exec)
if (likely(cfs_rq->runtime_remaining > 0))
return;
+ if (cfs_rq->throttled && smp_processor_id()==20) {
+
pr_err("__account_cfs_rq_runtime:cfs_rq=%p,comm=%s,pid=%d,cpu=%d\n",cfs_rq,current->comm,current->pid,smp_processor_id());
+ dump_stack();
+ }
+ //if (cfs_rq->throttled)
+ // return;
/*
* if we're unable to extend our runtime we resched so that the
active
* hierarchy can be throttled
@@ -4508,6 +4514,13 @@ static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
sub_nr_running(rq, task_delta);
cfs_rq->throttled = 1;
+ {
+ if (cfs_rq->nr_running > 0 && smp_processor_id()==20) {
+
pr_err("throttle_cfs_rq:cfs_rq=%p,comm=%s,pid=%d,cpu=%d\n",cfs_rq,current->comm,current->pid,smp_processor_id());
+ dump_stack();
+ }
+ }
cfs_rq->throttled_clock = rq_clock(rq);
raw_spin_lock(&cfs_b->lock);
empty = list_empty(&cfs_b->throttled_cfs_rq);
[ 257.406397]
throttle_cfs_rq:cfs_rq=b012d731,comm=delay,pid=4307,cpu=20
[ 257.407251] CPU: 20 PID: 4307 Comm: delay Tainted: GW E
5.2.0-rc3+ #9
[ 257.408795] Call Trace:
[ 257.409085] dump_stack+0x5c/0x7b
[ 257.409482] throttle_cfs_rq+0x2c3/0x2d0
[ 257.409940] check_cfs_rq_runtime+0x2f/0x50
[ 257.410430] pick_next_task_fair+0xb1/0x740
[ 257.410918] __schedule+0x104/0x670
[ 257.411333] schedule+0x33/0x90
[ 257.411706] exit_to_usermode_loop+0x6a/0xf0
[ 257.412201] prepare_exit_to_usermode+0x80/0xc0
[ 257.412734] retint_user+0x8/0x8
[ 257.413114] RIP: 0033:0x4006d0
[ 257.413480] Code: 7d f8 48 8b 45 f8 48 85 c0 74 24 eb 0d 0f 1f 00 66
2e 0f 1f 84 00 00 00 00 00 eb 0e 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00
00 <48> ff c8 75 fb 48 ff c8 90 5d c3 55 48 89 e5 48 83 ec 18 48 89 7d
[ 257.415630] RSP: 002b:7f9b74abbe90 EFLAGS: 0206 ORIG_RAX:
ff13
[ 257.416508] RAX: 00060f7b RBX: RCX:
[ 257.417333] RDX: 002625b3 RSI: RDI:
002625b4
[ 257.418155] RBP: 7f9b74abbe90 R08: 7f9b74abc700 R09:
7f9b74abc700
[ 257.418983] R10: 7f9b74abc9d0 R11: R12:
7ffee72e1afe
[ 257.419813] R13: 7ffee72e1aff R14: 7ffee72e1b00 R15:
[ 257.420718]
__account_cfs_rq_runtime:cfs_rq=b012d731,comm=delay,pid=4307,cpu=20
[ 257.421646] CPU: 20 PID: 4307 Comm: delay Tainted: GW E
5.2.0-rc3+ #9
[ 257.422538] Call Trace:
[ 257.424712] dump_stack+0x5c/0x7b
[ 257.425101] __account_cfs_rq_runtime+0x1d7/0x1e0
[ 257.425656] put_prev_entity+0x90/0x100
[ 257.426102] pick_next_task_fair+0x334/0x740
[ 257.426605] __schedule+0x104/0x670
[ 257.427013] schedule+0x33/0x90
[ 257.427384] exit_to_usermode_loop+0x6a/0xf0
[ 257.427879] prepare_exit_to_usermode+0x80/0xc0
[ 257.428406] retint_user+0x8/
Re: [PATCH V2] cpustat: print watchdog time and statistics of soft and hard interrupts in soft lockup scenes
On 2019/8/23 0:14, Peter Zijlstra wrote: > On Thu, Aug 22, 2019 at 07:58:37PM +0800, c00423981 wrote: > >> V1->V2 >> - fix the broken interfaces: get_idle_time and get_iowait_time > >> +else if (index == CPUTIME_IOWAIT) >> +time = get_iowait_time(kcs, cpu); > > I'm confused; isn't that still reporting per-cpu iowait, which is still > complete garbage? > > Yes, I understand that these two interfaces(nr_iowait_cpu and nr_iowait) will use nonsensical data. Thanks for your answer very much. By the way, are there an alternative about these two interfaces? Looking forward to your reply.
Re: [PATCH v2 4/5] dt-bindings: soundwire: add bindings for Qcom controller
On 13-08-19, 09:35, Srinivas Kandagatla wrote: > This patch adds bindings for Qualcomm soundwire controller. > > Qualcomm SoundWire Master controller is present in most Qualcomm SoCs > either integrated as part of WCD audio codecs via slimbus or > as part of SOC I/O. Rob.. ? > > Signed-off-by: Srinivas Kandagatla > --- > .../bindings/soundwire/qcom,sdw.txt | 167 ++ > 1 file changed, 167 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soundwire/qcom,sdw.txt > > diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt > b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt > new file mode 100644 > index ..436547f3b155 > --- /dev/null > +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt > @@ -0,0 +1,167 @@ > +Qualcomm SoundWire Controller Bindings > + > + > +This binding describes the Qualcomm SoundWire Controller along with its > +board specific bus parameters. > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be "qcom,soundwire-v..", > + Example: > + "qcom,soundwire-v1.3.0" > + "qcom,soundwire-v1.5.0" > + "qcom,soundwire-v1.6.0" > +- reg: > + Usage: required > + Value type: > + Definition: the base address and size of SoundWire controller > + address space. > + > +- interrupts: > + Usage: required > + Value type: > + Definition: should specify the SoundWire Controller IRQ > + > +- clock-names: > + Usage: required > + Value type: > + Definition: should be "iface" for SoundWire Controller interface clock > + > +- clocks: > + Usage: required > + Value type: > + Definition: should specify the SoundWire Controller interface clock > + > +- #sound-dai-cells: > + Usage: required > + Value type: > + Definition: must be 1 for digital audio interfaces on the controller. > + > +- qcom,dout-ports: > + Usage: required > + Value type: > + Definition: must be count of data out ports > + > +- qcom,din-ports: > + Usage: required > + Value type: > + Definition: must be count of data in ports > + > +- qcom,ports-offset1: > + Usage: required > + Value type: > + Definition: should specify payload transport window offset1 of each > + data port. Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-offset2: > + Usage: required > + Value type: > + Definition: should specify payload transport window offset2 of each > + data port. Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-sinterval-low: > + Usage: required > + Value type: > + Definition: should be sample interval low of each data port. > + Out ports followed by In ports. Used for Sample Interval > + calculation. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-word-length: > + Usage: optional > + Value type: > + Definition: should be size of payload channel sample. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-block-pack-mode: > + Usage: optional > + Value type: > + Definition: should be 0 or 1 to indicate the block packing mode. > + 0 to indicate Blocks are per Channel > + 1 to indicate Blocks are per Port. > + Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-block-group-count: > + Usage: optional > + Value type: > + Definition: should be in range 1 to 4 to indicate how many sample > + intervals are combined into a payload. > + Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-lane-control: > + Usage: optional > + Value type: > + Definition: should be in range 0 to 7 to identify which data lane > + the data port uses. > + Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-hstart: > + Usage: optional > + Value type: > + Definition: should be number identifying lowerst numbered coloum in > + SoundWire Frame, i.e. left edge of the Transport sub-frame > + for each port. Values between 0 and 15 are valid. > + Out ports followed by In ports. > + More info in MIPI Alliance SoundWire 1.0 Specifications. > + > +- qcom,ports-hstop: > + Usage: optional > + Value type: > + Definition: should be number identifying highest numbered coloum in
[PATCH net-next v4 2/2] r8152: add a helper function about setting EEE
Add a helper function "rtl_eee_enable" for setting EEE. Besides, I
move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(),
r8153_set_eee(), and r8153b_set_eee().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 168 ++--
1 file changed, 77 insertions(+), 91 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a7aa48bee732..17f0e9e98697 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3202,14 +3202,75 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
}
-static void r8152b_enable_eee(struct r8152 *tp)
+static void r8153_eee_en(struct r8152 *tp, bool enable)
{
- if (tp->eee_en) {
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
} else {
- r8152_eee_en(tp, false);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153b_eee_en(struct r8152 *tp, bool enable)
+{
+ r8153_eee_en(tp, enable);
+
+ if (enable)
+ r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
+ else
+ r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
+}
+
+static void rtl_eee_enable(struct r8152 *tp, bool enable)
+{
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ case RTL_VER_07:
+ if (enable) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
+ tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_03:
+ case RTL_VER_04:
+ case RTL_VER_05:
+ case RTL_VER_06:
+ if (enable) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ case RTL_VER_08:
+ case RTL_VER_09:
+ if (enable) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ } else {
+ r8153b_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ }
+ break;
+ default:
+ break;
}
}
@@ -3231,7 +3292,7 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- r8152b_enable_eee(tp);
+ rtl_eee_enable(tp, tp->eee_en);
r8152_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3425,36 +3486,6 @@ static void r8153b_aldps_en(struct r8152 *tp, bool
enable)
r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_ALDPS);
}
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153b_eee_en(struct r8152 *tp, bool enable)
-{
- r8153_eee_en(tp, enable);
-
- if (enable)
- r8153b_ups_flags_w1w0(tp, UPS_FLAGS_EN_EEE, 0);
- else
- r8153b_ups_flags_w1w0(tp, 0, UPS_FLAGS_EN_EEE);
-}
-
static void r8153b_enable_fc(struct r8152 *tp)
{
r8152b_enable_fc(tp);
@@ -3470,8 +3501,7 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8153_aldps_en(tp, false);
/* disable EEE before updating the PHY parameters */
- r8153_eee_en(tp, false);
- ocp_reg_write(tp, OCP_EEE_ADV, 0);
+ rtl_eee_enable(tp, false);
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
@@ -3502,10 +3532,8 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af)
[PATCH net-next v4 0/2] r8152: save EEE
v4: For patch #2, remove redundant calling of "ocp_reg_write(tp, OCP_EEE_ADV, 0)". v3: For patch #2, fix the mistake caused by copying and pasting. v2: Adjust patch #1. The EEE has been disabled in the beginning of r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if it is necessary to enable EEE. Add the patch #2 for the helper function. v1: Saving the settings of EEE to avoid they become the default settings after reset_resume(). Hayes Wang (2): r8152: saving the settings of EEE r8152: add a helper function about setting EEE drivers/net/usb/r8152.c | 182 +--- 1 file changed, 95 insertions(+), 87 deletions(-) -- 2.21.0
[PATCH net-next v4 1/2] r8152: saving the settings of EEE
Saving the settings of EEE to avoid they become the default settings
after reset_resume().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 80 +
1 file changed, 50 insertions(+), 30 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1aa61610f0bb..a7aa48bee732 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -751,6 +751,7 @@ struct r8152 {
atomic_t rx_count;
+ bool eee_en;
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -762,6 +763,7 @@ struct r8152 {
u16 ocp_base;
u16 speed;
+ u16 eee_adv;
u8 *intr_buff;
u8 version;
u8 duplex;
@@ -3202,8 +3204,13 @@ static void r8152_eee_en(struct r8152 *tp, bool enable)
static void r8152b_enable_eee(struct r8152 *tp)
{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, tp->eee_adv);
+ } else {
+ r8152_eee_en(tp, false);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+ }
}
static void r8152b_enable_fc(struct r8152 *tp)
@@ -3495,8 +3502,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
@@ -3599,8 +3608,10 @@ static void r8153b_hw_phy_cfg(struct r8152 *tp)
r8153b_ups_flags_w1w0(tp, ups_flags, 0);
- r8153b_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+ if (tp->eee_en) {
+ r8153b_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
+ }
r8153b_aldps_en(tp, true);
r8153b_enable_fc(tp);
@@ -4891,7 +4902,7 @@ static void rtl8152_get_strings(struct net_device *dev,
u32 stringset, u8 *data)
static int r8152_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = r8152_mmd_read(tp, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
@@ -4903,13 +4914,10 @@ static int r8152_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = r8152_mmd_read(tp, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4919,19 +4927,22 @@ static int r8152_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8152_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8152_eee_en(tp, eee->eee_enabled);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ if (eee->eee_enabled)
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ else
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
return 0;
}
static int r8153_get_eee(struct r8152 *tp, struct ethtool_eee *eee)
{
- u32 ocp_data, lp, adv, supported = 0;
+ u32 lp, adv, supported = 0;
u16 val;
val = ocp_reg_read(tp, OCP_EEE_ABLE);
@@ -4943,13 +4954,10 @@ static int r8153_get_eee(struct r8152 *tp, struct
ethtool_eee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
lp = mmd_eee_adv_to_ethtool_adv_t(val);
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- ocp_data &= EEE_RX_EN | EEE_TX_EN;
-
- eee->eee_enabled = !!ocp_data;
+ eee->eee_enabled = tp->eee_en;
eee->eee_active = !!(supported & adv & lp);
eee->supported = supported;
- eee->advertised = adv;
+ eee->advertised = tp->eee_adv;
eee->lp_advertised = lp;
return 0;
@@ -4959,12 +4967,15 @@ static int r8153_set_eee(struct r8152 *tp, struct
ethtool_eee *eee)
{
u16 val = ethtool_adv_to_mmd_eee_adv_t(eee->advertised);
- r8153_eee_en(tp, eee->eee_enabled);
+ tp->eee_en = eee->eee_enabled;
+ tp->eee_adv = val;
- if (!eee->eee_enabled)
- val = 0;
+ r8153_eee_en(tp, eee->eee
Re: [alsa-devel] [RFC PATCH 31/40] soundwire: intel: move shutdown() callback and don't export symbol
On 14-08-19, 14:31, Pierre-Louis Bossart wrote:
>
>
> > > > > +void intel_shutdown(struct snd_pcm_substream *substream,
> > > > > + struct snd_soc_dai *dai)
> > > > > +{
> > > > > + struct sdw_cdns_dma_data *dma;
> > > > > +
> > > > > + dma = snd_soc_dai_get_dma_data(dai, substream);
> > > > > + if (!dma)
> > > > > + return;
> > > > > +
> > > > > + snd_soc_dai_set_dma_data(dai, substream, NULL);
> > > > > + kfree(dma);
> > > > > +}
> > > >
> > > > Correct me if I'm wrong, but do we really need to _get_dma_ here?
> > > > _set_dma_ seems bulletproof, same for kfree.
> > >
> > > I must admit I have no idea why we have a reference to DMAs here, this
> > > looks
> > > like an abuse to store a dai-specific context, and the initial test looks
> > > like copy-paste to detect invalid configs, as done in other callbacks.
> > > Vinod
> > > and Sanyog might have more history than me here.
> >
> > I dont see snd_soc_dai_set_dma_data() call for
> > sdw_cdns_dma_data so somthing is missing (at least in upstream code)
> >
> > IIRC we should have a snd_soc_dai_set_dma_data() in alloc or some
> > initialization routine and we free it here.. Sanyog?
>
> Vinod, I double-checked that we do not indeed have a call to
> snd_soc_dai_dma_data(), but there is code in cdns_set_stream() that sets the
> relevant dai->playback/capture_dma_data, see below
>
> I am not a big fan of this code, touching the ASoC core internal fields
> isn't a good idea in general.
IIRC as long as you stick to single link I do not see this required. The
question comes into picture when we have multi links as you would need
to allocate a soundwire stream and set that for all the sdw DAIs
So, what is the current model of soundwire stream, which entity allocates
that and do you still care about multi-link? is there any machine driver
with soundwire upstream yet?
> Also not sure why for a DAI we need both _drvdata and _dma_data (especially
_drvdata is global for driver whereas _dma_data is typically used per
DAI
> for this case where the information stored has absolutely nothing to do with
> DMAs).
>
> If the idea was to keep a context that is direction-dependent, that's likely
> unnecessary. For the Intel/Cadence case the interfaces can be configured as
> playback OR capture, not both concurrently, so the "dma" information could
> have been stored in the generic DAI _drvdata.
>
> I have other things to look into for now but this code will likely need to
> be cleaned-up at some point to remove unnecessary parts.
Sure please go ahead and do the cleanup.
>
> int cdns_set_sdw_stream(struct snd_soc_dai *dai,
> void *stream, bool pcm, int direction)
> {
> struct sdw_cdns *cdns = snd_soc_dai_get_drvdata(dai);
> struct sdw_cdns_dma_data *dma;
>
> dma = kzalloc(sizeof(*dma), GFP_KERNEL);
> if (!dma)
> return -ENOMEM;
>
> if (pcm)
> dma->stream_type = SDW_STREAM_PCM;
> else
> dma->stream_type = SDW_STREAM_PDM;
>
> dma->bus = &cdns->bus;
> dma->link_id = cdns->instance;
>
> dma->stream = stream;
>
> >>> this is equivalent to snd_soc_dai_dma_data()
>
> if (direction == SNDRV_PCM_STREAM_PLAYBACK)
> dai->playback_dma_data = dma;
> else
> dai->capture_dma_data = dma;
>
> return 0;
> }
> EXPORT_SYMBOL(cdns_set_sdw_stream);
--
~Vinod
Re: [PATCH v1 1/3] gpio: mpc8xxx: add ls1088a platform gpio node DT binding description
On Thu, Aug 8, 2019 at 12:26 PM Hui Song wrote: > From: Song Hui > > ls1088a and ls1028a platform share common gpio node. > > Signed-off-by: Song Hui Patch applied with Rob's ACK! Yours, Linus Walleij
Re: [PATCH v1 3/3] gpio: mpc8xxx: add ls1088a platform special function
On Thu, Aug 8, 2019 at 12:26 PM Hui Song wrote: > From: Song Hui > > ls1028a and ls1088a platform share common special function. > The gpio hardware what they use is the same version. > > Signed-off-by: Song Hui Patch applied. Yours, Linus Walleij
Re: [RESEND PATCH v2 2/2] usb: xhci-mtk: add an optional xhci_ck clock
On 23/08/2019 08:40, Chunfeng Yun wrote:
> Some SoCs may have an optional clock xhci_ck (125M or 200M), it
> usually uses the same PLL as sys_ck, so support it.
>
> Signed-off-by: Chunfeng Yun
Reviewed-by: Matthias Brugger
> ---
> v2 no changes
> ---
> drivers/usb/host/xhci-mtk.c | 13 +
> drivers/usb/host/xhci-mtk.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index 026fe18972d3..b18a6baef204 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -216,6 +216,10 @@ static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
> return PTR_ERR(mtk->sys_clk);
> }
>
> + mtk->xhci_clk = devm_clk_get_optional(dev, "xhci_ck");
> + if (IS_ERR(mtk->xhci_clk))
> + return PTR_ERR(mtk->xhci_clk);
> +
> mtk->ref_clk = devm_clk_get_optional(dev, "ref_ck");
> if (IS_ERR(mtk->ref_clk))
> return PTR_ERR(mtk->ref_clk);
> @@ -244,6 +248,12 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
> goto sys_clk_err;
> }
>
> + ret = clk_prepare_enable(mtk->xhci_clk);
> + if (ret) {
> + dev_err(mtk->dev, "failed to enable xhci_clk\n");
> + goto xhci_clk_err;
> + }
> +
> ret = clk_prepare_enable(mtk->mcu_clk);
> if (ret) {
> dev_err(mtk->dev, "failed to enable mcu_clk\n");
> @@ -261,6 +271,8 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
> dma_clk_err:
> clk_disable_unprepare(mtk->mcu_clk);
> mcu_clk_err:
> + clk_disable_unprepare(mtk->xhci_clk);
> +xhci_clk_err:
> clk_disable_unprepare(mtk->sys_clk);
> sys_clk_err:
> clk_disable_unprepare(mtk->ref_clk);
> @@ -272,6 +284,7 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk
> *mtk)
> {
> clk_disable_unprepare(mtk->dma_clk);
> clk_disable_unprepare(mtk->mcu_clk);
> + clk_disable_unprepare(mtk->xhci_clk);
> clk_disable_unprepare(mtk->sys_clk);
> clk_disable_unprepare(mtk->ref_clk);
> }
> diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
> index 8be8c5f7ff62..5ac458b7d2e0 100644
> --- a/drivers/usb/host/xhci-mtk.h
> +++ b/drivers/usb/host/xhci-mtk.h
> @@ -139,6 +139,7 @@ struct xhci_hcd_mtk {
> struct regulator *vusb33;
> struct regulator *vbus;
> struct clk *sys_clk;/* sys and mac clock */
> + struct clk *xhci_clk;
> struct clk *ref_clk;
> struct clk *mcu_clk;
> struct clk *dma_clk;
>
Re: [PATCH 5/7] ARM: xscale: fix multi-cpu compilation
On Fri, Aug 9, 2019 at 6:33 PM Arnd Bergmann wrote: > Building a combined ARMv4+XScale kernel produces these > and other build failures: > > /tmp/copypage-xscale-3aa821.s: Assembler messages: > /tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support > `pld [r7,#0]' in ARM mode > /tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support > `pld [r7,#32]' in ARM mode > /tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support > `pld [r1,#0]' in ARM mode > /tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support > `pld [r1,#32]' in ARM mode > /tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support > `pld [r7,#64]' in ARM mode > /tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support > `ldrd r4,r5,[r7],#8' in ARM mode > /tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support > `strd r4,r5,[r1],#8' in ARM mode OK we certainly need this. > Add an explict .arch armv5 in the inline assembly to allow the ARMv5 > specific instructions regardless of the compiler -march= target. You probably mean... > +.arch xscale \n\ > pld [%0, #0]\n\ Explicit .arch xscale rather than .arch armv5. Yours, Linus Walleij
Re: [PATCH v8 0/5] media: Allwinner A10 CSI support
On Thu, Aug 22, 2019 at 10:21:11AM +0200, Maxime Ripard wrote: > From: Maxime Ripard > > Hi, > > Here is a series introducing the support for the A10 (and SoCs of the same > generation) CMOS Sensor Interface (called CSI, not to be confused with > MIPI-CSI, which isn't support by that IP). > > That interface is pretty straightforward, but the driver has a few issues > that I wanted to bring up: > > * The only board I've been testing this with has an ov5640 sensor > attached, which doesn't work with the upstream driver. Copying the > Allwinner init sequence works though, and this is how it has been > tested. Testing with a second sensor would allow to see if it's an > issue on the CSI side or the sensor side. > * We don't have support for the ISP at the moment, but this can be added > eventually. Applied patch 4. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH] brcmfmac: replace strncpy() by strscpy()
The strncpy() may truncate the copied string,
replace it by the safer strscpy().
To avoid below compile warning with gcc 8.2:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:In function
'brcmf_vndr_ie':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4227:2:
warning: 'strncpy' output truncated before terminating nul copying 3 bytes from
a string of the same length [-Wstringop-truncation]
strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
^~~~
Signed-off-by: Xulin Sun
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b6d0df354b36..7ad60374fa96 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4226,9 +4226,7 @@ brcmf_parse_vndr_ies(const u8 *vndr_ie_buf, u32
vndr_ie_len,
static u32
brcmf_vndr_ie(u8 *iebuf, s32 pktflag, u8 *ie_ptr, u32 ie_len, s8 *add_del_cmd)
{
-
- strncpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN - 1);
- iebuf[VNDR_IE_CMD_LEN - 1] = '\0';
+ strscpy(iebuf, add_del_cmd, VNDR_IE_CMD_LEN);
put_unaligned_le32(1, &iebuf[VNDR_IE_COUNT_OFFSET]);
--
2.17.1
Re: [PATCH v1 0/5] Improve MediaTek pinctrl v2 and make backward compatible to smartphone mass production usage
On Tue, Aug 13, 2019 at 10:53 AM Light Hsieh wrote: > This patch improves MediaTek pinctrl v2 and makes backward compatible to > current smartphone mass production usage by: > 1.Check gpio pin number and use binary search in control address lookup > 2.Supporting driving setting without mapping current to register value > 3.Correct usage of PIN_CONFIG get/set implementation I rely on Sean to review and get this in shape. > 4.Backward compatible to previous Mediatek's bias-pull usage This is fine as long as the new style of using explicit pull setting also works. It's nice to be compatible. > 5.Add support for pin configuration dump via sysfs Do you mean debugfs? You should use debugfs for debug. sysfs is subject to ABI rules. Yours, Linus Walleij
Re: [PATCH v5 15/20] RISC-V: KVM: Add timer functionality
On 22.08.19 10:46, Anup Patel wrote:
From: Atish Patra
The RISC-V hypervisor specification doesn't have any virtual timer
feature.
Due to this, the guest VCPU timer will be programmed via SBI calls.
The host will use a separate hrtimer event for each guest VCPU to
provide timer functionality. We inject a virtual timer interrupt to
the guest VCPU whenever the guest VCPU hrtimer event expires.
The following features are not supported yet and will be added in
future:
1. A time offset to adjust guest time from host time
2. A saved next event in guest vcpu for vm migration
Implementing these 2 bits right now should be trivial. Why wait?
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/include/asm/kvm_host.h | 4 +
arch/riscv/include/asm/kvm_vcpu_timer.h | 32 +++
arch/riscv/kvm/Makefile | 2 +-
arch/riscv/kvm/vcpu.c | 6 ++
arch/riscv/kvm/vcpu_timer.c | 106
drivers/clocksource/timer-riscv.c | 8 ++
include/clocksource/timer-riscv.h | 16
7 files changed, 173 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/include/asm/kvm_vcpu_timer.h
create mode 100644 arch/riscv/kvm/vcpu_timer.c
create mode 100644 include/clocksource/timer-riscv.h
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index ab33e59a3d88..d2a2e45eefc0 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_64BIT
#define KVM_MAX_VCPUS (1U << 16)
@@ -167,6 +168,9 @@ struct kvm_vcpu_arch {
unsigned long irqs_pending;
unsigned long irqs_pending_mask;
+ /* VCPU Timer */
+ struct kvm_vcpu_timer timer;
+
/* MMIO instruction details */
struct kvm_mmio_decode mmio_decode;
diff --git a/arch/riscv/include/asm/kvm_vcpu_timer.h b/arch/riscv/include/asm/kvm_vcpu_timer.h
new file mode 100644
index ..df67ea86988e
--- /dev/null
+++ b/arch/riscv/include/asm/kvm_vcpu_timer.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra
+ */
+
+#ifndef __KVM_VCPU_RISCV_TIMER_H
+#define __KVM_VCPU_RISCV_TIMER_H
+
+#include
+
+#define VCPU_TIMER_PROGRAM_THRESHOLD_NS1000
+
+struct kvm_vcpu_timer {
+ bool init_done;
+ /* Check if the timer is programmed */
+ bool is_set;
+ struct hrtimer hrt;
+ /* Mult & Shift values to get nanosec from cycles */
+ u32 mult;
+ u32 shift;
+};
+
+int kvm_riscv_vcpu_timer_init(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_timer_deinit(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_timer_reset(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_timer_next_event(struct kvm_vcpu *vcpu,
+ unsigned long ncycles);
This function never gets called?
+
+#endif
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index c0f57f26c13d..3e0c7558320d 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -9,6 +9,6 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
kvm-objs := $(common-objs-y)
kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
-kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c
index 6124077d154f..018fca436776 100644
--- a/arch/riscv/kvm/vcpu.c
+++ b/arch/riscv/kvm/vcpu.c
@@ -54,6 +54,8 @@ static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu)
memcpy(cntx, reset_cntx, sizeof(*cntx));
+ kvm_riscv_vcpu_timer_reset(vcpu);
+
WRITE_ONCE(vcpu->arch.irqs_pending, 0);
WRITE_ONCE(vcpu->arch.irqs_pending_mask, 0);
}
@@ -108,6 +110,9 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
cntx->hstatus |= HSTATUS_SP2P;
cntx->hstatus |= HSTATUS_SPV;
+ /* Setup VCPU timer */
+ kvm_riscv_vcpu_timer_init(vcpu);
+
/* Reset VCPU */
kvm_riscv_reset_vcpu(vcpu);
@@ -116,6 +121,7 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
{
+ kvm_riscv_vcpu_timer_deinit(vcpu);
kvm_riscv_stage2_flush_cache(vcpu);
kmem_cache_free(kvm_vcpu_cache, vcpu);
}
diff --git a/arch/riscv/kvm/vcpu_timer.c b/arch/riscv/kvm/vcpu_timer.c
new file mode 100644
index ..a45ca06e1aa6
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_timer.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum hrtimer_restart kvm_riscv_vcpu_hrtimer_expired(struct hrtimer *h)
Re: [PATCH v1 5/5] pinctrl: mediatek: Add support for pin configuration dump via sysfs.
Hi Light, thanks for your patch! On Tue, Aug 13, 2019 at 10:53 AM Light Hsieh wrote: > From: Light Hsieh > > Add support for pin configuration dump via catting > /sys/kernel/debug/pinctrl/$platform_dependent_path/pinconf-pins. This is debugfs so rename the subject "*debugfs" > pinctrl framework had already support such dump. This patch implement the > operation function pointer to fullfill this dump. Fair enough, that's fine. > Change-Id: Ib59212eb47febcd84140cbf84e1bd7286769beb0 This has been remarked on before. This patch is missing your Signed-off-by, please fix that. Yours, Linus Walleij
Re: [PATCH] MAINTAINERS: Remove FMC subsystem
On Tue, Aug 13, 2019 at 11:20 PM Denis Efremov wrote: > On 13.08.2019 11:54, Linus Walleij wrote: > > Do you need help to merge the patch? I can take it in the > > GPIO tree since the subsystem was removed there. > > Yes, please. I kindly ask you to take this patch in your tree. OK patch merged into the GPIO tree. Yours, Linus Walleij
[PATCH next v10 10/11] usb: common: add USB GPIO based connection detection driver
Due to the requirement of usb-connector.txt binding, the old way
using extcon to support USB Dual-Role switch is now deprecated
when use Type-B connector.
This patch introduces a USB GPIO based connection detection driver,
used to support Type-B connector which typically uses an input GPIO
to detect USB ID pin, and try to replace the function provided
by the extcon-usb-gpio driver
Signed-off-by: Chunfeng Yun
Tested-by: Nagarjuna Kristam
Reviewed-by: Linus Walleij
---
v10 no changes
v9 changes:
1. add reviewed-by Linus
v8 changes:
1. rename the driver name and usb new compatible suggested by Heikki
2. move the driver into usb/common from usb/roles suggested by Heikki
v7 changes:
1. remove macro DEV_PMS_OPS suggested by Andy
2. add tested-by Nagarjuna
v6 changes:
1. get usb-role-swtich by usb_role_switch_get()
v5 changes:
1. put usb_role_switch when error happens suggested by Biju
2. don't treat bype-B connector as a virtual device suggested by Rob
v4 changes:
1. remove linux/gpio.h suggested by Linus
2. put node when error happens
v3 changes:
1. treat bype-B connector as a virtual device;
2. change file name again
v2 changes:
1. file name is changed
2. use new compatible
---
drivers/usb/common/Kconfig | 13 ++
drivers/usb/common/Makefile| 1 +
drivers/usb/common/usb-conn-gpio.c | 284 +
3 files changed, 298 insertions(+)
create mode 100644 drivers/usb/common/usb-conn-gpio.c
diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig
index 848545b099cf..d611477aae41 100644
--- a/drivers/usb/common/Kconfig
+++ b/drivers/usb/common/Kconfig
@@ -36,3 +36,16 @@ config USB_ULPI_BUS
To compile this driver as a module, choose M here: the module will
be called ulpi.
+config USB_CONN_GPIO
+ tristate "USB GPIO Based Connection Detection Driver"
+ depends on GPIOLIB
+ select USB_ROLE_SWITCH
+ help
+ The driver supports USB role switch between host and device via GPIO
+ based USB cable detection, used typically if an input GPIO is used
+ to detect USB ID pin, and another input GPIO may be also used to
detect
+ Vbus pin at the same time, it also can be used to enable/disable
+ device if an input GPIO is only used to detect Vbus pin.
+
+ To compile the driver as a module, choose M here: the module will
+ be called usb-conn-gpio.ko
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 0a7c45e85481..8227ffc2cf0b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_USB_COMMON) += usb-common.o
usb-common-y += common.o
usb-common-$(CONFIG_USB_LED_TRIG) += led.o
+obj-$(CONFIG_USB_CONN_GPIO)+= usb-conn-gpio.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
diff --git a/drivers/usb/common/usb-conn-gpio.c
b/drivers/usb/common/usb-conn-gpio.c
new file mode 100644
index ..e4935e99f295
--- /dev/null
+++ b/drivers/usb/common/usb-conn-gpio.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USB GPIO Based Connection Detection Driver
+ *
+ * Copyright (C) 2019 MediaTek Inc.
+ *
+ * Author: Chunfeng Yun
+ *
+ * Some code borrowed from drivers/extcon/extcon-usb-gpio.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USB_GPIO_DEB_MS20 /* ms */
+#define USB_GPIO_DEB_US((USB_GPIO_DEB_MS) * 1000) /* us */
+
+#define USB_CONN_IRQF \
+ (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT)
+
+struct usb_conn_info {
+ struct device *dev;
+ struct usb_role_switch *role_sw;
+ enum usb_role last_role;
+ struct regulator *vbus;
+ struct delayed_work dw_det;
+ unsigned long debounce_jiffies;
+
+ struct gpio_desc *id_gpiod;
+ struct gpio_desc *vbus_gpiod;
+ int id_irq;
+ int vbus_irq;
+};
+
+/**
+ * "DEVICE" = VBUS and "HOST" = !ID, so we have:
+ * Both "DEVICE" and "HOST" can't be set as active at the same time
+ * so if "HOST" is active (i.e. ID is 0) we keep "DEVICE" inactive
+ * even if VBUS is on.
+ *
+ * Role | ID | VBUS
+ *
+ * [1] DEVICE| H | H
+ * [2] NONE | H | L
+ * [3] HOST | L | H
+ * [4] HOST | L | L
+ *
+ * In case we have only one of these signals:
+ * - VBUS only - we want to distinguish between [1] and [2], so ID is always 1
+ * - ID only - we want to distinguish between [1] and [4], so VBUS = ID
+ */
+static void usb_conn_detect_cable(struct work_struct *work)
+{
+ struct usb_conn_info *info;
+ enum usb_role role;
+ int id, vbus, ret;
+
+ info = container_of(to_delayed_work(work),
+ struct usb_conn_info, dw_det);
+
+ /* c
[PATCH next v10 04/11] dt-bindings: usb: mtu3: add properties about USB Role Switch
Now the USB Role Switch is supported, so add properties about it,
and modify some description related.
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
---
v6~v10 no changes
v5 changes:
1. modify decription about extcon and vbus-supply properties
2. make this patch depend on [1]
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
v4 no changes
v3 no changes
v2 changes:
1. fix typo
2. refer new binding about connector property
---
.../devicetree/bindings/usb/mediatek,mtu3.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index 3382b5cb471d..3a8300205cdb 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -28,8 +28,13 @@ Optional properties:
parent's address space
- extcon : external connector for vbus and idpin changes detection, needed
when supports dual-role mode.
+ it's considered valid for compatibility reasons, not allowed for
+ new bindings, and use "usb-role-switch" property instead.
- vbus-supply : reference to the VBUS regulator, needed when supports
dual-role mode.
+ it's considered valid for compatibility reasons, not allowed for
+ new bindings, and put into a usb-connector node.
+ see connector/usb-connector.txt.
- pinctrl-names : a pinctrl state named "default" is optional, and need be
defined if auto drd switch is enabled, that means the property dr_mode
is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
@@ -39,6 +44,8 @@ Optional properties:
- maximum-speed : valid arguments are "super-speed", "high-speed" and
"full-speed"; refer to usb/generic.txt
+ - usb-role-switch : use USB Role Switch to support dual-role switch, but
+ not extcon; see usb/generic.txt.
- enable-manual-drd : supports manual dual-role switch via debugfs; usually
used when receptacle is TYPE-A and also wants to support dual-role
mode.
@@ -61,6 +68,9 @@ The xhci should be added as subnode to mtu3 as shown in the
following example
if host mode is enabled. The DT binding details of xhci can be found in:
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+The port would be added as subnode if use "usb-role-switch" property.
+ see graph.txt
+
Example:
ssusb: usb@11271000 {
compatible = "mediatek,mt8173-mtu3";
--
2.23.0
[PATCH next v10 07/11] usb: roles: Add fwnode_usb_role_switch_get() function
From: Heikki Krogerus
The fwnode_usb_role_switch_get() function is exactly the
same as usb_role_switch_get(), except that it takes struct
fwnode_handle as parameter instead of struct device.
Signed-off-by: Heikki Krogerus
Signed-off-by: Chunfeng Yun
Tested-by: Biju Das
---
v10:
revert changes of v9
v9:
replace signed-off-by by suggested-by Heikki
v8: no changes
v7:
add signed-off-by Chunfeng and tested-by Biju
v6:
new patch
---
drivers/usb/roles/class.c | 20
include/linux/usb/role.h | 7 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index 0526efbc4922..2abb6fe384ca 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -123,6 +123,26 @@ struct usb_role_switch *usb_role_switch_get(struct device
*dev)
}
EXPORT_SYMBOL_GPL(usb_role_switch_get);
+/**
+ * fwnode_usb_role_switch_get - Find USB role switch linked with the caller
+ * @fwnode: The caller device node
+ *
+ * This is similar to the usb_role_switch_get() function above, but it searches
+ * the switch using fwnode instead of device entry.
+ */
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle
*fwnode)
+{
+ struct usb_role_switch *sw;
+
+ sw = fwnode_connection_find_match(fwnode, "usb-role-switch", NULL,
+ usb_role_switch_match);
+ if (!IS_ERR_OR_NULL(sw))
+ WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
+
+ return sw;
+}
+EXPORT_SYMBOL_GPL(fwnode_usb_role_switch_get);
+
/**
* usb_role_switch_put - Release handle to a switch
* @sw: USB Role Switch
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index da2b9641b877..2d77f97df72d 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -47,6 +47,7 @@ struct usb_role_switch_desc {
int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
struct usb_role_switch *usb_role_switch_get(struct device *dev);
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *node);
void usb_role_switch_put(struct usb_role_switch *sw);
struct usb_role_switch *
@@ -70,6 +71,12 @@ static inline struct usb_role_switch
*usb_role_switch_get(struct device *dev)
return ERR_PTR(-ENODEV);
}
+static inline struct usb_role_switch *
+fwnode_usb_role_switch_get(struct fwnode_handle *node)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
static inline struct usb_role_switch *
--
2.23.0
[PATCH next v10 11/11] usb: mtu3: register a USB Role Switch for dual role mode
Because extcon is not allowed for new bindings, and the
dual role switch is supported by USB Role Switch,
especially for Type-C drivers, so register a USB Role
Switch to support the new way
Signed-off-by: Chunfeng Yun
---
v5~v10 no changes
v4 changes:
1. assign fwnode member of usb_role_switch struct suggested by Heikki
v3 changes:
1. select USB_ROLE_SWITCH in Kconfig suggested by Heikki
2. rename ssusb_mode_manual_switch() to ssusb_mode_switch()
v2 no changes
---
drivers/usb/mtu3/Kconfig| 1 +
drivers/usb/mtu3/mtu3.h | 5
drivers/usb/mtu3/mtu3_debugfs.c | 4 +--
drivers/usb/mtu3/mtu3_dr.c | 48 -
drivers/usb/mtu3/mtu3_dr.h | 6 ++---
drivers/usb/mtu3/mtu3_plat.c| 3 ++-
6 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 928c2cd6fc00..bf98fd36341d 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -44,6 +44,7 @@ config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y ||
USB_GADGET=USB_MTU3))
depends on (EXTCON=y || EXTCON=USB_MTU3)
+ select USB_ROLE_SWITCH
help
This is the default mode of working of MTU3 controller where
both host and gadget features are enabled.
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 76ecf12fdf62..6087be236a35 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -199,6 +199,9 @@ struct mtu3_gpd_ring {
* @id_nb : notifier for iddig(idpin) detection
* @id_work : work of iddig detection notifier
* @id_event : event of iddig detecion notifier
+* @role_sw : use USB Role Switch to support dual-role switch, can't use
+* extcon at the same time, and extcon is deprecated.
+* @role_sw_used : true when the USB Role Switch is used.
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -212,6 +215,8 @@ struct otg_switch_mtk {
struct notifier_block id_nb;
struct work_struct id_work;
unsigned long id_event;
+ struct usb_role_switch *role_sw;
+ bool role_sw_used;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_debugfs.c b/drivers/usb/mtu3/mtu3_debugfs.c
index 62c57ddc554e..c96e5dab0a48 100644
--- a/drivers/usb/mtu3/mtu3_debugfs.c
+++ b/drivers/usb/mtu3/mtu3_debugfs.c
@@ -453,9 +453,9 @@ static ssize_t ssusb_mode_write(struct file *file, const
char __user *ubuf,
return -EFAULT;
if (!strncmp(buf, "host", 4) && !ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 1);
+ ssusb_mode_switch(ssusb, 1);
} else if (!strncmp(buf, "device", 6) && ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 0);
+ ssusb_mode_switch(ssusb, 0);
} else {
dev_err(ssusb->dev, "wrong or duplicated setting\n");
return -EINVAL;
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 5fcb71af875a..08e18448e8b8 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -7,6 +7,8 @@
* Author: Chunfeng Yun
*/
+#include
+
#include "mtu3.h"
#include "mtu3_dr.h"
#include "mtu3_debug.h"
@@ -280,7 +282,7 @@ static int ssusb_extcon_register(struct otg_switch_mtk
*otg_sx)
* This is useful in special cases, such as uses TYPE-A receptacle but also
* wants to support dual-role mode.
*/
-void ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host)
+void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
@@ -318,6 +320,47 @@ void ssusb_set_force_mode(struct ssusb_mtk *ssusb,
mtu3_writel(ssusb->ippc_base, SSUSB_U2_CTRL(0), value);
}
+static int ssusb_role_sw_set(struct device *dev, enum usb_role role)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ bool to_host = false;
+
+ if (role == USB_ROLE_HOST)
+ to_host = true;
+
+ if (to_host ^ ssusb->is_host)
+ ssusb_mode_switch(ssusb, to_host);
+
+ return 0;
+}
+
+static enum usb_role ssusb_role_sw_get(struct device *dev)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ enum usb_role role;
+
+ role = ssusb->is_host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+ return role;
+}
+
+static int ssusb_role_sw_register(struct otg_switch_mtk *otg_sx)
+{
+ struct usb_role_switch_desc role_sx_desc = { 0 };
+ struct ssusb_mtk *ssusb =
+ container_of(otg_sx, struct ssusb_mtk, otg_switch);
+
+ if (!otg_sx->role_sw_used)
+ return 0;
+
+ role_sx_desc.set = ssusb_role_sw_set;
+ role_sx_desc.get = ssusb_role_sw_get;
+ role_sx_des
[PATCH next v10 09/11] usb: common: create Kconfig file
Create Kconfig file for USB common core, and move USB_LED_TRIG and USB_ULPI_BUS configs into the new file from the parent Kconfig, it will help to add new configs later. Signed-off-by: Chunfeng Yun --- v9~v10: no changes v8: new patch --- drivers/usb/Kconfig| 35 +-- drivers/usb/common/Kconfig | 38 ++ 2 files changed, 39 insertions(+), 34 deletions(-) create mode 100644 drivers/usb/common/Kconfig diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 6e59d370ef81..7bf94e65ed2f 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -36,8 +36,7 @@ menuconfig USB_SUPPORT if USB_SUPPORT -config USB_COMMON - tristate +source "drivers/usb/common/Kconfig" config USB_ARCH_HAS_HCD def_bool y @@ -175,36 +174,4 @@ source "drivers/usb/typec/Kconfig" source "drivers/usb/roles/Kconfig" -config USB_LED_TRIG - bool "USB LED Triggers" - depends on LEDS_CLASS && LEDS_TRIGGERS - select USB_COMMON - help - This option adds LED triggers for USB host and/or gadget activity. - - Say Y here if you are working on a system with led-class supported - LEDs and you want to use them as activity indicators for USB host or - gadget. - -config USB_ULPI_BUS - tristate "USB ULPI PHY interface support" - select USB_COMMON - help - UTMI+ Low Pin Interface (ULPI) is specification for a commonly used - USB 2.0 PHY interface. The ULPI specification defines a standard set - of registers that can be used to detect the vendor and product which - allows ULPI to be handled as a bus. This module is the driver for that - bus. - - The ULPI interfaces (the buses) are registered by the drivers for USB - controllers which support ULPI register access and have ULPI PHY - attached to them. The ULPI PHY drivers themselves are normal PHY - drivers. - - ULPI PHYs provide often functions such as ADP sensing/probing (OTG - protocol) and USB charger detection. - - To compile this driver as a module, choose M here: the module will - be called ulpi. - endif # USB_SUPPORT diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig new file mode 100644 index ..848545b099cf --- /dev/null +++ b/drivers/usb/common/Kconfig @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 + +config USB_COMMON + tristate + + +config USB_LED_TRIG + bool "USB LED Triggers" + depends on LEDS_CLASS && LEDS_TRIGGERS + select USB_COMMON + help + This option adds LED triggers for USB host and/or gadget activity. + + Say Y here if you are working on a system with led-class supported + LEDs and you want to use them as activity indicators for USB host or + gadget. + +config USB_ULPI_BUS + tristate "USB ULPI PHY interface support" + select USB_COMMON + help + UTMI+ Low Pin Interface (ULPI) is specification for a commonly used + USB 2.0 PHY interface. The ULPI specification defines a standard set + of registers that can be used to detect the vendor and product which + allows ULPI to be handled as a bus. This module is the driver for that + bus. + + The ULPI interfaces (the buses) are registered by the drivers for USB + controllers which support ULPI register access and have ULPI PHY + attached to them. The ULPI PHY drivers themselves are normal PHY + drivers. + + ULPI PHYs provide often functions such as ADP sensing/probing (OTG + protocol) and USB charger detection. + + To compile this driver as a module, choose M here: the module will + be called ulpi. + -- 2.23.0
[PATCH next v10 00/11] add USB GPIO based connection detection driver
Because the USB Connector is introduced and the requirement of usb-connector.txt binding, the old way using extcon to support USB Dual-Role switch is now deprecated, meanwhile there is no available common driver when use Type-B connector, typically using an input GPIO to detect USB ID pin. This patch series introduce a USB GPIO based connection detection driver and try to replace the function provided by extcon-usb-gpio driver. v10 changes: 1. revert commit log changes of [06/11] and [07/11] v9 changes: 1. replace signed-off-by by suggested-by Heikki 2. add reviewed-by Linus 3. use class_find_device_by_fwnode() introduced by series [1] [1]: https://lore.kernel.org/patchwork/patch/1103630/ [v3,1/7] drivers: Introduce device lookup variants by name they are already in: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/log/drivers/base/core.c?h=driver-core-next v8 changes: 1. rename the driver's name suggested by Heikki 2. move the driver from usb/roles/ into usb/common/ suggested by Heikki 3. introduce Kconfig for usb common core to add the new driver 4. modify binding of the driver 5. rename the subject title v7 changes: 1. [5/10]: add signed-off-by Chunfeng 2. [6/10]: add signed-off-by Chunfeng 3. [6/10]: depends on linux-next of Rafael's tree [1] 4. [7/10]: add signed-off-by Chunfeng and tested-by Biju 5. [9/10]: add tested-by Nagarjuna, and remove DEV_PMS_OPS suggested by Andy [1] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next v6 changes: 1. merge [1] and [2] into this series 2. don't use graph anymore to find usb-role-switch 3. abandon [3] and introduce three patches (6, 7, 8 in this series) to rebuild APIs getting usb-role-switch [1]: [v3] dt-binding: usb: add usb-role-switch property https://patchwork.kernel.org/patch/10934835/ [2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h https://patchwork.kernel.org/patch/10909971/ [3]: [PATCH v5 4/6] usb: roles: add API to get usb_role_switch by node v5 changes: 1. remove linux/of.h and put usb_role_switch when error happens, suggested by Biju 2. treat Type-B connector as USB controller's child, but not as a virtual device, suggested by Rob 3. provide and use generic property "usb-role-switch", see [1], suggested by Rob Note: this series still depends on [2] [1]: [v3] dt-binding: usb: add usb-role-switch property https://patchwork.kernel.org/patch/10934835/ [2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h https://patchwork.kernel.org/patch/10909971/ v4 changes: 1. use switch_fwnode_match() to find fwnode suggested by Heikki 2. assign fwnode member of usb_role_switch struct suggested by Heikki 3. make [4/6] depend on [2] 3. remove linux/gpio.h suggested by Linus 4. put node when error happens [4/6] usb: roles: add API to get usb_role_switch by node [2] [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h https://patchwork.kernel.org/patch/10909971/ v3 changes: 1. add GPIO direction, and use fixed-regulator for GPIO controlled VBUS regulator suggested by Rob; 2. rebuild fwnode_usb_role_switch_get() suggested by Andy and Heikki 3. treat the type-B connector as a virtual device; 4. change file name of driver again 5. select USB_ROLE_SWITCH in mtu3/Kconfig suggested by Heikki 6. rename ssusb_mode_manual_switch() to ssusb_mode_switch() v2 changes: 1. make binding clear, and add a extra compatible suggested by Hans Chunfeng Yun (8): dt-binding: usb: add usb-role-switch property dt-bindings: connector: add optional properties for Type-B dt-bindings: usb: add binding for USB GPIO based connection detection driver dt-bindings: usb: mtu3: add properties about USB Role Switch usb: roles: get usb-role-switch from parent usb: common: create Kconfig file usb: common: add USB GPIO based connection detection driver usb: mtu3: register a USB Role Switch for dual role mode Heikki Krogerus (2): device connection: Add fwnode_connection_find_match() usb: roles: Add fwnode_usb_role_switch_get() function Yu Chen (1): usb: roles: Introduce stubs for the exiting functions in role.h .../bindings/connector/usb-connector.txt | 14 + .../devicetree/bindings/usb/generic.txt | 4 + .../devicetree/bindings/usb/mediatek,mtu3.txt | 10 + .../devicetree/bindings/usb/usb-conn-gpio.txt | 31 ++ drivers/base/devcon.c | 43 ++- drivers/usb/Kconfig | 35 +-- drivers/usb/common/Kconfig| 51 drivers/usb/common/Makefile | 1 + drivers/usb/common/usb-conn-gpio.c| 284 ++ drivers/usb/mtu3/Kconfig | 1 + drivers/usb/mtu3/mtu3.h | 5 + drivers/usb/mtu3/mtu3_debugfs.c | 4 +- dri
[PATCH next v10 02/11] dt-bindings: connector: add optional properties for Type-B
Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for usb-b-connector Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring --- v6~v10 no changes v5 changes: 1. add reviewed by Rob v4 no changes v3 changes: 1. add GPIO direction, and use fixed-regulator for GPIO controlled VBUS regulator suggested by Rob; v2 changes: 1. describe more clear for vbus-gpios and vbus-supply suggested by Hans --- .../bindings/connector/usb-connector.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt index cef556d4e5ee..d357987181ee 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.txt +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt @@ -17,6 +17,20 @@ Optional properties: - self-powered: Set this property if the usb device that has its own power source. +Optional properties for usb-b-connector: +- id-gpios: an input gpio for USB ID pin. +- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of + VBUS 5V. + see gpio/gpio.txt. +- vbus-supply: a phandle to the regulator for USB VBUS if needed when host + mode or dual role mode is supported. + Particularly, if use an output GPIO to control a VBUS regulator, should + model it as a regulator. + see regulator/fixed-regulator.yaml +- pinctrl-names : a pinctrl state named "default" is optional +- pinctrl-0 : pin control group + see pinctrl/pinctrl-bindings.txt + Optional properties for usb-c-connector: - power-role: should be one of "source", "sink" or "dual"(DRP) if typec connector has power support. -- 2.23.0
[PATCH next v10 06/11] device connection: Add fwnode_connection_find_match()
From: Heikki Krogerus
The fwnode_connection_find_match() function is exactly the
same as device_connection_find_match(), except it takes
struct fwnode_handle as parameter instead of struct device.
That allows locating device connections before the device
entries have been created.
Signed-off-by: Heikki Krogerus
Signed-off-by: Chunfeng Yun
---
v10:
revert changes of v9
v9:
replace signed-off-by by suggested-by Heikki
v8: no changes
v7:
rebased on Rafael's tree [1] (after rc4), provided by Heikki
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next
v6:
new patch
---
drivers/base/devcon.c | 43 ++
include/linux/device.h | 10 +++---
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index 1d488dc5dd0c..14e2178e09f8 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -12,9 +12,6 @@
static DEFINE_MUTEX(devcon_lock);
static LIST_HEAD(devcon_list);
-typedef void *(*devcon_match_fn_t)(struct device_connection *con, int ep,
- void *data);
-
static void *
fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
void *data, devcon_match_fn_t match)
@@ -60,6 +57,34 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char
*con_id,
return NULL;
}
+/**
+ * fwnode_connection_find_match - Find connection from a device node
+ * @fwnode: Device node with the connection
+ * @con_id: Identifier for the connection
+ * @data: Data for the match function
+ * @match: Function to check and convert the connection description
+ *
+ * Find a connection with unique identifier @con_id between @fwnode and another
+ * device node. @match will be used to convert the connection description to
+ * data the caller is expecting to be returned.
+ */
+void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
+ const char *con_id, void *data,
+ devcon_match_fn_t match)
+{
+ void *ret;
+
+ if (!fwnode || !match)
+ return NULL;
+
+ ret = fwnode_graph_devcon_match(fwnode, con_id, data, match);
+ if (ret)
+ return ret;
+
+ return fwnode_devcon_match(fwnode, con_id, data, match);
+}
+EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
+
/**
* device_connection_find_match - Find physical connection to a device
* @dev: Device with the connection
@@ -83,15 +108,9 @@ void *device_connection_find_match(struct device *dev,
const char *con_id,
if (!match)
return NULL;
- if (fwnode) {
- ret = fwnode_graph_devcon_match(fwnode, con_id, data, match);
- if (ret)
- return ret;
-
- ret = fwnode_devcon_match(fwnode, con_id, data, match);
- if (ret)
- return ret;
- }
+ ret = fwnode_connection_find_match(fwnode, con_id, data, match);
+ if (ret)
+ return ret;
mutex_lock(&devcon_lock);
diff --git a/include/linux/device.h b/include/linux/device.h
index 8ae3f4b47293..93626476c9ae 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1009,10 +1009,14 @@ struct device_connection {
struct list_headlist;
};
+typedef void *(*devcon_match_fn_t)(struct device_connection *con, int ep,
+ void *data);
+
+void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
+ const char *con_id, void *data,
+ devcon_match_fn_t match);
void *device_connection_find_match(struct device *dev, const char *con_id,
- void *data,
- void *(*match)(struct device_connection *con,
- int ep, void *data));
+ void *data, devcon_match_fn_t match);
struct device *device_connection_find(struct device *dev, const char *con_id);
--
2.23.0
[PATCH next v10 01/11] dt-binding: usb: add usb-role-switch property
Add a property usb-role-switch to tell the driver that use USB Role Switch framework to handle the role switch, it's useful when the driver has already supported other ways, such as extcon framework etc. Cc: Biju Das Cc: Yu Chen Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring Reviewed-by: Heikki Krogerus --- v7~v10: no changes v6: 1. merge into this series patch 2. add Reviewed-by (no v4, v5) v3: add property type, modify description suggested by Heikki v2: describe it in terms of h/w functionality suggested by Rob v1: the property is discussed in: [v2,2/7] dt-bindings: usb: renesas_usb3: add usb-role-switch property https://patchwork.kernel.org/patch/10852497/ Mediatek and Hisilicon also try to use it: [v4,3/6] dt-bindings: usb: mtu3: add properties about USB Role Switch https://patchwork.kernel.org/patch/10918385/ [v4,6/6] usb: mtu3: register a USB Role Switch for dual role mode https://patchwork.kernel.org/patch/10918367/ [v6,10/13] usb: dwc3: Registering a role switch in the DRD code https://patchwork.kernel.org/patch/10909981/ --- Documentation/devicetree/bindings/usb/generic.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt index 0a74ab8dfdc2..cf5a1ad456e6 100644 --- a/Documentation/devicetree/bindings/usb/generic.txt +++ b/Documentation/devicetree/bindings/usb/generic.txt @@ -30,6 +30,10 @@ Optional properties: optional for OTG device. - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is optional for OTG device. + - usb-role-switch: boolean, indicates that the device is capable of assigning + the USB data role (USB host or USB device) for a given + USB connector, such as Type-C, Type-B(micro). + see connector/usb-connector.txt. This is an attribute to a USB controller such as: -- 2.23.0
[PATCH next v10 08/11] usb: roles: get usb-role-switch from parent
when the USB host controller is the parent of the connector,
usually type-B, sometimes don't need the graph, so we should
check whether it's parent registers usb-role-switch or not
firstly, and get it if exists.
Suggested-by: Heikki Krogerus
Signed-off-by: Chunfeng Yun
---
v10: no changes
v9:
1. replace signed-off-by by suggested-by Heikki
2. use class_find_device_by_fwnode()
v8: no changes
v7:
add signed-off-by Chunfeng
v6:
new patch
---
drivers/usb/roles/class.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index 2abb6fe384ca..94b4e7db2b94 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -102,6 +102,19 @@ static void *usb_role_switch_match(struct
device_connection *con, int ep,
return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
}
+static struct usb_role_switch *
+usb_role_switch_is_parent(struct fwnode_handle *fwnode)
+{
+ struct fwnode_handle *parent = fwnode_get_parent(fwnode);
+ struct device *dev;
+
+ if (!parent || !fwnode_property_present(parent, "usb-role-switch"))
+ return NULL;
+
+ dev = class_find_device_by_fwnode(role_class, parent);
+ return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
+}
+
/**
* usb_role_switch_get - Find USB role switch linked with the caller
* @dev: The caller device
@@ -113,8 +126,10 @@ struct usb_role_switch *usb_role_switch_get(struct device
*dev)
{
struct usb_role_switch *sw;
- sw = device_connection_find_match(dev, "usb-role-switch", NULL,
- usb_role_switch_match);
+ sw = usb_role_switch_is_parent(dev_fwnode(dev));
+ if (!sw)
+ sw = device_connection_find_match(dev, "usb-role-switch", NULL,
+ usb_role_switch_match);
if (!IS_ERR_OR_NULL(sw))
WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
@@ -134,8 +149,10 @@ struct usb_role_switch *fwnode_usb_role_switch_get(struct
fwnode_handle *fwnode)
{
struct usb_role_switch *sw;
- sw = fwnode_connection_find_match(fwnode, "usb-role-switch", NULL,
- usb_role_switch_match);
+ sw = usb_role_switch_is_parent(fwnode);
+ if (!sw)
+ sw = fwnode_connection_find_match(fwnode, "usb-role-switch",
+ NULL, usb_role_switch_match);
if (!IS_ERR_OR_NULL(sw))
WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
--
2.23.0
[PATCH next v10 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
It's used to support dual role switch via GPIO when use Type-B
receptacle, typically the USB ID pin is connected to an input
GPIO, and also used to enable/disable device when the USB Vbus
pin is connected to an input GPIO.
Signed-off-by: Chunfeng Yun
---
v9~v10 no changes
v8 changes:
1. rename the title
2. change the compatible as "linux,usb-conn-gpio" instead of
"linux,typeb-conn-gpio"
v7 changes:
1. add description for device only mode
v6 changes:
1. remove status and port nodes in example
2. make vbus-supply as optional property
v5 changes:
1. treat type-B connector as child device of USB controller's, but not
as a separate virtual device, suggested by Rob
2. put connector's port node under connector node, suggested by Rob
v4 no changes
v3 changes:
1. treat type-B connector as a virtual device, but not child device of
USB controller's
v2 changes:
1. new patch to make binding clear suggested by Hans
---
.../devicetree/bindings/usb/usb-conn-gpio.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
new file mode 100644
index ..d4d107fedc22
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
@@ -0,0 +1,31 @@
+USB GPIO Based Connection Detection
+
+This is typically used to switch dual role mode from the USB ID pin connected
+to an input GPIO, and also used to enable/disable device mode from the USB
+Vbus pin connected to an input GPIO.
+
+Required properties:
+- compatible : should include "linux,usb-conn-gpio" and "usb-b-connector".
+- id-gpios, vbus-gpios : input gpios, either one of them must be present,
+ and both can be present as well.
+ see connector/usb-connector.txt
+
+Optional properties:
+- vbus-supply : can be present if needed when supports dual role mode.
+ see connector/usb-connector.txt
+
+- Sub-nodes:
+ - port : can be present.
+ see graph.txt
+
+Example:
+
+&mtu3 {
+ connector {
+ compatible = "linux,usb-conn-gpio", "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
+ vbus-supply = <&usb_p0_vbus>;
+ };
+};
--
2.23.0
[PATCH next v10 05/11] usb: roles: Introduce stubs for the exiting functions in role.h
From: Yu Chen
This patch adds stubs for the exiting functions while
CONFIG_USB_ROLE_SWITCH does not enabled.
Cc: Greg Kroah-Hartman
Cc: Heikki Krogerus
Cc: Hans de Goede
Cc: Andy Shevchenko
Cc: John Stultz
Reviewed-by: Heikki Krogerus
Signed-off-by: Yu Chen
Signed-off-by: Chunfeng Yun
---
v8~v10 no changes
v7:
add Signed-off-by Chunfeng
v6:
merge this patch [1] into this series to add new API
[1] https://patchwork.kernel.org/patch/10909971/
---
include/linux/usb/role.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index c05ffa6abda9..da2b9641b877 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -42,6 +42,8 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
};
+
+#if IS_ENABLED(CONFIG_USB_ROLE_SWITCH)
int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
struct usb_role_switch *usb_role_switch_get(struct device *dev);
@@ -51,5 +53,33 @@ struct usb_role_switch *
usb_role_switch_register(struct device *parent,
const struct usb_role_switch_desc *desc);
void usb_role_switch_unregister(struct usb_role_switch *sw);
+#else
+static inline int usb_role_switch_set_role(struct usb_role_switch *sw,
+ enum usb_role role)
+{
+ return 0;
+}
+
+static inline enum usb_role usb_role_switch_get_role(struct usb_role_switch
*sw)
+{
+ return USB_ROLE_NONE;
+}
+
+static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
+
+static inline struct usb_role_switch *
+usb_role_switch_register(struct device *parent,
+const struct usb_role_switch_desc *desc)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_unregister(struct usb_role_switch *sw) { }
+#endif
#endif /* __LINUX_USB_ROLE_H */
--
2.23.0
Re: [PATCH 1/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150 support
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul wrote: > Add support for the PM8150 GPIO support to the Qualcomm PMIC GPIO > binding. > > Signed-off-by: Vinod Koul Patch applied as lightweight and uncontroversial. Yours, Linus Walleij
Re: [PATCH 2/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150b support
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul wrote: > Add support for the PM8150b GPIO support to the Qualcomm PMIC GPIO > binding. > > Signed-off-by: Vinod Koul Patch applied. Yours, Linus Walleij
Re: [PATCH] x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386
On Thu, Aug 22, 2019 at 02:11:22PM -0700, Sean Christopherson wrote:
> Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to
> avoid clobbering flags.
>
> KVM's emulator makes indirect calls into a jump table of sorts, where
> the destination of the CALL_NOSPEC is a small blob of code that performs
> fast emulation by executing the target instruction with fixed operands.
>
> adcb_al_dl:
> 0x000339f8 <+0>: adc%dl,%al
> 0x000339fa <+2>: ret
>
> A major motiviation for doing fast emulation is to leverage the CPU to
> handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is
> both an input and output to the target of CALL_NOSPEC. Clobbering flags
> results in all sorts of incorrect emulation, e.g. Jcc instructions often
> take the wrong path. Sans the nops...
>
> asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
> 0x0003595a <+58>: mov0xc0(%ebx),%eax
> 0x00035960 <+64>: mov0x60(%ebx),%edx
> 0x00035963 <+67>: mov0x90(%ebx),%ecx
> 0x00035969 <+73>: push %edi
> 0x0003596a <+74>: popf
> 0x0003596b <+75>: call *%esi
> 0x000359a0 <+128>: pushf
> 0x000359a1 <+129>: pop%edi
> 0x000359a2 <+130>: mov%eax,0xc0(%ebx)
> 0x000359b1 <+145>: mov%edx,0x60(%ebx)
>
> ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
> 0x000359a8 <+136>: mov-0x10(%ebp),%eax
> 0x000359ab <+139>: and$0x8d5,%edi
> 0x000359b4 <+148>: and$0xf72a,%eax
> 0x000359b9 <+153>: or %eax,%edi
> 0x000359bd <+157>: mov%edi,0x4(%ebx)
>
> For the most part this has gone unnoticed as emulation of guest code
> that can trigger fast emulation is effectively limited to MMIO when
> running on modern hardware, and MMIO is rarely, if ever, accessed by
> instructions that affect or consume flags.
Also, because nobody every uses 32bit anymore, I suspect ;-)
> Breakage is almost instantaneous when running with unrestricted guest
> disabled, in which case KVM must emulate all instructions when the guest
> has invalid state, e.g. when the guest is in Big Real Mode during early
> BIOS.
>
> Cc: Peter Zijlstra
> Cc: Paolo Bonzini
> Cc:
> Cc:
> Fixes: 1a29b5b7f347a ("KVM: x86: Make indirect calls in emulator speculation
> safe")
Cute; arguably this is a fix for:
776b043848fd2 ("x86/retpoline: Add initial retpoline support")
The patch you quote just happens to trigger it in KVM, but you're right
to note that CALL shouldn't frob EFLAGS, and who knows what possible
other sites care.
Anyway,
Acked-by: Peter Zijlstra (Intel)
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/include/asm/nospec-branch.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/nospec-branch.h
> b/arch/x86/include/asm/nospec-branch.h
> index 109f974f9835..80bc209c0708 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -192,7 +192,7 @@
> " lfence;\n" \
> " jmp902b;\n" \
> " .align 16\n"\
> - "903: addl $4, %%esp;\n"\
> + "903: lea4(%%esp), %%esp;\n" \
> " pushl %[thunk_target];\n" \
> " ret;\n" \
> " .align 16\n"\
> --
> 2.22.0
>
Re: [PATCH 3/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150l support
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul wrote: > Add support for the PM8150l GPIO support to the Qualcomm PMIC GPIO > binding. > > Signed-off-by: Vinod Koul Patch applied. Yours, Linus Walleij
Re: [PATCH 4.9 000/103] 4.9.190-stable review
On Thu, 22 Aug 2019 at 22:53, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.190 release. > There are 103 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 24 Aug 2019 05:15:44 PM UTC. > 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.9.190-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.190-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 7a35fdc061cdc806d06bb3a34ed5c9c0d08ffc0d git describe: v4.9.189-104-g7a35fdc061cd Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.189-104-g7a35fdc061cd No regressions (compared to build v4.9.189) No fixes (compared to build v4.9.189) Ran 22554 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * ltp-syscalls-tests * network-basic-tests * ltp-open-posix-tests * prep-tmp-disk * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 00/71] 4.14.140-stable review
On Thu, 22 Aug 2019 at 22:55, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.140 release. > There are 71 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 24 Aug 2019 05:15:46 PM UTC. > 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.140-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. Summary kernel: 4.14.140-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: c62e7b28b99c68e465814b56bc02089022f90fc1 git describe: v4.14.139-72-gc62e7b28b99c Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.139-72-gc62e7b28b99c No regressions (compared to build v4.14.139) No fixes (compared to build v4.14.139) Ran 22435 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * v4l2-compliance * ltp-ipc-tests * perf * ltp-open-posix-tests * network-basic-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v5 18/20] RISC-V: KVM: Add SBI v0.1 support
On 22.08.19 10:46, Anup Patel wrote:
From: Atish Patra
The KVM host kernel running in HS-mode needs to handle SBI calls coming
from guest kernel running in VS-mode.
This patch adds SBI v0.1 support in KVM RISC-V. All the SBI calls are
implemented correctly except remote tlb flushes. For remote TLB flushes,
we are doing full TLB flush and this will be optimized in future.
Signed-off-by: Atish Patra
Signed-off-by: Anup Patel
Acked-by: Paolo Bonzini
Reviewed-by: Paolo Bonzini
---
arch/riscv/include/asm/kvm_host.h | 2 +
arch/riscv/kvm/Makefile | 2 +-
arch/riscv/kvm/vcpu_exit.c| 3 +
arch/riscv/kvm/vcpu_sbi.c | 119 ++
4 files changed, 125 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/kvm/vcpu_sbi.c
diff --git a/arch/riscv/include/asm/kvm_host.h
b/arch/riscv/include/asm/kvm_host.h
index 2af3a179c08e..0b1eceaef59f 100644
--- a/arch/riscv/include/asm/kvm_host.h
+++ b/arch/riscv/include/asm/kvm_host.h
@@ -241,4 +241,6 @@ bool kvm_riscv_vcpu_has_interrupt(struct kvm_vcpu *vcpu);
void kvm_riscv_vcpu_power_off(struct kvm_vcpu *vcpu);
void kvm_riscv_vcpu_power_on(struct kvm_vcpu *vcpu);
+int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu);
+
#endif /* __RISCV_KVM_HOST_H__ */
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 3e0c7558320d..b56dc1650d2c 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/Makefile
@@ -9,6 +9,6 @@ ccflags-y := -Ivirt/kvm -Iarch/riscv/kvm
kvm-objs := $(common-objs-y)
kvm-objs += main.o vm.o vmid.o tlb.o mmu.o
-kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o
+kvm-objs += vcpu.o vcpu_exit.o vcpu_switch.o vcpu_timer.o vcpu_sbi.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/arch/riscv/kvm/vcpu_exit.c b/arch/riscv/kvm/vcpu_exit.c
index fbc04fe335ad..87b83fcf9a14 100644
--- a/arch/riscv/kvm/vcpu_exit.c
+++ b/arch/riscv/kvm/vcpu_exit.c
@@ -534,6 +534,9 @@ int kvm_riscv_vcpu_exit(struct kvm_vcpu *vcpu, struct
kvm_run *run,
(vcpu->arch.guest_context.hstatus & HSTATUS_STL))
ret = stage2_page_fault(vcpu, run, scause, stval);
break;
+ case EXC_SUPERVISOR_SYSCALL:
+ if (vcpu->arch.guest_context.hstatus & HSTATUS_SPV)
+ ret = kvm_riscv_vcpu_sbi_ecall(vcpu);
default:
break;
};
diff --git a/arch/riscv/kvm/vcpu_sbi.c b/arch/riscv/kvm/vcpu_sbi.c
new file mode 100644
index ..5793202eb514
--- /dev/null
+++ b/arch/riscv/kvm/vcpu_sbi.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Atish Patra
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SBI_VERSION_MAJOR 0
+#define SBI_VERSION_MINOR 1
+
+/* TODO: Handle traps due to unpriv load and redirect it back to VS-mode */
Ugh, another one of those? Can't you just figure out a way to recover
from the page fault? Also, you want to combine this with the instruction
load logic, so that we have a single place that guest address space
reads go through.
+static unsigned long kvm_sbi_unpriv_load(const unsigned long *addr,
+struct kvm_vcpu *vcpu)
+{
+ unsigned long flags, val;
+ unsigned long __hstatus, __sstatus;
+
+ local_irq_save(flags);
+ __hstatus = csr_read(CSR_HSTATUS);
+ __sstatus = csr_read(CSR_SSTATUS);
+ csr_write(CSR_HSTATUS, vcpu->arch.guest_context.hstatus | HSTATUS_SPRV);
+ csr_write(CSR_SSTATUS, vcpu->arch.guest_context.sstatus);
+ val = *addr;
+ csr_write(CSR_HSTATUS, __hstatus);
+ csr_write(CSR_SSTATUS, __sstatus);
+ local_irq_restore(flags);
+
+ return val;
+}
+
+static void kvm_sbi_system_shutdown(struct kvm_vcpu *vcpu, u32 type)
+{
+ int i;
+ struct kvm_vcpu *tmp;
+
+ kvm_for_each_vcpu(i, tmp, vcpu->kvm)
+ tmp->arch.power_off = true;
+ kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
+
+ memset(&vcpu->run->system_event, 0, sizeof(vcpu->run->system_event));
+ vcpu->run->system_event.type = type;
+ vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
+}
+
+int kvm_riscv_vcpu_sbi_ecall(struct kvm_vcpu *vcpu)
+{
+ int ret = 1;
+ u64 next_cycle;
+ int vcpuid;
+ struct kvm_vcpu *remote_vcpu;
+ ulong dhart_mask;
+ struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
+
+ if (!cp)
+ return -EINVAL;
+ switch (cp->a7) {
+ case SBI_SET_TIMER:
+#if __riscv_xlen == 32
+ next_cycle = ((u64)cp->a1 << 32) | (u64)cp->a0;
+#else
+ next_cycle = (u64)cp->a0;
+#endif
+ kvm_riscv_vcpu_timer_next_event(vcpu, next_cycle);
Ah, this is where the timer set happens. I still don't understand how
this takes the frequency bit into account?
Re: [PATCH] perf/x86/intel: restrict period on Nehalem
On Mon, Aug 19, 2019 at 07:13:31PM -0400, Josh Hunt wrote: > We see our Nehalem machines reporting 'perfevents: irq loop stuck!' in > some cases when using perf: > > perfevents: irq loop stuck! > I found that a period limit of 32 was the lowest I could set it to without > the problem reoccurring. The idea for the patch and approach to find the > target value were suggested by Ingo and Thomas. > > Signed-off-by: Josh Hunt > Reported-by: Bhupesh Purandare > Suggested-by: Thomas Gleixner > Suggested-by: Ingo Molnar > Link: https://lore.kernel.org/lkml/20150501070226.gb18...@gmail.com/ > Link: > https://lore.kernel.org/lkml/alpine.deb.2.21.1908122133310.7...@nanos.tec.linutronix.de/ Thanks!
Re: [PATCH 4.19 00/85] 4.19.68-stable review
On Thu, 22 Aug 2019 at 22:57, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.68 release. > There are 85 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 24 Aug 2019 05:15:49 PM UTC. > 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.19.68-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.19.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. Summary kernel: 4.19.68-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 1ca4133a7b4ede95223d2f4e85900ad6565ca8f9 git describe: v4.19.67-86-g1ca4133a7b4e Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.67-86-g1ca4133a7b4e No regressions (compared to build v4.19.67) No fixes (compared to build v4.19.67) Ran 24105 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-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-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * spectre-meltdown-checker-test * ltp-fs-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * v4l2-compliance * ltp-open-posix-tests * kvm-unit-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v5 00/20] KVM RISC-V Support
On 22.08.19 10:42, Anup Patel wrote: This series adds initial KVM RISC-V support. Currently, we are able to boot RISC-V 64bit Linux Guests with multiple VCPUs. Few key aspects of KVM RISC-V added by this series are: 1. Minimal possible KVM world-switch which touches only GPRs and few CSRs. 2. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure. 3. KVM ONE_REG interface for VCPU register access from user-space. 4. PLIC emulation is done in user-space. In-kernel PLIC emulation, will be added in future. 5. Timer and IPI emuation is done in-kernel. 6. MMU notifiers supported. 7. FP lazy save/restore supported. 8. SBI v0.1 emulation for KVM Guest available. Here's a brief TODO list which we will work upon after this series: 1. Handle trap from unpriv access in reading Guest instruction 2. Handle trap from unpriv access in SBI v0.1 emulation 3. Implement recursive stage2 page table programing 4. SBI v0.2 emulation in-kernel 5. SBI v0.2 hart hotplug emulation in-kernel 6. In-kernel PLIC emulation 7. . and more . Please consider patches I did not comment on as Reviewed-by: Alexander Graf Overall, I'm quite happy with the code. It's a very clean implementation of a KVM target. The only major nit I have is the guest address space read: I don't think we should pull in code that we know allows user space to DOS the kernel. For that, we need to find an alternative. Either you implement a software page table walker and resolve VAs manually or you find a way to ensure that *any* exception taken during the read does not affect general code execution. Thanks, Alex
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On Thu, 22 Aug 2019 at 22:38, Sasha Levin wrote: > > > This is the start of the stable review cycle for the 5.2.10 release. > There are 135 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 24 Aug 2019 05:07:10 PM UTC. > 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-5.2.10-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-5.2.y > and the diffstat can be found below. > > -- > Thanks, > Sasha Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.2.10-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.2.y git commit: f5284fbdcd34b923c32f702a0d46a00b9e744d71 git describe: v5.2.9-135-gf5284fbdcd34 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.9-135-gf5284fbdcd34 No regressions (compared to build v5.2.9) No fixes (compared to build v5.2.9) Ran 22639 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-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-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2] i2c: mediatek: disable zero-length transfers for mt8183
On Thu, 2019-08-22 at 17:45 +0800, Hsin-Yi Wang wrote:
> When doing i2cdetect quick write mode, we would get transfer
> error ENOMEM, and i2cdetect shows there's no device at the address.
> Quoting from mt8183 datasheet, the number of transfers to be
> transferred in one transaction should be set to bigger than 1,
> so we should forbid zero-length transfer and update functionality.
>
> Incorrect return:
> localhost ~ # i2cdetect -q -y 0
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> After this patch:
> localhost ~ # i2cdetect -q -y 0
> Error: Can't use SMBus Quick Write command on this bus
>
> localhost ~ # i2cdetect -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Reported-by: Alexandru M Stan
> Signed-off-by: Hsin-Yi Wang
> ---
> Change from v1:
> * restore the order of algo and quirks
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 252edb433fdf..29eae1bf4f86 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -234,6 +234,10 @@ static const struct i2c_adapter_quirks mt7622_i2c_quirks
> = {
> .max_num_msgs = 255,
> };
>
> +static const struct i2c_adapter_quirks mt8183_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN,
> +};
> +
> static const struct mtk_i2c_compatible mt2712_compat = {
> .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> @@ -298,6 +302,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
> };
>
> static const struct mtk_i2c_compatible mt8183_compat = {
> + .quirks = &mt8183_i2c_quirks,
> .regs = mt_i2c_regs_v2,
> .pmic_i2c = 0,
> .dcm = 0,
> @@ -870,7 +875,11 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
>
> static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
> {
> - return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> + if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
> + return I2C_FUNC_I2C |
> + (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> + else
> + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
It can be removed?
> }
>
> static const struct i2c_algorithm mtk_i2c_algorithm = {
Re: [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool
On Thu, Aug 22, 2019 at 7:23 PM Andrew Morton wrote:
>
> On Tue, 20 Aug 2019 11:59:39 +0900 Sergey Senozhatsky
> wrote:
>
> > On (08/09/19 11:17), Henry Burns wrote:
> > > In zs_destroy_pool() we call flush_work(&pool->free_work). However, we
> > > have no guarantee that migration isn't happening in the background
> > > at that time.
> > >
> > > Since migration can't directly free pages, it relies on free_work
> > > being scheduled to free the pages. But there's nothing preventing an
> > > in-progress migrate from queuing the work *after*
> > > zs_unregister_migration() has called flush_work(). Which would mean
> > > pages still pointing at the inode when we free it.
> > >
> > > Since we know at destroy time all objects should be free, no new
> > > migrations can come in (since zs_page_isolate() fails for fully-free
> > > zspages). This means it is sufficient to track a "# isolated zspages"
> > > count by class, and have the destroy logic ensure all such pages have
> > > drained before proceeding. Keeping that state under the class
> > > spinlock keeps the logic straightforward.
> > >
> > > Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
> > > Signed-off-by: Henry Burns
> >
> > Reviewed-by: Sergey Senozhatsky
> >
>
> Thanks. So we have a couple of races which result in memory leaks? Do
> we feel this is serious enough to justify a -stable backport of the
> fixes?
In this case a memory leak could lead to an eventual crash if
compaction hits the leaked page. I don't know what a -stable
backport entails, but this crash would only occur if people are
changing their zswap backend at runtime
(which eventually starts destruction).
Re: [PATCH v2 -next] soundwire: Fix -Wunused-function warning
On 2019/8/23 14:44, Vinod Koul wrote: > On 22-08-19, 22:54, YueHaibing wrote: >> If CONFIG_ACPI is not set, gcc warning this: >> >> drivers/soundwire/slave.c:16:12: warning: >> 'sdw_slave_add' defined but not used [-Wunused-function] >> >> Now all code in slave.c is only used on ACPI enabled, >> so compiles it while CONFIG_ACPI is set. > > Sorry YueHaibing as I have said to other patch doing this, this slave.c > is acpi specific but Srini has already send DT support for this so it > doesn't become acpi only and this warn also goes away. We should get the > DT support soon Ok, thanks! > >> >> Reported-by: Hulk Robot >> Suggested-by: Ladislav Michl >> Signed-off-by: YueHaibing >> --- >> v2: use obj-$(CONFIG_ACPI) += slave.o >> --- >> drivers/soundwire/Makefile | 3 ++- >> drivers/soundwire/slave.c | 3 --- >> 2 files changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile >> index 45b7e50..a28bf3e 100644 >> --- a/drivers/soundwire/Makefile >> +++ b/drivers/soundwire/Makefile >> @@ -4,8 +4,9 @@ >> # >> >> #Bus Objs >> -soundwire-bus-objs := bus_type.o bus.o slave.o mipi_disco.o stream.o >> +soundwire-bus-objs := bus_type.o bus.o mipi_disco.o stream.o >> obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o >> +obj-$(CONFIG_ACPI) += slave.o >> >> #Cadence Objs >> soundwire-cadence-objs := cadence_master.o >> diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c >> index f39a581..0dc188e 100644 >> --- a/drivers/soundwire/slave.c >> +++ b/drivers/soundwire/slave.c >> @@ -60,7 +60,6 @@ static int sdw_slave_add(struct sdw_bus *bus, >> return ret; >> } >> >> -#if IS_ENABLED(CONFIG_ACPI) >> /* >> * sdw_acpi_find_slaves() - Find Slave devices in Master ACPI node >> * @bus: SDW bus instance >> @@ -110,5 +109,3 @@ int sdw_acpi_find_slaves(struct sdw_bus *bus) >> >> return 0; >> } >> - >> -#endif >> -- >> 2.7.4 >> >
Re: [PATCH 00/11 v3] Cleanup IOMMU passthrough setting (and disable IOMMU Passthrough when SME is active)
On Mon, Aug 19, 2019 at 03:22:45PM +0200, Joerg Roedel wrote: > Joerg Roedel (11): > iommu: Remember when default domain type was set on kernel command line > iommu: Add helpers to set/get default domain type > iommu: Use Functions to set default domain type in > iommu_set_def_domain_type() > iommu/amd: Request passthrough mode from IOMMU core > iommu/vt-d: Request passthrough mode from IOMMU core > x86/dma: Get rid of iommu_pass_through > ia64: Get rid of iommu_pass_through > iommu: Print default domain type on boot > iommu: Set default domain type at runtime > iommu: Disable passthrough mode when SME is active > Documentation: Update Documentation for iommu.passthrough > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > arch/ia64/include/asm/iommu.h | 2 - > arch/ia64/kernel/pci-dma.c | 2 - > arch/x86/include/asm/iommu.h| 1 - > arch/x86/kernel/pci-dma.c | 20 +- > drivers/iommu/amd_iommu.c | 6 +- > drivers/iommu/intel-iommu.c | 2 +- > drivers/iommu/iommu.c | 93 > +++-- > include/linux/iommu.h | 16 + > 9 files changed, 110 insertions(+), 34 deletions(-) Applied.
Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
Thu, Aug 22, 2019 at 03:33:30PM CEST, pa...@mellanox.com wrote: > > >> -Original Message- >> From: Jiri Pirko >> Sent: Thursday, August 22, 2019 5:50 PM >> To: Parav Pandit >> Cc: Alex Williamson ; Jiri Pirko >> ; David S . Miller ; Kirti >> Wankhede ; Cornelia Huck ; >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia ; >> net...@vger.kernel.org >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core >> >> Thu, Aug 22, 2019 at 12:04:02PM CEST, pa...@mellanox.com wrote: >> > >> > >> >> -Original Message- >> >> From: Jiri Pirko >> >> Sent: Thursday, August 22, 2019 3:28 PM >> >> To: Parav Pandit >> >> Cc: Alex Williamson ; Jiri Pirko >> >> ; David S . Miller ; Kirti >> >> Wankhede ; Cornelia Huck >> ; >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia >> >> ; net...@vger.kernel.org >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core >> >> >> >> Thu, Aug 22, 2019 at 11:42:13AM CEST, pa...@mellanox.com wrote: >> >> > >> >> > >> >> >> -Original Message- >> >> >> From: Jiri Pirko >> >> >> Sent: Thursday, August 22, 2019 2:59 PM >> >> >> To: Parav Pandit >> >> >> Cc: Alex Williamson ; Jiri Pirko >> >> >> ; David S . Miller ; Kirti >> >> >> Wankhede ; Cornelia Huck >> >> ; >> >> >> k...@vger.kernel.org; linux-kernel@vger.kernel.org; cjia >> >> >> ; net...@vger.kernel.org >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core >> >> >> >> >> >> Wed, Aug 21, 2019 at 08:23:17AM CEST, pa...@mellanox.com wrote: >> >> >> > >> >> >> > >> >> >> >> -Original Message- >> >> >> >> From: Alex Williamson >> >> >> >> Sent: Wednesday, August 21, 2019 10:56 AM >> >> >> >> To: Parav Pandit >> >> >> >> Cc: Jiri Pirko ; David S . Miller >> >> >> >> ; Kirti Wankhede ; >> >> >> >> Cornelia Huck ; k...@vger.kernel.org; >> >> >> >> linux-kernel@vger.kernel.org; cjia ; >> >> >> >> net...@vger.kernel.org >> >> >> >> Subject: Re: [PATCH v2 0/2] Simplify mtty driver and mdev core >> >> >> >> >> >> >> >> > > > > Just an example of the alias, not proposing how it's set. >> >> >> >> > > > > In fact, proposing that the user does not set it, >> >> >> >> > > > > mdev-core provides one >> >> >> >> > > automatically. >> >> >> >> > > > > >> >> >> >> > > > > > > Since there seems to be some prefix overhead, as I >> >> >> >> > > > > > > ask about above in how many characters we actually >> >> >> >> > > > > > > have to work with in IFNAMESZ, maybe we start with >> >> >> >> > > > > > > 8 characters (matching your "index" namespace) and >> >> >> >> > > > > > > expand as necessary for >> >> >> disambiguation. >> >> >> >> > > > > > > If we can eliminate overhead in IFNAMESZ, let's start >> >> >> >> > > > > > > with >> 12. >> >> >> >> > > > > > > Thanks, >> >> >> >> > > > > > > >> >> >> >> > > > > > If user is going to choose the alias, why does it >> >> >> >> > > > > > have to be limited to >> >> >> >> sha1? >> >> >> >> > > > > > Or you just told it as an example? >> >> >> >> > > > > > >> >> >> >> > > > > > It can be an alpha-numeric string. >> >> >> >> > > > > >> >> >> >> > > > > No, I'm proposing a different solution where mdev-core >> >> >> >> > > > > creates an alias based on an abbreviated sha1. The >> >> >> >> > > > > user does not provide the >> >> >> >> alias. >> >> >> >> > > > > >> >> >> >> > > > > > Instead of mdev imposing number of characters on the >> >> >> >> > > > > > alias, it should be best >> >> >> >> > > > > left to the user. >> >> >> >> > > > > > Because in future if netdev improves on the naming >> >> >> >> > > > > > scheme, mdev will be >> >> >> >> > > > > limiting it, which is not right. >> >> >> >> > > > > > So not restricting alias size seems right to me. >> >> >> >> > > > > > User configuring mdev for networking devices in a >> >> >> >> > > > > > given kernel knows what >> >> >> >> > > > > user is doing. >> >> >> >> > > > > > So user can choose alias name size as it finds suitable. >> >> >> >> > > > > >> >> >> >> > > > > That's not what I'm proposing, please read again. >> >> >> >> > > > > Thanks, >> >> >> >> > > > >> >> >> >> > > > I understood your point. But mdev doesn't know how user >> >> >> >> > > > is going to use >> >> >> >> > > udev/systemd to name the netdev. >> >> >> >> > > > So even if mdev chose to pick 12 characters, it could >> >> >> >> > > > result in >> >> collision. >> >> >> >> > > > Hence the proposal to provide the alias by the user, as >> >> >> >> > > > user know the best >> >> >> >> > > policy for its use case in the environment its using. >> >> >> >> > > > So 12 character sha1 method will still work by user. >> >> >> >> > > >> >> >> >> > > Haven't you already provided examples where certain drivers >> >> >> >> > > or subsystems have unique netdev prefixes? If mdev >> >> >> >> > > provides a unique alias within the subsystem, couldn't we >> >> >> >> > > simply define a netdev prefix for the mdev subsystem and >> >> >> >> > > avoid all other collisions? I'm not in favor of the user >> >> >> >> > > provi
Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote: > On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote: > > On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote: > > > On Wed, Aug 14, 2019 at 01:06:09PM +0200, Miroslav Benes wrote: > > > > > Really, we should be going in the opposite direction, by creating > > > > > module > > > > > dependencies, like all other kernel modules do, ensuring that a module > > > > > is loaded *before* we patch it. That would also eliminate this bug. > > > > > > We should look at whether it makes sense to destabilize live patching > > > for everybody, for a small minority of people who care about a small > > > minority of edge cases. > > > > I do not see it that simple. Forcing livepatched modules to be > > loaded would mean loading "random" new modules when updating > > livepatches: > > I don't want to start a long debate on this, because this idea isn't > even my first choice. But we shouldn't dismiss it outright. I am glad to hear that this is not your first choice. > > + It means more actions and higher risk to destabilize > > the system. Different modules have different quality. > > Maybe the distro shouldn't ship modules which would destabilize the > system. Is this realistic? Even the best QA could not check all scenarios. My point is that the more actions we do the bigger the risk is. Anyway, this approach might cause loading modules that are never or rarely loaded together. Real life systems have limited number of peripherals. I wonder if it might actually break certification of some hardware. It is just an idea. I do not know how certifications are done and what is the scope or limits. > > + It might open more security holes that are not fixed by > > the livepatch. > > Following the same line of thinking, the livepatch infrastructure might > open security holes because of the inherent complexity of late module > patching. Could you be more specific, please? Has there been any known security hole in the late module livepatching code? > > + It might require some extra configuration actions to handle > > the newly opened interfaces (devices). For example, updating > > SELinux policies. > > I assume you mean user-created policies, not distro ones? Is this even > a realistic concern? Honestly, I do not know. I am not familiar with this area. There are also containers. They are going to be everywhere. They also need a lot of rules to keep stuff separated. And it is another area where I have no idea if newly loaded and unexpectedly modules might need special handling. > > + Are there conflicting modules that might need to get > > livepatched? > > Again is this realistic? I do not know. But I could imagine it. > > This approach has a strong no-go from my side. > > > > I agree it's not ideal, but nothing is ideal at this point. Let's not > to rule it out prematurely. I do feel that our current approach is not > the best. It will continue to create problems for us until we fix it. I am sure that we could do better. I just think that forcibly loading modules is opening too huge can of worms. Basically all other approaches have more limited or better defined effects. For example, the newly added code that clears the relocations is something that can be tested. Behavior of "random" mix of loaded modules opens possibilities that have never been discovered before. > > > - Changing 'atomic replace' to allow patch modules to be per-object. > > > > The problem might be how to transition all loaded objects atomically > > when the needed code is loaded from different modules. > > I'm not sure what you mean. > > My idea was that each patch module would be specific to an object, with > no inter-module change dependencies. So when using atomic replace, if > the patch module is only targeted to vmlinux, then only vmlinux-targeted > patch modules would be replaced. > > In other words, 'atomic replace' would be object-specific. > > > Alternative would be to support only per-object consitency. But it > > might reduce the number of supported scenarios too much. Also it > > would make livepatching more error-prone. By per-object consistency I mean the same as you with "each patch module would be specific to an object, with no inter-module change dependencies". My concern is that it would prevent semantic changes in a shared code. Semantic changes are rare. But changes in shared code are not. If we reduce the consistency to per-object consistency. Will the consistency still make sense then? We might want to go back to trees, I mean immediate mode. Best Regards, Petr
Re: [PATCH 0/5] Further sanitize INTEL_FAM6 naming
On Thu, Aug 22, 2019 at 01:53:12PM -0700, Luck, Tony wrote: > On Thu, Aug 22, 2019 at 12:23:06PM +0200, Peter Zijlstra wrote: > > Lots of variation has crept in; time to collapse the lot again. > > Conceptually good. But I applied the series on top of tip/master > and got a build error: > > Looks like your scripts didn't anticipate the CPP gymnastics like: > > #define VULNWL_INTEL(model, whitelist) \ > VULNWL(INTEL, 6, INTEL_FAM6_##model, whitelist) Bah.. I'll go fix.
[PATCH v2 3/4] drm/vmwgfx: Update the backdoor call with support for new instructions
From: Thomas Hellstrom Use the definition provided by include/asm/vmware.h Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Doug Covelli --- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 21 + drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 35 +++-- 2 files changed, 28 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c index 81a86c3b77bc..1281e52898ee 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c @@ -45,8 +45,6 @@ #define RETRIES 3 #define VMW_HYPERVISOR_MAGIC0x564D5868 -#define VMW_HYPERVISOR_PORT 0x5658 -#define VMW_HYPERVISOR_HB_PORT 0x5659 #define VMW_PORT_CMD_MSG30 #define VMW_PORT_CMD_HB_MSG 0 @@ -92,7 +90,7 @@ static int vmw_open_channel(struct rpc_channel *channel, unsigned int protocol) VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL, (protocol | GUESTMSG_FLAG_COOKIE), si, di, - VMW_HYPERVISOR_PORT, + 0, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); @@ -125,7 +123,7 @@ static int vmw_close_channel(struct rpc_channel *channel) VMW_PORT(VMW_PORT_CMD_CLOSE_CHANNEL, 0, si, di, - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), + channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); @@ -159,7 +157,8 @@ static unsigned long vmw_port_hb_out(struct rpc_channel *channel, VMW_PORT_HB_OUT( (MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG, msg_len, si, di, - VMW_HYPERVISOR_HB_PORT | (channel->channel_id << 16), + VMWARE_HYPERVISOR_HB | (channel->channel_id << 16) | + VMWARE_HYPERVISOR_OUT, VMW_HYPERVISOR_MAGIC, bp, eax, ebx, ecx, edx, si, di); @@ -180,7 +179,7 @@ static unsigned long vmw_port_hb_out(struct rpc_channel *channel, VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_SENDPAYLOAD << 16), word, si, di, -VMW_HYPERVISOR_PORT | (channel->channel_id << 16), +channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); } @@ -212,7 +211,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel *channel, char *reply, VMW_PORT_HB_IN( (MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG, reply_len, si, di, - VMW_HYPERVISOR_HB_PORT | (channel->channel_id << 16), + VMWARE_HYPERVISOR_HB | (channel->channel_id << 16), VMW_HYPERVISOR_MAGIC, bp, eax, ebx, ecx, edx, si, di); @@ -229,7 +228,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel *channel, char *reply, VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_RECVPAYLOAD << 16), MESSAGE_STATUS_SUCCESS, si, di, -VMW_HYPERVISOR_PORT | (channel->channel_id << 16), +channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); @@ -268,7 +267,7 @@ static int vmw_send_msg(struct rpc_channel *channel, const char *msg) VMW_PORT(VMW_PORT_CMD_SENDSIZE, msg_len, si, di, - VMW_HYPERVISOR_PORT | (channel->channel_id << 16), + channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); @@ -326,7 +325,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void **msg, VMW_PORT(VMW_PORT_CMD_RECVSIZE, 0, si, di, - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), + channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); @@ -370,7 +369,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void **msg, VMW_PORT(VMW_PORT_CMD_RECVSTATUS, MESSAGE_STATUS_SUCCESS, si, di, - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), + channel->channel_id << 16, VMW_HYPERVISOR_MAGIC, eax, ebx, ecx, edx, si, di); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h index 4907e50fb20a..f685c7071dec 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h @@ -32,6 +32,7 @@
[PATCH 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3 variant bindings
The Khadas VIM3 is also available with the Pin-to-pin compatible Amlogic SM1 SoC in the S905D3 variant package. Change the description to match the S905X3/D3/Y3 variants like the G12A description, and add the vim3 compatible. Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index b48ea1e4913a..2751dd778ce0 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -150,9 +150,10 @@ properties: - const: amlogic,s922x - const: amlogic,g12b - - description: Boards with the Amlogic Meson SM1 S905X3 SoC + - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC items: - enum: - seirobotics,sei610 + - khadas,vim3 - const: amlogic,sm1 ... -- 2.22.0
[PATCH v2 2/4] x86/vmware: Add a header file for hypercall definitions
From: Thomas Hellstrom
The new header is intended to be used by drivers using the backdoor.
Follow the kvm example using alternatives self-patching to
choose between vmcall, vmmcall and io instructions.
Also define two new CPU feature flags to indicate hypervisor support
for vmcall- and vmmcall instructions.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Doug Covelli
---
MAINTAINERS| 1 +
arch/x86/include/asm/cpufeatures.h | 2 ++
arch/x86/include/asm/vmware.h | 48 ++
arch/x86/kernel/cpu/vmware.c | 6 +++-
4 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/include/asm/vmware.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c2d975da561f..5bf65a49fa19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17203,6 +17203,7 @@ M: "VMware, Inc."
L: virtualizat...@lists.linux-foundation.org
S: Supported
F: arch/x86/kernel/cpu/vmware.c
+F: arch/x86/include/asm/vmware.h
VMWARE PVRDMA DRIVER
M: Adit Ranadive
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 998c2cc08363..55fa3b3f0bac 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -232,6 +232,8 @@
#define X86_FEATURE_VMMCALL( 8*32+15) /* Prefer VMMCALL to VMCALL
*/
#define X86_FEATURE_XENPV ( 8*32+16) /* "" Xen paravirtual guest
*/
#define X86_FEATURE_EPT_AD ( 8*32+17) /* Intel Extended Page Table
access-dirty bit */
+#define X86_FEATURE_VMCALL ( 8*32+18) /* "" Hypervisor supports
the VMCALL instruction */
+#define X86_FEATURE_VMW_VMMCALL( 8*32+19) /* "" VMware prefers
VMMCALL hypercall instruction */
/* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
#define X86_FEATURE_FSGSBASE ( 9*32+ 0) /* RDFSBASE, WRFSBASE,
RDGSBASE, WRGSBASE instructions*/
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
new file mode 100644
index ..4b220e2bb3e8
--- /dev/null
+++ b/arch/x86/include/asm/vmware.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 or MIT */
+#ifndef _ASM_X86_VMWARE_H
+#define _ASM_X86_VMWARE_H
+
+#include
+#include
+
+/*
+ * The hypercall definitions differ in the low word of the edx argument in
+ * the following way: The old port base interface uses the port number to
+ * distinguish between high- and low bandwidth versions. The new vmcall
+ * interface instead uses a set of flags to select bandwidth mode and
+ * transfer direction. New driver code should strictly use the new
+ * definition of edx content.
+ */
+
+/* Old port-based version */
+#define VMWARE_HYPERVISOR_PORT"0x5658"
+#define VMWARE_HYPERVISOR_PORT_HB "0x5659"
+
+/* Current vmcall / vmmcall version */
+#define VMWARE_HYPERVISOR_HB BIT(0)
+#define VMWARE_HYPERVISOR_OUT BIT(1)
+
+/* The low bandwidth call. The low word of edx is presumed clear. */
+#define VMWARE_HYPERCALL \
+ ALTERNATIVE_2("movw $" VMWARE_HYPERVISOR_PORT ", %%dx; inl (%%dx)", \
+ "vmcall", X86_FEATURE_VMCALL, \
+ "vmmcall", X86_FEATURE_VMW_VMMCALL)
+
+/*
+ * The high bandwidth out call. The low word of edx is presumed to have the
+ * HB and OUT bits set.
+ */
+#define VMWARE_HYPERCALL_HB_OUT
\
+ ALTERNATIVE_2("movw $" VMWARE_HYPERVISOR_PORT_HB ", %%dx; rep outsb", \
+ "vmcall", X86_FEATURE_VMCALL, \
+ "vmmcall", X86_FEATURE_VMW_VMMCALL)
+
+/*
+ * The high bandwidth in call. The low word of edx is presumed to have the
+ * HB bit set.
+ */
+#define VMWARE_HYPERCALL_HB_IN \
+ ALTERNATIVE_2("movw $" VMWARE_HYPERVISOR_PORT_HB ", %%dx; rep insb", \
+ "vmcall", X86_FEATURE_VMCALL, \
+ "vmmcall", X86_FEATURE_VMW_VMMCALL)
+#endif
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index fcb84b1e099e..abaa1b27353c 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#undef pr_fmt
#define pr_fmt(fmt)"vmware: " fmt
@@ -41,7 +42,6 @@
#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
#define VMWARE_HYPERVISOR_MAGIC0x564D5868
-#define VMWARE_HYPERVISOR_PORT 0x5658
#define VMWARE_CMD_GETVERSION10
#define VMWARE_CMD_GETHZ 45
@@ -165,6 +165,10 @@ static void __init vmware_set_capabilities(void)
{
setup_force_cpu_cap(X86_FEATURE_CONSTANT_TSC);
setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+ if (vmware_hypercall_mode == CPUID_VMWARE_FEATURES_ECX_VMCALL)
+ setup_force_cpu_cap(X86_FEATURE_VMCAL
