* Re: (subset) [PATCH v3 08/17] arm64: dts: exynos: Add EL2 virtual timer interrupt
From: Krzysztof Kozlowski @ 2026-05-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Marc Zyngier
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-9-maz@kernel.org>
On Sat, 23 May 2026 15:02:33 +0100, Marc Zyngier wrote:
> A bunch of Samsung SoCs are missing the EL2 virtual timer interrupt
> despite using ARMv8.1+ CPUs. Add the missing interrupt, except for
> those broken designs where the interrupt is documented as not being
> wired.
Applied, thanks!
[08/17] arm64: dts: exynos: Add EL2 virtual timer interrupt
https://git.kernel.org/krzk/linux/c/d0298724f901d45c76f1f2193225706200f565e4
Best regards,
--
Krzysztof Kozlowski <krzk@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Demi Marie Obenour @ 2026-05-24 20:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, linux-kernel, linux-crypto, linux-arm-msm,
Eric Biggers, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <7rgfuvv3hai7g4wt4accbkejtzdt5dnb6mkj6x7ox5sz35q4n2@h7j6rr7extuj>
[-- Attachment #1.1.1: Type: text/plain, Size: 1145 bytes --]
On 5/24/26 12:42, Dmitry Baryshkov wrote:
> On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>
>> It's slower than the generic C code and causes problems.
>
> Which problems?
See https://lore.kernel.org/all/20260522024912.GC5937@quark/.
Also, if there are no systems in which the QCE driver is actually
the highest priority, then unless someone adjusts priorities manually
it's unused code.
> Also in the security world faster and safer are two orthogonal axis with
> very limited correlation.
If by "safer" you mean protection against physical side-channel
attacks, then my understanding is that all operations on secret keys
need to be masked. This includes copying and storage.
Linux only supports this for protected keys, and even then sometimes
uses the kernel's own RNG for key generation. There is no support
for using the QCE for protected keys.
Linux does support using hardware-wrapped keys with inline crypto
engines, which are what are actually used on Android.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Krzysztof Kozlowski @ 2026-05-24 20:24 UTC (permalink / raw)
To: demiobenour, Herbert Xu, David S. Miller, Thara Gopinath,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Russell King
Cc: linux-kernel, linux-crypto, linux-arm-msm, Eric Biggers,
Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <20260523-delete-qce-v1-1-86105cd7f406@gmail.com>
On 23/05/2026 21:03, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
>
> It's slower than the generic C code and causes problems.
That's really vague and incomplete. You need to make your case, provide
arguments, numbers, data. Otherwise it is just trolling.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v9 0/9] Allwinner A31/A83T MIPI CSI-2 and A31 ISP / Platform Support
From: Chen-Yu Tsai @ 2026-05-24 20:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Paul Kocialkowski
Cc: Yong Deng, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Brian Masney, Maxime Ripard
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
On Mon, 18 May 2026 17:33:29 +0200, Paul Kocialkowski wrote:
> This series adds platform support for the V3s/V3/S3 MIPI CSI-2 and ISP units
> as well the as A83T MIPI CSI-2 unit in the respective device-trees.
> Overlays for the BananaPi M3 cameras are also provided as actual users of the
> camera pipeline on A83T.
>
> The corresponding drivers and dt bindings were merged a long time ago but this
> series was never actually picked up. It seems more than ready to be merged!
>
> [...]
Applied to sunxi/dt-for-7.2 in sunxi, thanks!
[1/9] dt-bindings: media: sun6i-a31-csi: Add optional interconnect properties
https://git.kernel.org/sunxi/linux/c/4543300b2d55
[2/9] dt-bindings: media: sun6i-a31-isp: Add optional interconnect properties
https://git.kernel.org/sunxi/linux/c/bdf22efc6cb2
[4/9] ARM: dts: sun8i: v3s: Add mbus node to represent the interconnect
https://git.kernel.org/sunxi/linux/c/3c6867908ecb
[7/9] ARM: dts: sun8i: a83t: Add MIPI CSI-2 controller node
https://git.kernel.org/sunxi/linux/c/4fc5086a3d99
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Krzysztof Kozlowski @ 2026-05-24 20:29 UTC (permalink / raw)
To: Demi Marie Obenour, Dmitry Baryshkov
Cc: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, linux-kernel, linux-crypto, linux-arm-msm,
Eric Biggers, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <66317f6a-645e-432b-ae11-8f40569d4117@gmail.com>
On 24/05/2026 22:12, Demi Marie Obenour wrote:
> On 5/24/26 12:42, Dmitry Baryshkov wrote:
>> On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
>>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>>
>>> It's slower than the generic C code and causes problems.
>>
>> Which problems?
>
> See https://lore.kernel.org/all/20260522024912.GC5937@quark/.
Your commit is still incomplete and other people's opinion is poor
reason. If you do not know what to write, ask that person to make
necessary changes.
Not mentioning that removing driver is not even necessary to achieve the
goal Eric was mentioning and if I understood correctly: you are removing
even the pieces Eric found useful.
>
> Also, if there are no systems in which the QCE driver is actually
> the highest priority, then unless someone adjusts priorities manually
> it's unused code.
That's not a reason to remove a driver.
>
>> Also in the security world faster and safer are two orthogonal axis with
>> very limited correlation.
>
> If by "safer" you mean protection against physical side-channel
> attacks, then my understanding is that all operations on secret keys
> need to be masked. This includes copying and storage.
>
> Linux only supports this for protected keys, and even then sometimes
> uses the kernel's own RNG for key generation. There is no support
> for using the QCE for protected keys.
>
> Linux does support using hardware-wrapped keys with inline crypto
> engines, which are what are actually used on Android.
Patches are discussed for some time, did you miss that?
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v3 00/17] arm64: Use EL2 virtual timer when running VHE
From: Chen-Yu Tsai @ 2026-05-24 20:30 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Marc Zyngier
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
On Sat, 23 May 2026 15:02:25 +0100, Marc Zyngier wrote:
> This is the third version of the series initially posted at [1],
> which
>
> - updates the ACPI GTDT parsing to deal the v3 layout and the EL2
> virtual timer,
> - moves the architected timer driver to use it when running VHE,
> - fixes a number of DTs to reflect the reality of the HW.
>
> [...]
Applied to sunxi/dt-for-7.2 in sunxi, thanks!
[05/17] arm64: dts: allwinner: Add EL2 virtual timer interrupt
https://git.kernel.org/sunxi/linux/c/86eeca347091
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Demi Marie Obenour @ 2026-05-24 20:31 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Baryshkov
Cc: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, linux-kernel, linux-crypto, linux-arm-msm,
Eric Biggers, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <d97382a6-6c5d-4a3f-89cc-3ae9b432de3f@kernel.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1919 bytes --]
On 5/24/26 16:29, Krzysztof Kozlowski wrote:
> On 24/05/2026 22:12, Demi Marie Obenour wrote:
>> On 5/24/26 12:42, Dmitry Baryshkov wrote:
>>> On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
>>>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>>>
>>>> It's slower than the generic C code and causes problems.
>>>
>>> Which problems?
>>
>> See https://lore.kernel.org/all/20260522024912.GC5937@quark/.
>
> Your commit is still incomplete and other people's opinion is poor
> reason. If you do not know what to write, ask that person to make
> necessary changes.
>
> Not mentioning that removing driver is not even necessary to achieve the
> goal Eric was mentioning and if I understood correctly: you are removing
> even the pieces Eric found useful.
>
>>
>> Also, if there are no systems in which the QCE driver is actually
>> the highest priority, then unless someone adjusts priorities manually
>> it's unused code.
>
> That's not a reason to remove a driver.
>
>
>>
>>> Also in the security world faster and safer are two orthogonal axis with
>>> very limited correlation.
>>
>> If by "safer" you mean protection against physical side-channel
>> attacks, then my understanding is that all operations on secret keys
>> need to be masked. This includes copying and storage.
>>
>> Linux only supports this for protected keys, and even then sometimes
>> uses the kernel's own RNG for key generation. There is no support
>> for using the QCE for protected keys.
>>
>> Linux does support using hardware-wrapped keys with inline crypto
>> engines, which are what are actually used on Android.
>
> Patches are discussed for some time, did you miss that?
>
> Best regards,
> Krzysztof
Thanks for the useful explanation. I'll remove this patch from my
tree and won't resend it.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v9 0/9] Allwinner A31/A83T MIPI CSI-2 and A31 ISP / Platform Support
From: Chen-Yu Tsai @ 2026-05-24 19:36 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Paul Kocialkowski
Cc: Yong Deng, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Brian Masney, Maxime Ripard
In-Reply-To: <20260518153339.619947-1-paulk@sys-base.io>
On Mon, 18 May 2026 17:33:29 +0200, Paul Kocialkowski wrote:
> This series adds platform support for the V3s/V3/S3 MIPI CSI-2 and ISP units
> as well the as A83T MIPI CSI-2 unit in the respective device-trees.
> Overlays for the BananaPi M3 cameras are also provided as actual users of the
> camera pipeline on A83T.
>
> The corresponding drivers and dt bindings were merged a long time ago but this
> series was never actually picked up. It seems more than ready to be merged!
>
> [...]
Applied to sunxi/shared-clk-dt-ids-for-7.2 in sunxi, thanks!
[3/9] clk: sunxi-ng: v3s: Export MBUS and DRAM clocks to the public header
https://git.kernel.org/sunxi/linux/c/356a74a9325d
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 8/9] ARM: dts: sun8i-a83t: Add BananaPi M3 OV5640 camera overlay
From: Chen-Yu Tsai @ 2026-05-24 20:24 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Yong Deng, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Brian Masney, Maxime Ripard,
Paul Kocialkowski
In-Reply-To: <20260518153339.619947-9-paulk@sys-base.io>
On Mon, May 18, 2026 at 6:15 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> Add an overlay supporting the OV5640 from the BananaPi Camera v3
> peripheral board. The board has two sensors (OV5640 and OV8865)
> which cannot be supported in parallel as they share the same reset
> pin and the kernel currently has no support for this case.
This part is no longer true. The kernel recently gained shared GPIO
support. I've tried it on Chromebooks to describe a USB 2/3 hub.
(This is actually one chip and one pin, but has two device nodes
to model the USB 2.0 and USB 3.1 portions.)
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> arch/arm/boot/dts/allwinner/Makefile | 3 +
> .../sun8i-a83t-bananapi-m3-camera-ov5640.dtso | 115 ++++++++++++++++++
> 2 files changed, 118 insertions(+)
> create mode 100644 arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
>
> diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
> index f71392a55df8..6975df9d7b46 100644
> --- a/arch/arm/boot/dts/allwinner/Makefile
> +++ b/arch/arm/boot/dts/allwinner/Makefile
> @@ -221,6 +221,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a33-vstar.dtb \
> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> sun8i-a83t-bananapi-m3.dtb \
> + sun8i-a83t-bananapi-m3-camera-ov5640.dtb \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-a83t-tbs-a711.dtb \
> sun8i-h2-plus-bananapi-m2-zero.dtb \
> @@ -270,6 +271,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-v3s-licheepi-zero-dock.dtb \
> sun8i-v3s-netcube-kumquat.dtb \
> sun8i-v40-bananapi-m2-berry.dtb
> +sun8i-a83t-bananapi-m3-camera-ov5640-dtbs += \
> + sun8i-a83t-bananapi-m3.dtb sun8i-a83t-bananapi-m3-camera-ov5640.dtbo
> sun8i-h2-plus-orangepi-zero-interface-board-dtbs += \
> sun8i-h2-plus-orangepi-zero.dtb sun8i-orangepi-zero-interface-board.dtbo
> sun8i-h3-orangepi-zero-plus2-interface-board-dtbs += \
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
> new file mode 100644
> index 000000000000..0d4de0027fea
> --- /dev/null
> +++ b/arch/arm/boot/dts/allwinner/sun8i-a83t-bananapi-m3-camera-ov5640.dtso
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0 OR X11
> +/*
> + * Copyright 2022 Bootlin
> + * Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/sun8i-a83t-ccu.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&{/} {
> + /*
> + * These regulators actually have DLDO4 tied to their EN pin, which is
> + * described as input supply here for lack of a better representation.
> + * Their actual supply is PS, which is always-on.
> + */
> +
> + ov5640_avdd: ov5640-avdd {
You should fix the device node names, as Sashiko mentioned for patch 9.
> + compatible = "regulator-fixed";
> + regulator-name = "ov5640-avdd";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + vin-supply = <®_dldo4>;
> + };
> +
> + ov5640_dovdd: ov5640-dovdd {
> + compatible = "regulator-fixed";
> + regulator-name = "ov5640-dovdd";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + vin-supply = <®_dldo4>;
> + };
> +
> + ov5640_dvdd: ov5640-dvdd {
This one as well.
> + compatible = "regulator-fixed";
> + regulator-name = "ov5640-dvdd";
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + vin-supply = <®_dldo4>;
> + };
> +};
> +
> +&csi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&csi_8bit_parallel_pins>;
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csi_in_ov5640: endpoint {
> + remote-endpoint = <&ov5640_out_csi>;
> + bus-width = <8>;
> + data-shift = <2>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pe_pins>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640: camera@3c {
> + pinctrl-names = "default";
> + pinctrl-0 = <&csi_mclk_pin>;
> +
> + compatible = "ovti,ov5640";
> + reg = <0x3c>;
Per the "new" DT coding style guide, the compatible property is always
the first oen, and reg, if present, is always the second.
Same comments also apply to patch 9.
Thanks
ChenYu
> +
> + clocks = <&ccu CLK_CSI_MCLK>;
> + clock-names = "xclk";
> + assigned-clocks = <&ccu CLK_CSI_MCLK>;
> + assigned-clock-parents = <&osc24M>;
> + assigned-clock-rates = <24000000>;
> +
> + AVDD-supply = <&ov5640_avdd>;
> + DOVDD-supply = <&ov5640_dovdd>;
> + DVDD-supply = <&ov5640_dvdd>;
> +
> + powerdown-gpios = <&pio 3 15 GPIO_ACTIVE_HIGH>; /* PD15 */
> + reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
> +
> + rotation = <180>;
> +
> + port {
> + ov5640_out_csi: endpoint {
> + remote-endpoint = <&csi_in_ov5640>;
> + bus-width = <8>;
> + data-shift = <2>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> +};
> +
> +®_dldo4 {
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> +};
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Eric Biggers @ 2026-05-24 20:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Demi Marie Obenour, Dmitry Baryshkov, Herbert Xu, David S. Miller,
Thara Gopinath, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Russell King, linux-kernel,
linux-crypto, linux-arm-msm, Ard Biesheuvel, devicetree,
linux-arm-kernel
In-Reply-To: <d97382a6-6c5d-4a3f-89cc-3ae9b432de3f@kernel.org>
On Sun, May 24, 2026 at 10:29:28PM +0200, Krzysztof Kozlowski wrote:
> On 24/05/2026 22:12, Demi Marie Obenour wrote:
> > On 5/24/26 12:42, Dmitry Baryshkov wrote:
> >> On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
> >>> From: Demi Marie Obenour <demiobenour@gmail.com>
> >>>
> >>> It's slower than the generic C code and causes problems.
> >>
> >> Which problems?
> >
> > See https://lore.kernel.org/all/20260522024912.GC5937@quark/.
>
> Your commit is still incomplete and other people's opinion is poor
> reason. If you do not know what to write, ask that person to make
> necessary changes.
>
> Not mentioning that removing driver is not even necessary to achieve the
> goal Eric was mentioning and if I understood correctly: you are removing
> even the pieces Eric found useful.
This driver is more than an order of magnitude slower than the CPU for
both encryption and hashing. See:
https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
https://lore.kernel.org/r/20250615031807.GA81869@sol/
There are many examples of it having bugs as well, for example see the
second link above.
That's why it had to be disabled via the cra_priority system. This
driver was actively making Linux worse.
This isn't particularly unique to drivers/crypto/, of course. This one
we just have data on, so it's a bit clearer.
I've yet to see any real reason to keep this driver.
Crypto drivers need to be held to a higher standard than other device
drivers, as well. The onus is on those who want to keep a particular
crypto driver to prove that it's worth keeping.
- Eric
^ permalink raw reply
* Re: [PATCH 5/7] arm64: dts: allwinner: sun50i-h6: Add missing SRAM region for video engine
From: Chen-Yu Tsai @ 2026-05-24 20:46 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: Maxime Ripard, Mauro Carvalho Chehab, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, linux-media, linux-staging, devicetree,
linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <afpUiupOgPhLksM8@shepard>
On Tue, May 5, 2026 at 10:35 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Chen-Yu,
>
> On Tue 05 May 26, 21:48, Chen-Yu Tsai wrote:
> > The SRAM C region contains a partial alias to the VE SRAM already
> > referenced by the video engine. To avoid access through this alias
> > window, the region should also be claimed by the video engine.
> >
> > Add a reference to the SRAM C region to the video engine node.
>
> It feels very weird to have a reference to the DE2 SRAM region in the
> VE node. It seems unlikely that the same region would be used by both DE2 and
> VE and I am pretty sure can have both running at the same time without
> overstepping.
>
> From what I can see we have so far assumed that the SRAM C and SRAM C1
> are two different physical SRAM areas, but this is most likely not the case.
> My guess would be that SRAM C1 is actually a part of SRAM C and the DE2 is
No. It's the opposite. 0x28000 maps to the same SRAM block at 0x1a00000.
If you write to one, you see the results in both. However the alias at
028000 can be disabled while retaining access to 0x1a00000. I don't
remember how much of the alias points to VE SRAM (0x1a00000). Maybe it
was the whole alias on the H6.
Also, I can't remember if this was tested on the H6 or H616, but the
VE indeed writes to VE SRAM (0x1a00000), so that part is indeed used
by the video engine.
> using another part of it. The syscon block probably allows switching access
> to these different parts of SRAM C.
From what I've seen in the vendor BSP, both drivers toggle the switch.
I believe the goal is to prevent the CPU from having access, rather than
either peripheral claiming it as its own. And that is also what our SRAM
driver does. It claims the SRAM from the CPU. That's all. The toggle bit
pattern used by both drivers is the same.
> Also the sram_c1 node implies it's 2 MiB, which sounds quite unlikely.
That is what the memory map says. Calling it SRAM C1 is probably wrong.
ChenYu
> All the best,
>
> Paul
>
> >
> > Fixes: b542570e5605 ("arm64: dts: allwinner: h6: Add Video Engine node")
> > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 72ce1a75647b..88c6e3e105c0 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -205,7 +205,7 @@ video-codec@1c0e000 {
> > clock-names = "ahb", "mod", "ram";
> > resets = <&ccu RST_BUS_VE>;
> > interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
> > - allwinner,sram = <&ve_sram 1>;
> > + allwinner,sram = <&ve_sram 1>, <&de2_sram 1>;
> > iommus = <&iommu 3>;
> > };
> >
> > --
> > 2.47.3
> >
>
> --
> Paul Kocialkowski,
>
> Independent contractor - sys-base - https://www.sys-base.io/
> Free software developer - https://www.paulk.fr/
>
> Expert in multimedia, graphics and embedded hardware support with Linux.
^ permalink raw reply
* Re: [PATCH v18 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Eric Biggers @ 2026-05-24 20:49 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com>
On Fri, May 22, 2026 at 03:39:53PM +0200, Bartosz Golaszewski wrote:
> Currently the QCE crypto driver accesses the crypto engine registers
> directly via CPU. Trust Zone may perform crypto operations simultaneously
> resulting in a race condition.
So this driver is just critically broken currently? Yet it's still not
marked as BROKEN?
What are we even doing?
- Eric
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add GPADC support for A523
From: Chen-Yu Tsai @ 2026-05-24 21:04 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Maksim Kiselev, Michal Piekos
Cc: linux-iio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Conor Dooley
In-Reply-To: <20260516-sunxi-a523-gpadc-v3-0-a3a04cff2620@mmpsystems.pl>
On Sat, 16 May 2026 07:34:13 +0200, Michal Piekos wrote:
> Add support for Allwinner A523 GPADC in sun20i gpadc driver and describe
> corresponding node in dts for A523 SoC.
>
> A523 uses same model as existing driver except it has two clocks.
>
> Added support to enable more than one clock in the driver, extended the
> binding with new compatible and wired up dts node for A523 as its own
> fallback compatible.
>
> [...]
Applied to sunxi/dt-for-7.2 in sunxi, thanks!
[3/3] arm64: dts: allwinner: a523: add gpadc node
https://git.kernel.org/sunxi/linux/c/44cf19e41c76
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Chen-Yu Tsai @ 2026-05-24 21:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jernej Skrabec, samuel, mripard, maarten.lankhorst, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, mturquette, sboyd,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk
In-Reply-To: <20260514-valiant-ape-of-discourse-a4f5a9@quoll>
Hi,
On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
> > From: Jernej Skrabec <jernej.skrabec@gmail.com>
> >
> > As it turns out, current H616 DE33 binding was written based on
> > incomplete understanding of DE33 design. Namely, planes are shared
> > resource and not tied to specific mixer, which was the case for previous
> > generations of Display Engine (DE3 and earlier).
> >
> > This means that current DE33 binding doesn't properly reflect HW and
> > using it would mean that second mixer (used for second display output)
> > can't be supported.
> >
> > Remove layer register space, which will be represented with additional
> > node, and replace it with phandle, which will point to that new, shared
> > node. That way, all mixers can share same layers.
> >
> > There is no user of this binding yet, so changes can be made safely,
> > without breaking any backward compatibility.
>
> There is user. git grep gives me:
> drivers/gpu/drm/sun4i/sun8i_mixer.c
>
> which means this is a released ABI. As I understood, the old code was
We held off on merging the DT changes so that we could rework this.
I can't find the actual request though. It was probably over IRC.
> working fine but just did not support all use cases. Why this cannot be
> kept backwards compatible?
AFAIK the "planes" block is shared between two display mixers. As the
commit message explains, this prevents using the second mixer, since
only one of them can claim and map the register space. And on the H700
(which is the same die as the H616 discussed here but with more exposed
interfaces), there could actually be a use case for the second mixer.
Hope that explains things.
ChenYu
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Chen-Yu Tsai @ 2026-05-24 21:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jernej Skrabec, samuel, mripard, maarten.lankhorst, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, mturquette, sboyd,
dri-devel, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk
In-Reply-To: <20260514-valiant-ape-of-discourse-a4f5a9@quoll>
Hi,
(resent from new email)
On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
> > From: Jernej Skrabec <jernej.skrabec@gmail.com>
> >
> > As it turns out, current H616 DE33 binding was written based on
> > incomplete understanding of DE33 design. Namely, planes are shared
> > resource and not tied to specific mixer, which was the case for previous
> > generations of Display Engine (DE3 and earlier).
> >
> > This means that current DE33 binding doesn't properly reflect HW and
> > using it would mean that second mixer (used for second display output)
> > can't be supported.
> >
> > Remove layer register space, which will be represented with additional
> > node, and replace it with phandle, which will point to that new, shared
> > node. That way, all mixers can share same layers.
> >
> > There is no user of this binding yet, so changes can be made safely,
> > without breaking any backward compatibility.
>
> There is user. git grep gives me:
> drivers/gpu/drm/sun4i/sun8i_mixer.c
>
> which means this is a released ABI. As I understood, the old code was
We held off on merging the DT changes so that we could rework this.
I can't find the actual request though. It was probably over IRC.
> working fine but just did not support all use cases. Why this cannot be
> kept backwards compatible?
AFAIK the "planes" block is shared between two display mixers. As the
commit message explains, this prevents using the second mixer, since
only one of them can claim and map the register space. And on the H700
(which is the same die as the H616 discussed here but with more exposed
interfaces), there could actually be a use case for the second mixer.
Hope that explains things.
ChenYu
^ permalink raw reply
* Re: [PATCH v2 0/6] firmware: samsung: acpm: TMU support and cleanups
From: Alexey Klimov @ 2026-05-24 22:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Tudor Ambarus
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <177965159562.32222.17454581524471571236.b4-ty@b4>
On Sun May 24, 2026 at 8:40 PM BST, Krzysztof Kozlowski wrote:
>
> On Fri, 15 May 2026 09:32:24 +0000, Tudor Ambarus wrote:
>> This series introduces protocol support for the Exynos
>> Thermal Management Unit (TMU) to the ACPM driver, alongside several
>> cleanups.
>>
>> Dependencies
>> ============
>> Krzysztof, these patches together with the acpm fixes from your `fixes`
>> branch will be needed by the thermal maintainers. I'm going to send the
>> ACPM TMU (thermal) driver for review. In case they'll take it for the
>> next release, we'll need an immutable tag with the acpm fixes, cleanup
>> and thermal helpers. Thanks!
>>
>> [...]
>
> Applied, thanks!
>
> [1/6] firmware: samsung: acpm: Consolidate transfer initialization helper
> https://git.kernel.org/krzk/linux/c/43d3733b7ffd82b2bfeda69befa2a179335dfe6c
> [2/6] firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
> https://git.kernel.org/krzk/linux/c/7b20fd06f783c1e901d34305c68df16212cdf669
> [3/6] firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
> https://git.kernel.org/krzk/linux/c/ef1109e4b6120a52be1ea66d486d6744d0c5ac47
> [4/6] firmware: samsung: acpm: Make acpm_ops const and access via pointer
> https://git.kernel.org/krzk/linux/c/e694e19bf7db26ee324ff6bb450cc523592f5bee
> [5/6] firmware: samsung: acpm: Add TMU protocol support
> https://git.kernel.org/krzk/linux/c/f6af402de525d0848fc4a50f25ff01f56fc68d98
That commit contained the questionable error conversion which works
only for gs101 -- acpm_tmu_to_linux_err() hides some sensible errors into -EIO.
There were on-going discussion on maillist.
Now, it is needed to ignore that or generalise that or split it to have
different SoCs if needed. Some re-work will be needed.
BR,
Alexey.
^ permalink raw reply
* Re: [PATCH] bus: sunxi-rsb: Always check register address validity
From: Chen-Yu Tsai @ 2026-05-24 22:38 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, linux-arm-kernel, linux-sunxi,
linux-kernel, Chen-Yu Tsai, Andrey Skvortsov
In-Reply-To: <20260301144939.1832806-1-andrej.skvortzov@gmail.com>
On Sun, 01 Mar 2026 17:49:39 +0300, Andrey Skvortsov wrote:
> The register address was already validated for read operations in
> regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
> have the same set of possible addresses, and the address is being truncated
> from u32 to u8 here as well, so the same check is needed.
>
>
Remerged for 7.2 instead.
Applied to sunxi/drivers-for-7.2 in sunxi, thanks!
[1/1] bus: sunxi-rsb: Always check register address validity
https://git.kernel.org/sunxi/linux/c/61192938a587
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* [PATCH net-next] net: airoha: bind WLAN-bound flows on PPE driver L2 cache miss
From: Jihong Min @ 2026-05-24 22:43 UTC (permalink / raw)
To: netdev
Cc: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-arm-kernel, linux-mediatek,
linux-kernel, Jihong Min
The Linux bridge FDB can resolve a destination station to WDMA even when
the Airoha PPE driver's L2 offload cache has no entry for that MAC pair.
The normal bind path only checks the PPE driver's L2 offload cache, so an
unbound PPE hit for WLAN egress can stay unbound even though the bridge
already knows the right output path, unless a later offload event fills
that PPE driver cache.
This matters for bridge-visible WLAN egress, such as wired-to-WLAN
forwarding or WLAN peer forwarding across another BSS, radio or MLO link.
Same-link or same-radio intra-BSS forwarding can stay inside the WLAN
datapath and is not covered.
Before touching the PPE table, resolve the destination MAC through the
bridge device above the ingress netdev. If the PPE driver's L2 offload
cache lookup misses, bind the hardware flow to the resolved CDM4/WDMA
path.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Jihong Min <hurryman2212@gmail.com>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 138 +++++++++++++++++++----
1 file changed, 119 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 26da519236bf..ea932e6d87f6 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -803,65 +803,163 @@ static void airoha_ppe_foe_flow_remove_entry(struct airoha_ppe *ppe,
}
static int
-airoha_ppe_foe_commit_subflow_entry(struct airoha_ppe *ppe,
- struct airoha_flow_table_entry *e,
- u32 hash, bool rx_wlan)
+airoha_ppe_foe_commit_subflow(struct airoha_ppe *ppe,
+ const struct airoha_foe_entry *bridge,
+ u32 hash, bool rx_wlan)
{
u32 mask = AIROHA_FOE_IB1_BIND_PACKET_TYPE | AIROHA_FOE_IB1_BIND_UDP;
struct airoha_foe_entry *hwe_p, hwe;
- struct airoha_flow_table_entry *f;
int type;
hwe_p = airoha_ppe_foe_get_entry_locked(ppe, hash);
if (!hwe_p)
return -EINVAL;
- f = kzalloc_obj(*f, GFP_ATOMIC);
- if (!f)
- return -ENOMEM;
-
- hlist_add_head(&f->l2_subflow_node, &e->l2_flows);
- f->type = FLOW_TYPE_L2_SUBFLOW;
- f->hash = hash;
-
memcpy(&hwe, hwe_p, sizeof(*hwe_p));
- hwe.ib1 = (hwe.ib1 & mask) | (e->data.ib1 & ~mask);
+ hwe.ib1 = (hwe.ib1 & mask) | (bridge->ib1 & ~mask);
type = FIELD_GET(AIROHA_FOE_IB1_BIND_PACKET_TYPE, hwe.ib1);
if (type >= PPE_PKT_TYPE_IPV6_ROUTE_3T) {
- memcpy(&hwe.ipv6.l2, &e->data.bridge.l2, sizeof(hwe.ipv6.l2));
- hwe.ipv6.ib2 = e->data.bridge.ib2;
+ memcpy(&hwe.ipv6.l2, &bridge->bridge.l2,
+ sizeof(hwe.ipv6.l2));
+ hwe.ipv6.ib2 = bridge->bridge.ib2;
/* setting smac_id to 0xf instruct the hw to keep original
* source mac address
*/
hwe.ipv6.l2.src_mac_hi = FIELD_PREP(AIROHA_FOE_MAC_SMAC_ID,
0xf);
} else {
- memcpy(&hwe.bridge.l2, &e->data.bridge.l2,
+ memcpy(&hwe.bridge.l2, &bridge->bridge.l2,
sizeof(hwe.bridge.l2));
- hwe.bridge.ib2 = e->data.bridge.ib2;
+ hwe.bridge.ib2 = bridge->bridge.ib2;
if (type == PPE_PKT_TYPE_IPV4_HNAPT)
memcpy(&hwe.ipv4.new_tuple, &hwe.ipv4.orig_tuple,
sizeof(hwe.ipv4.new_tuple));
}
- hwe.bridge.data = e->data.bridge.data;
- airoha_ppe_foe_commit_entry(ppe, &hwe, hash, rx_wlan);
+ hwe.bridge.data = bridge->bridge.data;
+
+ return airoha_ppe_foe_commit_entry(ppe, &hwe, hash, rx_wlan);
+}
+
+static int
+airoha_ppe_foe_commit_subflow_entry(struct airoha_ppe *ppe,
+ struct airoha_flow_table_entry *e,
+ u32 hash, bool rx_wlan)
+{
+ struct airoha_flow_table_entry *f;
+ int err;
+
+ f = kzalloc_obj(*f, GFP_ATOMIC);
+ if (!f)
+ return -ENOMEM;
+
+ err = airoha_ppe_foe_commit_subflow(ppe, &e->data, hash, rx_wlan);
+ if (err) {
+ kfree(f);
+ return err;
+ }
+
+ hlist_add_head(&f->l2_subflow_node, &e->l2_flows);
+ f->type = FLOW_TYPE_L2_SUBFLOW;
+ f->hash = hash;
return 0;
}
+static bool
+airoha_ppe_foe_prepare_wdma_subflow_dev(struct airoha_ppe *ppe,
+ struct net_device *dev,
+ struct airoha_flow_data *data,
+ struct airoha_foe_entry *hwe)
+{
+ u32 pse_port;
+ int err;
+
+ err = airoha_ppe_foe_entry_prepare(ppe->eth, hwe, dev,
+ PPE_PKT_TYPE_BRIDGE, data, 0);
+ if (err)
+ return false;
+
+ pse_port = FIELD_GET(AIROHA_FOE_IB2_PSE_PORT, hwe->bridge.ib2);
+ if (pse_port != FE_PSE_PORT_CDM4)
+ return false;
+
+ return true;
+}
+
+static struct net_device *
+airoha_ppe_foe_get_bridge_master(struct net_device *dev)
+{
+ struct net_device *master = NULL;
+
+ rcu_read_lock();
+ master = netdev_master_upper_dev_get_rcu(dev);
+ if (master && netif_is_bridge_master(master))
+ dev_hold(master);
+ else
+ master = NULL;
+ rcu_read_unlock();
+
+ return master;
+}
+
+static bool
+airoha_ppe_foe_prepare_wdma_subflow(struct airoha_ppe *ppe,
+ struct sk_buff *skb,
+ struct airoha_foe_entry *hwe)
+{
+ struct ethhdr *eh = eth_hdr(skb);
+ struct airoha_flow_data data = {};
+ struct net_device *master;
+
+ if (!is_valid_ether_addr(eh->h_source) ||
+ !is_valid_ether_addr(eh->h_dest))
+ return false;
+
+ ether_addr_copy(data.eth.h_dest, eh->h_dest);
+ ether_addr_copy(data.eth.h_source, eh->h_source);
+
+ if (!skb->dev)
+ return false;
+
+ /* WLAN egress unbound hits can arrive before flowtable creates the
+ * L2 master flow normally used for subflow binding. Resolve only
+ * through the bridge master so dev_fill_forward_path() must use the
+ * bridge FDB for the destination MAC. Calling the ingress AP netdev
+ * directly can describe the source station's WDMA path and would
+ * corrupt Wi-Fi-to-wired flows whose real egress is not WDMA.
+ */
+ master = airoha_ppe_foe_get_bridge_master(skb->dev);
+ if (!master)
+ return false;
+
+ if (airoha_ppe_foe_prepare_wdma_subflow_dev(ppe, master, &data,
+ hwe)) {
+ dev_put(master);
+ return true;
+ }
+
+ dev_put(master);
+ return false;
+}
+
static void airoha_ppe_foe_insert_entry(struct airoha_ppe *ppe,
struct sk_buff *skb,
u32 hash, bool rx_wlan)
{
+ struct airoha_foe_entry wdma_hwe = {};
struct airoha_flow_table_entry *e;
struct airoha_foe_bridge br = {};
struct airoha_foe_entry *hwe;
bool commit_done = false;
+ bool wdma_ready = false;
struct hlist_node *n;
u32 index, state;
+ wdma_ready = airoha_ppe_foe_prepare_wdma_subflow(ppe, skb,
+ &wdma_hwe);
+
spin_lock_bh(&ppe_lock);
hwe = airoha_ppe_foe_get_entry_locked(ppe, hash);
@@ -899,6 +997,8 @@ static void airoha_ppe_foe_insert_entry(struct airoha_ppe *ppe,
airoha_l2_flow_table_params);
if (e)
airoha_ppe_foe_commit_subflow_entry(ppe, e, hash, rx_wlan);
+ else if (wdma_ready)
+ airoha_ppe_foe_commit_subflow(ppe, &wdma_hwe, hash, rx_wlan);
unlock:
spin_unlock_bh(&ppe_lock);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Alexey Klimov @ 2026-05-24 23:02 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin
Cc: Krzysztof Kozlowski, Michael Turquette, Stephen Boyd, Lee Jones,
Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
jyescas, kernel-team, Krzysztof Kozlowski
In-Reply-To: <b061d100-c0dd-467d-8289-be2c0935791b@linaro.org>
On Thu May 21, 2026 at 3:49 PM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> On 5/21/26 4:37 PM, Alexey Klimov wrote:
>> Peter, I agree we shouldn't bother about hypothetical SoCs. However,
>
> It's standard kernel philosophy to not add code that __might__ be useful
> later.
No idea what you mean by saying standard kernel philosophy but people
do add code that might be useful later. Some examples are:
-- ftrace subsystem;
-- commit eb2415854f3ba7d95c4f30d259f6f598ab604616
-- commit 78723fe309f189ee4010d5b7a55f6a14644a40c2
(if you so fancy about debug printk)
We can probably find more examples.
> Please consider adding that print when you submit support for
> e850.
Support for e850 was already sent:
https://lore.kernel.org/linux-samsung-soc/20260513-exynos850-acpm-firmware-support-v1-0-3858d097e433@linaro.org/
It doesn't matter now. Krzysztof already accepted ACPM TMU with error
conversion variant for gs101 only.
It will be nice to see ACPM that is more generic towards Exynos/Samsung
SoCs rather than gs.
BR,
Alexey.
^ permalink raw reply
* Re: [PATCH] Documentation: ABI: sysfs-class-reboot-mode-reboot_modes: fix doc warnings
From: Randy Dunlap @ 2026-05-24 22:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-arm-kernel, Sebastian Reichel, Shivendra Pratap,
linux-doc, linux-kernel
In-Reply-To: <CAMRc=McUr8Tuv9+LNQ0=ufj1z4Tstp_ujmL=r7bXrLaBXg4E5g@mail.gmail.com>
Sebastian,
On 4/27/26 2:11 AM, Bartosz Golaszewski wrote:
> On Mon, 27 Apr 2026 01:27:05 +0200, Randy Dunlap <rdunlap@infradead.org> said:
>> Repair the docs build warnings in this file by unindenting the description,
>> adding blank lines, and using `` to quote *arg.
>>
>> WARNING: Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:36: abi_sys_class_reboot_mode_driver_reboot_modes doesn't have a description
>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: WARNING: Inline emphasis start-string without end-string. [docutils]
>> Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes:1: ERROR: Unexpected indentation. [docutils]
>>
>> Fixes: d3da03025e6d ("Documentation: ABI: Add sysfs-class-reboot-mode-reboot_modes")
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
This build warning is now in mainline.
Will you be merging this patch soon?
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: Zeng Heng @ 2026-05-25 1:25 UTC (permalink / raw)
To: Catalin Marinas
Cc: yezhenyu2, zhurui3, will, akpm, npiggin, aneesh.kumar, peterz,
linux-kernel, wangkefeng.wang, linux-arm-kernel, linux-mm,
linux-arch, David Hildenbrand, zengheng4
In-Reply-To: <ahAyMO_6UcPc2q4U@arm.com>
Hi Catalin,
On 2026/5/22 18:38, Catalin Marinas wrote:
> On Fri, May 22, 2026 at 11:13:17AM +0100, Catalin Marinas wrote:
>> On Fri, May 22, 2026 at 01:32:07PM +0800, Zeng Heng wrote:
>>> On 2026/5/21 23:15, Catalin Marinas wrote:
>>>> On Thu, May 21, 2026 at 04:05:07PM +0100, Catalin Marinas wrote:
>>>>> On Thu, May 21, 2026 at 03:30:11PM +0800, Zeng Heng wrote:
>>>>>> From: Zeng Heng <zengheng4@huawei.com>
>>>>>>
>>>>>> When huge_pmd_unshare() is called to unshare a PMD table, the
>>>>>> tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
>>>>>> but the aarch64 tlb_flush() only checked tlb->freed_tables to
>>>>>> determine whether to use TLBF_NONE (vae1is, invalidates walk
>>>>>> cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
>>>>>>
>>>>>> This caused the stale PMD page table entry to remain in the walk cache
>>>>>> after unshare, potentially leading to incorrect page table walks.
>>>>>>
>>>>>> Fix by including unshared_tables in the check, so that when
>>>>>> unsharing tables, TLBF_NONE is used and the walk cache is properly
>>>>>> invalidated.
>>>>>>
>>>>>> Here is the detailed distinction between vae1is and vale1is:
>>>>>>
>>>>>> | Instruction Combination | Actual Invalidation Scope |
>>>>>> | ------------------------ | --------------------------------------------------|
>>>>>> | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) |
>>>>>> | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 |
>>>>>> | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) |
>>>>>> | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |
To clarify, the above was confirmed internally with the Kunpeng team.
>>> Per the ARM Architecture Reference Manual, whether only the last-level
>>> page table entry is invalidated is determined by the instruction used
>>> (vale1is for leaf entry only, vae1is for walk cache including leaf entry and
>>> non-leaf entry), rather than the TTL field. The TTL field merely specifies
>>> which level the leaf entry belongs to.
>>
>> Ah, yes, you are right. The TTL is still 2 in this case for a huge pmd,
>> we just want the walk cache leading to it to be invalidated. So no need
>> for the additional tlb_get_level().
>
> The Arm ARM is still unclear. The RVAE1IS has this wording:
>
> The TTL hint is only guaranteed to invalidate:
>
> - Non-leaf-level entries in the range up to but not including the
> level described by the TTL hint.
>
> - Leaf-level entries in the range that match the level described by
> the TTL hint.
>
> But we don't have such wording around non-leaf-level entries for VAE1IS.
> I presume it would be the same but I'll ask internally next week. In the
> meantime, I'll take this patch.
>
Got it. I agree the official ARM documentation doesn’t fully explain
this clearly.
Thanks for the additional confirmation.
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Andrew Jeffery @ 2026-05-25 1:25 UTC (permalink / raw)
To: Andrew Lunn, Anirudh Srinivasan
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Rob Herring, Conor Dooley, Krzysztof Kozlowski, Joel Stanley
In-Reply-To: <d8c7d7c9-6f2f-4d3f-95d4-877e8504a1b6@lunn.ch>
On Fri, 2026-05-22 at 14:05 +0200, Andrew Lunn wrote:
> On Thu, May 21, 2026 at 10:49:24PM -0500, Anirudh Srinivasan wrote:
> > Hi Andrew,
> >
> > On Tue, Mar 31, 2026 at 9:18 AM Anirudh Srinivasan
> > <anirudhsriniv@gmail.com> wrote:
> > >
> > > Adds the DT nodes needed for ethernet support for Asus Kommando, with
> > > phy mode set to rgmii-id.
> > >
> > > When this DT was originally added, the phy mode was set to rgmii (which
> > > was incorrect). It was suggested to remove networking support from the
> > > DT till the Aspeed networking driver was patched so that the correct phy
> > > mode could be used.
> > >
> > > The discussion in [1] mentions that u-boot was inserting clk delays that
> > > weren't needed, which resulted in needing to set the phy mode in linux
> > > to rgmii incorrectly. The solution suggested there was to patch u-boot to
> > > no longer insert these clk delays and use rgmii-id as the phy mode for
> > > any future DTs added to linux.
> > >
> > > This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT
> > > modified to insert clk delays of 0 (instead of patching u-boot itself).
> > > [3] adds a u-boot DT for this device (without networking) and describes
> > > how to patch it to add networking support. If this patched DT is used,
> > > then networking works with rgmii-id phy mode in both u-boot and linux.
> > >
> > > [1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
> > > [2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc
> > > [3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
> > >
> > > Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
> > > ---
> > > This patch is based off aspeed/arm/dt from bmc tree
> > > ---
> > > Changes in v2:
> > > - Commit message now mentions that the u-boot tested against is the
> > > openbmc u-boot fork
> > > - Link to v1: https://lore.kernel.org/r/20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com
> > > ---
> > > .../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > > index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
> > > --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > > @@ -107,6 +107,24 @@ &gpio1 {
> > > /*18E0 32*/ "","","","","","","","";
> > > };
> > >
> > > +&mac2 {
> > > + status = "okay";
> > > +
> > > + phy-mode = "rgmii-id";
> > > + phy-handle = <ðphy2>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&pinctrl_rgmii3_default>;
> > > +};
> > > +
> > > +&mdio2 {
> > > + status = "okay";
> > > +
> > > + ethphy2: ethernet-phy@0 {
> > > + compatible = "ethernet-phy-ieee802.3-c22";
> > > + reg = <0>;
> > > + };
> > > +};
> > > +
> > > &vhub {
> > > status = "okay";
> > > };
> > >
> > > ---
> > > base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
> > > change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
> > >
> > > Best regards,
> > > --
> > > Anirudh Srinivasan <anirudhsriniv@gmail.com>
> > >
> >
> > While we're figuring out what to do with u-boot, what are your
> > thoughts on getting this patch in so that the kernel DTS changes
> > needed for networking land in this cycle?
> >
> > The current commit message might become somewhat outdated if the
> > u-boot patch changes though, so not sure if that's okay.
>
> The commit message explains "Why?", which is what is important. So it
> should not matter if it becomes outdated. And the DT is correct, no
> matter how the issue is solved.
Yeah, this was my thought too, so I intend to apply it.
>
> So i'm O.K. with this.
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 0/9] iio: timestamp declaration cleanup
From: David Lechner @ 2026-05-25 1:38 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck
Cc: linux-iio, linux-kernel, linux-arm-kernel, linux-stm32,
chrome-platform, David Lechner, Andy Shevchenko
While looking around the code, I noticed that there are a lot of places
were we are manually filling all of the fields of an IIO timestamp.
This is error-prone (as seen in the first patch) and more verbose than
it needs to be.
Thanks to Andy's patch, we can just make the macro a compound literal
so it can be used directly in assignments and initializers.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
Changes in v2:
- Include Andy's compound literal patch.
- Drop explicity compound literal in later patches.
- Link to v1: https://patch.msgid.link/20260517-iio-timestamp-cleanup-v1-0-61fb908c11c7@baylibre.com
---
Andy Shevchenko (1):
iio: Convert IIO_CHAN_SOFT_TIMESTAMP() to be compound literal
David Lechner (8):
iio: common: scmi_sensors: simplify timestamp channel definition
iio: adc: dln2-adc: simplify timestamp channel definition
iio: adc: at91_adc: simplify timestamp channel definition
iio: adc: cc10001_adc: simplify timestamp channel definition
iio: adc: stm32-adc: simplify timestamp channel definition
iio: common: cros_ec_sensors: simplify timestamp channel definition
iio: light: cros_ec_light_prox: simplify timestamp channel definition
iio: pressure: cros_ec_baro: simplify timestamp channel definition
drivers/iio/adc/ad7606.c | 2 +-
drivers/iio/adc/at91_adc.c | 12 +++---------
drivers/iio/adc/cc10001_adc.c | 10 ++--------
drivers/iio/adc/dln2-adc.c | 12 +-----------
drivers/iio/adc/max11410.c | 2 +-
drivers/iio/adc/stm32-adc.c | 10 +---------
drivers/iio/common/cros_ec_sensors/cros_ec_activity.c | 8 +-------
drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 8 +-------
drivers/iio/common/scmi_sensors/scmi_iio.c | 13 +------------
drivers/iio/light/cros_ec_light_prox.c | 8 +-------
drivers/iio/pressure/cros_ec_baro.c | 8 +-------
include/linux/iio/iio.h | 6 +++---
12 files changed, 17 insertions(+), 82 deletions(-)
---
base-commit: e1a29334a9c043defe7a9363fa76d399d3fdfbec
change-id: 20260517-iio-timestamp-cleanup-1ee82f081a70
Best regards,
--
David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* [PATCH v2 3/9] iio: adc: dln2-adc: simplify timestamp channel definition
From: David Lechner @ 2026-05-25 1:38 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck
Cc: linux-iio, linux-kernel, linux-arm-kernel, linux-stm32,
chrome-platform, David Lechner
In-Reply-To: <20260524-iio-timestamp-cleanup-v2-0-c37c9408b7f7@baylibre.com>
Use IIO_CHAN_SOFT_TIMESTAMP() to define the timestamp channel instead of
manually filling in the struct iio_chan_spec fields. This makes the code
less verbose and mistake-prone.
Signed-off-by: David Lechner <dlechner@baylibre.com>
---
drivers/iio/adc/dln2-adc.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
index eb902a946efe..b01c6f5a73b1 100644
--- a/drivers/iio/adc/dln2-adc.c
+++ b/drivers/iio/adc/dln2-adc.c
@@ -444,16 +444,6 @@ static int dln2_update_scan_mode(struct iio_dev *indio_dev,
lval.scan_type.endianness = IIO_LE; \
}
-/* Assignment version of IIO_CHAN_SOFT_TIMESTAMP */
-#define IIO_CHAN_SOFT_TIMESTAMP_ASSIGN(lval, _si) { \
- lval.type = IIO_TIMESTAMP; \
- lval.channel = -1; \
- lval.scan_index = _si; \
- lval.scan_type.sign = 's'; \
- lval.scan_type.realbits = 64; \
- lval.scan_type.storagebits = 64; \
-}
-
static const struct iio_info dln2_adc_info = {
.read_raw = dln2_adc_read_raw,
.write_raw = dln2_adc_write_raw,
@@ -614,7 +604,7 @@ static int dln2_adc_probe(struct platform_device *pdev)
for (i = 0; i < chans; ++i)
DLN2_ADC_CHAN(dln2->iio_channels[i], i)
- IIO_CHAN_SOFT_TIMESTAMP_ASSIGN(dln2->iio_channels[i], i);
+ dln2->iio_channels[i] = IIO_CHAN_SOFT_TIMESTAMP(i);
indio_dev->name = DLN2_ADC_MOD_NAME;
indio_dev->info = &dln2_adc_info;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/9] iio: Convert IIO_CHAN_SOFT_TIMESTAMP() to be compound literal
From: David Lechner @ 2026-05-25 1:38 UTC (permalink / raw)
To: Jyoti Bhayana, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck
Cc: linux-iio, linux-kernel, linux-arm-kernel, linux-stm32,
chrome-platform, David Lechner, Andy Shevchenko
In-Reply-To: <20260524-iio-timestamp-cleanup-v2-0-c37c9408b7f7@baylibre.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Currently IIO_CHAN_SOFT_TIMESTAMP() can only be used to fill the static
data. In some cases it would be convenient to use it as right value in
the assignment operation. But it can't be done as is, because compiler
has no clue about the data layout. Converting it to be a compound literal
allows the above mentioned usage.
While at it, tidy up the indentation.
We also have to change existing uses of compound literal at the same
time to avoid compiler errors.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: David Lechner <dlechner@baylibre.com> (fixed compile errors)
---
drivers/iio/adc/ad7606.c | 2 +-
drivers/iio/adc/max11410.c | 2 +-
include/linux/iio/iio.h | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
index d9271894f091..cebb8ed8dcb1 100644
--- a/drivers/iio/adc/ad7606.c
+++ b/drivers/iio/adc/ad7606.c
@@ -1475,7 +1475,7 @@ static int ad7606_probe_channels(struct iio_dev *indio_dev)
}
if (slow_bus)
- channels[i] = (struct iio_chan_spec)IIO_CHAN_SOFT_TIMESTAMP(i);
+ channels[i] = IIO_CHAN_SOFT_TIMESTAMP(i);
indio_dev->channels = channels;
diff --git a/drivers/iio/adc/max11410.c b/drivers/iio/adc/max11410.c
index 69351f4f10bb..dc1b96356592 100644
--- a/drivers/iio/adc/max11410.c
+++ b/drivers/iio/adc/max11410.c
@@ -804,7 +804,7 @@ static int max11410_parse_channels(struct max11410_state *st,
chan_idx++;
}
- channels[chan_idx] = (struct iio_chan_spec)IIO_CHAN_SOFT_TIMESTAMP(chan_idx);
+ channels[chan_idx] = IIO_CHAN_SOFT_TIMESTAMP(chan_idx);
indio_dev->num_channels = chan_idx + 1;
indio_dev->channels = channels;
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 96b05c86c325..711c00f67371 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -353,15 +353,15 @@ static inline bool iio_channel_has_available(const struct iio_chan_spec *chan,
(chan->info_mask_shared_by_all_available & BIT(type));
}
-#define IIO_CHAN_SOFT_TIMESTAMP(_si) { \
+#define IIO_CHAN_SOFT_TIMESTAMP(_si) (struct iio_chan_spec) { \
.type = IIO_TIMESTAMP, \
.channel = -1, \
.scan_index = _si, \
.scan_type = { \
.sign = 's', \
- .realbits = 64, \
+ .realbits = 64, \
.storagebits = 64, \
- }, \
+ }, \
}
s64 iio_get_time_ns(const struct iio_dev *indio_dev);
--
2.43.0
^ permalink raw reply related
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