* [PATCH v7 01/22] ARM: dts: aspeed: yosemite4: Revise i2c-mux devices
From: Delphine CC Chiu @ 2024-03-21 2:12 UTC (permalink / raw)
To: patrick, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery
Cc: Delphine CC Chiu, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240321021236.1823693-1-Delphine_CC_Chiu@wiwynn.com>
Revise Yosemite 4 devicetree for devices behind i2c-mux
- Add gpio and eeprom behind i2c-mux
- Remove redundant idle-state setting for i2c-mux
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
---
.../aspeed/aspeed-bmc-facebook-yosemite4.dts | 381 ++++++++++++++++--
1 file changed, 347 insertions(+), 34 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..dac58d3ea63c 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -17,6 +17,25 @@ aliases {
serial6 = &uart7;
serial7 = &uart8;
serial8 = &uart9;
+
+ i2c16 = &imux16;
+ i2c17 = &imux17;
+ i2c18 = &imux18;
+ i2c19 = &imux19;
+ i2c20 = &imux20;
+ i2c21 = &imux21;
+ i2c22 = &imux22;
+ i2c23 = &imux23;
+ i2c24 = &imux24;
+ i2c25 = &imux25;
+ i2c26 = &imux26;
+ i2c27 = &imux27;
+ i2c28 = &imux28;
+ i2c29 = &imux29;
+ i2c30 = &imux30;
+ i2c31 = &imux31;
+ i2c32 = &imux32;
+ i2c33 = &imux33;
};
chosen {
@@ -259,9 +278,109 @@ &i2c8 {
bus-frequency = <400000>;
i2c-mux@70 {
compatible = "nxp,pca9544";
- idle-state = <0>;
i2c-mux-idle-disconnect;
reg = <0x70>;
+
+ imux16: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux17: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux18: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux19: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
};
};
@@ -270,15 +389,174 @@ &i2c9 {
bus-frequency = <400000>;
i2c-mux@71 {
compatible = "nxp,pca9544";
- idle-state = <0>;
i2c-mux-idle-disconnect;
reg = <0x71>;
+
+ imux20: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux21: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux22: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
+
+ imux23: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ gpio@49 {
+ compatible = "nxp,pca9537";
+ reg = <0x49>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+ };
};
};
&i2c10 {
status = "okay";
bus-frequency = <400000>;
+ i2c-mux@74 {
+ compatible = "nxp,pca9544";
+ i2c-mux-idle-disconnect;
+ reg = <0x74>;
+
+ imux28: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ gpio@20 {
+ compatible = "nxp,pca9506";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9506";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9506";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@23 {
+ compatible = "nxp,pca9506";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpio@24 {
+ compatible = "nxp,pca9506";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "","","","",
+ "NIC0-MAIN-PWR-EN","NIC1-MAIN-PWR-EN",
+ "NIC2-MAIN-PWR-EN","NIC3-MAIN-PWR-EN",
+ "","","","","","","","",
+ "","","","","","","","",
+ "","","","","","","","";
+ };
+ };
+
+ imux29: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
&i2c11 {
@@ -433,16 +711,14 @@ eeprom@51 {
reg = <0x51>;
};
- i2c-mux@71 {
- compatible = "nxp,pca9846";
+ i2c-mux@74 {
+ compatible = "nxp,pca9546";
#address-cells = <1>;
#size-cells = <0>;
-
- idle-state = <0>;
i2c-mux-idle-disconnect;
- reg = <0x71>;
+ reg = <0x74>;
- i2c@0 {
+ imux30: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
@@ -450,26 +726,26 @@ i2c@0 {
adc@1f {
compatible = "ti,adc128d818";
reg = <0x1f>;
- ti,mode = /bits/ 8 <2>;
+ ti,mode = /bits/ 8 <1>;
};
pwm@20{
- compatible = "max31790";
+ compatible = "maxim,max31790";
+ pwm-as-tach = <4 5>;
reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
};
gpio@22{
compatible = "ti,tca6424";
reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
};
- pwm@23{
- compatible = "max31790";
- reg = <0x23>;
- #address-cells = <1>;
- #size-cells = <0>;
+ pwm@2f{
+ compatible = "maxim,max31790";
+ pwm-as-tach = <4 5>;
+ reg = <0x2f>;
};
adc@33 {
@@ -492,34 +768,34 @@ gpio@61 {
};
};
- i2c@1 {
+ imux31: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
- reg = <0>;
+ reg = <1>;
adc@1f {
compatible = "ti,adc128d818";
reg = <0x1f>;
- ti,mode = /bits/ 8 <2>;
+ ti,mode = /bits/ 8 <1>;
};
pwm@20{
- compatible = "max31790";
+ compatible = "maxim,max31790";
+ pwm-as-tach = <4 5>;
reg = <0x20>;
- #address-cells = <1>;
- #size-cells = <0>;
};
gpio@22{
compatible = "ti,tca6424";
reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
};
- pwm@23{
- compatible = "max31790";
- reg = <0x23>;
- #address-cells = <1>;
- #size-cells = <0>;
+ pwm@2f{
+ compatible = "maxim,max31790";
+ pwm-as-tach = <4 5>;
+ reg = <0x2f>;
};
adc@33 {
@@ -547,12 +823,10 @@ i2c-mux@73 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
-
- idle-state = <0>;
i2c-mux-idle-disconnect;
reg = <0x73>;
- i2c@0 {
+ imux32: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
@@ -563,10 +837,10 @@ adc@35 {
};
};
- i2c@1 {
+ imux33: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
- reg = <0>;
+ reg = <1>;
adc@35 {
compatible = "maxim,max11617";
@@ -589,9 +863,48 @@ mctp@10 {
i2c-mux@72 {
compatible = "nxp,pca9544";
- idle-state = <0>;
i2c-mux-idle-disconnect;
reg = <0x72>;
+
+ imux24: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ temperature-sensor@1f {
+ compatible = "ti,tmp421";
+ reg = <0x1f>;
+ };
+ };
+
+ imux25: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ temperature-sensor@1f {
+ compatible = "ti,tmp421";
+ reg = <0x1f>;
+ };
+ };
+
+ imux26: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ temperature-sensor@1f {
+ compatible = "ti,tmp421";
+ reg = <0x1f>;
+ };
+ };
+
+ imux27: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ temperature-sensor@1f {
+ compatible = "ti,tmp421";
+ reg = <0x1f>;
+ };
+ };
};
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 03/22] ARM: dts: aspeed: yosemite4: Enable spi-gpio setting
From: Delphine CC Chiu @ 2024-03-21 2:12 UTC (permalink / raw)
To: patrick, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery
Cc: Delphine CC Chiu, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240321021236.1823693-1-Delphine_CC_Chiu@wiwynn.com>
enable spi-gpio setting for spi flash
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
---
.../aspeed/aspeed-bmc-facebook-yosemite4.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 6846aab893ad..ea8fd3ec0982 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -53,6 +53,24 @@ iio-hwmon {
<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
<&adc1 0>, <&adc1 1>, <&adc1 7>;
};
+
+ spi_gpio: spi-gpio {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio-sck = <&gpio0 ASPEED_GPIO(X, 3) GPIO_ACTIVE_HIGH>;
+ gpio-mosi = <&gpio0 ASPEED_GPIO(X, 4) GPIO_ACTIVE_HIGH>;
+ gpio-miso = <&gpio0 ASPEED_GPIO(X, 5) GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(X, 0) GPIO_ACTIVE_LOW>;
+
+ tpmdev@0 {
+ compatible = "tcg,tpm_tis-spi";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+ };
};
&uart1 {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v7 02/22] ARM: dts: aspeed: yosemite4: Enable adc15
From: Delphine CC Chiu @ 2024-03-21 2:12 UTC (permalink / raw)
To: patrick, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery
Cc: Delphine CC Chiu, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240321021236.1823693-1-Delphine_CC_Chiu@wiwynn.com>
Enable Yosemite 4 adc15 config
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index dac58d3ea63c..6846aab893ad 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -51,7 +51,7 @@ iio-hwmon {
compatible = "iio-hwmon";
io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
<&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
- <&adc1 0>, <&adc1 1>;
+ <&adc1 0>, <&adc1 1>, <&adc1 7>;
};
};
@@ -920,10 +920,10 @@ &pinctrl_adc4_default &pinctrl_adc5_default
&adc1 {
ref_voltage = <2500>;
status = "okay";
- pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default>;
+ pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc9_default
+ &pinctrl_adc15_default>;
};
-
&ehci0 {
status = "okay";
};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] media: mediatek: vcodec: Handle invalid decoder vsi
From: Irui Wang (王瑞) @ 2024-03-21 1:55 UTC (permalink / raw)
To: matthias.bgg@gmail.com, mchehab@kernel.org,
sebastian.fricke@collabora.com,
angelogioacchino.delregno@collabora.com,
nicolas.dufresne@collabora.com, hverkuil-cisco@xs4all.nl,
Yunfei Dong (董云飞)
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
Maoguang Meng (孟毛广),
linux-mediatek@lists.infradead.org,
Longfei Wang (王龙飞),
Project_Global_Chrome_Upstream_Group
In-Reply-To: <c09b063f-a11a-4bc0-8b12-3d66f692c48c@collabora.com>
Dear Angelo,
Thanks for your reviewing, patch v2 has been sent with 'Fixes' tag,
thank you very much.
Best Regards
On Wed, 2024-03-20 at 10:13 +0100, AngeloGioacchino Del Regno wrote:
> Il 20/03/24 07:13, Irui Wang ha scritto:
> > Handle invalid decoder vsi in vpu_dec_init to ensure the decoder
> > vsi is
> > valid for future use.
> >
> > Signed-off-by: Irui Wang <irui.wang@mediatek.com>
>
> This commit needs a Fixes tag, can you please add the relevant one
> and resend?
>
> Thanks,
> Angelo
>
> > ---
> > .../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 6
> > ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > index 82e57ae983d5..17770993fe5a 100644
> > --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
> > @@ -231,6 +231,12 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
> > mtk_vdec_debug(vpu->ctx, "vdec_inst=%p", vpu);
> >
> > err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg));
> > +
> > + if (IS_ERR_OR_NULL(vpu->vsi)) {
> > + mtk_vdec_err(vpu->ctx, "invalid vdec vsi, status=%d",
> > err);
> > + return -EINVAL;
> > + }
> > +
> > mtk_vdec_debug(vpu->ctx, "- ret=%d", err);
> > return err;
> > }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] media: mediatek: vcodec: Handle invalid decoder vsi
From: Irui Wang @ 2024-03-21 1:47 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Matthias Brugger,
Yunfei Dong, angelogioacchino.delregno, nicolas.dufresne,
sebastian.fricke
Cc: Longfei Wang, Maoguang Meng, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
Handle invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is
valid for future use.
Fixes: 590577a4e525 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver")
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
changed with v1:
- add Fixes tag
---
.../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index 82e57ae983d5..17770993fe5a 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -231,6 +231,12 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
mtk_vdec_debug(vpu->ctx, "vdec_inst=%p", vpu);
err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg));
+
+ if (IS_ERR_OR_NULL(vpu->vsi)) {
+ mtk_vdec_err(vpu->ctx, "invalid vdec vsi, status=%d", err);
+ return -EINVAL;
+ }
+
mtk_vdec_debug(vpu->ctx, "- ret=%d", err);
return err;
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] arm: fix clang build warning in include/asm/memory.h
From: Yipeng Zou @ 2024-03-21 1:35 UTC (permalink / raw)
To: linux, ndesaulniers, morbo, justinstitt, linus.walleij, ssantosh,
linux-arm-kernel, nathan
Cc: zouyipeng
There is a build error has been founded with build in clang-15.0.4:
./arch/arm/include/asm/memory.h:358:12: error: result of comparison "phys addr_t’ (aka 'unsigned int’) > 4294967295 is always false [-Werror, -Wtautological-type-limit-compare]
if (addr > (u32)~0)
~~~~ ^ ~~~~~~~
It will be always goes fail without CONFIG_PHYS_ADDR_T_64BIT.
Directly silence it by Use CONFIG_PHYS_ADDR_T_64BIT.
Fixes: 981b6714dbd2 ("ARM: provide improved virt_to_idmap() functionality")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
---
V2: IDMAP_INVALID_ADDR was used in other place, keep it defined.
arch/arm/include/asm/memory.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ef2aa79ece5a..07c7e759d04c 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -353,8 +353,10 @@ static inline unsigned long phys_to_idmap(phys_addr_t addr)
{
if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
addr += arch_phys_to_idmap_offset;
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
if (addr > (u32)~0)
addr = IDMAP_INVALID_ADDR;
+#endif
}
return addr;
}
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Zijie Zhao @ 2024-03-21 1:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King (Oracle), gregory.clement, sebastian.hesselbarth,
linux-arm-kernel, chenyuan0y
In-Reply-To: <69bbda51-f298-494e-bcfc-8e76eacb189d@lunn.ch>
On 3/20/24 8:10 PM, Andrew Lunn wrote:
>>> If we are out of memory at this point in the kernel boot, then what are
>>> the chances of the kernel getting to the point where it can run
>>> userspace?
>>>
>>> I think that is the essence of Andrew's argument. A failure to allocate
>>> memory here means there is a serious problem and the system won't boot
>>> _even_ if we add something like:
>>>
>>> if (!new_compat)
>>> continue;
>>>
>>> to that loop.
>>>
>>
>>
>> Hi Andrew and Russell,
>>
>> Thanks for pointing out the consequence! It makes sense and we will try to
>> make our analyzer realize this as well. Thanks again for your time!
>
> If you can make the analyzer realise this, that would be great.
>
> If not, feel free to repost this patch, but please rework the commit
> message. Point out that checking for NULL is pointless here, the
> system is doomed. However, the static analysers cannot determine
> that. And it makes sense to silence this pointless warning to stop it
> hiding other real warning which could be real issues. "Cannot see the
> forest because of the trees".
>
> Something else to consider. The system is doomed. So maybe call
> panic()?
>
> Andrew
Hi Andrew,
Thanks for considering help our analyzer. We examined more similar
cases and found there are a few other locations where OOM equals dead
system, so it would probably be better to improve the analyzer instead
of adding more checks.
Thanks again for the information and your time!
Best,
Zijie
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] watchdog: stm32_iwdg: Add pretimeout support
From: Marek Vasut @ 2024-03-21 1:11 UTC (permalink / raw)
To: linux-watchdog
Cc: Marek Vasut, Alexandre Torgue, Guenter Roeck, Maxime Coquelin,
Wim Van Sebroeck, linux-arm-kernel, linux-stm32
The STM32MP15xx IWDG adds registers which permit this IP to generate
pretimeout interrupt. This interrupt can also be used to wake the CPU
from suspend. Implement support for generating this interrupt and let
userspace configure the pretimeout. In case the pretimeout is not
configured by user, set pretimeout to half of the WDT timeout cycle.
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-watchdog@vger.kernel.org
---
V2: - Subtract the pretimeout value from timeout value before writing it
into the IWDG pretimeout register, because the watchdog counter
register is counting down, and the pretimeout interrupt triggers
when watchdog counter register matches the pretimeout register
content.
- Set default pretimeout to 3/4 of timeout .
V3: - Use dev instead of pdev->dev
- Swap order of ret/return 0
- Split this from the DT changes, which are orthogonal
- Uh, this patch got stuck in upstreaming queue, sorry
---
drivers/watchdog/stm32_iwdg.c | 95 ++++++++++++++++++++++++++++++++++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 5404e03876202..d700e0d49bb95 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -18,6 +18,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
#include <linux/watchdog.h>
#define DEFAULT_TIMEOUT 10
@@ -28,6 +29,7 @@
#define IWDG_RLR 0x08 /* ReLoad Register */
#define IWDG_SR 0x0C /* Status Register */
#define IWDG_WINR 0x10 /* Windows Register */
+#define IWDG_EWCR 0x14 /* Early Wake-up Register */
/* IWDG_KR register bit mask */
#define KR_KEY_RELOAD 0xAAAA /* reload counter enable */
@@ -47,22 +49,29 @@
#define SR_PVU BIT(0) /* Watchdog prescaler value update */
#define SR_RVU BIT(1) /* Watchdog counter reload value update */
+#define EWCR_EWIT GENMASK(11, 0) /* Watchdog counter window value */
+#define EWCR_EWIC BIT(14) /* Watchdog early interrupt acknowledge */
+#define EWCR_EWIE BIT(15) /* Watchdog early interrupt enable */
+
/* set timeout to 100000 us */
#define TIMEOUT_US 100000
#define SLEEP_US 1000
struct stm32_iwdg_data {
bool has_pclk;
+ bool has_early_wakeup;
u32 max_prescaler;
};
static const struct stm32_iwdg_data stm32_iwdg_data = {
.has_pclk = false,
+ .has_early_wakeup = false,
.max_prescaler = 256,
};
static const struct stm32_iwdg_data stm32mp1_iwdg_data = {
.has_pclk = true,
+ .has_early_wakeup = true,
.max_prescaler = 1024,
};
@@ -88,13 +97,18 @@ static inline void reg_write(void __iomem *base, u32 reg, u32 val)
static int stm32_iwdg_start(struct watchdog_device *wdd)
{
struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
- u32 tout, presc, iwdg_rlr, iwdg_pr, iwdg_sr;
+ u32 tout, ptot, presc, iwdg_rlr, iwdg_ewcr, iwdg_pr, iwdg_sr;
int ret;
dev_dbg(wdd->parent, "%s\n", __func__);
+ if (!wdd->pretimeout)
+ wdd->pretimeout = 3 * wdd->timeout / 4;
+
tout = clamp_t(unsigned int, wdd->timeout,
wdd->min_timeout, wdd->max_hw_heartbeat_ms / 1000);
+ ptot = clamp_t(unsigned int, tout - wdd->pretimeout,
+ wdd->min_timeout, tout);
presc = DIV_ROUND_UP(tout * wdt->rate, RLR_MAX + 1);
@@ -102,6 +116,7 @@ static int stm32_iwdg_start(struct watchdog_device *wdd)
presc = roundup_pow_of_two(presc);
iwdg_pr = presc <= 1 << PR_SHIFT ? 0 : ilog2(presc) - PR_SHIFT;
iwdg_rlr = ((tout * wdt->rate) / presc) - 1;
+ iwdg_ewcr = ((ptot * wdt->rate) / presc) - 1;
/* enable write access */
reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
@@ -109,6 +124,8 @@ static int stm32_iwdg_start(struct watchdog_device *wdd)
/* set prescaler & reload registers */
reg_write(wdt->regs, IWDG_PR, iwdg_pr);
reg_write(wdt->regs, IWDG_RLR, iwdg_rlr);
+ if (wdt->data->has_early_wakeup)
+ reg_write(wdt->regs, IWDG_EWCR, iwdg_ewcr | EWCR_EWIE);
reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
/* wait for the registers to be updated (max 100ms) */
@@ -151,6 +168,34 @@ static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
return 0;
}
+static int stm32_iwdg_set_pretimeout(struct watchdog_device *wdd,
+ unsigned int pretimeout)
+{
+ dev_dbg(wdd->parent, "%s pretimeout: %d sec\n", __func__, pretimeout);
+
+ wdd->pretimeout = pretimeout;
+
+ if (watchdog_active(wdd))
+ return stm32_iwdg_start(wdd);
+
+ return 0;
+}
+
+static irqreturn_t stm32_iwdg_isr(int irq, void *wdog_arg)
+{
+ struct watchdog_device *wdd = wdog_arg;
+ struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
+ u32 reg;
+
+ reg = reg_read(wdt->regs, IWDG_EWCR);
+ reg |= EWCR_EWIC;
+ reg_write(wdt->regs, IWDG_EWCR, reg);
+
+ watchdog_notify_pretimeout(wdd);
+
+ return IRQ_HANDLED;
+}
+
static void stm32_clk_disable_unprepare(void *data)
{
clk_disable_unprepare(data);
@@ -207,11 +252,20 @@ static const struct watchdog_info stm32_iwdg_info = {
.identity = "STM32 Independent Watchdog",
};
+static const struct watchdog_info stm32_iwdg_preinfo = {
+ .options = WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE |
+ WDIOF_KEEPALIVEPING |
+ WDIOF_PRETIMEOUT,
+ .identity = "STM32 Independent Watchdog",
+};
+
static const struct watchdog_ops stm32_iwdg_ops = {
.owner = THIS_MODULE,
.start = stm32_iwdg_start,
.ping = stm32_iwdg_ping,
.set_timeout = stm32_iwdg_set_timeout,
+ .set_pretimeout = stm32_iwdg_set_pretimeout,
};
static const struct of_device_id stm32_iwdg_of_match[] = {
@@ -221,6 +275,40 @@ static const struct of_device_id stm32_iwdg_of_match[] = {
};
MODULE_DEVICE_TABLE(of, stm32_iwdg_of_match);
+static int stm32_iwdg_irq_init(struct platform_device *pdev,
+ struct stm32_iwdg *wdt)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct watchdog_device *wdd = &wdt->wdd;
+ struct device *dev = &pdev->dev;
+ int irq, ret;
+
+ if (!wdt->data->has_early_wakeup)
+ return 0;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq <= 0)
+ return 0;
+
+ if (of_property_read_bool(np, "wakeup-source")) {
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ return ret;
+
+ ret = dev_pm_set_wake_irq(dev, irq);
+ if (ret)
+ return ret;
+ }
+
+ ret = devm_request_irq(dev, irq, stm32_iwdg_isr, 0,
+ dev_name(dev), wdd);
+ if (ret)
+ return ret;
+
+ wdd->info = &stm32_iwdg_preinfo;
+ return 0;
+}
+
static int stm32_iwdg_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -255,6 +343,11 @@ static int stm32_iwdg_probe(struct platform_device *pdev)
wdd->max_hw_heartbeat_ms = ((RLR_MAX + 1) * wdt->data->max_prescaler *
1000) / wdt->rate;
+ /* Initialize IRQ, this might override wdd->info, hence it is here. */
+ ret = stm32_iwdg_irq_init(pdev, wdt);
+ if (ret)
+ return ret;
+
watchdog_set_drvdata(wdd, wdt);
watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT);
watchdog_init_timeout(wdd, 0, dev);
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Andrew Lunn @ 2024-03-21 1:10 UTC (permalink / raw)
To: Zijie Zhao
Cc: Russell King (Oracle), gregory.clement, sebastian.hesselbarth,
linux-arm-kernel, chenyuan0y
In-Reply-To: <f6ee6176-8945-4e24-9377-28248829ad5e@gmail.com>
> > If we are out of memory at this point in the kernel boot, then what are
> > the chances of the kernel getting to the point where it can run
> > userspace?
> >
> > I think that is the essence of Andrew's argument. A failure to allocate
> > memory here means there is a serious problem and the system won't boot
> > _even_ if we add something like:
> >
> > if (!new_compat)
> > continue;
> >
> > to that loop.
> >
>
>
> Hi Andrew and Russell,
>
> Thanks for pointing out the consequence! It makes sense and we will try to
> make our analyzer realize this as well. Thanks again for your time!
If you can make the analyzer realise this, that would be great.
If not, feel free to repost this patch, but please rework the commit
message. Point out that checking for NULL is pointless here, the
system is doomed. However, the static analysers cannot determine
that. And it makes sense to silence this pointless warning to stop it
hiding other real warning which could be real issues. "Cannot see the
forest because of the trees".
Something else to consider. The system is doomed. So maybe call
panic()?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] firmware: arm_scmi: perf: print domain name in error path
From: Peng Fan @ 2024-03-20 23:48 UTC (permalink / raw)
To: Sudeep Holla, Peng Fan (OSS)
Cc: cristian.marussi@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ZfrJnEpzfQ-AsU9q@bogus>
> Subject: Re: [PATCH] firmware: arm_scmi: perf: print domain name in error
> path
>
> On Wed, Mar 20, 2024 at 03:42:13PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > It would be easier to locate the problem if domain name is printed out.
> > And including a coding style update.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > drivers/firmware/arm_scmi/perf.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/perf.c
> > b/drivers/firmware/arm_scmi/perf.c
> > index 345fff167b52..e98ca6d15b0c 100644
> > --- a/drivers/firmware/arm_scmi/perf.c
> > +++ b/drivers/firmware/arm_scmi/perf.c
> > @@ -79,7 +79,7 @@ struct scmi_msg_resp_perf_domain_attributes {
> > __le32 rate_limit_us;
> > __le32 sustained_freq_khz;
> > __le32 sustained_perf_level;
> > - u8 name[SCMI_SHORT_NAME_MAX_SIZE];
> > + u8 name[SCMI_SHORT_NAME_MAX_SIZE];
>
> Spurious change ?
I just think this is a coding style cleanup, I could drop it in v2.
>
> > };
> >
> > struct scmi_msg_perf_describe_levels { @@ -387,8 +387,8 @@
> > process_response_opp(struct device *dev, struct perf_dom_info *dom,
> >
> > ret = xa_insert(&dom->opps_by_lvl, opp->perf, opp, GFP_KERNEL);
> > if (ret)
> > - dev_warn(dev, "Failed to add opps_by_lvl at %d - ret:%d\n",
> > - opp->perf, ret);
> > + dev_warn(dev, "Failed to add opps_by_lvl at %d for %s-
> ret:%d\n",
> > + opp->perf, dom->info.name, ret);
> > }
> >
> > static inline void
> > @@ -405,8 +405,8 @@ process_response_opp_v4(struct device *dev,
> struct
> > perf_dom_info *dom,
> >
> > ret = xa_insert(&dom->opps_by_lvl, opp->perf, opp, GFP_KERNEL);
> > if (ret)
> > - dev_warn(dev, "Failed to add opps_by_lvl at %d - ret:%d\n",
> > - opp->perf, ret);
> > + dev_warn(dev, "Failed to add opps_by_lvl at %d for %s -
> ret:%d\n",
> > + opp->perf, dom->info.name, ret);
> >
>
> Are you really hitting these issues ?
Yes. two levels had same freq on i.MX95, but we fixed.
Or is it just code
> observation/improvements ?
>
> It looks good otherwise. You can also add the below change when you respin.
ok, will include in v2.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
>
> diff --git i/drivers/firmware/arm_scmi/perf.c
> w/drivers/firmware/arm_scmi/perf.c
> index 211e8e0aef2c..ef1c27a65552 100644
> --- i/drivers/firmware/arm_scmi/perf.c
> +++ w/drivers/firmware/arm_scmi/perf.c
> @@ -830,7 +830,8 @@ static int scmi_dvfs_device_opps_add(const struct
> scmi_protocol_handle *ph,
>
> ret = dev_pm_opp_add_dynamic(dev, &data);
> if (ret) {
> - dev_warn(dev, "failed to add opp %luHz\n", freq);
> + dev_warn(dev, "[%d][%s]: Failed to add OPP[%d] %lu\n",
> + domain, dom->info.name, idx, freq);
> dev_pm_opp_remove_all_dynamic(dev);
> return ret;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 18/27] iommu/arm-smmu-v3: Make SVA allocate a normal arm_smmu_domain
From: Jason Gunthorpe @ 2024-03-20 23:20 UTC (permalink / raw)
To: Michael Shavit
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <CAKHBV24C7Vesum8NzkOvTHiQy9F6K4fFFDWfWFHTjbfgiL5EaQ@mail.gmail.com>
On Tue, Mar 19, 2024 at 10:52:11PM +0800, Michael Shavit wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index dd7f841cd19b3c..2db2b822292a87 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -2291,23 +2291,10 @@ static bool arm_smmu_capable(struct device *dev, enum iommu_cap cap)
> > }
> > }
> >
> > -static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> > -{
> > -
> > - if (type == IOMMU_DOMAIN_SVA)
> > - return arm_smmu_sva_domain_alloc();
> > - return ERR_PTR(-EOPNOTSUPP);
> > -}
> > -
> > -static struct iommu_domain *arm_smmu_domain_alloc_paging(struct device *dev)
> > +struct arm_smmu_domain *arm_smmu_domain_alloc(void)
>
> Consider renaming arm_smmu_domain_free as well since there's asymmetry
> between arm_smmu_domain_alloc and arm_smmu_domain_free that could be a
> little confusing:
> 1. arm_smmu_domain_alloc is shared between arm_smmu_sva_domain_alloc
> and arm_smmu_domain_alloc_paging
> 2. arm_smmu_domain_free is only used by paging domains, with SVA
> domains freed through arm_smmu_sva_domain_free.
Yeah, that is a good idea, done
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
From: Rob Herring @ 2024-03-20 21:41 UTC (permalink / raw)
To: Andrej Picej
Cc: kernel, jic23, devicetree, haibo.chen, s.hauer, linux-iio,
linux-arm-kernel, festevam, linux-kernel, conor+dt, upstream, imx,
shawnguo, lars, krzysztof.kozlowski+dt
In-Reply-To: <20240320100407.1639082-3-andrej.picej@norik.com>
On Wed, 20 Mar 2024 11:04:06 +0100, Andrej Picej wrote:
> Document calibration properties and how to set them.
>
> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> ---
> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml: nxp,calib-avg-en: missing type definition
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml: nxp,calib-nr-samples: missing type definition
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml: nxp,calib-t-samples: missing type definition
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240320100407.1639082-3-andrej.picej@norik.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/2] Update st,stih407-thermal device
From: Raphael Gallais-Pou @ 2024-03-20 21:33 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Patrice Chotard,
Lee Jones
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel
Those two patches update the thermal device by converting the deprecated
txt documentation file to DT schema, and adding a required property in
the device tree where it is needed.
Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
---
Changes in v3:
- [1/2] Specify const value for '#thermal-sensor-cells'
- [1/2] Add 'maxItems' for 'interrupts' property
- [1/2] Change commit log accordingly
- Did not add Krzysztof's r-b since patch [1/2] was modified
Changes in v2:
- [1/2] Change commit log to use imperative
- [1/2] Drop description
- [1/2] Drop 'clocks' description
- [1/2] Add 'reg' property
- [1/2] Add '#thermal-sensor-cells'
- [1/2] Make node name generic in example
- [1/2] Fix YAML style
---
Raphael Gallais-Pou (2):
dt-bindings: thermal: convert st,stih407-thermal to DT schema
ARM: dts: st: add thermal property on stih410.dtsi and stih418.dtsi
.../bindings/thermal/st,stih407-thermal.yaml | 58 ++++++++++++++++++++++
.../devicetree/bindings/thermal/st-thermal.txt | 32 ------------
arch/arm/boot/dts/st/stih410.dtsi | 1 +
arch/arm/boot/dts/st/stih418.dtsi | 1 +
4 files changed, 60 insertions(+), 32 deletions(-)
---
base-commit: b6d69282db550689ab5980e06eedd23b64584a73
change-id: 20240225-thermal-8cd0ba7f452b
Best regards,
--
Raphael Gallais-Pou <rgallaispou@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: thermal: convert st,stih407-thermal to DT schema
From: Raphael Gallais-Pou @ 2024-03-20 21:33 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Patrice Chotard,
Lee Jones
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240320-thermal-v3-0-700296694c4a@gmail.com>
'st,passive_colling_temp' does not appear in the device-tree, 'reg' and
'#thermal-sensor-cells' are also missing in the device description.
Convert st,stih407-thermal binding to DT schema format in order to clean
unused 'st,passive_cooling_temp' and add missing properties.
Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
---
Changes in v3:
- Specify const value for '#thermal-sensor-cells'
- Add 'maxItems' for 'interrupts' property
- Change commit log accordingly
Changes in v2:
- Change commit log to use imperative
- Drop description
- Drop 'clocks' description
- Add 'reg' property
- Add '#thermal-sensor-cells'
- Make node name generic in example
- Fix YAML style
---
.../bindings/thermal/st,stih407-thermal.yaml | 58 ++++++++++++++++++++++
.../devicetree/bindings/thermal/st-thermal.txt | 32 ------------
2 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml
new file mode 100644
index 000000000000..9f6fc5c95c55
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/st,stih407-thermal.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/st,stih407-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi digital thermal sensor (DTS)
+
+maintainers:
+ - Patrice Chotard <patrice.chotard@foss.st.com>
+ - Lee Jones <lee@kernel.org>
+
+allOf:
+ - $ref: thermal-sensor.yaml
+
+properties:
+ compatible:
+ const: st,stih407-thermal
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: thermal
+
+ interrupts:
+ description:
+ For thermal sensors for which no interrupt has been defined, a polling
+ delay of 1000ms will be used to read the temperature from device.
+ maxItems: 1
+
+ '#thermal-sensor-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ temperature-sensor@91a0000 {
+ compatible = "st,stih407-thermal";
+ reg = <0x91a0000 0x28>;
+ clock-names = "thermal";
+ clocks = <&CLK_SYSIN>;
+ interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
+ #thermal-sensor-cells = <0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt b/Documentation/devicetree/bindings/thermal/st-thermal.txt
deleted file mode 100644
index a2f939137e35..000000000000
--- a/Documentation/devicetree/bindings/thermal/st-thermal.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs.
-
-Required parameters:
--------------------
-
-compatible : Should be "st,stih407-thermal"
-
-clock-names : Should be "thermal".
- See: Documentation/devicetree/bindings/resource-names.txt
-clocks : Phandle of the clock used by the thermal sensor.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Optional parameters:
--------------------
-
-reg : For non-sysconf based sensors, this should be the physical base
- address and length of the sensor's registers.
-interrupts : Standard way to define interrupt number.
- NB: For thermal sensor's for which no interrupt has been
- defined, a polling delay of 1000ms will be used to read the
- temperature from device.
-
-Example:
-
- temp0@91a0000 {
- compatible = "st,stih407-thermal";
- reg = <0x91a0000 0x28>;
- clock-names = "thermal";
- clocks = <&CLK_SYSIN>;
- interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
- st,passive_cooling_temp = <110>;
- };
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: st: add thermal property on stih410.dtsi and stih418.dtsi
From: Raphael Gallais-Pou @ 2024-03-20 21:33 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Patrice Chotard,
Lee Jones
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240320-thermal-v3-0-700296694c4a@gmail.com>
"#thermal-sensor-cells" is required and missing in thermal nodes.
Add it.
Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
---
arch/arm/boot/dts/st/stih410.dtsi | 1 +
arch/arm/boot/dts/st/stih418.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/st/stih410.dtsi b/arch/arm/boot/dts/st/stih410.dtsi
index 29e95e9d3229..a69231854f78 100644
--- a/arch/arm/boot/dts/st/stih410.dtsi
+++ b/arch/arm/boot/dts/st/stih410.dtsi
@@ -270,6 +270,7 @@ thermal@91a0000 {
clock-names = "thermal";
clocks = <&clk_sysin>;
interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
+ #thermal-sensor-cells = <0>;
};
cec@94a087c {
diff --git a/arch/arm/boot/dts/st/stih418.dtsi b/arch/arm/boot/dts/st/stih418.dtsi
index b35b9b7a7ccc..0f0db988a907 100644
--- a/arch/arm/boot/dts/st/stih418.dtsi
+++ b/arch/arm/boot/dts/st/stih418.dtsi
@@ -113,6 +113,7 @@ thermal@91a0000 {
clock-names = "thermal";
clocks = <&clk_sysin>;
interrupts = <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>;
+ #thermal-sensor-cells = <0>;
};
};
};
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/3] net: phy: mediatek-ge: do not disable EEE advertisement
From: Russell King (Oracle) @ 2024-03-20 20:53 UTC (permalink / raw)
To: Arınç ÜNAL
Cc: Daniel Golle, DENG Qingfang, Sean Wang, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, René van Dorst, SkyLake Huang,
Heiner Kallweit, Bartel Eerdekens, mithat.guner, erkin.bozoglu,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <3698b522-d6dc-46c1-bab2-d5ee3bed1fce@arinc9.com>
On Wed, Mar 20, 2024 at 11:40:56PM +0300, Arınç ÜNAL wrote:
> On 18.03.2024 10:46, Arınç ÜNAL via B4 Relay wrote:
> > From: Arınç ÜNAL <arinc.unal@arinc9.com>
> >
> > There's no need to disable Energy-Efficient Ethernet (EEE) advertisement on
> > the MT7530 and MT7531 switch PHYs. EEE works fine on MT7530 and MT7531
> > switch PHYs. Remove the code where EEE advertisement is disabled.
> >
> > This is a bugfix because there's a possible race condition where the
> > mediatek-ge driver would kick in after the MT7530 DSA subdriver which would
> > have EEE disabled until manually enabled.
>
> Can I get an opinion on this? Is it actually possible that the PHY driver
> would start probing after the DSA subdriver? On the console logs for the
> DSA subdriver, I can see that the name of the PHY driver will appear, which
> makes me believe the PHY driver would actually never probe after the DSA
> subdriver.
>
> [ 4.402641] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.420392] mt7530-mdio mdio-bus:1f lan0 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.437791] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.455096] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=POLL)
> [ 4.472422] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7530 PHY] (irq=POLL)
>
> I don't want to submit a bugfix to the net tree if the bug won't ever
> happen in real life.
It would be really great if you could tell us which bug fixes you're
submitting are for a real problem that you or a user have encountered,
and which are down to essentially code inspection and things that
"aren't correct". Basically, don't do this.
It isn't true that the PHY specific driver will be probed before DSA
initialises - consider the case where the DSA driver is built-in but
the PHY specific driver is modular and on the not-yet-mounted rootfs.
That would result in the generic PHY driver being used even when the
PHY specific driver were to be loaded later - and thus only basic
standard 802.3 PHY behaviour will be supported.
That's not specific to mt7530, it applies to everything that uses
phylib. It isn't something that really warrants "bug fixing" in each
and every driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net] net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530
From: Arınç ÜNAL via B4 Relay @ 2024-03-20 20:45 UTC (permalink / raw)
To: Daniel Golle, DENG Qingfang, Sean Wang, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Landen Chao
Cc: Bartel Eerdekens, mithat.guner, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek,
Arınç ÜNAL
From: Arınç ÜNAL <arinc.unal@arinc9.com>
The MT7530 switch after reset initialises with a core clock frequency that
works with a 25MHz XTAL connected to it. For 40MHz XTAL, the core clock
frequency must be set to 500MHz.
The mt7530_pll_setup() function is responsible of setting the core clock
frequency. Currently, it runs on MT7530 with 25MHz and 40MHz XTAL. This
causes MT7530 switch with 25MHz XTAL to egress and ingress frames
improperly.
Introduce a check to run it only on MT7530 with 40MHz XTAL.
The core clock frequency is set by writing to a switch PHY's register.
Access to the PHY's register is done via the MDIO bus the switch is also
on. Therefore, it works only when the switch makes switch PHYs listen on
the MDIO bus the switch is on. This is controlled either by the state of
the ESW_P1_LED_1 pin after reset deassertion or modifying bit 5 of the
modifiable trap register.
When ESW_P1_LED_1 is pulled high, PHY indirect access is used. That means
accessing PHY registers via the PHY indirect access control register of the
switch.
When ESW_P1_LED_1 is pulled low, PHY direct access is used. That means
accessing PHY registers via the MDIO bus the switch is on.
For MT7530 switch with 40MHz XTAL on a board with ESW_P1_LED_1 pulled high,
the core clock frequency won't be set to 500MHz, causing the switch to
egress and ingress frames improperly.
Run mt7530_pll_setup() after PHY direct access is set on the modifiable
trap register.
With these two changes, all MT7530 switches with 25MHz and 40MHz, and
P1_LED_1 pulled high or low, will egress and ingress frames properly.
Link: https://github.com/BPI-SINOVOIP/BPI-R2-bsp/blob/4a5dd143f2172ec97a2872fa29c7c4cd520f45b5/linux-mt/drivers/net/ethernet/mediatek/gsw_mt7623.c#L1039
Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
drivers/net/dsa/mt7530.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 6986f538a4d0..c856a13bc2f1 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2232,8 +2232,6 @@ mt7530_setup(struct dsa_switch *ds)
SYS_CTRL_PHY_RST | SYS_CTRL_SW_RST |
SYS_CTRL_REG_RST);
- mt7530_pll_setup(priv);
-
/* Lower Tx driving for TRGMII path */
for (i = 0; i < NUM_TRGMII_CTRL; i++)
mt7530_write(priv, MT7530_TRGMII_TD_ODT(i),
@@ -2249,6 +2247,9 @@ mt7530_setup(struct dsa_switch *ds)
val |= MHWTRAP_MANUAL;
mt7530_write(priv, MT7530_MHWTRAP, val);
+ if ((val & HWTRAP_XTAL_MASK) == HWTRAP_XTAL_40MHZ)
+ mt7530_pll_setup(priv);
+
mt753x_trap_frames(priv);
/* Enable and reset MIB counters */
---
base-commit: 9c6a59543a3965071d65b0f9ea43aa396ce2ed14
change-id: 20240320-for-net-mt7530-fix-25mhz-xtal-with-direct-phy-access-e2aaed550ed5
Best regards,
--
Arınç ÜNAL <arinc.unal@arinc9.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Zijie Zhao @ 2024-03-20 20:26 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, gregory.clement, sebastian.hesselbarth,
linux-arm-kernel, chenyuan0y
In-Reply-To: <Zfs9I2IWSgb1gU8e@shell.armlinux.org.uk>
On 3/20/24 2:46 PM, Russell King (Oracle) wrote:
> On Wed, Mar 20, 2024 at 01:48:26PM -0500, zzjas98@gmail.com wrote:
>> On 3/20/24 7:27 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> On Tue, Mar 19, 2024 at 10:03:22PM -0500, Zijie Zhao wrote:
>>>> Dear ARM/Marvell maintainers,
>>>>
>>>> We came across an unusual usage of kzalloc in
>>>> arch/arm/mach-mvebu/board-v7.c, function i2c_quirk:
>>>>
>>>> https://elixir.bootlin.com/linux/v6.8/source/arch/arm/mach-mvebu/board-v7.c#L127
>>>> ```
>>>> static void __init i2c_quirk(void)
>>>> {
>>>> struct device_node *np;
>>>> u32 dev, rev;
>>>>
>>>> /*
>>>> * Only revisons more recent than A0 support the offload
>>>> * mechanism. We can exit only if we are sure that we can
>>>> * get the SoC revision and it is more recent than A0.
>>>> */
>>>> if (mvebu_get_soc_id(&dev, &rev) == 0 && rev > MV78XX0_A0_REV)
>>>> return;
>>>>
>>>> for_each_compatible_node(np, NULL, "marvell,mv78230-i2c") {
>>>> struct property *new_compat;
>>>>
>>>> new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
>>>>
>>>> new_compat->name = kstrdup("compatible", GFP_KERNEL);
>>>> new_compat->length = sizeof("marvell,mv78230-a0-i2c");
>>>> new_compat->value = kstrdup("marvell,mv78230-a0-i2c",
>>>> GFP_KERNEL);
>>>>
>>>> of_update_property(np, new_compat);
>>>> }
>>>> }
>>>> ```
>>>>
>>>> Should the new_compat be checked against NULL in case kzalloc fails, to
>>>> avoid NULL dereference later in the code?
>>>>
>>>> Please kindly let us know if we missed any key information and this is
>>>> actually intended. We appreciate your information and time! Thanks!
>>>
>>> What context is this code run in? What would need to happen for the
>>> allocation to fail? And what happens next if it does fail, both in
>>> this function and the system in general?
>>>
>>> Andrew
>>>
>>
>> Hi Andrew,
>>
>> Thanks for checking!
>>
>> We encountered this kzalloc while doing a static analysis for the kernel code.
>>
>> kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault.
>
> If we are out of memory at this point in the kernel boot, then what are
> the chances of the kernel getting to the point where it can run
> userspace?
>
> I think that is the essence of Andrew's argument. A failure to allocate
> memory here means there is a serious problem and the system won't boot
> _even_ if we add something like:
>
> if (!new_compat)
> continue;
>
> to that loop.
>
Hi Andrew and Russell,
Thanks for pointing out the consequence! It makes sense and we will
try to make our analyzer realize this as well. Thanks again for your time!
Best,
Zijie
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()
From: Peter Xu @ 2024-03-20 20:24 UTC (permalink / raw)
To: Christophe Leroy
Cc: Aneesh Kumar K.V, Jason Gunthorpe, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
Matthew Wilcox, linuxppc-dev@lists.ozlabs.org, Andrew Morton,
x86@kernel.org, Mike Rapoport, Muchun Song,
sparclinux@vger.kernel.org, Michael Ellerman, Nicholas Piggin,
Naveen N. Rao
In-Reply-To: <2e632389-eb4e-42af-adee-36d5ba6c3d0f@csgroup.eu>
On Wed, Mar 20, 2024 at 05:40:39PM +0000, Christophe Leroy wrote:
>
>
> Le 20/03/2024 à 17:09, Peter Xu a écrit :
> > On Wed, Mar 20, 2024 at 06:16:43AM +0000, Christophe Leroy wrote:
> >> At the first place that was to get a close fit between hardware
> >> pagetable topology and linux pagetable topology. But obviously we
> >> already stepped back for 512k pages, so let's go one more step aside and
> >> do similar with 8M pages.
> >>
> >> I'll give it a try and see how it goes.
> >
> > So you're talking about 8M only for 8xx, am I right?
>
> Yes I am.
>
> >
> > There seem to be other PowerPC systems use hugepd. Is it possible that we
> > convert all hugepd into cont_pte form?
>
> Indeed.
>
> Seems like we have hugepd for book3s/64 and for nohash.
>
> For book3s I don't know, may Aneesh can answer.
>
> For nohash I think it should be possible because TLB misses are handled
> by software. Even the e6500 which has a hardware tablewalk falls back on
> software walk when it is a hugepage IIUC.
It'll be great if I can get some answer here, and then I know the path for
hugepd in general. I don't want to add any new code into core mm to
something destined to fade away soon.
One option for me is I can check a macro of hugepd existance, so all new
code will only work when hugepd is not supported on such arch. However
that'll start to make some PowerPC systems special (which I still tried
hard to avoid, if that wasn't proved in the past..), meanwhile we'll also
need to keep some generic-mm paths (that I can already remove along with
the new code) only for these hugepd systems. But it's still okay to me,
it'll be just a matter of when to drop those codes, sooner or later.
Thanks,
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] media: dt-binding: media: Document rk3588’s vepu121
From: Sebastian Reichel @ 2024-03-20 20:16 UTC (permalink / raw)
To: Emmanuel Gil Peyrot
Cc: linux-kernel, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Cristian Ciocaltea, Dragan Simic, Shreeya Patel,
Chris Morgan, Andy Yan, Nicolas Frattaroli, linux-media,
linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-3-linkmauve@linkmauve.fr>
[-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --]
Hi,
On Wed, Mar 20, 2024 at 06:37:31PM +0100, Emmanuel Gil Peyrot wrote:
> This encoder-only device is present four times on this SoC, and should
> support everything the rk3568 vepu supports (so JPEG, H.264 and VP8
> encoding).
>
> Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> ---
> .../devicetree/bindings/media/rockchip,rk3568-vepu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> index 9d90d8d0565a..947ad699cc5e 100644
> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> @@ -17,6 +17,7 @@ properties:
> compatible:
> enum:
> - rockchip,rk3568-vepu
> + - rockchip,rk3588-vepu121
Looks like they are fully compatible. In that case it's better to
use a fallback compatible (i.e. like the iommu binding), which does
not need any drivers changes. So binding should be like this:
compatible:
oneOf:
- const: rockchip,rk3568-vepu
- items:
- enum:
- rockchip,rk3588-vepu121
- const: rockchip,rk3568-vepu
Then in DT (i.e. the following patch) you use
compatible = "rockchip,rk3588-vepu121", "rockchip,rk3568-vepu";
And patch 4/4 can be dropped.
Greetings,
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Russell King (Oracle) @ 2024-03-20 19:46 UTC (permalink / raw)
To: zzjas98
Cc: Andrew Lunn, gregory.clement, sebastian.hesselbarth,
linux-arm-kernel, chenyuan0y
In-Reply-To: <2baa9e59-fe81-4c92-b6ca-a86233c5e06d@gmail.com>
On Wed, Mar 20, 2024 at 01:48:26PM -0500, zzjas98@gmail.com wrote:
> On 3/20/24 7:27 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Tue, Mar 19, 2024 at 10:03:22PM -0500, Zijie Zhao wrote:
> > > Dear ARM/Marvell maintainers,
> > >
> > > We came across an unusual usage of kzalloc in
> > > arch/arm/mach-mvebu/board-v7.c, function i2c_quirk:
> > >
> > > https://elixir.bootlin.com/linux/v6.8/source/arch/arm/mach-mvebu/board-v7.c#L127
> > > ```
> > > static void __init i2c_quirk(void)
> > > {
> > > struct device_node *np;
> > > u32 dev, rev;
> > >
> > > /*
> > > * Only revisons more recent than A0 support the offload
> > > * mechanism. We can exit only if we are sure that we can
> > > * get the SoC revision and it is more recent than A0.
> > > */
> > > if (mvebu_get_soc_id(&dev, &rev) == 0 && rev > MV78XX0_A0_REV)
> > > return;
> > >
> > > for_each_compatible_node(np, NULL, "marvell,mv78230-i2c") {
> > > struct property *new_compat;
> > >
> > > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> > >
> > > new_compat->name = kstrdup("compatible", GFP_KERNEL);
> > > new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> > > new_compat->value = kstrdup("marvell,mv78230-a0-i2c",
> > > GFP_KERNEL);
> > >
> > > of_update_property(np, new_compat);
> > > }
> > > }
> > > ```
> > >
> > > Should the new_compat be checked against NULL in case kzalloc fails, to
> > > avoid NULL dereference later in the code?
> > >
> > > Please kindly let us know if we missed any key information and this is
> > > actually intended. We appreciate your information and time! Thanks!
> >
> > What context is this code run in? What would need to happen for the
> > allocation to fail? And what happens next if it does fail, both in
> > this function and the system in general?
> >
> > Andrew
> >
>
> Hi Andrew,
>
> Thanks for checking!
>
> We encountered this kzalloc while doing a static analysis for the kernel code.
>
> kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault.
If we are out of memory at this point in the kernel boot, then what are
the chances of the kernel getting to the point where it can run
userspace?
I think that is the essence of Andrew's argument. A failure to allocate
memory here means there is a serious problem and the system won't boot
_even_ if we add something like:
if (!new_compat)
continue;
to that loop.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] ARM: unwind: improve unwinders for noreturn case
From: Russell King (Oracle) @ 2024-03-20 19:42 UTC (permalink / raw)
To: Jiangfeng Xiao
Cc: linus.walleij, arnd, keescook, haibo.li,
angelogioacchino.delregno, amergnat, akpm, dave.hansen,
douzhaolei, gustavoars, jpoimboe, kepler.chenxin, kirill.shutemov,
linux-hardening, linux-kernel, linux-mm, linux-arm-kernel,
nixiaoming, peterz, wangbing6, wangfangpeng1, jannh, willy,
David.Laight
In-Reply-To: <1710949294-29287-1-git-send-email-xiaojiangfeng@huawei.com>
On Wed, Mar 20, 2024 at 11:41:34PM +0800, Jiangfeng Xiao wrote:
> This is an off-by-one bug which is common in unwinders,
> due to the fact that the address on the stack points
> to the return address rather than the call address.
>
> So, for example, when the last instruction of a function
> is a function call (e.g., to a noreturn function), it can
> cause the unwinder to incorrectly try to unwind from
> the function after the callee.
>
> foo:
> ...
> bl bar
> ... end of function and thus next function ...
>
> which results in LR pointing into the next function.
>
> Fixed this by subtracting 1 from frmae->pc in the call frame
> like ORC on x86 does.
>
> Refer to the unwind_next_frame function in the unwind_orc.c
This came in while I was still replying to your previous reply, so
I'm going to ignore this. Please allow at least 24 hours between
postings, and please allow discussion to finish before posting a
new version - give your reviewers adequate time to compose a reply
bearing in mind that timezones might get in the way, but also making
supper (as is the case in this instance) may cause several hour delay
in reply.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case
From: Russell King (Oracle) @ 2024-03-20 19:40 UTC (permalink / raw)
To: Jiangfeng Xiao
Cc: arnd, keescook, haibo.li, angelogioacchino.delregno, amergnat,
akpm, dave.hansen, douzhaolei, gustavoars, jpoimboe,
kepler.chenxin, kirill.shutemov, linux-hardening, linux-kernel,
linux-mm, linux-arm-kernel, nixiaoming, peterz, wangbing6,
wangfangpeng1, jannh, willy, David.Laight
In-Reply-To: <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com>
On Wed, Mar 20, 2024 at 11:30:05PM +0800, Jiangfeng Xiao wrote:
>
>
> On 2024/3/20 16:45, Russell King (Oracle) wrote:
> > On Wed, Mar 20, 2024 at 11:44:38AM +0800, Jiangfeng Xiao wrote:
> >> This is an off-by-one bug which is common in unwinders,
> >> due to the fact that the address on the stack points
> >> to the return address rather than the call address.
> >>
> >> So, for example, when the last instruction of a function
> >> is a function call (e.g., to a noreturn function), it can
> >> cause the unwinder to incorrectly try to unwind from
> >> the function after the callee.
> >>
> >> foo:
> >> ...
> >> bl bar
> >> ... end of function and thus next function ...
> >>
> >> which results in LR pointing into the next function.
> >>
> >> Fixed this by subtracting 1 from frmae->pc in the call frame
> >> (but not exception frames) like ORC on x86 does.
> >
> > The reason that I'm not accepting this patch is because the above says
> > that it fixes it by subtracting 1 from the PC value, but the patch is
> > *way* more complicated than that and there's no explanation why.
> >
> > For example, the following are unexplained:
> >
> > - Why do we always need ex_frame
>
> ```
> bar:
> ...
> ... end of function bar ...
>
> foo:
> BUG();
> ... end of function foo ...
> ```
>
> For example, when the first instruction of function 'foo'
> is a undefined instruction, after function 'foo' is executed
> to trigger an exception, 'arm_get_current_stackframe' assigns
> 'regs->ARM_pc' to 'frame.pc'.
>
> If we always decrement frame.pc by 1, unwinder will incorrectly
> try to unwind from the function 'bar' before the function 'foo'.
>
> So we need to 'ext_frame' to distinguish this case
> where we don't need to subtract 1.
This just sounds wrong to me. We have two different cases:
1) we're unwinding a frame where PC points at the offending instruction.
This may or may not be in the exception text.
2) we're unwinding a frame that has been created because of a branch,
where the PC points at the next instruction _after_ that callsite.
While we're unwinding, we will mostly hit the second type of frames, but
we'll only hit the first type on the initial frame. Some exception
entries will have the PC pointing at the next instruction to be
executed, others will have it pointing at the offending instruction
(e.g. if it needs to be retried.)
So, I don't see what being in the exception/entry text really has much
to do with any decision making here. I think you've found that it works
for your case, but it won't _always_ work and you're just shifting the
"bug" with how these traces work from one issue to a different but
similar issue.
> > - What is the purpose of the change in format string for the display of
> > backtraces
> ```
> unwind_frame(&frame);
> dump_backtrace_entry(...from) //from = frame.pc
> printk("...%pS\n", ...(void *)from);
> ```
> %pB will do sprint_backtrace and print the symbol at (from - 1) address
> %pS will do sprint_symbol_build_id and print the symbol at (from) address
The quote in printk-formats.rst states:
%pS versatile_init+0x0/0x110
%pB prev_fn_of_versatile_init+0x88/0x88
This is rather ambiguous on its own, since the definition of "previous
function" is ambiguous. Given the offset and size stated there, it's
also not obvious what pointer was passed. It would be nice if these
examples actually said what the pointer passed in actually was.
I had been interpreting "prev_fn_of_" to mean the caller of
versatile_init() but it could also be the preceeding function in the
kernel text to versatile_init() - that is where the ambiguity comes
from.
So, the question I now have is... if %pB prints the symbol corresponding
with "from - 1", then
- with the frame pointer walker, from will always be the return address
found on the stack for the function we are currently in.
- with the unwinder it will be whatever the unwinder computes as the LR
register unless the unwind instructions place a non-zero value in PC.
Is there a case where the unwinder gets this wrong?
I think what would help is if you split this patch up, and addressed
each part separately, describing the issue that each part is addressing
giving an example that clearly explains what the patch is doing.
However, please note my comments above that using the fact that we're
in an exception frame doesn't actually tell you anything about whether
you need to correct the PC value or not.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iommu: rockchip: Fix rk3588 variant
From: Sebastian Reichel @ 2024-03-20 19:15 UTC (permalink / raw)
To: Emmanuel Gil Peyrot
Cc: linux-kernel, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Cristian Ciocaltea, Dragan Simic, Shreeya Patel,
Chris Morgan, Andy Yan, Nicolas Frattaroli, linux-media,
linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240320173736.2720778-2-linkmauve@linkmauve.fr>
[-- Attachment #1.1: Type: text/plain, Size: 2175 bytes --]
Hello Emmanuel,
On Wed, Mar 20, 2024 at 06:37:30PM +0100, Emmanuel Gil Peyrot wrote:
> The documentation got added in f8aa519976b38e67aae02d2db3e2998513305e80,
> but it hasn’t been added to the driver so it was unused.
>
> Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> ---
Everything is fine with f8aa519976b38e67aae02d2db3e2998513305e80
(well the patch description could be better :)) and this patch is
just wrong. The documentation explicitly adds the combination of
rk3588-iommu with rk3568-iommu as fallback. The idea is, that the
driver handles it just like an rk3568 iommu. If some differences
are found in the future, the driver can switch to handle the more
specific compatible without any DT changes (which is ABI).
I suggest watching this presentation:
https://www.youtube.com/watch?v=6iguKSJJfxo
Greetings,
-- Sebastian
> arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 2 +-
> drivers/iommu/rockchip-iommu.c | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> index 87b83c87bd55..2a23b4dc36e4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> @@ -704,7 +704,7 @@ vp3: port@3 {
> };
>
> vop_mmu: iommu@fdd97e00 {
> - compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
> + compatible = "rockchip,rk3588-iommu";
> reg = <0x0 0xfdd97e00 0x0 0x100>, <0x0 0xfdd97f00 0x0 0x100>;
> interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH 0>;
> clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>;
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index da79d9f4cf63..da0e93c139d1 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1361,6 +1361,9 @@ static const struct of_device_id rk_iommu_dt_ids[] = {
> { .compatible = "rockchip,rk3568-iommu",
> .data = &iommu_data_ops_v2,
> },
> + { .compatible = "rockchip,rk3588-iommu",
> + .data = &iommu_data_ops_v2,
> + },
> { /* sentinel */ }
> };
>
> --
> 2.44.0
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arch/arm/mach-mvebu] Question about kzalloc NULL check in i2c_quirk
From: Andrew Lunn @ 2024-03-20 19:03 UTC (permalink / raw)
To: zzjas98
Cc: gregory.clement, sebastian.hesselbarth, linux, linux-arm-kernel,
chenyuan0y
In-Reply-To: <2baa9e59-fe81-4c92-b6ca-a86233c5e06d@gmail.com>
> > What context is this code run in? What would need to happen for the
> > allocation to fail? And what happens next if it does fail, both in
> > this function and the system in general?
> >
> > Andrew
> >
>
> Hi Andrew,
>
> Thanks for checking!
>
> We encountered this kzalloc while doing a static analysis for the kernel code.
>
> kzalloc would return NULL in case of out-of-memory and would make the next field access new_compat->name segfault.
>
> However, we are not sure if i2c_quirk, used in an init_machine hook, has any special assumption, so would appreciate your knowledge to decide whether an NULL check is needed.
Please configure your email client to wrap lines at around 70
characters.
O.K, let me help you answer your questions.
When is init_machine called?
What would need to happen for the allocation to fail?
Say it does fall, and you avoid a NULL pointer dereference here. What
happens next to the system in general.
These are not hard questions to answer, you just need to think about
them a little.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox