* [PATCH v2 3/6] arm64: dts: qcom: qcs6490-rb3gen2: Enable adsp and cdsp
From: Bjorn Andersson @ 2024-03-27 2:04 UTC (permalink / raw)
To: cros-qcom-dts-watchers, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
Bjorn Andersson
In-Reply-To: <20240326-rb3gen2-dp-connector-v2-0-a9f1bc32ecaf@quicinc.com>
Define firmware paths and enable the ADSP and CDSP remoteprocs.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index f90bf3518e98..5b267a94a282 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -508,6 +508,16 @@ &qupv3_id_0 {
status = "okay";
};
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs6490/adsp.mbn";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs6490/cdsp.mbn";
+ status = "okay";
+};
+
&tlmm {
gpio-reserved-ranges = <32 2>, /* ADSP */
<48 4>; /* NFC */
--
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 v5 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Tan Chun Hau @ 2024-03-27 1:57 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Simon Horman, Bartosz Golaszewski,
Andrew Halaney, Jisheng Zhang, Uwe Kleine-König,
Russell King
Cc: Ley Foon Tan, Jee Heng Sia, netdev, devicetree, linux-kernel,
linux-stm32, linux-arm-kernel, linux-riscv
In-Reply-To: <20240327015750.226349-1-chunhau.tan@starfivetech.com>
Add StarFive JH8100 dwmac support.
The JH8100 dwmac shares the same driver code as the JH7110 dwmac
and has only one reset signal.
Please refer to below:
JH8100: reset-names = "stmmaceth";
JH7110: reset-names = "stmmaceth", "ahb";
JH7100: reset-names = "ahb";
Example usage of JH8100 in the device tree:
gmac0: ethernet@16030000 {
compatible = "starfive,jh8100-dwmac",
"starfive,jh7110-dwmac",
"snps,dwmac-5.20";
...
};
Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 29 +++++++++++++++----
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 6b0341a8e0ea..a6d596b7dcf4 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -97,6 +97,7 @@ properties:
- snps,dwxgmac-2.10
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jh8100-dwmac
reg:
minItems: 1
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..5805a58c55d1 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -18,6 +18,7 @@ select:
enum:
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jh8100-dwmac
required:
- compatible
@@ -30,6 +31,10 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jh8100-dwmac
+ - const: starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -116,11 +121,25 @@ allOf:
minItems: 3
maxItems: 3
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh8100-dwmac
+ then:
+ properties:
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+ else:
+ properties:
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
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 v5 0/1] Add StarFive JH8100 dwmac support
From: Tan Chun Hau @ 2024-03-27 1:57 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Simon Horman, Bartosz Golaszewski,
Andrew Halaney, Jisheng Zhang, Uwe Kleine-König,
Russell King
Cc: Ley Foon Tan, Jee Heng Sia, netdev, devicetree, linux-kernel,
linux-stm32, linux-arm-kernel, linux-riscv
Add StarFive JH8100 dwmac support.
The JH8100 dwmac shares the same driver code as the JH7110 dwmac
and has only one reset signal.
Please refer to below:
JH8100: reset-names = "stmmaceth";
JH7110: reset-names = "stmmaceth", "ahb";
JH7100: reset-names = "ahb";
Example usage of JH8100 in the device tree:
gmac0: ethernet@16030000 {
compatible = "starfive,jh8100-dwmac",
"starfive,jh7110-dwmac",
"snps,dwmac-5.20";
...
};
Changes in v5:
- Addressed duplicated interrupts and interrupt-names.
Tan Chun Hau (1):
dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 29 +++++++++++++++----
2 files changed, 25 insertions(+), 5 deletions(-)
--
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
* RE: [PATCH v4 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: ChunHau Tan @ 2024-03-27 1:56 UTC (permalink / raw)
To: Rob Herring
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Leyfoon Tan, JeeHeng Sia,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20240326213426.GA3667606-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Wednesday, 27 March, 2024 5:34 AM
> To: ChunHau Tan <chunhau.tan@starfivetech.com>
> Cc: David S . Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Emil Renner Berthing <kernel@esmil.dk>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Maxime Coquelin <mcoquelin.stm32@gmail.com>;
> Alexandre Torgue <alexandre.torgue@foss.st.com>; Simon Horman
> <horms@kernel.org>; Bartosz Golaszewski <bartosz.golaszewski@linaro.org>;
> Andrew Halaney <ahalaney@redhat.com>; Jisheng Zhang <jszhang@kernel.org>;
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de>; Russell King
> <rmk+kernel@armlinux.org.uk>; Leyfoon Tan <leyfoon.tan@starfivetech.com>;
> JeeHeng Sia <jeeheng.sia@starfivetech.com>; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-stm32@st-md-mailman.stormreply.com;
> linux-arm-kernel@lists.infradead.org; linux-riscv@lists.infradead.org
> Subject: Re: [PATCH v4 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add
> StarFive JH8100 support
>
> On Mon, Mar 25, 2024 at 10:25:05PM -0700, Tan Chun Hau wrote:
> > Add StarFive JH8100 dwmac support.
> > The JH8100 dwmac shares the same driver code as the JH7110 dwmac and
> > has only one reset signal.
> >
> > Please refer to below:
> >
> > JH8100: reset-names = "stmmaceth";
> > JH7110: reset-names = "stmmaceth", "ahb";
> > JH7100: reset-names = "ahb";
> >
> > Example usage of JH8100 in the device tree:
> >
> > gmac0: ethernet@16030000 {
> > compatible = "starfive,jh8100-dwmac",
> > "starfive,jh7110-dwmac",
> > "snps,dwmac-5.20";
> > ...
> > };
> >
> > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > ---
> > .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> > .../bindings/net/starfive,jh7110-dwmac.yaml | 54 ++++++++++++++-----
> > 2 files changed, 41 insertions(+), 14 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index 6b0341a8e0ea..a6d596b7dcf4 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -97,6 +97,7 @@ properties:
> > - snps,dwxgmac-2.10
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
> >
> > reg:
> > minItems: 1
> > diff --git
> > a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > index 0d1962980f57..ce018e9768d2 100644
> > --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > @@ -18,6 +18,7 @@ select:
> > enum:
> > - starfive,jh7100-dwmac
> > - starfive,jh7110-dwmac
> > + - starfive,jh8100-dwmac
> > required:
> > - compatible
> >
> > @@ -30,6 +31,10 @@ properties:
> > - items:
> > - const: starfive,jh7110-dwmac
> > - const: snps,dwmac-5.20
> > + - items:
> > + - const: starfive,jh8100-dwmac
> > + - const: starfive,jh7110-dwmac
> > + - const: snps,dwmac-5.20
> >
> > reg:
> > maxItems: 1
> > @@ -107,20 +112,41 @@ allOf:
> > contains:
> > const: starfive,jh7110-dwmac
> > then:
> > - properties:
> > - interrupts:
> > - minItems: 3
> > - maxItems: 3
> > -
> > - interrupt-names:
> > - minItems: 3
> > - maxItems: 3
>
> interrupts and interrupt-names are the same, so you can leave them here instead
> of duplicating them as you have.
Okay, thank you for the feedback.
>
> > -
> > - resets:
> > - minItems: 2
> > -
> > - reset-names:
> > - minItems: 2
> > + if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: starfive,jh8100-dwmac
> > + then:
> > + properties:
> > + interrupts:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + interrupt-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + const: stmmaceth
> > + else:
> > + properties:
> > + interrupts:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + interrupt-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + resets:
> > + minItems: 2
> > +
> > + reset-names:
> > + minItems: 2
> >
> > unevaluatedProperties: false
> >
> > --
> > 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
* Re: [PATCH v6 0/2] Add Reviewed-by and Acked-by tags
From: Andrew Jeffery @ 2024-03-27 1:46 UTC (permalink / raw)
To: Kelly Hung, robh+dt
Cc: krzysztof.kozlowski+dt, conor+dt, joel, devicetree,
linux-arm-kernel, linux-aspeed, linux-kernel, openbmc, kelly_hung,
Allenyy_Hsu
In-Reply-To: <20240326103549.2413515-1-Kelly_Hung@asus.com>
Hi Kelly,
On Tue, 2024-03-26 at 18:35 +0800, Kelly Hung wrote:
> There are no changes to the Patch file, just the reviewed and acked tags are added.
> PATCH v5 has been merged into the next branch.
As others have said, please don't add tags that have not been
explicitly given for your patches.
Further, if a patch has been added to any upstream "next" branches it's
not necessary to resend the patches beyond that point, unless there are
errors that need correcting.
Joel had added an earlier revision of your patches to a branch of
candidate patches to upstream, and I've updated those in my own that
I'm maintaining while he's on leave. I'd also added your patches to the
OpenBMC kernel tree as a consequence, but you shouldn't apply tags to
your upstream patches that other people didn't provide you on that
basis.
As for the concerns reported by Rob's bot, I've got a series that
cleans up many of them. I'm working to find time to send them out.
Hopefully these help reduce the noise in the future.
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 4/5] dt-bindings: arm: Add Au-Zone Maivin AI Vision Starter Kit
From: Laurent Pinchart @ 2024-03-27 1:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Li Yang
In-Reply-To: <75218bd1-0d88-4986-90a6-35f7bdc53918@linaro.org>
Hi Krzysztof,
On Tue, Mar 26, 2024 at 08:11:34AM +0100, Krzysztof Kozlowski wrote:
> On 25/03/2024 21:32, Laurent Pinchart wrote:
> > The Maivin board is an AI vision starter kit sold by Au-Zone
> > Technologies, developed in collaboration with Toradex and Vision
> > Components. It is based on a Toradex Verdin i.MX8MP SoM.
> >
> > Add a corresponding compatible string.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index 0027201e19f8..d892c4f9fda3 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -1064,6 +1064,13 @@ properties:
> > - toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules
> > - const: fsl,imx8mp
> >
> > + - description: Au-Zone Technologies i.MX8MP-based boards
> > + items:
> > + - const: au-zone,maivin-starter-kit # Au-Zone Maivin AI Vision Starter Kit
> > + - const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
> > + - const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
>
> I think this should be part of existing "Toradex Boards with Verdin
> iMX8M Plus Modules)", just renamed to "boards using Toradex Verdin ...".
Is this what you have in mind ?
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index d892c4f9fda3..df5a04ab83a0 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1106,9 +1106,10 @@ properties:
- const: polyhex,imx8mp-debix-som-a # Polyhex Debix SOM A
- const: fsl,imx8mp
- - description: Toradex Boards with Verdin iMX8M Plus Modules
+ - description: Boards using Toradex Verdin iMX8M Plus Modules
items:
- enum:
+ - au-zone,maivin-starter-kit # Au-Zone Maivin AI Vision Starter Kit
- toradex,verdin-imx8mp-nonwifi-dahlia # Verdin iMX8M Plus Module on Dahlia
- toradex,verdin-imx8mp-nonwifi-dev # Verdin iMX8M Plus Module on Verdin Development Board
- toradex,verdin-imx8mp-nonwifi-mallow # Verdin iMX8M Plus Module on Mallow
--
Regards,
Laurent Pinchart
_______________________________________________
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] arm64: dts: debix-a: Remove i2c2 from base .dts
From: Laurent Pinchart @ 2024-03-27 0:51 UTC (permalink / raw)
To: Kieran Bingham
Cc: devicetree, imx, linux-arm-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jacopo Mondi,
Jacopo Mondi
In-Reply-To: <171144729683.3566204.12672101779935759480@ping.linuxembedded.co.uk>
On Tue, Mar 26, 2024 at 10:01:36AM +0000, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2024-03-25 22:50:48)
> > From: Jacopo Mondi <jacopo@jmondi.org>
> >
> > The I2C2 bus is used for the CSI and DSI connectors only, no devices are
> > connected to it on neither the Debix Model A nor its IO board. Remove
> > the bus from the board's .dts and rely on display panel or camera sensor
> > overlsy to enable it when necessary.
>
> s/overlsy/overlays/
Oops. Shawn, could you fix this when taking the patch in your tree, or
would you live me to submit a v2 ?
> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
>
> >
> > Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > .../boot/dts/freescale/imx8mp-debix-model-a.dts | 14 --------------
> > 1 file changed, 14 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > index 5ac77eaf23d5..26c303b7c7fa 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > @@ -210,13 +210,6 @@ ldo5: LDO5 {
> > };
> > };
> >
> > -&i2c2 {
> > - clock-frequency = <100000>;
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_i2c2>;
> > - status = "okay";
> > -};
> > -
> > &i2c3 {
> > clock-frequency = <400000>;
> > pinctrl-names = "default";
> > @@ -392,13 +385,6 @@ MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c2
> > >;
> > };
> >
> > - pinctrl_i2c2: i2c2grp {
> > - fsl,pins = <
> > - MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c2
> > - MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001c2
> > - >;
> > - };
> > -
> > pinctrl_i2c3: i2c3grp {
> > fsl,pins = <
> > MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c2
--
Regards,
Laurent Pinchart
_______________________________________________
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 v11 0/5]arm64: add ARCH_HAS_COPY_MC support
From: Tong Tiangen @ 2024-03-27 0:49 UTC (permalink / raw)
To: Mark Rutland, Catalin Marinas, Will Deacon, Andrew Morton,
James Morse, Robin Murphy, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Michael Ellerman, Nicholas Piggin,
Andrey Ryabinin, Alexander Potapenko, Christophe Leroy,
Aneesh Kumar K.V, Naveen N. Rao, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-arm-kernel, linux-mm, linuxppc-dev, linux-kernel,
wangkefeng.wang, Guohanjun
In-Reply-To: <20240207132204.1720444-1-tongtiangen@huawei.com>
Hi Mark:
Kindly ping...
Thanks,
Tong.
在 2024/2/7 21:21, Tong Tiangen 写道:
> With the increase of memory capacity and density, the probability of memory
> error also increases. The increasing size and density of server RAM in data
> centers and clouds have shown increased uncorrectable memory errors.
>
> Currently, more and more scenarios that can tolerate memory errors，such as
> CoW[1,2], KSM copy[3], coredump copy[4], khugepaged[5,6], uaccess copy[7],
> etc.
>
> This patchset introduces a new processing framework on ARM64, which enables
> ARM64 to support error recovery in the above scenarios, and more scenarios
> can be expanded based on this in the future.
>
> In arm64, memory error handling in do_sea(), which is divided into two cases:
> 1. If the user state consumed the memory errors, the solution is to kill
> the user process and isolate the error page.
> 2. If the kernel state consumed the memory errors, the solution is to
> panic.
>
> For case 2, Undifferentiated panic may not be the optimal choice, as it can
> be handled better. In some scenarios, we can avoid panic, such as uaccess,
> if the uaccess fails due to memory error, only the user process will be
> affected, killing the user process and isolating the user page with
> hardware memory errors is a better choice.
>
> [1] commit d302c2398ba2 ("mm, hwpoison: when copy-on-write hits poison, take page offline")
> [2] commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults")
> [3] commit 6b970599e807 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()")
> [4] commit 245f09226893 ("mm: hwpoison: coredump: support recovery from dump_user_range()")
> [5] commit 98c76c9f1ef7 ("mm/khugepaged: recover from poisoned anonymous memory")
> [6] commit 12904d953364 ("mm/khugepaged: recover from poisoned file-backed memory")
> [7] commit 278b917f8cb9 ("x86/mce: Add _ASM_EXTABLE_CPY for copy user access")
>
> ------------------
> Test result:
>
> 1. copy_page(), copy_mc_page() basic function test pass, and the disassembly
> contents remains the same before and after refactor.
>
> 2. copy_to/from_user() access kernel NULL pointer raise translation fault
> and dump error message then die(), test pass.
>
> 3. Test following scenarios: copy_from_user(), get_user(), COW.
>
> Before patched: trigger a hardware memory error then panic.
> After patched: trigger a hardware memory error without panic.
>
> Testing step:
> step1. start an user-process.
> step2. poison(einj) the user-process's page.
> step3: user-process access the poison page in kernel mode, then trigger SEA.
> step4: the kernel will not panic, only the user process is killed, the poison
> page is isolated. (before patched, the kernel will panic in do_sea())
>
> ------------------
>
> Since V10:
> Accroding Mark's suggestion:
> 1. Merge V10's patch2 and patch3 to V11's patch2.
> 2. Patch2(V11): use new fixup_type for ld* in copy_to_user(), fix fatal
> issues (NULL kernel pointeraccess) been fixup incorrectly.
> 3. Patch2(V11): refactoring the logic of do_sea().
> 4. Patch4(V11): Remove duplicate assembly logic and remove do_mte().
>
> Besides:
> 1. Patch2(V11): remove st* insn's fixup, st* generally not trigger memory error.
> 2. Split a part of the logic of patch2(V11) to patch5(V11), for detail,
> see patch5(V11)'s commit msg.
> 3. Remove patch6(v10) “arm64: introduce copy_mc_to_kernel() implementation”.
> During modification, some problems that cannot be solved in a short
> period are found. The patch will be released after the problems are
> solved.
> 4. Add test result in this patch.
> 5. Modify patchset title, do not use machine check and remove "-next".
>
> Since V9:
> 1. Rebase to latest kernel version 6.8-rc2.
> 2. Add patch 6/6 to support copy_mc_to_kernel().
>
> Since V8:
> 1. Rebase to latest kernel version and fix topo in some of the patches.
> 2. According to the suggestion of Catalin, I attempted to modify the
> return value of function copy_mc_[user]_highpage() to bytes not copied.
> During the modification process, I found that it would be more
> reasonable to return -EFAULT when copy error occurs (referring to the
> newly added patch 4).
>
> For ARM64, the implementation of copy_mc_[user]_highpage() needs to
> consider MTE. Considering the scenario where data copying is successful
> but the MTE tag copying fails, it is also not reasonable to return
> bytes not copied.
> 3. Considering the recent addition of machine check safe support for
> multiple scenarios, modify commit message for patch 5 (patch 4 for V8).
>
> Since V7:
> Currently, there are patches supporting recover from poison
> consumption for the cow scenario[1]. Therefore, Supporting cow
> scenario under the arm64 architecture only needs to modify the relevant
> code under the arch/.
> [1]https://lore.kernel.org/lkml/20221031201029.102123-1-tony.luck@intel.com/
>
> Since V6:
> Resend patches that are not merged into the mainline in V6.
>
> Since V5:
> 1. Add patch2/3 to add uaccess assembly helpers.
> 2. Optimize the implementation logic of arm64_do_kernel_sea() in patch8.
> 3. Remove kernel access fixup in patch9.
> All suggestion are from Mark.
>
> Since V4:
> 1. According Michael's suggestion, add patch5.
> 2. According Mark's suggestiog, do some restructuring to arm64
> extable, then a new adaptation of machine check safe support is made based
> on this.
> 3. According Mark's suggestion, support machine check safe in do_mte() in
> cow scene.
> 4. In V4, two patches have been merged into -next, so V5 not send these
> two patches.
>
> Since V3:
> 1. According to Robin's suggestion, direct modify user_ldst and
> user_ldp in asm-uaccess.h and modify mte.S.
> 2. Add new macro USER_MC in asm-uaccess.h, used in copy_from_user.S
> and copy_to_user.S.
> 3. According to Robin's suggestion, using micro in copy_page_mc.S to
> simplify code.
> 4. According to KeFeng's suggestion, modify powerpc code in patch1.
> 5. According to KeFeng's suggestion, modify mm/extable.c and some code
> optimization.
>
> Since V2:
> 1. According to Mark's suggestion, all uaccess can be recovered due to
> memory error.
> 2. Scenario pagecache reading is also supported as part of uaccess
> (copy_to_user()) and duplication code problem is also solved.
> Thanks for Robin's suggestion.
> 3. According Mark's suggestion, update commit message of patch 2/5.
> 4. According Borisllav's suggestion, update commit message of patch 1/5.
>
> Since V1:
> 1.Consistent with PPC/x86, Using CONFIG_ARCH_HAS_COPY_MC instead of
> ARM64_UCE_KERNEL_RECOVERY.
> 2.Add two new scenes, cow and pagecache reading.
> 3.Fix two small bug(the first two patch).
>
> V1 in here:
> https://lore.kernel.org/lkml/20220323033705.3966643-1-tongtiangen@huawei.com/
>
> Tong Tiangen (5):
> uaccess: add generic fallback version of copy_mc_to_user()
> arm64: add support for ARCH_HAS_COPY_MC
> mm/hwpoison: return -EFAULT when copy fail in
> copy_mc_[user]_highpage()
> arm64: support copy_mc_[user]_highpage()
> arm64: send SIGBUS to user process for SEA exception
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/asm-extable.h | 31 ++++++++++++---
> arch/arm64/include/asm/asm-uaccess.h | 4 ++
> arch/arm64/include/asm/extable.h | 1 +
> arch/arm64/include/asm/mte.h | 9 +++++
> arch/arm64/include/asm/page.h | 10 +++++
> arch/arm64/lib/Makefile | 2 +
> arch/arm64/lib/copy_mc_page.S | 37 ++++++++++++++++++
> arch/arm64/lib/copy_page.S | 50 +++----------------------
> arch/arm64/lib/copy_page_template.S | 56 ++++++++++++++++++++++++++++
> arch/arm64/lib/copy_to_user.S | 10 ++---
> arch/arm64/lib/mte.S | 29 ++++++++++++++
> arch/arm64/mm/copypage.c | 45 ++++++++++++++++++++++
> arch/arm64/mm/extable.c | 19 ++++++++++
> arch/arm64/mm/fault.c | 39 ++++++++++++++-----
> arch/powerpc/include/asm/uaccess.h | 1 +
> arch/x86/include/asm/uaccess.h | 1 +
> include/linux/highmem.h | 16 ++++++--
> include/linux/uaccess.h | 9 +++++
> mm/khugepaged.c | 4 +-
> 20 files changed, 304 insertions(+), 70 deletions(-)
> create mode 100644 arch/arm64/lib/copy_mc_page.S
> create mode 100644 arch/arm64/lib/copy_page_template.S
>
_______________________________________________
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 4/4] kprobes: Remove core dependency on modules
From: Masami Hiramatsu @ 2024-03-27 0:01 UTC (permalink / raw)
To: Mark Rutland
Cc: Jarkko Sakkinen, linux-kernel, agordeev, anil.s.keshavamurthy,
aou, bp, catalin.marinas, dave.hansen, davem, gor, hca,
jcalvinowens, linux-arm-kernel, mhiramat, mingo, mpe,
naveen.n.rao, palmer, paul.walmsley, tglx, will
In-Reply-To: <ZgMICo-dZJgVklc4@FVFF77S0Q05N.cambridge.arm.com>
On Tue, 26 Mar 2024 17:38:18 +0000
Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Mar 26, 2024 at 07:13:51PM +0200, Jarkko Sakkinen wrote:
> > On Tue Mar 26, 2024 at 6:36 PM EET, Mark Rutland wrote:
>
> > > +#ifdef CONFIG_MODULES
> > > /* Check if 'p' is probing a module. */
> > > *probed_mod = __module_text_address((unsigned long) p->addr);
> > > if (*probed_mod) {
> > > @@ -1605,6 +1606,8 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > > ret = -ENOENT;
> > > }
> > > }
> > > +#endif
> >
> > This can be scoped a bit more (see v7 of my patch set).
>
> > > +#ifdef CONFIG_MODULES
> > > static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> > > {
> > > char *p;
> > > @@ -129,6 +130,9 @@ static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> > >
> > > return ret;
> > > }
> > > +#else
> > > +#define trace_kprobe_module_exist(tk) false /* aka a module never exists */
> > > +#endif /* CONFIG_MODULES */
> > >
> > > static bool trace_kprobe_is_busy(struct dyn_event *ev)
> > > {
> > > @@ -670,6 +674,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
> > > return ret;
> > > }
> > >
> > > +#ifdef CONFIG_MODULES
> > > /* Module notifier call back, checking event on the module */
> > > static int trace_kprobe_module_callback(struct notifier_block *nb,
> > > unsigned long val, void *data)
> > > @@ -699,6 +704,9 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
> > >
> > > return NOTIFY_DONE;
> > > }
> > > +#else
> > > +#define trace_kprobe_module_callback (NULL)
> > > +#endif /* CONFIG_MODULES */
> >
> > The last two CONFIG_MODULES sections could be combined. This was also in
> > v7.
>
> > Other than lgtm.
>
> Great! I've folded your v7 changes in, and pushed that out to:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kprobes/without-modules
>
> I'll hold off sending that out to the list until other folk have had a chance
> to comment.
Yeah, the updated one looks good to me too.
Thanks!
>
> Mark.
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
_______________________________________________
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] virtio_ring: Fix the stale index in available ring
From: Gavin Shan @ 2024-03-27 0:01 UTC (permalink / raw)
To: Will Deacon, Keir Fraser
Cc: Michael S. Tsirkin, virtualization, linux-kernel, jasowang,
xuanzhuo, yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas,
mochs
In-Reply-To: <6bdf2884-852e-42d3-9e67-c9d5aa7d932a@redhat.com>
On 3/27/24 09:14, Gavin Shan wrote:
> On 3/27/24 01:46, Will Deacon wrote:
>> On Tue, Mar 26, 2024 at 11:43:13AM +0000, Will Deacon wrote:
>>
>> Ok, long shot after eyeballing the vhost code, but does the diff below
>> help at all? It looks like vhost_vq_avail_empty() can advance the value
>> saved in 'vq->avail_idx' but without the read barrier, possibly confusing
>> vhost_get_vq_desc() in polling mode.
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index 045f666b4f12..87bff710331a 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -2801,6 +2801,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
>> return false;
>> vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
>> + smp_rmb();
>> return vq->avail_idx == vq->last_avail_idx;
>> }
>> EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
>>
>
> Thanks, Will. I already noticed smp_rmb() has been missed in vhost_vq_avail_empty().
> The issue still exists after smp_rmb() is added here. However, I'm inspired by your
> suggestion and recheck the code again. It seems another smp_rmb() has been missed
> in vhost_enable_notify().
>
> With smp_rmb() added to vhost_vq_avail_empty() and vhost_enable_notify(), I'm unable
> to hit the issue. I will try for more times to make sure the issue is really resolved.
> After that, I will post formal patches for review.
>
Thanks again, Will. The formal patches have been sent for review.
https://lkml.org/lkml/2024/3/27/40
Thanks,
Gavin
_______________________________________________
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: fix clang build warning in include/asm/memory.h
From: Nathan Chancellor @ 2024-03-26 23:55 UTC (permalink / raw)
To: Yipeng Zou
Cc: linux, ndesaulniers, morbo, justinstitt, linus.walleij, ssantosh,
linux-arm-kernel
In-Reply-To: <20240321013529.962023-1-zouyipeng@huawei.com>
On Thu, Mar 21, 2024 at 09:35:29AM +0800, Yipeng Zou wrote:
> 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>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> 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
* Re: [PATCH] ARM: vfp: use asm volatile for FP control register accesses
From: Nathan Chancellor @ 2024-03-26 23:55 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux, arnd, linus.walleij, Ard Biesheuvel,
stable
In-Reply-To: <20240318093004.117153-2-ardb+git@google.com>
On Mon, Mar 18, 2024 at 10:30:05AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Clang may reorder FP control register reads and writes, due to the fact
> that the inline asm() blocks in the read/write wrappers are not volatile
> qualified, and the compiler has no idea that these reads and writes may
> have side effects.
>
> In particular, reads of FPSCR may generate an UNDEF exception if a
> floating point exception is pending, and the FP emulation code in
> VFP_bounce() explicitly clears FP exceptions temporarily in order to be
> able to perform the emulation on behalf of user space. This requires
> that the writes to FPEXC are never reordered with respect to accesses to
> other FP control registers, such as FPSCR.
>
> So use asm volatile for both the read and the write helpers.
>
> Cc: <stable@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This seems reasonable to me based on my understanding of GCC's
documentation. However, their documentation states "the compiler can
move even volatile asm instructions relative to other code, including
across jump instructions" and I feel like there was some discussion
around this sentence in the past but I can't remember what the
conclusion was, although I want to say Clang did not have the same
behavior. Regardless:
Acked-by: Nathan Chancellor <nathan@kernel.org>
I am just curious, how was this discovered or noticed? Was there a
report I missed?
> ---
> arch/arm/vfp/vfpinstr.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> index 3c7938fd40aa..c4ac778e6fc9 100644
> --- a/arch/arm/vfp/vfpinstr.h
> +++ b/arch/arm/vfp/vfpinstr.h
> @@ -66,14 +66,14 @@
>
> #define fmrx(_vfp_) ({ \
> u32 __v; \
> - asm(".fpu vfpv2\n" \
> + asm volatile(".fpu vfpv2\n" \
> "vmrs %0, " #_vfp_ \
> : "=r" (__v) : : "cc"); \
> __v; \
> })
>
> #define fmxr(_vfp_,_var_) \
> - asm(".fpu vfpv2\n" \
> + asm volatile(".fpu vfpv2\n" \
> "vmsr " #_vfp_ ", %0" \
> : : "r" (_var_) : "cc")
>
> --
> 2.39.2
>
_______________________________________________
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 00/19] amba: store owner from modules with amba_driver_register()
From: Suzuki K Poulose @ 2024-03-26 23:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Russell King, Mike Leach, James Clark,
Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Andi Shyti, Olivia Mackall, Herbert Xu, Vinod Koul,
Dmitry Torokhov, Miquel Raynal, Michal Simek, Eric Auger,
Alex Williamson
Cc: linux-kernel, coresight, linux-arm-kernel, linux-stm32, linux-i2c,
linux-crypto, dmaengine, linux-input, kvm
In-Reply-To: <20240326-module-owner-amba-v1-0-4517b091385b@linaro.org>
Hi Krzysztof
On 26/03/2024 20:23, Krzysztof Kozlowski wrote:
> Merging
> =======
> All further patches depend on the first amba patch, therefore please ack
> and this should go via one tree.
Are you able to provide a stable branch with these patches once you pull
them in to "one tree" here ? We have changes coming up in the coresight
tree, which would conflict with the changes here (horribly).
FWIW,
For patches 1 to 13 :
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Suzuki
_______________________________________________
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 v6] PCI: keystone: Fix pci_ops for AM654x SoC
From: Bjorn Helgaas @ 2024-03-26 23:24 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lpieralisi, kw, robh, bhelgaas, manivannan.sadhasivam,
fancer.lancer, u.kleine-koenig, cassel, dlemoal,
yoshihiro.shimoda.uh, linux-pci, linux-kernel, linux-arm-kernel,
srk
In-Reply-To: <20240326144258.2404433-1-s-vadapalli@ti.com>
On Tue, Mar 26, 2024 at 08:12:58PM +0530, Siddharth Vadapalli wrote:
> In the process of converting .scan_bus() callbacks to .add_bus(), the
> ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
> The .scan_bus() method belonged to ks_pcie_host_ops which was specific
> to controller version 3.65a, while the .add_bus() method had been added
> to ks_pcie_ops which is shared between the controller versions 3.65a and
> 4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
> ks_pcie_v3_65_add_bus() method is applicable to the controller version
> 4.90a which is present in AM654x SoCs.
>
> Thus, as a fix, move the contents of "ks_pcie_v3_65_add_bus()" to the
> .msi_init callback "ks_pcie_msi_host_init()" which is specific to the
> 3.65a controller. Also, move the definitions of ks_pcie_set_dbi_mode()
> and ks_pcie_clear_dbi_mode() above ks_pcie_msi_host_init() in order to
> avoid forward declaration.
If it's possible to split this into two patches (one that strictly
*moves* the code without otherwise changing it, and another that makes
the actual fix), it would be easier to review the fix. It's a pain to
have to compare the code in the old location with that in the new
location.
Bjorn
_______________________________________________
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] virtio_ring: Fix the stale index in available ring
From: Gavin Shan @ 2024-03-26 23:14 UTC (permalink / raw)
To: Will Deacon, Keir Fraser
Cc: Michael S. Tsirkin, virtualization, linux-kernel, jasowang,
xuanzhuo, yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas,
mochs
In-Reply-To: <20240326154628.GA9613@willie-the-truck>
On 3/27/24 01:46, Will Deacon wrote:
> On Tue, Mar 26, 2024 at 11:43:13AM +0000, Will Deacon wrote:
>
> Ok, long shot after eyeballing the vhost code, but does the diff below
> help at all? It looks like vhost_vq_avail_empty() can advance the value
> saved in 'vq->avail_idx' but without the read barrier, possibly confusing
> vhost_get_vq_desc() in polling mode.
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 045f666b4f12..87bff710331a 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2801,6 +2801,7 @@ bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
> return false;
> vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
>
> + smp_rmb();
> return vq->avail_idx == vq->last_avail_idx;
> }
> EXPORT_SYMBOL_GPL(vhost_vq_avail_empty);
>
Thanks, Will. I already noticed smp_rmb() has been missed in vhost_vq_avail_empty().
The issue still exists after smp_rmb() is added here. However, I'm inspired by your
suggestion and recheck the code again. It seems another smp_rmb() has been missed
in vhost_enable_notify().
With smp_rmb() added to vhost_vq_avail_empty() and vhost_enable_notify(), I'm unable
to hit the issue. I will try for more times to make sure the issue is really resolved.
After that, I will post formal patches for review.
Thanks,
Gavin
_______________________________________________
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 2/2] arm64: dts: allwinner: pinephone: add multicolor LED node
From: Jernej Škrabec @ 2024-03-26 22:44 UTC (permalink / raw)
To: linux-kernel, Aren Moynihan
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Chen-Yu Tsai,
Pavel Machek, devicetree, linux-sunxi, Miles Alan, Samuel Holland,
linux-arm-kernel, Ondrej Jirman, Aren Moynihan
In-Reply-To: <20240317004116.1473967-2-aren@peacevolution.org>
Dne nedelja, 17. marec 2024 ob 01:39:29 CET je Aren Moynihan napisal(a):
> The red, green, and blue LEDs currently in the device tree represent a
> single RGB LED on the front of the PinePhone.
>
> Signed-off-by: Aren Moynihan <aren@peacevolution.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] firmware: ti_sci: Use devm_register_restart_handler()
From: Andrew Davis @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Santosh Shilimkar,
Nishanth Menon, Vignesh Raghavendra
Cc: devicetree, linux-arm-kernel, linux-kernel, Andrew Davis
In-Reply-To: <20240326223730.54639-1-afd@ti.com>
Use device life-cycle managed register function to simplify probe.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Gabriel Somlo <gsomlo@gmail.com>
---
drivers/firmware/ti_sci.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 8b9a2556de16d..9885e1763591b 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -87,7 +87,6 @@ struct ti_sci_desc {
* struct ti_sci_info - Structure representing a TI SCI instance
* @dev: Device pointer
* @desc: SoC description for this instance
- * @nb: Reboot Notifier block
* @d: Debugfs file entry
* @debug_region: Memory region where the debug message are available
* @debug_region_size: Debug region size
@@ -103,7 +102,6 @@ struct ti_sci_desc {
*/
struct ti_sci_info {
struct device *dev;
- struct notifier_block nb;
const struct ti_sci_desc *desc;
struct dentry *d;
void __iomem *debug_region;
@@ -122,7 +120,6 @@ struct ti_sci_info {
#define cl_to_ti_sci_info(c) container_of(c, struct ti_sci_info, cl)
#define handle_to_ti_sci_info(h) container_of(h, struct ti_sci_info, handle)
-#define reboot_to_ti_sci_info(n) container_of(n, struct ti_sci_info, nb)
#ifdef CONFIG_DEBUG_FS
@@ -3254,10 +3251,9 @@ devm_ti_sci_get_resource(const struct ti_sci_handle *handle, struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_ti_sci_get_resource);
-static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
- void *cmd)
+static int tisci_reboot_handler(struct sys_off_data *data)
{
- struct ti_sci_info *info = reboot_to_ti_sci_info(nb);
+ struct ti_sci_info *info = data->cb_data;
const struct ti_sci_handle *handle = &info->handle;
ti_sci_cmd_core_reboot(handle);
@@ -3400,10 +3396,9 @@ static int ti_sci_probe(struct platform_device *pdev)
ti_sci_setup_ops(info);
if (reboot) {
- info->nb.notifier_call = tisci_reboot_handler;
- info->nb.priority = 128;
-
- ret = register_restart_handler(&info->nb);
+ ret = devm_register_restart_handler(dev,
+ tisci_reboot_handler,
+ info);
if (ret) {
dev_err(dev, "reboot registration fail(%d)\n", ret);
goto out;
--
2.39.2
_______________________________________________
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 4/4] dt-bindings: arm: keystone: Remove ti,system-reboot-controller property
From: Andrew Davis @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Santosh Shilimkar,
Nishanth Menon, Vignesh Raghavendra
Cc: devicetree, linux-arm-kernel, linux-kernel, Andrew Davis
In-Reply-To: <20240326223730.54639-1-afd@ti.com>
This property was only ever used in one device. It is no longer needed as
what it signaled is now default. Remove this unneeded/unused property.
Signed-off-by: Andrew Davis <afd@ti.com>
---
Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml | 5 -----
1 file changed, 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
index c24ad0968f3ef..7f06b10802449 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -61,10 +61,6 @@ properties:
mboxes:
minItems: 2
- ti,system-reboot-controller:
- description: Determines If system reboot can be triggered by SoC reboot
- type: boolean
-
ti,host-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
@@ -94,7 +90,6 @@ examples:
- |
pmmc: system-controller@2921800 {
compatible = "ti,k2g-sci";
- ti,system-reboot-controller;
mbox-names = "rx", "tx";
mboxes = <&msgmgr 5 2>,
<&msgmgr 0 0>;
--
2.39.2
_______________________________________________
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 2/4] firmware: ti_sci: Unconditionally register reset handler
From: Andrew Davis @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Santosh Shilimkar,
Nishanth Menon, Vignesh Raghavendra
Cc: devicetree, linux-arm-kernel, linux-kernel, Andrew Davis
In-Reply-To: <20240326223730.54639-1-afd@ti.com>
There was once a limitation that there could only be one system
reset handler. Due to that we only would register this handler
when a non-standard device tree property was found, else we left
the default handler in place (usually PSCI). Now that we can
have multiple handlers, and TI-SCI reset is always available
in the firmware, register this handler unconditionally.
This priority is left at the default so higher priority handlers
(like PSCI) are still attempted first.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/firmware/ti_sci.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 9885e1763591b..160968301b1fb 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -3299,7 +3299,6 @@ static int ti_sci_probe(struct platform_device *pdev)
struct mbox_client *cl;
int ret = -EINVAL;
int i;
- int reboot = 0;
u32 h_id;
desc = device_get_match_data(dev);
@@ -3323,8 +3322,6 @@ static int ti_sci_probe(struct platform_device *pdev)
}
}
- reboot = of_property_read_bool(dev->of_node,
- "ti,system-reboot-controller");
INIT_LIST_HEAD(&info->node);
minfo = &info->minfo;
@@ -3395,14 +3392,10 @@ static int ti_sci_probe(struct platform_device *pdev)
ti_sci_setup_ops(info);
- if (reboot) {
- ret = devm_register_restart_handler(dev,
- tisci_reboot_handler,
- info);
- if (ret) {
- dev_err(dev, "reboot registration fail(%d)\n", ret);
- goto out;
- }
+ ret = devm_register_restart_handler(dev, tisci_reboot_handler, info);
+ if (ret) {
+ dev_err(dev, "reboot registration fail(%d)\n", ret);
+ goto out;
}
dev_info(dev, "ABI: %d.%d (firmware rev 0x%04x '%s')\n",
--
2.39.2
_______________________________________________
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 3/4] ARM: dts: ti: keystone: k2g: Remove ti,system-reboot-controller property
From: Andrew Davis @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Santosh Shilimkar,
Nishanth Menon, Vignesh Raghavendra
Cc: devicetree, linux-arm-kernel, linux-kernel, Andrew Davis
In-Reply-To: <20240326223730.54639-1-afd@ti.com>
The property ti,system-reboot-controller is no longer needed as the reboot
handler is now always registered. Remove this property.
While here remove the comment about delete-property, all K2G platforms use
PMMC, and it wasn't good advice anyway.
Signed-off-by: Andrew Davis <afd@ti.com>
---
arch/arm/boot/dts/ti/keystone/keystone-k2g.dtsi | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/ti/keystone/keystone-k2g.dtsi b/arch/arm/boot/dts/ti/keystone/keystone-k2g.dtsi
index 790b29ab0fa2c..dafe485dfe197 100644
--- a/arch/arm/boot/dts/ti/keystone/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/ti/keystone/keystone-k2g.dtsi
@@ -256,11 +256,6 @@ msgmgr: mailbox@2a00000 {
pmmc: system-controller@2921c00 {
compatible = "ti,k2g-sci";
- /*
- * In case of rare platforms that does not use k2g as
- * system master, use /delete-property/
- */
- ti,system-reboot-controller;
mbox-names = "rx", "tx";
mboxes = <&msgmgr 5 2>,
<&msgmgr 0 0>;
--
2.39.2
_______________________________________________
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 0/4] Unconditionally register TI-SCI reset handler
From: Andrew Davis @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Santosh Shilimkar,
Nishanth Menon, Vignesh Raghavendra
Cc: devicetree, linux-arm-kernel, linux-kernel, Andrew Davis
Hello all,
This series is the replacement for this series[0] and is based on a
comment in that series by Rob here[1].
First patch is just a fixup, second patch is the core of the series.
Thanks,
Andrew
[0] https://lore.kernel.org/lkml/20240131221957.213717-1-afd@ti.com/
[1] https://lore.kernel.org/lkml/20240201230351.GA1900918-robh@kernel.org/
Andrew Davis (4):
firmware: ti_sci: Use devm_register_restart_handler()
firmware: ti_sci: Unconditionally register reset handler
ARM: dts: ti: keystone: k2g: Remove ti,system-reboot-controller
property
dt-bindings: arm: keystone: Remove ti,system-reboot-controller
property
.../bindings/arm/keystone/ti,sci.yaml | 5 ----
.../boot/dts/ti/keystone/keystone-k2g.dtsi | 5 ----
drivers/firmware/ti_sci.c | 24 +++++--------------
3 files changed, 6 insertions(+), 28 deletions(-)
--
2.39.2
_______________________________________________
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 2/2] ARM: dts: sun5i: Add PocketBook 614 Plus support
From: Jernej Škrabec @ 2024-03-26 22:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Maxime Ripard, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, Denis Burkov
Cc: Denis Burkov
In-Reply-To: <20240317083445.4668-2-hitechshell@mail.ru>
Dne nedelja, 17. marec 2024 ob 09:34:45 CET je Denis Burkov napisal(a):
> What works:
>
> - Serial console
> - mmc0, mmc2 (both microSD card slots on the board)
> - All buttons (gpio and lradc based)
> - Power LED
> - PMIC
> - RTC
> - USB OTG/gadgets mode
>
> Signed-off-by: Denis Burkov <hitechshell@mail.ru>
> ---
> arch/arm/boot/dts/allwinner/Makefile | 1 +
> .../sun5i-a13-pocketbook-614-plus.dts | 215 ++++++++++++++++++
> 2 files changed, 216 insertions(+)
> create mode 100644 arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
>
> diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
> index 5fbb44ddacd0..6209243ad975 100644
> --- a/arch/arm/boot/dts/allwinner/Makefile
> +++ b/arch/arm/boot/dts/allwinner/Makefile
> @@ -61,6 +61,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-olinuxino.dtb \
> sun5i-a13-olinuxino-micro.dtb \
> sun5i-a13-pocketbook-touch-lux-3.dtb \
> + sun5i-a13-pocketbook-614-plus.dtb \
> sun5i-a13-q8-tablet.dtb \
> sun5i-a13-utoo-p66.dtb \
> sun5i-gr8-chip-pro.dtb \
> diff --git a/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts b/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
> new file mode 100644
> index 000000000000..b5449301789a
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun5i-a13-pocketbook-614-plus.dts
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2024 Denis Burkov <hitechshell@mail.ru>
> + */
> +
> +/dts-v1/;
> +#include "sun5i-a13.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + model = "PocketBook 614 Plus";
> + compatible = "pocketbook,614-plus", "allwinner,sun5i-a13";
> +
> + aliases {
> + serial0 = &uart1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led {
led-0 is preferred by the DT binding. Please also add function and color
properties.
Please run DT check with W=2 to catch andy other potential issues.
Best regards,
Jernej
> + gpios = <&pio 4 8 GPIO_ACTIVE_LOW>; /* PE8 */
> + default-state = "on";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + key-right {
Key node names should contain key-[number], starting with 0.
> + label = "Right";
> + linux,code = <KEY_NEXT>;
> + gpios = <&pio 6 9 GPIO_ACTIVE_LOW>; /* PG9 */
> + };
> +
> + key-left {
> + label = "Left";
> + linux,code = <KEY_PREVIOUS>;
> + gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
> + };
> + };
> +
> + reg_3v3_mmc0: regulator-mmc0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-mmc0";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&pio 4 4 GPIO_ACTIVE_LOW>; /* PE4 */
> + vin-supply = <®_vcc3v3>;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <®_dcdc2>;
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + axp209: pmic@34 {
> + compatible = "x-powers,axp209";
> + reg = <0x34>;
> + interrupts = <0>;
> + };
> +};
> +
> +#include "axp209.dtsi"
> +
> +&i2c1 {
> + status = "okay";
> +
> + pcf8563: rtc@51 {
> + compatible = "nxp,pcf8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + };
> +};
> +
> +&lradc {
> + vref-supply = <®_ldo2>;
> + status = "okay";
> +
> + button-300 {
> + label = "Down";
> + linux,code = <KEY_DOWN>;
> + channel = <0>;
> + voltage = <300000>;
> + };
> +
> + button-700 {
> + label = "Up";
> + linux,code = <KEY_UP>;
> + channel = <0>;
> + voltage = <700000>;
> + };
> +
> + button-1000 {
> + label = "Left";
> + linux,code = <KEY_LEFT>;
> + channel = <0>;
> + voltage = <1000000>;
> + };
> +
> + button-1200 {
> + label = "Menu";
> + linux,code = <KEY_MENU>;
> + channel = <0>;
> + voltage = <1200000>;
> + };
> +
> + button-1500 {
> + label = "Right";
> + linux,code = <KEY_RIGHT>;
> + channel = <0>;
> + voltage = <1500000>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_3v3_mmc0>;
> + bus-width = <4>;
> + cd-gpios = <&pio 6 0 GPIO_ACTIVE_LOW>; /* PG0 */
> + status = "okay";
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_4bit_pc_pins>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&otg_sram {
> + status = "okay";
> +};
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "vdd-int-dll";
> +};
> +
> +®_ldo1 {
> + regulator-name = "vdd-rtc";
> +};
> +
> +®_ldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "avcc";
> +};
> +
> +®_usb0_vbus {
> + status = "okay";
> + gpio = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> +};
> +
> +®_usb1_vbus {
> + gpio = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pg_pins>;
> + status = "okay";
> +};
> +
> +&usb_otg {
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
> +&usb_power_supply {
> + status = "okay";
> +};
> +
> +&battery_power_supply {
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
> + usb0_vbus_det-gpios = <&axp_gpio 1 GPIO_ACTIVE_HIGH>;
> + usb0_vbus-supply = <®_usb0_vbus>;
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> +};
>
_______________________________________________
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 bpf-next v2 1/1] arm64/cfi,bpf: Support kCFI + BPF on arm64
From: Puranjay Mohan @ 2024-03-26 22:28 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Will Deacon, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Zi Shen Lim, Suzuki K Poulose, Mark Brown,
linux-arm-kernel, open list,
open list:BPF [GENERAL] (Safe Dynamic Programs and Tools),
Josh Poimboeuf
In-Reply-To: <ZgMbFqWpmZgahiV6@FVFF77S0Q05N.cambridge.arm.com>
Mark Rutland <mark.rutland@arm.com> writes:
> Hi Puranjay,
>
> On Sun, Mar 24, 2024 at 09:15:18PM +0000, Puranjay Mohan wrote:
>> Currently, bpf_dispatcher_*_func() is marked with `__nocfi` therefore
>> calling BPF programs from this interface doesn't cause CFI warnings.
>>
>> When BPF programs are called directly from C: from BPF helpers or
>> struct_ops, CFI warnings are generated.
>>
>> Implement proper CFI prologues for the BPF programs and callbacks and
>> drop __nocfi for arm64. Fix the trampoline generation code to emit kCFI
>> prologue when a struct_ops trampoline is being prepared.
>>
>> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
>
> Presumably this'll need a Cc stable and a Fixes tag?
Thanks for mentioning, I will find out from what commit this is broken.
>
>> ---
>> arch/arm64/include/asm/cfi.h | 23 ++++++++++++++
>> arch/arm64/kernel/alternative.c | 54 +++++++++++++++++++++++++++++++++
>> arch/arm64/net/bpf_jit_comp.c | 28 +++++++++++++----
>> 3 files changed, 99 insertions(+), 6 deletions(-)
>> create mode 100644 arch/arm64/include/asm/cfi.h
>>
>> diff --git a/arch/arm64/include/asm/cfi.h b/arch/arm64/include/asm/cfi.h
>> new file mode 100644
>> index 000000000000..670e191f8628
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cfi.h
>> @@ -0,0 +1,23 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_ARM64_CFI_H
>> +#define _ASM_ARM64_CFI_H
>> +
>> +#ifdef CONFIG_CFI_CLANG
>> +#define __bpfcall
>> +static inline int cfi_get_offset(void)
>> +{
>> + return 4;
>> +}
>> +#define cfi_get_offset cfi_get_offset
>> +extern u32 cfi_bpf_hash;
>> +extern u32 cfi_bpf_subprog_hash;
>> +extern u32 cfi_get_func_hash(void *func);
>> +#else
>> +#define cfi_bpf_hash 0U
>> +#define cfi_bpf_subprog_hash 0U
>> +static inline u32 cfi_get_func_hash(void *func)
>> +{
>> + return 0;
>> +}
>> +#endif /* CONFIG_CFI_CLANG */
>> +#endif /* _ASM_ARM64_CFI_H */
>> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
>> index 8ff6610af496..1715da7df137 100644
>> --- a/arch/arm64/kernel/alternative.c
>> +++ b/arch/arm64/kernel/alternative.c
>> @@ -13,6 +13,7 @@
>> #include <linux/elf.h>
>> #include <asm/cacheflush.h>
>> #include <asm/alternative.h>
>> +#include <asm/cfi.h>
>> #include <asm/cpufeature.h>
>> #include <asm/insn.h>
>> #include <asm/module.h>
>> @@ -298,3 +299,56 @@ noinstr void alt_cb_patch_nops(struct alt_instr *alt, __le32 *origptr,
>> updptr[i] = cpu_to_le32(aarch64_insn_gen_nop());
>> }
>> EXPORT_SYMBOL(alt_cb_patch_nops);
>> +
>> +#ifdef CONFIG_CFI_CLANG
>> +struct bpf_insn;
>> +
>> +/* Must match bpf_func_t / DEFINE_BPF_PROG_RUN() */
>> +extern unsigned int __bpf_prog_runX(const void *ctx,
>> + const struct bpf_insn *insn);
>> +
>> +/*
>> + * Force a reference to the external symbol so the compiler generates
>> + * __kcfi_typid.
>> + */
>> +__ADDRESSABLE(__bpf_prog_runX);
>> +
>> +/* u32 __ro_after_init cfi_bpf_hash = __kcfi_typeid___bpf_prog_runX; */
>> +asm (
>> +" .pushsection .data..ro_after_init,\"aw\",@progbits \n"
>> +" .type cfi_bpf_hash,@object \n"
>> +" .globl cfi_bpf_hash \n"
>> +" .p2align 2, 0x0 \n"
>> +"cfi_bpf_hash: \n"
>> +" .word __kcfi_typeid___bpf_prog_runX \n"
>> +" .size cfi_bpf_hash, 4 \n"
>> +" .popsection \n"
>> +);
>> +
>> +/* Must match bpf_callback_t */
>> +extern u64 __bpf_callback_fn(u64, u64, u64, u64, u64);
>> +
>> +__ADDRESSABLE(__bpf_callback_fn);
>> +
>> +/* u32 __ro_after_init cfi_bpf_subprog_hash = __kcfi_typeid___bpf_callback_fn; */
>> +asm (
>> +" .pushsection .data..ro_after_init,\"aw\",@progbits \n"
>> +" .type cfi_bpf_subprog_hash,@object \n"
>> +" .globl cfi_bpf_subprog_hash \n"
>> +" .p2align 2, 0x0 \n"
>> +"cfi_bpf_subprog_hash: \n"
>> +" .word __kcfi_typeid___bpf_callback_fn \n"
>> +" .size cfi_bpf_subprog_hash, 4 \n"
>> +" .popsection \n"
>> +);
>> +
>> +u32 cfi_get_func_hash(void *func)
>> +{
>> + u32 hash;
>> +
>> + if (get_kernel_nofault(hash, func - cfi_get_offset()))
>> + return 0;
>> +
>> + return hash;
>> +}
>> +#endif
>
> I realise this is following the example of x86, but this has nothing to do with
> alternatives, so could we please place it elsewhere? e.g. add a new
> arch/arm64/net/bpf_cfi.c?
Sure, a new file would work.
How about: arch/arm64/kernel/cfi.c
>
> Which functions is cfi_get_func_hash() used against? The comment in the code
> below says:
>
> if (flags & BPF_TRAMP_F_INDIRECT) {
> /*
> * Indirect call for bpf_struct_ops
> */
> emit_kcfi(cfi_get_func_hash(func_addr), ctx);
> }
>
> ... but it's not clear to me which functions specifically would be in that
> 'func_addr', not why returning 0 is fine -- surely we should fail compilation
> if the provided function pointer causes a fault and we don't have a valid
> typeid?
'func_addr' will have one of the cfi_stubs like in net/ipv4/bpf_tcp_ca.c
Explained in more detail below:
>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>> index bc16eb694657..2372812bb47c 100644
>> --- a/arch/arm64/net/bpf_jit_comp.c
>> +++ b/arch/arm64/net/bpf_jit_comp.c
>> @@ -17,6 +17,7 @@
>> #include <asm/asm-extable.h>
>> #include <asm/byteorder.h>
>> #include <asm/cacheflush.h>
>> +#include <asm/cfi.h>
>> #include <asm/debug-monitors.h>
>> #include <asm/insn.h>
>> #include <asm/patching.h>
>> @@ -158,6 +159,12 @@ static inline void emit_bti(u32 insn, struct jit_ctx *ctx)
>> emit(insn, ctx);
>> }
>>
>> +static inline void emit_kcfi(u32 hash, struct jit_ctx *ctx)
>> +{
>> + if (IS_ENABLED(CONFIG_CFI_CLANG))
>> + emit(hash, ctx);
>> +}
>> +
>> /*
>> * Kernel addresses in the vmalloc space use at most 48 bits, and the
>> * remaining bits are guaranteed to be 0x1. So we can compose the address
>> @@ -295,7 +302,7 @@ static bool is_lsi_offset(int offset, int scale)
>> #define PROLOGUE_OFFSET (BTI_INSNS + 2 + PAC_INSNS + 8)
>>
>> static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
>> - bool is_exception_cb)
>> + bool is_exception_cb, bool is_subprog)
>> {
>> const struct bpf_prog *prog = ctx->prog;
>> const bool is_main_prog = !bpf_is_subprog(prog);
>> @@ -306,7 +313,6 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
>> const u8 fp = bpf2a64[BPF_REG_FP];
>> const u8 tcc = bpf2a64[TCALL_CNT];
>> const u8 fpb = bpf2a64[FP_BOTTOM];
>> - const int idx0 = ctx->idx;
>> int cur_offset;
>>
>> /*
>> @@ -332,6 +338,8 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf,
>> *
>> */
>>
>> + emit_kcfi(is_subprog ? cfi_bpf_subprog_hash : cfi_bpf_hash, ctx);
>> + const int idx0 = ctx->idx;
>> /* bpf function may be invoked by 3 instruction types:
>> * 1. bl, attached via freplace to bpf prog via short jump
>> * 2. br, attached via freplace to bpf prog via long jump
>> @@ -1648,7 +1656,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> * BPF line info needs ctx->offset[i] to be the offset of
>> * instruction[i] in jited image, so build prologue first.
>> */
>> - if (build_prologue(&ctx, was_classic, prog->aux->exception_cb)) {
>> + if (build_prologue(&ctx, was_classic, prog->aux->exception_cb,
>> + bpf_is_subprog(prog))) {
>> prog = orig_prog;
>> goto out_off;
>> }
>> @@ -1696,7 +1705,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> ctx.idx = 0;
>> ctx.exentry_idx = 0;
>>
>> - build_prologue(&ctx, was_classic, prog->aux->exception_cb);
>> + build_prologue(&ctx, was_classic, prog->aux->exception_cb,
>> + bpf_is_subprog(prog));
>>
>> if (build_body(&ctx, extra_pass)) {
>> prog = orig_prog;
>> @@ -1745,9 +1755,9 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> jit_data->ro_header = ro_header;
>> }
>>
>> - prog->bpf_func = (void *)ctx.ro_image;
>> + prog->bpf_func = (void *)ctx.ro_image + cfi_get_offset();
>> prog->jited = 1;
>> - prog->jited_len = prog_size;
>> + prog->jited_len = prog_size - cfi_get_offset();
>>
>> if (!prog->is_func || extra_pass) {
>> int i;
>> @@ -2011,6 +2021,12 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
>> /* return address locates above FP */
>> retaddr_off = stack_size + 8;
>>
>> + if (flags & BPF_TRAMP_F_INDIRECT) {
>> + /*
>> + * Indirect call for bpf_struct_ops
>> + */
>> + emit_kcfi(cfi_get_func_hash(func_addr), ctx);
>> + }
>
> I'm confused; why does the trampoline need this?
>
> The code that branches to the trampoline doesn't check the type hash: either
> the callsite branches directly (hence no check), or the common ftrace
> trampoline does so indirectly, and the latter doesn't know the expected typeid,
> so it cannot check.
This is not used when the trampoline is attached to the entry of a
kernel function and called through a direct call or from ftrace_caller.
This is only used when we are building a trampoline for bpf_struct_ops.
Here a kernel subsystem can call this trampoline through a function
pointer.
See: tools/testing/selftests/bpf/progs/bpf_dctcp.c
Here tcp_congestion_ops functions are implemented in BPF and
registered with the networking subsystem.
So, the networking subsystem will call them directly for example like:
struct tcp_congestion_ops *ca_ops = ....
ca_ops->cwnd_event(sk, event);
cwnd_event() is implemented in BPF and this call will land on a
trampoline. Because this is being called from the kernel through a
function pointer, type_id will be checked. So, the landing location in
the trampoline should have a type_id above it.
In the above example kernel is calling a function of type
void cwnd_event(struct sock *sk, enum tcp_ca_event ev);
so the calling code will fetch the type_id from above the destination
and compare it with the type_id of the above prototype.
To make this work with BPF trampolines, we define stubs while
registering these struct_ops with the BPF subsystem.
Like in net/ipv4/bpf_tcp_ca.c
a stub is defined like following:
static void bpf_tcp_ca_cwnd_event(struct sock *sk, enum tcp_ca_event ev)
{
}
This is what `func_addr` will have in the prepare_trampoline() function
and we use cfi_get_func_hash() to fetch the type_id and put it above the
landing location in the trampoline.
> If we wanted a tpyeid here, that should probably be distinct from the original
> function tpyeid, since the trampoline calling convention is different.
Here the trampoline is called using standard calling convention and the
type_id is dependent on the prototype of the called function.
> IIUC this isn't reachable today regardless since CALL_OPS and KCFI are
> currently mutually exclusive.
As explained above, this kind of the BPF trampoline is not called from
function entry through a direct call so CALL_OPS is not required for
this usage.
I am not well versed with the in-depth implementation of struct_ops, so
maybe Alexei can explain more about this feature or correct me if I miss
represented some fact.
Thanks,
Puranjay
_______________________________________________
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 05/27] iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry()
From: Jason Gunthorpe @ 2024-03-26 22:27 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <ZgMeNZP08aZu-nVe@google.com>
On Tue, Mar 26, 2024 at 07:12:53PM +0000, Mostafa Saleh wrote:
> On Tue, Mar 26, 2024 at 03:30:55PM -0300, Jason Gunthorpe wrote:
> > On Sat, Mar 23, 2024 at 01:02:15PM +0000, Mostafa Saleh wrote:
> > > > +static void arm_smmu_get_cd_used(const __le64 *ent, __le64 *used_bits)
> > > > +{
> > > > + used_bits[0] = cpu_to_le64(CTXDESC_CD_0_V);
> > > > + if (!(ent[0] & cpu_to_le64(CTXDESC_CD_0_V)))
> > > > + return;
> > > > + memset(used_bits, 0xFF, sizeof(struct arm_smmu_cd));
> > >
> > > This is a slightly different approach than what the driver does for STEs,
> > > where it explicitly sets the used bits. Is there a reason for that?
> >
> > It is just more compact this way
>
> IMHO, it seems too much to have this mechanism for CDs for just one
> SVA case, but I'll need to go through the whole seires first to make
> sure I am not missing anything.
It is pretty ugly if you try to do it that way. You still need to
create some ops because the entry_set should be re-used (I mean I
guess you could copy it as well). Then you have to open code the
logic. And then the EPD0 path is somewhat fragile. Something sort of
like this:
void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
struct arm_smmu_cd *cdptr,
const struct arm_smmu_cd *target)
{
bool target_valid = target->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
bool cur_valid = cdptr->data[0] & cpu_to_le64(CTXDESC_CD_0_V);
struct arm_smmu_cd_writer cd_writer = {
.writer = {
.ops = &arm_smmu_cd_writer_ops,
.master = master,
},
.ssid = ssid,
};
if (ssid != IOMMU_NO_PASID && cur_valid != target_valid) {
if (cur_valid)
master->cd_table.used_ssids--;
else
master->cd_table.used_ssids++;
}
/* Force a V=0/V=1 update*/
__le64 update = target[0] & ~cpu_to_le64(CTXDESC_CD_0_V);
entry_set(&cd_writer.writer, cdptr->data, &update, 0, 1);
entry_set(&cd_writer.writer, cdptr->data, target->data, 1, NUM_ENTRY_QWORDS - 1);
entry_set(&cd_writer.writer, cdptr->data, target->data, 0, 1);
}
void arm_smmu_write_cd_entry_epd0(struct arm_smmu_master *master, int ssid,
struct arm_smmu_cd *cdptr,
const struct arm_smmu_cd *target)
{
struct arm_smmu_cd_writer cd_writer = {
.writer = {
.ops = &arm_smmu_cd_writer_ops,
.master = master,
},
.ssid = ssid,
};
/*
* Target must the EPD0 = 1 version of the existing CD entry, caller
* must enforce it. Assume used_ssids doesn't need updating
* for this reason.
*/
/* Update EPD0 */
entry_set(&cd_writer.writer, cdptr->data, target->data, 0, 1);
/* Update everthing else */
entry_set(&cd_writer.writer, cdptr->data, target->data, 0, NUM_ENTRY_QWORDS - 1);
}
IMOH, at this point it is saner to have just implemented the used
function and use the mechanism robustly. Less special cases, less
fragility, less duplication.
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 4/4] arm: dts: allwinner: drop underscore in node names
From: Jernej Škrabec @ 2024-03-26 22:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Corentin Labbe, Maxime Ripard, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, Krzysztof Kozlowski
Cc: Krzysztof Kozlowski
In-Reply-To: <20240317184130.157695-4-krzysztof.kozlowski@linaro.org>
Dne nedelja, 17. marec 2024 ob 19:41:30 CET je Krzysztof Kozlowski napisal(a):
> Underscores should not be used in node names (dtc with W=2 warns about
> them), so replace them with hyphens. Use also generic name for pwrseq
> node, because generic naming is favored by Devicetree spec. All the
> clocks affected by this change use clock-output-names, so resulting
> clock name should not change. Functional impact checked with comparing
> before/after DTBs with dtx_diff and fdtdump.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
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