* Re: [PATCH v3 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
From: Sebastian Ene @ 2026-06-16 14:30 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <ajFKRFj8vp_KqrNc@google.com>
On Tue, Jun 16, 2026 at 02:06:12PM +0100, Vincent Donnefort wrote:
> On Tue, Jun 16, 2026 at 10:54:12AM +0000, Sebastian Ene wrote:
> > Verify the arguments of the FF-A notification bind call and forward the
> > message to Trustzone.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index dc7496ec295f..3d8ed829f558 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -42,6 +42,8 @@
> > */
> > #define HOST_FFA_ID 0
> >
> > +#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
> > +
> > /*
> > * A buffer to hold the maximum descriptor size we can see from the host,
> > * which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
> > @@ -713,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
> > case FFA_MEM_DONATE:
> > case FFA_MEM_RETRIEVE_REQ:
> > /* Optional notification interfaces added in FF-A 1.1 */
> > - case FFA_NOTIFICATION_BIND:
> > case FFA_NOTIFICATION_UNBIND:
> > case FFA_NOTIFICATION_SET:
> > case FFA_NOTIFICATION_GET:
> > @@ -929,6 +930,32 @@ static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
> > hyp_smccc_1_2_smc(args, res);
> > }
> >
> > +static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
> > + struct kvm_cpu_context *ctxt)
> > +{
> > + DECLARE_REG(u32, endp_id, ctxt, 1);
> > + DECLARE_REG(u32, flags, ctxt, 2);
> > + struct arm_smccc_1_2_regs *args;
> > +
> > + if (ffa_check_unused_args_sbz(ctxt, 5)) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
>
> "A Receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
> notifications to the Sender"
>
> Does that mean that if the host issues a FFA_NOTIFICATION_BIND it is the
> "Receiver" and not the "Sender"?
>
> (Same for unbind)
>
This means that we will have to check the ID of the receiver and not the
sender. Thanks for pointing out, I will add this to unbind as well.
>
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + if (flags > 1) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + args = (void *)&ctxt->regs.regs[0];
> > + hyp_smccc_1_2_smc(args, res);
> > +}
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_1_2_regs res;
> > @@ -991,6 +1018,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_NOTIFICATION_BITMAP_DESTROY:
> > do_ffa_notif_bitmap(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_NOTIFICATION_BIND:
> > + do_ffa_notif_bind(&res, host_ctxt);
> > + goto out_handled;
> > }
> >
> > if (ffa_call_supported(func_id))
> > --
> > 2.54.0.1136.gdb2ca164c4-goog
> >
Sebastian
^ permalink raw reply
* Re: [PATCH v3 1/7] KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
From: Sebastian Ene @ 2026-06-16 14:28 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <ajFEOK3bVu5QRoCv@google.com>
On Tue, Jun 16, 2026 at 01:40:24PM +0100, Vincent Donnefort wrote:
> On Tue, Jun 16, 2026 at 10:54:09AM +0000, Sebastian Ene wrote:
> > Allow FF-A notification bitmap creation messages to be forwarded to
> > Trustzone from the host and introduce a helper to check for SBZ
> > register fields.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 36 ++++++++++++++++++++++++++++++++++-
> > 1 file changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 1af722771178..b1e5f9ee86ef 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
> > static bool has_version_negotiated;
> > static hyp_spinlock_t version_lock;
> >
> > +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> > +{
> > + int reg;
> > +
> > + for (reg = first_reg; reg < 17; reg++) {
> > + if (cpu_reg(ctxt, reg))
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
>
> Hum, there's something a bit weird, as this function was introduced already in
> the previous patch. (and both have the same number)
>
Something is messed up here, I will have to spin a new version. Thanks
for letting me know.
>
> > static void ffa_to_smccc_error(struct arm_smccc_1_2_regs *res, u64 ffa_errno)
> > {
> > *res = (struct arm_smccc_1_2_regs) {
> > @@ -676,7 +688,6 @@ static bool ffa_call_supported(u64 func_id)
> > case FFA_MEM_DONATE:
> > case FFA_MEM_RETRIEVE_REQ:
> > /* Optional notification interfaces added in FF-A 1.1 */
> > - case FFA_NOTIFICATION_BITMAP_CREATE:
> > case FFA_NOTIFICATION_BITMAP_DESTROY:
> > case FFA_NOTIFICATION_BIND:
> > case FFA_NOTIFICATION_UNBIND:
> > @@ -862,6 +873,26 @@ static void do_ffa_part_get(struct arm_smccc_1_2_regs *res,
> > hyp_spin_unlock(&host_buffers.lock);
> > }
> >
> > +static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
> > + struct kvm_cpu_context *ctxt)
> > +{
> > + DECLARE_REG(u32, vmid, ctxt, 1);
> > + struct arm_smccc_1_2_regs *args;
> > +
> > + if (ffa_check_unused_args_sbz(ctxt, 3)) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + if (vmid != HOST_FFA_ID) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + args = (void *)&ctxt->regs.regs[0];
> > + hyp_smccc_1_2_smc(args, res);
> > +}
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_1_2_regs res;
> > @@ -920,6 +951,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_PARTITION_INFO_GET:
> > do_ffa_part_get(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_NOTIFICATION_BITMAP_CREATE:
> > + do_ffa_notif_bitmap(&res, host_ctxt);
> > + goto out_handled;
> > }
> >
> > if (ffa_call_supported(func_id))
> > --
> > 2.54.0.1099.g489fc7bff1-goog
> >
Sebastian
^ permalink raw reply
* Re: [PATCH v3 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
From: Sebastian Ene @ 2026-06-16 14:24 UTC (permalink / raw)
To: Vincent Donnefort
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <ajFPIhMGsjqAbtN7@google.com>
On Tue, Jun 16, 2026 at 02:26:58PM +0100, Vincent Donnefort wrote:
> On Tue, Jun 16, 2026 at 10:54:15AM +0000, Sebastian Ene wrote:
> > Allow FF-A notification GET messages to be proxied from the pKVM
> > hypervisor to Trustzone and enforce MBZ/SBZ fields.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index fcfaa441770d..549250ff8f82 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -715,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
> > case FFA_MEM_DONATE:
> > case FFA_MEM_RETRIEVE_REQ:
> > /* Optional notification interfaces added in FF-A 1.1 */
> > - case FFA_NOTIFICATION_GET:
> > case FFA_NOTIFICATION_INFO_GET:
> > /* Optional interfaces added in FF-A 1.2 */
> > case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> > @@ -1001,6 +1000,26 @@ static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
> > arm_smccc_1_2_smc(args, res);
> > }
> >
> > +static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
> > + struct kvm_cpu_context *ctxt)
> > +{
> > + DECLARE_REG(u32, flags, ctxt, 2);
> > + struct arm_smccc_1_2_regs *args;
> > +
> > + if (ffa_check_unused_args_sbz(ctxt, 3)) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
>
> Shall we check that the endpoint ID is HOST_FFA_ID here?
>
Yes we can add this check
> > +
> > + if (flags & GENMASK(31, 4)) {
> > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> > + return;
> > + }
> > +
> > + args = (void *)&ctxt->regs.regs[0];
> > + arm_smccc_1_2_smc(args, res);
> > +}
> > +
> > bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > {
> > struct arm_smccc_1_2_regs res;
> > @@ -1072,6 +1091,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> > case FFA_NOTIFICATION_SET:
> > do_ffa_notif_set(&res, host_ctxt);
> > goto out_handled;
> > + case FFA_NOTIFICATION_GET:
> > + do_ffa_notif_get(&res, host_ctxt);
> > + goto out_handled;
> > }
> >
> > if (ffa_call_supported(func_id))
> > --
> > 2.54.0.1136.gdb2ca164c4-goog
> >
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: mediatek: mt6323: add AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 AUXADC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..c070f4b0936c 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,11 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ mt6323_adc: adc {
+ compatible = "mediatek,mt6323-auxadc";
+ #io-channel-cells = <1>;
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
temperature, and other internal measurements. The IP block is not
register-compatible with mt6359 and should use a separate driver.
Add the devicetree binding documentation and the associated header file
defining the ADC channel constants.
Also change the description to 'MT6350 series and similar' because
the binding already includes more than mt635x series PMICs.
Finally, add the MAINTAINERS entry for the header with ADC constants.
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 ++-
MAINTAINERS | 6 ++++++
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++++++++++++++++++++++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
index 5d4ab701f51a..852eb7336a5a 100644
--- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6359-auxadc.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6359-auxadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek MT6350 series PMIC AUXADC
+title: MediaTek MT6350 series and similar PMIC AUXADC
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
@@ -19,6 +19,7 @@ description:
properties:
compatible:
enum:
+ - mediatek,mt6323-auxadc
- mediatek,mt6357-auxadc
- mediatek,mt6358-auxadc
- mediatek,mt6359-auxadc
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..2551c8cd9e9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,12 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC AUXADC DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+L: linux-iio@vger.kernel.org
+S: Maintained
+F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
new file mode 100644
index 000000000000..6ee9a9ecffc1
--- /dev/null
+++ b/include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+#define _DT_BINDINGS_MEDIATEK_MT6323_AUXADC_H
+
+#define MT6323_AUXADC_BATON2 0
+#define MT6323_AUXADC_CH6 1
+#define MT6323_AUXADC_BAT_TEMP 2
+#define MT6323_AUXADC_CHIP_TEMP 3
+#define MT6323_AUXADC_VCDT 4
+#define MT6323_AUXADC_BATON1 5
+#define MT6323_AUXADC_ISENSE 6
+#define MT6323_AUXADC_BATSNS 7
+#define MT6323_AUXADC_ACCDET 8
+#define MT6323_AUXADC_AUDIO0 9
+#define MT6323_AUXADC_AUDIO1 10
+#define MT6323_AUXADC_AUDIO2 11
+#define MT6323_AUXADC_AUDIO3 12
+#define MT6323_AUXADC_AUDIO4 13
+#define MT6323_AUXADC_AUDIO5 14
+#define MT6323_AUXADC_AUDIO6 15
+#define MT6323_AUXADC_AUDIO7 16
+
+#endif
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Andy Shevchenko
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
provides support for reading various channels including battery and
charger voltages, battery and chip temperature, current sensing and
accessory detection.
Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
---
MAINTAINERS | 1 +
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 327 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2551c8cd9e9d..fb40128451dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16260,6 +16260,7 @@ MEDIATEK MT6323 PMIC AUXADC DRIVER
M: Roman Vivchar <rva333@protonmail.com>
L: linux-iio@vger.kernel.org
S: Maintained
+F: drivers/iio/adc/mt6323-auxadc.c
F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
MEDIATEK MT6735 CLOCK & RESET DRIVERS
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..a03614b46041 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1137,6 +1137,17 @@ config MCP3911
This driver can also be built as a module. If so, the module will be
called mcp3911.
+config MEDIATEK_MT6323_AUXADC
+ tristate "MediaTek MT6323 PMIC AUXADC driver"
+ depends on MFD_MT6397
+ help
+ Say yes here to enable support for MediaTek MT6323 PMIC Auxiliary ADC.
+ This driver provides multiple channels for system monitoring,
+ such as battery voltage, PMIC temperature, and others.
+
+ This driver can also be built as a module. If so, the module will be
+ called mt6323-auxadc.
+
config MEDIATEK_MT6359_AUXADC
tristate "MediaTek MT6359 PMIC AUXADC driver"
depends on MFD_MT6397
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index c76550415ff1..58161750d6e3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
obj-$(CONFIG_MCP3564) += mcp3564.o
obj-$(CONFIG_MCP3911) += mcp3911.o
+obj-$(CONFIG_MEDIATEK_MT6323_AUXADC) += mt6323-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6359_AUXADC) += mt6359-auxadc.o
obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
new file mode 100644
index 000000000000..572466c3f375
--- /dev/null
+++ b/drivers/iio/adc/mt6323-auxadc.c
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ *
+ * Based on drivers/iio/adc/mt6359-auxadc.c
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/cleanup.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stringify.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#include <dt-bindings/iio/adc/mediatek,mt6323-auxadc.h>
+
+#define AUXADC_STRUP_CON10_RSTB_SEL BIT(7)
+#define AUXADC_STRUP_CON10_RSTB_SW BIT(5)
+
+#define AUXADC_TOP_CKPDN2_CTL_CK BIT(5)
+
+#define AUXADC_TRIM_CH2_MASK GENMASK(11, 10)
+#define AUXADC_TRIM_CH4_MASK GENMASK(9, 8)
+#define AUXADC_TRIM_CH5_MASK GENMASK(5, 4)
+#define AUXADC_TRIM_CH6_MASK GENMASK(3, 2)
+
+#define AUXADC_CON27_VREF18_ENB_MD BIT(15)
+#define AUXADC_CON27_MD_STATUS BIT(0)
+
+#define AUXADC_CON19_GPS_STATUS BIT(1)
+
+#define AUXADC_CON26_VREF18_SELB BIT(1)
+#define AUXADC_CON26_DECI_GDLY_SEL BIT(0)
+
+#define AUXADC_CON11_VBUF_EN BIT(4)
+
+#define AUXADC_CON19_DECI_GDLY_MASK GENMASK(15, 14)
+#define AUXADC_ADC19_BUSY_MASK GENMASK(15, 1)
+#define AUXADC_READY_MASK BIT(15)
+#define AUXADC_DATA_MASK GENMASK(14, 0)
+
+#define AUXADC_CON9_OSR_MASK GENMASK(12, 10)
+#define AUXADC_DEFAULT_OSR 3
+
+#define MTK_PMIC_IIO_CHAN(_name, _chan, _addr) \
+{ \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _chan, \
+ .address = _addr, \
+ .datasheet_name = __stringify(_name), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+/*
+ * AUXADC reports everything in mV, including temperature and
+ * current channels. Channel macros are mapped such that their
+ * ID matches their respective hardware bit position in CON22.
+ */
+static const struct iio_chan_spec mt6323_auxadc_channels[] = {
+ MTK_PMIC_IIO_CHAN(baton2, MT6323_AUXADC_BATON2, MT6323_AUXADC_ADC6),
+ MTK_PMIC_IIO_CHAN(ch6, MT6323_AUXADC_CH6, MT6323_AUXADC_ADC11),
+ MTK_PMIC_IIO_CHAN(bat_temp, MT6323_AUXADC_BAT_TEMP, MT6323_AUXADC_ADC5),
+ MTK_PMIC_IIO_CHAN(chip_temp, MT6323_AUXADC_CHIP_TEMP, MT6323_AUXADC_ADC4),
+ MTK_PMIC_IIO_CHAN(vcdt, MT6323_AUXADC_VCDT, MT6323_AUXADC_ADC2),
+ MTK_PMIC_IIO_CHAN(baton1, MT6323_AUXADC_BATON1, MT6323_AUXADC_ADC3),
+ MTK_PMIC_IIO_CHAN(isense, MT6323_AUXADC_ISENSE, MT6323_AUXADC_ADC1),
+ MTK_PMIC_IIO_CHAN(batsns, MT6323_AUXADC_BATSNS, MT6323_AUXADC_ADC0),
+ MTK_PMIC_IIO_CHAN(accdet, MT6323_AUXADC_ACCDET, MT6323_AUXADC_ADC7),
+};
+
+/*
+ * The MediaTek MT6323 (as well as a lot of other PMICs) has the following hierarchy:
+ * PMIC AUXADC <- PMIC MFD <- SoC PWRAP (wrapper for PWRAP FSM)
+ *
+ * Therefore, PWRAP regmap should be obtained using dev->parent->parent.
+ */
+struct mt6323_auxadc {
+ struct regmap *regmap;
+ /* AUXADC doesn't support reading multiple channels simultaneously. */
+ struct mutex lock;
+};
+
+static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
+ if (ret)
+ return ret;
+
+ /* The ADC is idle. */
+ if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
+ return 0;
+
+ ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
+ !(val & AUXADC_ADC19_BUSY_MASK),
+ 10, 500);
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON19,
+ AUXADC_CON19_DECI_GDLY_MASK);
+}
+
+static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+}
+
+static int mt6323_auxadc_release(struct mt6323_auxadc *auxadc,
+ unsigned long channel)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_clear_bits(map, MT6323_AUXADC_CON22, BIT(channel));
+ if (ret)
+ return ret;
+
+ return regmap_clear_bits(map, MT6323_AUXADC_CON11, AUXADC_CON11_VBUF_EN);
+}
+
+static int mt6323_auxadc_read(struct mt6323_auxadc *auxadc,
+ const struct iio_chan_spec *chan, int *out)
+{
+ struct regmap *map = auxadc->regmap;
+ u32 val;
+ int ret;
+
+ ret = regmap_read_poll_timeout(map, chan->address,
+ val, (val & AUXADC_READY_MASK),
+ 1 * USEC_PER_MSEC, 100 * USEC_PER_MSEC);
+ if (ret)
+ return ret;
+
+ *out = FIELD_GET(AUXADC_DATA_MASK, val);
+
+ return 0;
+}
+
+static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
+ int ret, mult;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->channel == MT6323_AUXADC_ISENSE ||
+ chan->channel == MT6323_AUXADC_BATSNS)
+ mult = 4;
+ else
+ mult = 1;
+
+ /* 1800mV full range with 15-bit resolution. */
+ *val = mult * 1800;
+ *val2 = 15;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_RAW: {
+ guard(mutex)(&auxadc->lock);
+
+ ret = mt6323_auxadc_prepare_channel(auxadc);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_request(auxadc, chan->channel);
+ if (ret)
+ return ret;
+
+ /* Hardware limitation: the AUXADC needs a delay to become ready. */
+ fsleep(300);
+
+ ret = mt6323_auxadc_read(auxadc, chan, val);
+
+ if (mt6323_auxadc_release(auxadc, chan->channel))
+ dev_err(&indio_dev->dev,
+ "failed to release channel %d\n", chan->channel);
+
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
+{
+ struct regmap *map = auxadc->regmap;
+ int ret;
+
+ ret = regmap_set_bits(map, MT6323_STRUP_CON10,
+ AUXADC_STRUP_CON10_RSTB_SW |
+ AUXADC_STRUP_CON10_RSTB_SEL);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_TOP_CKPDN2, AUXADC_TOP_CKPDN2_CTL_CK);
+ if (ret)
+ return ret;
+
+ ret = regmap_update_bits(map, MT6323_AUXADC_CON10,
+ AUXADC_TRIM_CH2_MASK | AUXADC_TRIM_CH4_MASK |
+ AUXADC_TRIM_CH5_MASK | AUXADC_TRIM_CH6_MASK,
+ FIELD_PREP(AUXADC_TRIM_CH2_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH4_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH5_MASK, 1) |
+ FIELD_PREP(AUXADC_TRIM_CH6_MASK, 1));
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON27,
+ AUXADC_CON27_VREF18_ENB_MD |
+ AUXADC_CON27_MD_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON19, AUXADC_CON19_GPS_STATUS);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(map, MT6323_AUXADC_CON26,
+ AUXADC_CON26_VREF18_SELB |
+ AUXADC_CON26_DECI_GDLY_SEL);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(map, MT6323_AUXADC_CON9, AUXADC_CON9_OSR_MASK,
+ FIELD_PREP(AUXADC_CON9_OSR_MASK, AUXADC_DEFAULT_OSR));
+}
+
+static const struct iio_info mt6323_auxadc_iio_info = {
+ .read_raw = mt6323_auxadc_read_raw,
+};
+
+static int mt6323_auxadc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mt6323_auxadc *auxadc;
+ struct regmap *regmap;
+ struct iio_dev *iio;
+ int ret;
+
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ iio = devm_iio_device_alloc(dev, sizeof(*auxadc));
+ if (!iio)
+ return -ENOMEM;
+
+ auxadc = iio_priv(iio);
+ auxadc->regmap = regmap;
+
+ ret = devm_mutex_init(dev, &auxadc->lock);
+ if (ret)
+ return ret;
+
+ ret = mt6323_auxadc_init(auxadc);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to initialize auxadc\n");
+
+ iio->name = "mt6323-auxadc";
+ iio->info = &mt6323_auxadc_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = mt6323_auxadc_channels;
+ iio->num_channels = ARRAY_SIZE(mt6323_auxadc_channels);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id mt6323_auxadc_of_match[] = {
+ { .compatible = "mediatek,mt6323-auxadc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_auxadc_of_match);
+
+static struct platform_driver mt6323_auxadc_driver = {
+ .driver = {
+ .name = "mt6323-auxadc",
+ .of_match_table = mt6323_auxadc_of_match,
+ },
+ .probe = mt6323_auxadc_probe,
+};
+module_platform_driver(mt6323_auxadc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC AUXADC Driver");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/4] AUXADC driver for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar, Andy Shevchenko
This series adds support for the 15-bit AUXADC hardware block found on
the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
The other parts (EFUSE and thermal) will probably be sent this week.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v3:
- AUXADC driver:
- Add comment for channels table about voltage and channel IDs (Jonathan)
- Add comment for mutex in the 'mt6323_auxadc' struct (Jonathan)
- Break 'regmap_read_poll_timeout' on logical boundaries (Andy)
- Switch to 'guard' from 'scoped_guard' (Andy)
- Link to v2: https://patch.msgid.link/20260609-mt6323-adc-v2-0-aa93a22309f9@protonmail.com
Changes in v2:
- AUXADC driver:
- Drop channel type from the MTK_PMIC_IIO_CHAN macro (Nuno)
- Drop kerneldoc for the mt6323_auxadc struct (Nuno)
- Add channel release to save power (Sashiko, Jonathan)
- Drop 'reg' variable in the mt6323_auxadc_read (Jonathan)
- Sort variables in the mt6323_auxadc_probe (Jonathan)
- Maintainers:
- Drop linux-mediatek list (Andy)
- Split between dt-bindings and driver to avoid missing file (Nuno)
- Link to v1: https://patch.msgid.link/20260602-mt6323-adc-v1-0-68ec737508ee@protonmail.com
Changes after split:
- dt-bindings: Change 'MT63xx' to 'MT6350 series and similar' (Jonathan)
- AUXADC driver:
- Add missing headers (Andy)
- Fix AUXADC_TRIM_CH* values (Andy)
- Rename masks to include their register name (Jonathan)
- Fix formatting (Andy, Jonathan)
- Replace channel address with actual register value (Jonathan), align the table
- Replace IIO_TEMP with IIO_VOLTAGE, since the actual output is still mV, not mC
- Rename constants to match their registers (Jonathan)
- Remove 'if/else if/else' in the mt6323_auxadc_read_raw (Andy)
- Add comments for fsleep, ADC range and resolution (Andy, Jonathan)
- Remove useless error messages (Andy)
- Maintainers:
- Explicitly include mt6323 in the name (Jonathan)
- Squash with AUXADC driver commit (Krzysztof)
- Set status back to 'Maintained'
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
mfd: mt6397-core: add mt6323 AUXADC support
ARM: dts: mediatek: mt6323: add AUXADC support
.../bindings/iio/adc/mediatek,mt6359-auxadc.yaml | 3 +-
MAINTAINERS | 7 +
arch/arm/boot/dts/mediatek/mt6323.dtsi | 5 +
drivers/iio/adc/Kconfig | 11 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mt6323-auxadc.c | 314 +++++++++++++++++++++
drivers/mfd/mt6397-core.c | 3 +
.../dt-bindings/iio/adc/mediatek,mt6323-auxadc.h | 24 ++
8 files changed, 367 insertions(+), 1 deletion(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260525-mt6323-adc-3befce36cbf2
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH v3 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Roman Vivchar via B4 Relay @ 2026-06-16 14:15 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones
Cc: linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ben Grisdale, Roman Vivchar
In-Reply-To: <20260616-mt6323-adc-v3-0-1c27c588185d@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..013b0857fb54 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-auxadc",
+ .of_compatible = "mediatek,mt6323-auxadc",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Konrad Dybcio @ 2026-06-16 14:14 UTC (permalink / raw)
To: Andrew Lunn, Mohd Ayaan Anwar, Bjorn Andersson,
Bartosz Golaszewski, Eric Chanudet, Lucas Karpinski,
Andrew Halaney
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <82705420-771d-41bf-a4d9-ed94dff86ff0@lunn.ch>
On 6/15/26 6:48 PM, Andrew Lunn wrote:
> On Mon, Jun 15, 2026 at 09:24:07AM +0530, Mohd Ayaan Anwar wrote:
>> Hello Andrew,
>> On Thu, Jun 11, 2026 at 10:54:37PM +0200, Andrew Lunn wrote:
>>> On Fri, Jun 12, 2026 at 12:06:59AM +0530, Mohd Ayaan Anwar wrote:
>>>> When "rgmii-id" is selected the PHY supplies both TX and RX delays, so
>>>> the MAC must not add its own. The driver currently falls through to the
>>>> generic DLL initialisation path which programs it to add a delay.
>>>>
>>>> Power down the DLL and set DDR bypass mode for RGMII_ID, then program
>>>> the IO_MACRO via a new ethqos_rgmii_id_macro_init() helper. Also fix
>>>> ethqos_set_clk_tx_rate() to not double the clock rate in bypass mode at
>>>> 100M/10M, and remove RGMII_ID from the phase-shift suppression in
>>>> ethqos_rgmii_macro_init() since RGMII_ID no longer reaches that path.
>>>
>>> I'm curious how this works at the moment? Do no boards make use of
>>> RGMII ID? Are all current boards broken?
>>
>> Searching through the DTS, I found that we have two boards using "rgmii"
>> (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
>> "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
>
> So this causes problems. We cannot break existing boards, yet it would
> be good to fix the current broken behaviour.
These are a funny bunch.. QCS404 is a stuck in a perpetual cycle of
"no one has the hardware" and "someone has the hw but zero interest or
time". I think we've considered it for removal at one point..
I'm not sure to what degree the two SA8xxx boards are used. They
may have been stuck in some sort of a limbo. Maybe Bjorn knows?
Also +Cc some of the folks that contributed to them in the past
Konrad
^ permalink raw reply
* [PATCH v4] drm: uapi: Add macro for chipset specific event ID region
From: Bence Csokas @ 2026-06-16 13:48 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-arm-kernel, linux-samsung-soc,
nouveau
Cc: Bence Csokas, Daniel Kiss, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Inki Dae,
Seung-Woo Kim, Kyungmin Park, Krzysztof Kozlowski, Alim Akhtar,
Lyude Paul, Danilo Krummrich, Zack Rusin,
Broadcom internal kernel review list
uapi/drm/drm.h states:
Event types 0 - 0x7fffffff are generic DRM events, 0x80000000 and
up are chipset specific.
However, this distinction was not put in the code. To elevate the contract
between the generic DRM framework and the driver from the comment to code,
put this in a macro for clarity and convenience.
Cc: Daniel Kiss <Daniel.Kiss@arm.com>
Signed-off-by: Bence Csokas <bence.csokas@arm.com>
---
Changes in v4:
* Document `_v` parameter
* Also convert DRM_NOUVEAU_EVENT_NVIF
Changes in v2, v3:
* Rebase to master
Link to v1:
https://lore.kernel.org/lkml/20260408163608.361826-2-bence.csokas@arm.com/T/#u
include/uapi/drm/drm.h | 9 +++++++++
include/uapi/drm/exynos_drm.h | 4 ++--
include/uapi/drm/nouveau_drm.h | 2 +-
include/uapi/drm/virtgpu_drm.h | 2 +-
include/uapi/drm/vmwgfx_drm.h | 2 +-
5 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 27cc159c1d27..6acb1eee6bd2 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -1419,6 +1419,15 @@ struct drm_event {
* The event payload is a struct drm_event_crtc_sequence.
*/
#define DRM_EVENT_CRTC_SEQUENCE 0x03
+/**
+ * DRM_EVENT_VENDOR_SPECIFIC - vendor/chipset specific event
+ * @_v: vendor-specific ID
+ *
+ * These event IDs are reserved for chipset and driver specific events.
+ *
+ * Refer to the chipset driver's header for details and payload struct.
+ */
+#define DRM_EVENT_VENDOR_SPECIFIC(_v) ((_v) | 0x80000000)
struct drm_event_vblank {
struct drm_event base;
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index a51aa1c618c1..8d3156fb129c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -395,8 +395,8 @@ struct drm_exynos_ioctl_ipp_commit {
DRM_EXYNOS_IPP_COMMIT, struct drm_exynos_ioctl_ipp_commit)
/* Exynos specific events */
-#define DRM_EXYNOS_G2D_EVENT 0x80000000
-#define DRM_EXYNOS_IPP_EVENT 0x80000002
+#define DRM_EXYNOS_G2D_EVENT DRM_EVENT_VENDOR_SPECIFIC(0x0)
+#define DRM_EXYNOS_IPP_EVENT DRM_EVENT_VENDOR_SPECIFIC(0x2)
struct drm_exynos_g2d_event {
struct drm_event base;
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 1fa82fa6af38..6d9d7ed52d28 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -25,7 +25,7 @@
#ifndef __NOUVEAU_DRM_H__
#define __NOUVEAU_DRM_H__
-#define DRM_NOUVEAU_EVENT_NVIF 0x80000000
+#define DRM_NOUVEAU_EVENT_NVIF DRM_EVENT_VENDOR_SPECIFIC(0x0)
#include "drm.h"
diff --git a/include/uapi/drm/virtgpu_drm.h b/include/uapi/drm/virtgpu_drm.h
index 9debb320c34b..03e8a0c7f778 100644
--- a/include/uapi/drm/virtgpu_drm.h
+++ b/include/uapi/drm/virtgpu_drm.h
@@ -224,7 +224,7 @@ struct drm_virtgpu_context_init {
* effect. The event size is sizeof(drm_event), since there is no additional
* payload.
*/
-#define VIRTGPU_EVENT_FENCE_SIGNALED 0x90000000
+#define VIRTGPU_EVENT_FENCE_SIGNALED DRM_EVENT_VENDOR_SPECIFIC(0x10000000)
#define DRM_IOCTL_VIRTGPU_MAP \
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
index 7d786a0cc835..5e5878384e60 100644
--- a/include/uapi/drm/vmwgfx_drm.h
+++ b/include/uapi/drm/vmwgfx_drm.h
@@ -715,7 +715,7 @@ struct drm_vmw_fence_arg {
/*
* The event type
*/
-#define DRM_VMW_EVENT_FENCE_SIGNALED 0x80000000
+#define DRM_VMW_EVENT_FENCE_SIGNALED DRM_EVENT_VENDOR_SPECIFIC(0x0)
struct drm_vmw_event_fence {
struct drm_event base;
base-commit: 0e0611827f3349d0a2ac121c023a6d3260dcecdb
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v7 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Rob Herring (Arm) @ 2026-06-16 13:43 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Lee Jones, Mark Brown, linux-input, linux-pm, Louis-Alexis Eyraud,
linux-kernel, Julien Massot, Macpaul Lin, Krzysztof Kozlowski,
Liam Girdwood, Linus Walleij, Conor Dooley, Dmitry Torokhov,
Akari Tsuyukusa, AngeloGioacchino Del Regno, Chen Zhong,
Fabien Parent, linux-mediatek, Val Packett, linux-arm-kernel,
Matthias Brugger, devicetree, Sean Wang, Sen Chu, linux-gpio
In-Reply-To: <20260615071836.362883-2-l.scorcia@gmail.com>
On Mon, 15 Jun 2026 09:16:07 +0200, Luca Leonardo Scorcia wrote:
> Describe the MT6392 PMIC and its RTC and regulator devices. This device
> is mostly based on MT6323 with some similarities to MT6397 and is usually
> found on boards using the MT8516/MT8167 SoC.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 0/9] Add support for MT6392 PMIC
From: Rob Herring @ 2026-06-16 13:42 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Julien Massot, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Akari Tsuyukusa, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260615071836.362883-1-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:06AM +0200, Luca Leonardo Scorcia wrote:
> The MediaTek MT6392 PMIC is usually found on devices powered by
> the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
>
> This series is mostly based around patches submitted a couple
> years ago by Fabien Parent and not merged and from Val Packett's
> submission from Jan 2025 that included extra cleanups, fixes, and a
> new dtsi file similar to ones that exist for other PMICs. Some
> comments weren't addressed and the series was ultimately not merged.
>
> These patches enable four functions: keys, regulator, pinctrl and RTC.
> Mono speaker amp will follow later as I need to work further on the
> audio codec.
>
> I added a handful of device tree improvements to fix some dtbs_check
> errors, added support for the pinctrl device and addressed the comments
> from last year's reviews.
>
> Please note that patch 0006 and 0008 depend on patch 0005 as they need the
> registers.h file, but belong to different driver areas. I'm not sure if
> I'm supposed to squash them even if they belong to different driver
> areas of if it's fine like this. Any advice is welcome.
>
> The series has been tested on Xiaomi Mi Smart Clock X04G and on the
> Lenovo Smart Clock 2 CD-24502F.
>
> Changes in v7:
> - Removed patch 0008 dependency on patch 0003.
> - Reintroduced the regulator driver. In earlier revisions of this series,
> it was proposed to remove the dedicated compatible for the regulator
> device [3]. The driver does not use actually it, but it is not possible
> at this time to remove it from the bindings since it's a required
> property.
>
> Making the regulator-required property conditional was NACKed in [5],
> with the suggestion to create a separate binding altogether for devices
> that do not require the compatible property. I tried implementing this,
> but since the parent device needs to be declared as compatible with
> mt6323, it leads to a warning in dt_binding_check since mt6323 would
> be declared as a compatible in both mt6392 and mt6397.
>
> In the end the only regulator driver from the mt6397 documentation that
> still declares an of_match is mt6397-regulator and it does not seem
> to be necessary, so it should be possible to remove it and make the
> regulator compatible optional for all regulators, but that change would
> probably deserve its own separate patch series.
I don't really follow what the issue is here, but compatible should
never be optional.
Rob
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Rob Herring @ 2026-06-16 13:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260615071836.362883-10-l.scorcia@gmail.com>
On Mon, Jun 15, 2026 at 09:16:15AM +0200, Luca Leonardo Scorcia wrote:
> From: Val Packett <val@packett.cool>
>
> Add the dts to be included by all boards using the MT6392 PMIC,
> providing support for regulator, keys, pinctrl and RTC.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
> 1 file changed, 75 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
Nothing is using this so it is a dead file that doesn't get tested.
Rob
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Andre Przywara @ 2026-06-16 13:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jernej Škrabec, wens
Cc: 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: <b1f03d81-85db-4303-89ff-64440b6e1890@kernel.org>
Hi,
On 6/16/26 05:51, Krzysztof Kozlowski wrote:
> On 15/06/2026 17:47, Jernej Škrabec wrote:
>> Dne ponedeljek, 15. junij 2026 ob 06:28:54 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
>>> On 14/06/2026 16:08, Jernej Škrabec wrote:
>>>> Dne ponedeljek, 25. maj 2026 ob 14:10:38 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
>>>>> On 24/05/2026 23:33, Chen-Yu Tsai wrote:
>>>>>> 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.
>>>>>
>>>>> It explains why you want to make the changes but not why you cannot keep
>>>>> it backwards compatible.
>>>>
>>>> I guess it can be backward compatible, but I don't think it makes sense.
>>>> Yes, original driver implemented original DT bindings, but there is no node
>>>> which uses that binding. If there is no user of that, why would driver
>>>
>>> Did you check all out of tree users of the ABI? All vendor kernels,
>>> forks and all of them for which the ABI was made for?
>>
>> Since when do we care about out of tree users? I understand that drivers
>
> Since always? That is the meaning of ABI. Otherwise there is no point to
> discuss ABI at all. Why would it exist if you had all DTS inside kernel
> always matching the code?
In general I would agree with Krzysztof, merged binding means we need to
stick to it, but in this case I think that would be over the top. As
Jernej said, there are no users, since we didn't commit on the DTs, and
the DE33 graphics support in the kernel (bindings and code) is
incomplete: it's really just the mixer, but no other components (TCON or
output PHYs) required. So it never worked as such.
In hindsight we could say that we should have never merged the bindings
without having fully working, reviewed and accepted driver code, for the
whole display chain. Which we need to do because we create those
bindings based on reverse engineering efforts, not by looking at
documentation or design documents (which we don't have).
>> must support old device tree files. Once they work, compatibility must
>> be carried forward. But that's not the case here.
>>
>> In any case, vendor kernels have completely different DT structure. This
>> was developed independently from them. Take a look at [1] how BSP DT looks
>> like, specifically Display Engine node.
>>
>> Of course there are some distros which grab WIP patches from mailing lists
>> soon after they are available. For example, I know that Armbian carried old
>> WIP patches which used old ABI. However, such distros generally don't care
>> about exact solution and ditch patches as soon as proper solution is merged
>> upstream or even when better WIP patches come around. DT files in such
>> distros get updated alongside kernel, they are not hidden in firmware.
>>
>
> I am not talking about BSP. I am talking about out of tree users for
> which we defined the ABI and called it that way.
If you are looking for DT users outside of the Linux kernel, this is the
result of a quick check (list of users from ChatGPT, checks by myself
with git clone/git grep):
Zephyr RTOS: no graphics support
FreeBSD: no H616 support
OpenBSD: no H616 graphics support
NetBSD: no H616 support
U-Boot: no H616 graphics support
Barebox: no H616 support
TF-A: no graphics support
OP-TEE: no (Allwinner) graphics support
EDK2: no Allwinner support
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: Nicolai Buchwitz @ 2026-06-16 13:37 UTC (permalink / raw)
To: Andrea della Porta
Cc: netdev, Theo Lebrun, Nicolas Ferre, Claudiu Beznea, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel, linux-arm-kernel, linux-rpi-kernel, Lukasz Raczylo,
Steffen Jaeckel
In-Reply-To: <468f480454a314303bac6a54780b153f689f2267.1781598350.git.andrea.porta@suse.com>
On 16.6.2026 15:23, Andrea della Porta wrote:
> From: Lukasz Raczylo <lukasz@raczylo.com>
>
> The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on
> the TX queue.
> While the exact root cause is not yet fully understood, it is likely
> related to a hardware issue where a TSTART write to the NCR register
> is missed, preventing the transmission from being kicked off.
>
> Implement a timeout callback to handle TX queue stalls, triggering the
> existing restart mechanism to recover.
>
> Link:
> https://lore.kernel.org/all/20260514215459.36109-1-lukasz@raczylo.com/
> Fixes: dc110d1b23564 ("net: cadence: macb: Add support for Raspberry Pi
> RP1 ethernet controller")
> Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
> Co-developed-by: Steffen Jaeckel <sjaeckel@suse.de>
> Signed-off-by: Steffen Jaeckel <sjaeckel@suse.de>
> Co-developed-by: Andrea della Porta <andrea.porta@suse.com>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
>
> CHANGES IN v2:
>
> - dropped the rate-limited log message
> - avoid incrementing tx_error as this is per packet
>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index a12aa21244e83..fd282a1700fb9 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -4522,6 +4522,13 @@ static int macb_setup_tc(struct net_device *dev,
> enum tc_setup_type type,
> }
> }
>
> +static void macb_tx_timeout(struct net_device *dev, unsigned int q)
> +{
> + struct macb *bp = netdev_priv(dev);
> +
> + macb_tx_restart(&bp->queues[q]);
> +}
> +
> static const struct net_device_ops macb_netdev_ops = {
> .ndo_open = macb_open,
> .ndo_stop = macb_close,
> @@ -4540,6 +4547,7 @@ static const struct net_device_ops
> macb_netdev_ops = {
> .ndo_hwtstamp_set = macb_hwtstamp_set,
> .ndo_hwtstamp_get = macb_hwtstamp_get,
> .ndo_setup_tc = macb_setup_tc,
> + .ndo_tx_timeout = macb_tx_timeout,
> };
>
> /* Configure peripheral capabilities according to device tree
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Thanks,
Nicolai
^ permalink raw reply
* Re: [PATCH v3 6/7] KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
From: Vincent Donnefort @ 2026-06-16 13:26 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260616105417.2578670-9-sebastianene@google.com>
On Tue, Jun 16, 2026 at 10:54:15AM +0000, Sebastian Ene wrote:
> Allow FF-A notification GET messages to be proxied from the pKVM
> hypervisor to Trustzone and enforce MBZ/SBZ fields.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index fcfaa441770d..549250ff8f82 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -715,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_MEM_DONATE:
> case FFA_MEM_RETRIEVE_REQ:
> /* Optional notification interfaces added in FF-A 1.1 */
> - case FFA_NOTIFICATION_GET:
> case FFA_NOTIFICATION_INFO_GET:
> /* Optional interfaces added in FF-A 1.2 */
> case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> @@ -1001,6 +1000,26 @@ static void do_ffa_notif_set(struct arm_smccc_1_2_regs *res,
> arm_smccc_1_2_smc(args, res);
> }
>
> +static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, flags, ctxt, 2);
> + struct arm_smccc_1_2_regs *args;
> +
> + if (ffa_check_unused_args_sbz(ctxt, 3)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
Shall we check that the endpoint ID is HOST_FFA_ID here?
> +
> + if (flags & GENMASK(31, 4)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + args = (void *)&ctxt->regs.regs[0];
> + arm_smccc_1_2_smc(args, res);
> +}
> +
> bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> {
> struct arm_smccc_1_2_regs res;
> @@ -1072,6 +1091,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_NOTIFICATION_SET:
> do_ffa_notif_set(&res, host_ctxt);
> goto out_handled;
> + case FFA_NOTIFICATION_GET:
> + do_ffa_notif_get(&res, host_ctxt);
> + goto out_handled;
> }
>
> if (ffa_call_supported(func_id))
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Shanker Donthineni @ 2026-06-16 13:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Catalin Marinas, Vladimir Murzin,
linux-arm-kernel@lists.infradead.org, Mark Rutland,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Vikram Sethi, Jason Sequeira
In-Reply-To: <20260612124825.GF1962447@nvidia.com>
Hi Will,
On 6/12/2026 7:48 AM, Jason Gunthorpe wrote:
> On Thu, Jun 11, 2026 at 08:13:48PM -0500, Shanker Donthineni wrote:
>
>> For the scalar MMIO helpers, the workaround promotes the raw writes to
>> store-release on affected CPUs as v1/v2 shown below. For the memcpy-toIO
>> helpers, could you please clarify the specific reason for adding a dmb despite
>> the documented no-ordering contract? Is the concern that some drivers may
>> be relying on ordering across memcpy_toio_*() today even though the API
>> does not guarantee it, and that we should cover those cases defensively?
> I think given how arm implements them today the iocopy's are actually
> the _relaxed variations.. I wonder if this matters to any user?
Following Jason's observation that on arm64 the memcpy_toio()
/__iowrite{32,64}_copy() helpers are effectively the relaxed
(write-combining) variants, I'd like to settle one open point before
posting v4: should the workaround also promote dgh() > dmb on affected
CPUs (now Olympus core), or leave dgh() as a plain hint?
If you'd still prefer the dmb defensively, to cover drivers that may
rely on ordering across memcpy_toio() today despite the relaxed
contract, I'm happy to fold it into v4.
Please let me know how you'd like me to proceed.
-Shanker
^ permalink raw reply
* [PATCH v2] net: macb: add TX stall timeout callback to recover from lost TSTART write
From: Andrea della Porta @ 2026-06-16 13:23 UTC (permalink / raw)
To: netdev, Theo Lebrun, Andrea della Porta, Nicolas Ferre,
Claudiu Beznea, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, Nicolai Buchwitz
Cc: Lukasz Raczylo, Steffen Jaeckel
From: Lukasz Raczylo <lukasz@raczylo.com>
The MACB found in the Raspberry Pi RP1 suffers from sporadic stalls on
the TX queue.
While the exact root cause is not yet fully understood, it is likely
related to a hardware issue where a TSTART write to the NCR register
is missed, preventing the transmission from being kicked off.
Implement a timeout callback to handle TX queue stalls, triggering the
existing restart mechanism to recover.
Link: https://lore.kernel.org/all/20260514215459.36109-1-lukasz@raczylo.com/
Fixes: dc110d1b23564 ("net: cadence: macb: Add support for Raspberry Pi RP1 ethernet controller")
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
Co-developed-by: Steffen Jaeckel <sjaeckel@suse.de>
Signed-off-by: Steffen Jaeckel <sjaeckel@suse.de>
Co-developed-by: Andrea della Porta <andrea.porta@suse.com>
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
---
CHANGES IN v2:
- dropped the rate-limited log message
- avoid incrementing tx_error as this is per packet
---
drivers/net/ethernet/cadence/macb_main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a12aa21244e83..fd282a1700fb9 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4522,6 +4522,13 @@ static int macb_setup_tc(struct net_device *dev, enum tc_setup_type type,
}
}
+static void macb_tx_timeout(struct net_device *dev, unsigned int q)
+{
+ struct macb *bp = netdev_priv(dev);
+
+ macb_tx_restart(&bp->queues[q]);
+}
+
static const struct net_device_ops macb_netdev_ops = {
.ndo_open = macb_open,
.ndo_stop = macb_close,
@@ -4540,6 +4547,7 @@ static const struct net_device_ops macb_netdev_ops = {
.ndo_hwtstamp_set = macb_hwtstamp_set,
.ndo_hwtstamp_get = macb_hwtstamp_get,
.ndo_setup_tc = macb_setup_tc,
+ .ndo_tx_timeout = macb_tx_timeout,
};
/* Configure peripheral capabilities according to device tree
--
2.35.3
^ permalink raw reply related
* Re: [PATCH v3 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
From: Vincent Donnefort @ 2026-06-16 13:06 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260616105417.2578670-6-sebastianene@google.com>
On Tue, Jun 16, 2026 at 10:54:12AM +0000, Sebastian Ene wrote:
> Verify the arguments of the FF-A notification bind call and forward the
> message to Trustzone.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index dc7496ec295f..3d8ed829f558 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -42,6 +42,8 @@
> */
> #define HOST_FFA_ID 0
>
> +#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
> +
> /*
> * A buffer to hold the maximum descriptor size we can see from the host,
> * which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
> @@ -713,7 +715,6 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_MEM_DONATE:
> case FFA_MEM_RETRIEVE_REQ:
> /* Optional notification interfaces added in FF-A 1.1 */
> - case FFA_NOTIFICATION_BIND:
> case FFA_NOTIFICATION_UNBIND:
> case FFA_NOTIFICATION_SET:
> case FFA_NOTIFICATION_GET:
> @@ -929,6 +930,32 @@ static void do_ffa_notif_bitmap(struct arm_smccc_1_2_regs *res,
> hyp_smccc_1_2_smc(args, res);
> }
>
> +static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, endp_id, ctxt, 1);
> + DECLARE_REG(u32, flags, ctxt, 2);
> + struct arm_smccc_1_2_regs *args;
> +
> + if (ffa_check_unused_args_sbz(ctxt, 5)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
"A Receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
notifications to the Sender"
Does that mean that if the host issues a FFA_NOTIFICATION_BIND it is the
"Receiver" and not the "Sender"?
(Same for unbind)
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (flags > 1) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + args = (void *)&ctxt->regs.regs[0];
> + hyp_smccc_1_2_smc(args, res);
> +}
> +
> bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> {
> struct arm_smccc_1_2_regs res;
> @@ -991,6 +1018,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_NOTIFICATION_BITMAP_DESTROY:
> do_ffa_notif_bitmap(&res, host_ctxt);
> goto out_handled;
> + case FFA_NOTIFICATION_BIND:
> + do_ffa_notif_bind(&res, host_ctxt);
> + goto out_handled;
> }
>
> if (ffa_call_supported(func_id))
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v3 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Vincent Donnefort @ 2026-06-16 13:00 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260616105417.2578670-2-sebastianene@google.com>
On Tue, Jun 16, 2026 at 10:54:08AM +0000, Sebastian Ene wrote:
> Introduce a helper method ffa_check_unused_args_sbz to enforce strict
> arguments checking when the hypervisor acts as a relayer between the
> host and Trustzone.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 47 +++++++++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 1af722771178..c723a21006aa 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -71,6 +71,18 @@ static u32 hyp_ffa_version;
> static bool has_version_negotiated;
> static hyp_spinlock_t version_lock;
>
> +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> +{
> + int reg;
> +
> + for (reg = first_reg; reg < 17; reg++) {
Hum, should it be reg <= 17?
> + if (cpu_reg(ctxt, reg))
> + return true;
> + }
> +
> + return false;
> +}
> +
[...]
^ permalink raw reply
* Re: [PATCH] arm64: kgdb: Fix interrupt-induced single-step exception
From: Mark Rutland @ 2026-06-16 12:54 UTC (permalink / raw)
To: liuqiqi
Cc: Catalin Marinas, linux-kernel, Tongbo Wei, Will Deacon,
linux-arm-kernel
In-Reply-To: <20260615052903.207943-1-liuqiqi@kylinos.cn>
On Mon, Jun 15, 2026 at 01:29:03PM +0800, liuqiqi@kylinos.cn wrote:
> From: Qiqi Liu <liuqiqi@kylinos.cn>
>
> After entering kdb due to breakpoint, when we execute 'ss' or 'go'
> (will delay installing breakpoints, do single-step first),
> and it will enter kdb again.
> We found that due to context switching caused by interrupt,
> the instruction at ss is no longer the original breakpoint instruction.
>
> Before the patch:
> [root@localhost ~]# echo g > /proc/sysrq-trigger
> Entering kdb (current=0xffff030004f2bc00, pid 8818) on processor 15 due to Keyboard Entry
> [15]kdb> bp sysctl_vm_numa_stat_handler
> Instruction(i) BP #0 at 0xffffae550650c810 (sysctl_vm_numa_stat_handler)
> is enabled addr at 0xffffae550650c810, hardtype=0 installed=0
> [15]kdb> g
> [root@localhost ~]# echo 1 > /proc/sys/vm/numa_stat
> Entering kdb (current=0xffff030004f2bc00, pid 8818) on processor 12 due to Breakpoint @ 0xffffae550650c810
> [12]kdb> g
> Entering kdb (current=0xffff030004f2bc00, pid 8818) on processor 12 due to Breakpoint @ 0xffffae550650c810
> [12]kdb> g
>
> After the patch:
> [root@localhost ~]# echo g > /proc/sysrq-trigger
> Entering kdb (current=0xfffff010012c36400, pid 6488) on processor 41 due to Keyboard Entry
> [41]kdb> bp sysctl_vm_numa_stat_handler
> Instruction(i) BP #0 at 0xfffffd1768c2dc7c8 (sysctl_vm_numa_stat_handler)
> is enabled addr at ffffdf1768c2dc7c8, hardtype=0 installed=0
> [41]kdb> g
> [root@localhost ~]# echo 1 > /proc/sys/vm/numa_stat
> Entering kdb (current=0xfffff010012c36400, pid 6488) on processor 7 due to Breakpoint @ 0xfffffd1768c2dc7c8
> [7]kdb> g
> [root@localhost ~]#
>
> Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support")
> Co-developed-by: Tongbo Wei <kf.weitongbo@h3c.com>
> Signed-off-by: Tongbo Wei <kf.weitongbo@h3c.com>
> Signed-off-by: Qiqi Liu <liuqiqi@kylinos.cn>
> ---
> arch/arm64/kernel/kgdb.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
> index 968324a79a89..e9a246a0c34f 100644
> --- a/arch/arm64/kernel/kgdb.c
> +++ b/arch/arm64/kernel/kgdb.c
> @@ -101,6 +101,8 @@ struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] = {
> { "fpcr", 4, -1 },
> };
>
> +static DEFINE_PER_CPU(unsigned int, kgdb_pstate);
> +
> char *dbg_get_reg(int regno, void *mem, struct pt_regs *regs)
> {
> if (regno >= DBG_MAX_REG_NUM || regno < 0)
> @@ -207,6 +209,8 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
> err = 0;
> break;
> case 's':
> + __this_cpu_write(kgdb_pstate, linux_regs->pstate);
> + linux_regs->pstate |= PSR_I_BIT;
> /*
> * Update step address value with address passed
> * with step packet.
> @@ -252,9 +256,17 @@ NOKPROBE_SYMBOL(kgdb_compiled_brk_handler);
>
> int kgdb_single_step_handler(struct pt_regs *regs, unsigned long esr)
> {
> + unsigned int pstate;
> if (!kgdb_single_step)
> return DBG_HOOK_ERROR;
>
> + /* restore interrupt mask status */
> + pstate = __this_cpu_read(kgdb_pstate);
> + if (pstate & PSR_I_BIT)
> + regs->pstate |= PSR_I_BIT;
> + else
> + regs->pstate &= ~PSR_I_BIT;
I don't think this is sufficient; see the comments from last time this
approach was proposed:
https://lore.kernel.org/linux-arm-kernel/aNPiUbdRhaRklebF@J2N7QTR9R3/
I don't think we can solve this without enlightening the entry code.
Mark.
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] net: ti: icssg-prueth: Add ethtool ops for Frame Preemption MAC Merge
From: Meghana Malladi @ 2026-06-16 12:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: elfring, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, arnd, basharath, afd, parvathi, vladimir.oltean,
rogerq, danishanwar, pabeni, edumazet, davem, andrew+netdev,
linux-arm-kernel, netdev, linux-kernel, srk, vigneshr
In-Reply-To: <20260615163932.50bb3df0@kernel.org>
Hi Jakub,
On 6/16/26 05:09, Jakub Kicinski wrote:
> On Mon, 15 Jun 2026 16:10:41 -0700 Jakub Kicinski wrote:
>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> index 5ec0b38e0c67..8073deac35c3 100644
>>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> @@ -189,6 +187,11 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
>>> ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED),
>>> ICSSG_PA_STATS(FW_INF_DROP_NOTAG),
>>> ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER),
>>> + ICSSG_PA_STATS(FW_PREEMPT_BAD_FRAG),
>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_ERR),
>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_TX),
>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_OK),
>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_RX),
>>> ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR),
>>> ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF),
>>> ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF),
>>
>> [Medium]
>> Are these five new entries duplicating values that already have a
>> standard uAPI?
>>
>> The same five firmware counters are exposed through the new
>> .get_mm_stats callback as the standardized MAC Merge stats
>> (MACMergeFrameAssOkCount, MACMergeFrameAssErrorCount, MACMergeFragCountRx,
>> MACMergeFragCountTx, MACMergeFrameSmdErrorCount in struct
>> ethtool_mm_stats), and adding them to icssg_all_pa_stats[] also
>> publishes them via emac_get_strings() / emac_get_ethtool_stats() as
>> ethtool -S strings.
>>
>> Documentation/networking/statistics.rst describes ethtool -S as the
>> private-driver-stats interface; counters that have a standard uAPI are
>> expected to flow only through that uAPI.
>>
>> Could the firmware-register lookup table used by emac_get_stat_by_name()
>> be separated from the ethtool -S string table, so the new preemption
>> counters feed get_mm_stats without also showing up under ethtool -S?
>
> This -- not sure about the other complaints but this one looks legit.
I agree that this is legit, but right now there is no other place holder
other than pa stats to put the mac merge firmware counters. I believe
the effort needs to go in re-structuring the hardware and firmware stats
implementation to address this issue.
^ permalink raw reply
* Re: [PATCH 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-16 12:53 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260610153329.937833-2-v@baodeep.com>
On Wed, 10 Jun 2026 17:32:10 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
Sigh... Ok let's try this. This limits users of shared pins to using them from
process context exclusively but maybe there is in fact no need to do it from
atomic context. After all: bit-banging can't work if we're using the voting
mechanism.
>
> drivers/gpio/gpio-shared-proxy.c | 43 +++++++-------------------------
> drivers/gpio/gpiolib-shared.c | 9 ++-----
> drivers/gpio/gpiolib-shared.h | 31 +++++++++--------------
> 3 files changed, 23 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpio/gpio-shared-proxy.c b/drivers/gpio/gpio-shared-proxy.c
> index 6941e4be6cf1..856e5b9d6163 100644
> --- a/drivers/gpio/gpio-shared-proxy.c
> +++ b/drivers/gpio/gpio-shared-proxy.c
> @@ -109,7 +109,7 @@ static void gpio_shared_proxy_free(struct gpio_chip *gc, unsigned int offset)
>
> if (proxy->voted_high) {
> ret = gpio_shared_proxy_set_unlocked(proxy,
> - shared_desc->can_sleep ? gpiod_set_value_cansleep : gpiod_set_value, 0);
> + gpiod_set_value_cansleep, 0);
> if (ret)
> dev_err(proxy->dev,
> "Failed to unset the shared GPIO value on release: %d\n", ret);
> @@ -222,13 +222,6 @@ static int gpio_shared_proxy_direction_output(struct gpio_chip *gc,
> return gpio_shared_proxy_set_unlocked(proxy, gpiod_direction_output, value);
> }
>
> -static int gpio_shared_proxy_get(struct gpio_chip *gc, unsigned int offset)
> -{
> - struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
> -
> - return gpiod_get_value(proxy->shared_desc->desc);
> -}
> -
> static int gpio_shared_proxy_get_cansleep(struct gpio_chip *gc,
> unsigned int offset)
> {
> @@ -237,29 +230,15 @@ static int gpio_shared_proxy_get_cansleep(struct gpio_chip *gc,
> return gpiod_get_value_cansleep(proxy->shared_desc->desc);
> }
>
> -static int gpio_shared_proxy_do_set(struct gpio_shared_proxy_data *proxy,
> - int (*set_func)(struct gpio_desc *desc, int value),
> - int value)
> -{
> - guard(gpio_shared_desc_lock)(proxy->shared_desc);
> -
> - return gpio_shared_proxy_set_unlocked(proxy, set_func, value);
> -}
> -
> -static int gpio_shared_proxy_set(struct gpio_chip *gc, unsigned int offset,
> - int value)
> -{
> - struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
> -
> - return gpio_shared_proxy_do_set(proxy, gpiod_set_value, value);
> -}
> -
> static int gpio_shared_proxy_set_cansleep(struct gpio_chip *gc,
> unsigned int offset, int value)
> {
> struct gpio_shared_proxy_data *proxy = gpiochip_get_data(gc);
>
> - return gpio_shared_proxy_do_set(proxy, gpiod_set_value_cansleep, value);
> + guard(gpio_shared_desc_lock)(proxy->shared_desc);
> +
> + return gpio_shared_proxy_set_unlocked(proxy, gpiod_set_value_cansleep,
> + value);
> }
>
> static int gpio_shared_proxy_get_direction(struct gpio_chip *gc,
> @@ -302,20 +281,16 @@ static int gpio_shared_proxy_probe(struct auxiliary_device *adev,
> gc->label = dev_name(dev);
> gc->parent = dev;
> gc->owner = THIS_MODULE;
> - gc->can_sleep = shared_desc->can_sleep;
> + /* Always a sleeping gpiochip: see the lock comment in gpiolib-shared.h. */
> + gc->can_sleep = true;
>
> gc->request = gpio_shared_proxy_request;
> gc->free = gpio_shared_proxy_free;
> gc->set_config = gpio_shared_proxy_set_config;
> gc->direction_input = gpio_shared_proxy_direction_input;
> gc->direction_output = gpio_shared_proxy_direction_output;
> - if (gc->can_sleep) {
> - gc->set = gpio_shared_proxy_set_cansleep;
> - gc->get = gpio_shared_proxy_get_cansleep;
> - } else {
> - gc->set = gpio_shared_proxy_set;
> - gc->get = gpio_shared_proxy_get;
> - }
> + gc->set = gpio_shared_proxy_set_cansleep;
> + gc->get = gpio_shared_proxy_get_cansleep;
> gc->get_direction = gpio_shared_proxy_get_direction;
> gc->to_irq = gpio_shared_proxy_to_irq;
>
> diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
> index de72776fb154..495bd3d0ddf0 100644
> --- a/drivers/gpio/gpiolib-shared.c
> +++ b/drivers/gpio/gpiolib-shared.c
> @@ -627,8 +627,7 @@ static void gpio_shared_release(struct kref *kref)
>
> shared_desc = entry->shared_desc;
> gpio_device_put(shared_desc->desc->gdev);
> - if (shared_desc->can_sleep)
> - mutex_destroy(&shared_desc->mutex);
> + mutex_destroy(&shared_desc->mutex);
> kfree(shared_desc);
> entry->shared_desc = NULL;
> }
> @@ -659,11 +658,7 @@ gpiod_shared_desc_create(struct gpio_shared_entry *entry)
> }
>
> shared_desc->desc = &gdev->descs[entry->offset];
> - shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> - if (shared_desc->can_sleep)
> - mutex_init(&shared_desc->mutex);
> - else
> - spin_lock_init(&shared_desc->spinlock);
> + mutex_init(&shared_desc->mutex);
>
> return shared_desc;
> }
> diff --git a/drivers/gpio/gpiolib-shared.h b/drivers/gpio/gpiolib-shared.h
> index 15e72a8dcdb1..5c725118b1af 100644
> --- a/drivers/gpio/gpiolib-shared.h
> +++ b/drivers/gpio/gpiolib-shared.h
> @@ -6,7 +6,6 @@
> #include <linux/cleanup.h>
> #include <linux/lockdep.h>
> #include <linux/mutex.h>
> -#include <linux/spinlock.h>
>
> struct gpio_device;
> struct gpio_desc;
> @@ -42,35 +41,29 @@ static inline int gpio_shared_add_proxy_lookup(struct device *consumer,
>
> struct gpio_shared_desc {
> struct gpio_desc *desc;
> - bool can_sleep;
> unsigned long cfg;
> unsigned int usecnt;
> unsigned int highcnt;
> - union {
> - struct mutex mutex;
> - spinlock_t spinlock;
> - };
> + struct mutex mutex; /* serializes all proxy operations on this descriptor */
> };
>
> struct gpio_shared_desc *devm_gpiod_shared_get(struct device *dev);
>
> +/*
> + * Under this lock the proxy may call gpiod_set_config()/gpiod_direction_*(),
> + * which can reach pinctrl paths that take a mutex (e.g. gpiod_set_config() ->
> + * gpiochip_generic_config() -> pinctrl_gpio_set_config()), independent of the
> + * underlying chip's can_sleep. A spinlock would run that sleeping call from
> + * atomic context, so the descriptor lock must be a mutex and the proxy
> + * gpiochip is therefore sleeping (can_sleep=true).
> + */
> DEFINE_LOCK_GUARD_1(gpio_shared_desc_lock, struct gpio_shared_desc,
> - if (_T->lock->can_sleep)
> - mutex_lock(&_T->lock->mutex);
> - else
> - spin_lock_irqsave(&_T->lock->spinlock, _T->flags),
> - if (_T->lock->can_sleep)
> - mutex_unlock(&_T->lock->mutex);
> - else
> - spin_unlock_irqrestore(&_T->lock->spinlock, _T->flags),
> - unsigned long flags)
> + mutex_lock(&_T->lock->mutex),
> + mutex_unlock(&_T->lock->mutex))
Just drop these wrappers altogether then, let's open-code mutex locking in
the proxy.
>
> static inline void gpio_shared_lockdep_assert(struct gpio_shared_desc *shared_desc)
> {
> - if (shared_desc->can_sleep)
> - lockdep_assert_held(&shared_desc->mutex);
> - else
> - lockdep_assert_held(&shared_desc->spinlock);
> + lockdep_assert_held(&shared_desc->mutex);
Same here, move it to the proxy.
> }
>
> #endif /* __LINUX_GPIO_SHARED_H */
> --
> 2.54.0
>
>
>
Bart
^ permalink raw reply
* Re: [PATCH v3 7/7] KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
From: Vincent Donnefort @ 2026-06-16 12:47 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260616105417.2578670-10-sebastianene@google.com>
On Tue, Jun 16, 2026 at 10:54:16AM +0000, Sebastian Ene wrote:
> Allow the host to query the FF-A notifiction status and proxy the info
> get message to Trustzone. Make sure that the SBZ fields are enforced.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 549250ff8f82..dac30a5fcf5a 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -714,8 +714,6 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_RXTX_MAP:
> case FFA_MEM_DONATE:
> case FFA_MEM_RETRIEVE_REQ:
> - /* Optional notification interfaces added in FF-A 1.1 */
> - case FFA_NOTIFICATION_INFO_GET:
> /* Optional interfaces added in FF-A 1.2 */
> case FFA_MSG_SEND_DIRECT_REQ2: /* Optional per 7.5.1 */
> case FFA_MSG_SEND_DIRECT_RESP2: /* Optional per 7.5.1 */
> @@ -1020,6 +1018,20 @@ static void do_ffa_notif_get(struct arm_smccc_1_2_regs *res,
> arm_smccc_1_2_smc(args, res);
> }
>
> +static void do_ffa_notif_info_get(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + struct arm_smccc_1_2_regs *args;
> +
> + if (ffa_check_unused_args_sbz(ctxt, 1)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + args = (void *)&ctxt->regs.regs[0];
> + arm_smccc_1_2_smc(args, res);
hyp_smccc_1_2_smc()
ditto FFA_NOTIFICATION_GET, FFA_NOTIFICATION_SET, FFA_NOTIFICATION_UNBIND
> +}
> +
> bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> {
> struct arm_smccc_1_2_regs res;
> @@ -1094,6 +1106,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_NOTIFICATION_GET:
> do_ffa_notif_get(&res, host_ctxt);
> goto out_handled;
> + case FFA_NOTIFICATION_INFO_GET:
> + do_ffa_notif_info_get(&res, host_ctxt);
> + goto out_handled;
> }
>
> if (ffa_call_supported(func_id))
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Clean up RX queues in airoha_dev_stop
From: Lorenzo Bianconi @ 2026-06-16 12:45 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161160256.2165161.14322392784449633554@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
On Jun 16, Wayen Yan wrote:
> When the last port is stopped, airoha_dev_stop() clears TX queues
> but neglects to clean up RX queues. This can lead to:
> - RX ring buffer descriptors remaining valid after device close
> - Potential DMA synchronization issues on device reopen
> - Risk of use-after-free if pages are freed while DMA is still active
>
> Add cleanup loop for RX queues to mirror the TX queue cleanup,
> ensuring symmetric resource management.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen Yan <win847@gmail.com>
when you send a new revision:
- please add a note of what you changed with respect to the previous one.
- please give some time to reviewers to take a look to the previous revision.
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..9ca5bbf64d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1771,6 +1771,13 @@ static int airoha_dev_stop(struct net_device *dev)
>
> airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> }
> +
> + for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
> + if (!qdma->q_rx[i].ndesc)
> + continue;
> +
> + airoha_qdma_cleanup_rx_queue(&qdma->q_rx[i]);
> + }
> }
I do not think this patch is needed since there is no point to remove all the
RX buffers from the hw RX queues stopping the device, this is necessary just
removing the module (I think we can avoid it for TX too, I have a patch for it
I need to post).
Moreover, doing so, when the device is opened again, RX queues will be empty.
Regards,
Lorenzo
>
> return 0;
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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