* Re: [PATCH 00/15] drm/tidss: Add BeagleY-AI display support (and some more)
From: Swamil Jain @ 2026-05-11 13:19 UTC (permalink / raw)
To: Tomi Valkeinen, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Aradhya Bhatia,
Nishanth Menon, Vignesh Raghavendra, Devarsh Thakkar,
Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Jayesh Choudhary, Aradhya Bhatia, Andrew Davis
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
On 20-04-2026 18:24, Tomi Valkeinen wrote:
> This series aims to add display support for all display interfaces on
> BeagleY-AI board. More generally, it adds display support for TI AM62P,
> J722S, and related SoCs, and, as a bit extra, improves AM62L's DPI
> handling.
>
> The main topics to highlight:
>
> - The ti,am625-dss-dpi0-clk-ctrl feels a bit like a hack.
> But it is a single quirk register, among other registers that belong
> to either the firmware or other drivers. So what other options are
> there? This has already been discussed e.g. in
> https://lore.kernel.org/all/20250730-fix-edge-handling-v1-0-1bdfb3fe7922%40bootlin.com/
> without proper conclusion.
>
> - The tidss OLDI support will now use auxiliary device/driver. This seems
> to solve quite neatly the requirement to have a power-domain for each
> OLDI. The main issue that remains is that on AM62P (and similar) we
> will have three OLDI TX DT nodes, even if there are only two in the
> hardware.
>
> With this series one can use the HDMI output on BeagleY-AI. I have also
> tested the DSI output with Raspberry Pi's 7" DSI display, and OLDI
> output with an oscilloscope (I don't have a suitable OLDI panel).
>
> Tomi
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
The series is tested on TI's AM62P[1] SoC and tested HDMI display and
audio output with BeagleY-AI(AM67A SoC[2]).
Display panels used:
--------------------
DSI Panel: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
OLDI Panel: https://www.ti.com/tool/SK-LCD1
HDMI Panel: https://www.viewsonic.com/in/products/lcd/VA1655-3
Test branch:
https://github.com/jainswamil/linux-next/tree/AM62P_J722S_BEAGLEY_AI_DSS_V1_TEST
Got some DT check warnings with the above test branch[3].
Links
[1]: https://www.ti.com/product/AM62P
[2]: https://www.ti.com/product/AM67A
[3]: https://gist.github.com/jainswamil/945a9859c0f75b41ef21abeede405b2e
Tested-by: Swamil Jain <s-jain1@ti.com>
> Andrew Davis (1):
> arm64: dts: ti: beagley-ai: Enable HDMI display and audio
>
> Jayesh Choudhary (1):
> arm64: dts: ti: k3-am62p-j722s-common-main: Add support for DSS
>
> Swamil Jain (1):
> drm/tidss: Add support for AM62P display subsystem
>
> Tomi Valkeinen (12):
> dt-bindings: display: ti: Move ti,am62l-dss binding to a new binding file
> dt-bindings: display: ti,am65x-dss: Simplify binding
> dt-bindings: mfd: syscon: Add ti,am625-dss-dpi0-clk-ctrl compatible
> dt-bindings: display: ti,am625-oldi: Add optional power-domain for OLDI
> dt-bindings: display: ti,am65x-dss: Add AM62P DSS
> drm/tidss: Remove extra pm_runtime_mark_last_busy
> drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
> drm/tidss: Add mechanism to detect DPI output
> drm/tidss: Add external data and sync signal edge configuration
> drm/tidss: Add support for DPIENABLE bit
> drm/tidss: oldi: Fix OLDI signal polarities
> drm/tidss: oldi: Convert OLDI to an aux driver
>
> .../bindings/display/ti/ti,am625-oldi.yaml | 4 +
> .../bindings/display/ti/ti,am62l-dss.yaml | 136 ++++++
> .../bindings/display/ti/ti,am65x-dss.yaml | 176 +++----
> Documentation/devicetree/bindings/mfd/syscon.yaml | 2 +
> MAINTAINERS | 1 +
> .../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 112 +++++
> arch/arm64/boot/dts/ti/k3-am62p.dtsi | 16 +
> arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 197 ++++++++
> arch/arm64/boot/dts/ti/k3-j722s.dtsi | 16 +
> drivers/gpu/drm/tidss/tidss_crtc.c | 10 +-
> drivers/gpu/drm/tidss/tidss_crtc.h | 4 +-
> drivers/gpu/drm/tidss/tidss_dispc.c | 46 +-
> drivers/gpu/drm/tidss/tidss_dispc.h | 5 +-
> drivers/gpu/drm/tidss/tidss_dispc_regs.h | 5 +
> drivers/gpu/drm/tidss/tidss_drv.c | 54 ++-
> drivers/gpu/drm/tidss/tidss_drv.h | 5 +-
> drivers/gpu/drm/tidss/tidss_kms.c | 55 ++-
> drivers/gpu/drm/tidss/tidss_oldi.c | 531 +++++++++++++++------
> drivers/gpu/drm/tidss/tidss_oldi.h | 8 +-
> 19 files changed, 1095 insertions(+), 288 deletions(-)
> ---
> base-commit: 3131ff5a117498bb4b9db3a238bb311cbf8383ce
> change-id: 20260420-beagley-ai-display-d7f634cde5f4
> prerequisite-message-id: <20260415110409.2577633-1-s-jain1@ti.com>
> prerequisite-patch-id: 654d90f9cddec8b41e6fb1b3776a632606fef88c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Jason Gunthorpe @ 2026-05-11 13:21 UTC (permalink / raw)
To: Robin Murphy
Cc: Joonwon Kang, Alexander.Grest, amhetre, baolu.lu, iommu, joro,
jpb, kees, linux-arm-kernel, linux-kernel, nicolinc, praan,
smostafa, will, jacob.jun.pan, easwar.hariharan, kevin.tian
In-Reply-To: <30eefd04-1d0f-45d8-b55d-e3e8d41a57ef@arm.com>
On Mon, May 11, 2026 at 01:39:06PM +0100, Robin Murphy wrote:
> On 2026-05-09 6:10 pm, Jason Gunthorpe wrote:
> > On Thu, May 07, 2026 at 09:58:51AM +0000, Joonwon Kang wrote:
> >
> > > By "similar instruction" on ARM, I guess you mean ST64BV0, which fetches
> > > the bottom 32 bits data from ACCDATA_EL1. Please let me know if you meant
> > > others as it will matter. If ST64BV0 is supported on ARM, however, it
> > > would mean that ST64B and ST64BV are also supported already according to
> > > the ID_AA64ISAR1_EL1's LS64 field. The latter 2 instructions are just to
> > > atomically store whatever user wants to a memory location without
> > > referring to ACCDATA_EL1 and all the 3 instructions can be run at EL0. So,
> > > the userspace driver would have enough capability to designate arbitrary
> > > PASID as it wants via the latter 2 instructions when communicating with
> > > multiple devices.
> >
> > IDK exactly what ARM did. IIRC on Intel ENQCMD forms a special
> > non-posted write TLP and the device can tell the TLP came from ENQCMD
> > and so it trusts the encoded PASID. ARM has to have done the same
> > thing - allowing anyone to forge the PASID by using a different
> > instruction misses the point of the Intel design.
>
> Yes, ACCDATA_EL1 is a privileged register neither writeable nor readable by
> userspace[1], so it should be functionally equivalent from an SVA point of
> view.
There is a bit more going on though, I think that is what Joonwon is
mentioning by asking about ST64B and ST64BV. I *think* the answer is:
- ST64B uses a posted write
- ST64BV can be restricted so EL0 cannot execute it, it uses a
non-posted write (AI tells me via EnASR)
- ST64BV0 can be used by EL0, always uses a non-posted write, and always
uses ACCDATA_EL1
Which is similar to Intel. The device only processes the PASID from a
non-posted write, and the CPU prevents userspace from forming
non-posted writes except through ST64BV0
> > Honestly, I'm not sure why they even implemented it. SMMUv3 can't do
> > the translation scheme required to use ENQCMD from a VM anyhow, so it
> > is pretty useless.
>
> Not sure what you mean there - indeed you can't do the SIOV thing of
> assigning individual ADIs to _different_ VMs, but there's still no reason
> you couldn't give the whole accelerator device to one VM, and run the "full"
> kernel driver in that VM to hand out ADIs to processes, same as for
> non-virtualised ST64BV0/ENQCMD usage. It's entirely usable, just not so
> "scalable".
Well yes, technically, but I'm not sure this is attractive in
practice.
The value of ENQCMD on Intel was it can eliminate any HW side
per-context state for simple HW like DMA engines, including for
virtualization.
You pay for that value with some performance loss, but it can be
attractive because of the universal scalability.
However complex devices don't seem to want to use it, once you have to
have per-context state for any other reason the performance downsides
of ENQCMD make it unappealing.
So, IDK, maybe some embedded on-chip device will find a way to make
good use of it, but also I'm not aware of any adoption on x86..
Jason
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
From: Pranjal Shrivastava @ 2026-05-11 13:21 UTC (permalink / raw)
To: Robin Murphy
Cc: Jason Gunthorpe, Nicolin Chen, Will Deacon, Joerg Roedel,
Jean-Philippe Brucker, Catalin Marinas, Mikołaj Lenczewski,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <4e129891-2f52-4bac-8e33-1fdde42fd29a@arm.com>
On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > On Fri, May 08, 2026 at 02:31:11PM +0100, Robin Murphy wrote:
> > > On 2026-05-08 2:12 pm, Pranjal Shrivastava wrote:
> > > > On Fri, May 08, 2026 at 09:35:50AM -0300, Jason Gunthorpe wrote:
> > > > > On Thu, May 07, 2026 at 10:30:14PM +0000, Pranjal Shrivastava wrote:
> > > > > > > @@ -92,6 +92,16 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
> > > > > > > target->data[1] = cpu_to_le64(virt_to_phys(mm->pgd) &
> > > > > > > CTXDESC_CD_1_TTB0_MASK);
> > > > > > > +
> > > > > > > + /*
> > > > > > > + * Enable Hardware Access and Dirty updates (DBM) if supported.
> > > > > > > + * This is safe to enable by default, as PTE_WRITE and PTE_DBM
> > > > > > > + * share the same bit.
> > > > > > > + */
> > > > > > > + if (master->smmu->features & ARM_SMMU_FEAT_HA)
> > > > > > > + target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> > > > > > > + if (master->smmu->features & ARM_SMMU_FEAT_HD)
> > > > > > > + target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> > > > > >
> > > > > > IIUC, we should be setting these if IO_PGTABLE_QUIRK_ARM_HD is present?
> > > > >
> > > > > SVA does not use IO_PGTABLE at all, and it directly constructs its own
> > > > > CD.
> > > > >
> > > > > No relation between those two flows.
> > > >
> > > > I understand that but I mean we need to know if the system supports
> > > > HTTU ? Like for SMMU we use the IO_PGTABLE_QUIRK, shouldn't we be
> > > > checking if the CPU's tables support HTTU?
> > > >
> > > > Are we assuming that if the SMMU IDR presents HTTU capability the MMU
> > > > would also have it? I think an unconditional enablement is risky as we
> > > > may not have system-wide HTTU support.
> > > >
> > > > If we look at arm_smmu_master_sva_supported, the driver already
> > > > maintains a strict agreement between the CPU and SMMU for SVA.
> > > > It checks sanitized CPU ID registers for things like PARANGE & ASIDBITS,
> > > > and it uses system_supports_bbml2_noabort() to decide whether to enable
> > > > FEAT_BBML2.
> > > >
> > > > Shouldn't we follow this exact same pattern for HTTU ?
> > > > We should probably be checking cpu_has_hw_af() (from asm/cpufeature.h)
> > > > in the SVA support check or here if we wanna enable HTTU.
> > >
> > > It might make sense to depend on CONFIG_ARM64_HW_AFDBM - when that is
> > > enabled, then IIRC we already expect to cope with some CPUs not supporting
> > > hardware updates, so it should still be fine for an SMMU to make them even
> > > if no CPU does. However, if it's disabled then I'm not sure if missing
> > > access flag faults (if SMMU HA silently sets them) might be an issue - for
> > > dirty, we'd just never put down the Writeable-Clean permission so enabling
> > > SMMU HD wouldn't do anything anyway.
> >
> > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > Since the fault handlers are already expecting HW-triggered updates?
> >
> > Which means our check would be something like:
> >
> > if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > if (smmu->features & FEAT_HA)
> > ...
> > }
> >
> > instead of cpu_has_hw_af()?
>
> Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> CPU doesn't support HAFDBS, so perhaps you were right the first time :)
>
Yea, I believe the cpu_has_hw_af() is the right gate.
> Although AFAICS from __cpu_setup(), ARM64_HW_AFDBM will still
> unconditionally enable TCR_EL1.HA on CPUs which do support it, so maybe it
> is OK anyway?
>
I believe cpu_has_hw_af() is still the safer gate for SVA. While
individual cores might turn on their local HA support, cpu_has_hw_af()
represents the sanitized system view.
In mismatched systems (where some cores support HAFDBS and others don't),
cpu_has_hw_af() will be false & mm shall default to software-managed AF/
Dirty for consistency across all threads. Enabling HTTU in the SMMU while
the kernel mm is in 'SW-Managed' mode could cause the SMMU to silently
flip bits that the kernel is expecting to handle via faults, leading to a
mismatch.
Thanks,
Praan
^ permalink raw reply
* [PATCH v12 2/5] regulator: Add support for MediaTek MT6373 SPMI PMIC Regulators
From: AngeloGioacchino Del Regno @ 2026-05-11 10:13 UTC (permalink / raw)
To: linux-mediatek
Cc: lee, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, lgirdwood, broonie, devicetree,
linux-kernel, linux-arm-kernel, kernel, wenst
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
Add a driver for the regulators found on the MediaTek MT6373 PMIC,
fully controlled by SPMI interface.
Similarly to MT6363, this PMIC regulates voltage with input range
of 2.6-5.0V, and features 10 buck converters and 25 LDOs.
This PMIC is usually found on board designs using the MT6991 or
MT8196 SoC, in combination with the MT6363 PMIC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/mt6373-regulator.c | 772 +++++++++++++++++++++
include/linux/regulator/mt6373-regulator.h | 161 +++++
4 files changed, 944 insertions(+)
create mode 100644 drivers/regulator/mt6373-regulator.c
create mode 100644 include/linux/regulator/mt6373-regulator.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index d71dac9436e3..d1ccc1da2f32 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -991,6 +991,16 @@ config REGULATOR_MT6370
This driver supports the control for DisplayBias voltages and one
general purpose LDO which is commonly used to drive the vibrator.
+config REGULATOR_MT6373
+ tristate "MT6373 SPMI PMIC regulator driver"
+ depends on SPMI
+ select REGMAP_SPMI
+ help
+ Say Y here to enable support for buck and LDO regulators found in
+ the MediaTek MT6373 SPMI PMIC and its variants.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
config REGULATOR_MT6380
tristate "MediaTek MT6380 PMIC"
depends on MTK_PMIC_WRAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 35639f3115fd..a0195e28c8e6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_REGULATOR_MT6359) += mt6359-regulator.o
obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
obj-$(CONFIG_REGULATOR_MT6363) += mt6363-regulator.o
obj-$(CONFIG_REGULATOR_MT6370) += mt6370-regulator.o
+obj-$(CONFIG_REGULATOR_MT6373) += mt6373-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
diff --git a/drivers/regulator/mt6373-regulator.c b/drivers/regulator/mt6373-regulator.c
new file mode 100644
index 000000000000..90672ae1eb80
--- /dev/null
+++ b/drivers/regulator/mt6373-regulator.c
@@ -0,0 +1,772 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2024 MediaTek Inc.
+// Copyright (c) 2025 Collabora Ltd
+// AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/devm-helpers.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/spmi.h>
+
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6373-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6373_REGULATOR_MODE_NORMAL 0
+#define MT6373_REGULATOR_MODE_FCCM 1
+#define MT6373_REGULATOR_MODE_LP 2
+#define MT6373_REGULATOR_MODE_ULP 3
+
+#define EN_SET_OFFSET 0x1
+#define EN_CLR_OFFSET 0x2
+
+#define OC_IRQ_ENABLE_DELAY_MS 10
+
+/* Unlock key for mode setting */
+#define MT6373_BUCK_TOP_UNLOCK_VALUE 0x5543
+
+enum {
+ MT6373_ID_VBUCK0,
+ MT6373_ID_VBUCK1,
+ MT6373_ID_VBUCK2,
+ MT6373_ID_VBUCK3,
+ MT6373_ID_VBUCK4,
+ MT6373_ID_VBUCK5,
+ MT6373_ID_VBUCK6,
+ MT6373_ID_VBUCK7,
+ MT6373_ID_VBUCK8,
+ MT6373_ID_VBUCK9,
+ MT6373_ID_VANT18,
+ MT6373_ID_VAUD18,
+ MT6373_ID_VAUX18,
+ MT6373_ID_VCN18IO,
+ MT6373_ID_VCN33_1,
+ MT6373_ID_VCN33_2,
+ MT6373_ID_VCN33_3,
+ MT6373_ID_VEFUSE,
+ MT6373_ID_VFP,
+ MT6373_ID_VIBR,
+ MT6373_ID_VIO28,
+ MT6373_ID_VMC,
+ MT6373_ID_VMCH,
+ MT6373_ID_VMCH_EINT_HIGH,
+ MT6373_ID_VMCH_EINT_LOW,
+ MT6373_ID_VRF09_AIF,
+ MT6373_ID_VRF12_AIF,
+ MT6373_ID_VRF13_AIF,
+ MT6373_ID_VRF18_AIF,
+ MT6373_ID_VRFIO18_AIF,
+ MT6373_ID_VSRAM_DIGRF_AIF,
+ MT6373_ID_VTP,
+ MT6373_ID_VUSB,
+};
+
+/**
+ * struct mt6373_regulator_info - MT6373 regulators information
+ * @desc: Regulator description structure
+ * @lp_mode_reg: Low Power mode register (normal/idle)
+ * @lp_mode_mask: Low Power mode regulator mask
+ * @modeset_reg: AUTO/PWM mode register
+ * @modeset_mask: AUTO/PWM regulator mask
+ * @oc_work: Delayed work for enabling overcurrent IRQ
+ * @hwirq: PMIC-Internal HW Interrupt for overcurrent event
+ * @virq: Mapped Interrupt for overcurrent event
+ */
+struct mt6373_regulator_info {
+ struct regulator_desc desc;
+ u16 lp_mode_reg;
+ u16 lp_mode_mask;
+ u16 modeset_reg;
+ u16 modeset_mask;
+ struct delayed_work oc_work;
+ u8 hwirq;
+ int virq;
+};
+
+#define MT6373_BUCK(match, vreg, min, max, step, en_reg, lp_reg, \
+ mset_reg, ocp_intn) \
+[MT6373_ID_##vreg] = { \
+ .desc = { \
+ .name = match, \
+ .supply_name = "vsys-"match, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6373_vreg_setclr_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6373_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = (max - min) / step + 1, \
+ .min_uV = min, \
+ .uV_step = step, \
+ .enable_reg = en_reg, \
+ .enable_mask = BIT(MT6373_PMIC_RG_BUCK_##vreg##_EN_BIT),\
+ .vsel_reg = MT6373_PMIC_RG_BUCK_##vreg##_VOSEL_ADDR, \
+ .vsel_mask = MT6373_PMIC_RG_BUCK_VOSEL_MASK, \
+ .of_map_mode = mt6373_map_mode, \
+ }, \
+ .lp_mode_reg = lp_reg, \
+ .lp_mode_mask = BIT(MT6373_PMIC_RG_BUCK_##vreg##_LP_BIT), \
+ .modeset_reg = mset_reg, \
+ .modeset_mask = BIT(MT6373_PMIC_RG_##vreg##_FCCM_BIT), \
+ .hwirq = ocp_intn, \
+}
+
+
+#define MT6373_LDO_L(match, vreg, in_sup, min, max, step, ocp_intn) \
+[MT6373_ID_##vreg] = { \
+ .desc = { \
+ .name = match, \
+ .supply_name = in_sup, \
+ .of_match = of_match_ptr(match), \
+ .ops = &mt6373_ldo_linear_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6373_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = (max - min) / step + 1, \
+ .min_uV = min, \
+ .uV_step = step, \
+ .enable_reg = MT6373_PMIC_RG_LDO_##vreg##_ADDR, \
+ .enable_mask = BIT(0), \
+ .vsel_reg = MT6373_PMIC_RG_##vreg##_VOSEL_ADDR, \
+ .vsel_mask = MT6373_PMIC_RG_##vreg##_VOSEL_MASK, \
+ .of_map_mode = mt6373_map_mode, \
+ }, \
+ .lp_mode_reg = MT6373_PMIC_RG_LDO_##vreg##_ADDR, \
+ .lp_mode_mask = BIT(1), \
+ .hwirq = ocp_intn, \
+}
+
+#define MT6373_LDO_VT_OPS(match, vreg, in_sup, vops, vrnum, ocp_intn) \
+[MT6373_ID_##vreg] = { \
+ .desc = { \
+ .name = match, \
+ .supply_name = in_sup, \
+ .of_match = of_match_ptr(match), \
+ .ops = &vops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6373_ID_##vreg, \
+ .owner = THIS_MODULE, \
+ .n_voltages = ARRAY_SIZE(ldo_volt_ranges##vrnum) * 11, \
+ .linear_ranges = ldo_volt_ranges##vrnum, \
+ .n_linear_ranges = ARRAY_SIZE(ldo_volt_ranges##vrnum), \
+ .linear_range_selectors_bitfield = ldos_cal_selectors, \
+ .enable_reg = MT6373_PMIC_RG_LDO_##vreg##_ADDR, \
+ .enable_mask = BIT(0), \
+ .vsel_reg = MT6373_PMIC_RG_##vreg##_VOCAL_ADDR, \
+ .vsel_mask = MT6373_PMIC_RG_LDO_VT_VOCALSEL_MASK, \
+ .vsel_range_reg = MT6373_PMIC_RG_##vreg##_VOSEL_ADDR, \
+ .vsel_range_mask = MT6373_PMIC_RG_LDO_VT_VOCALSEL_MASK, \
+ .of_map_mode = mt6373_map_mode, \
+ }, \
+ .lp_mode_reg = MT6373_PMIC_RG_LDO_##vreg##_ADDR, \
+ .lp_mode_mask = BIT(1), \
+ .hwirq = ocp_intn, \
+}
+
+#define MT6373_LDO_VT(match, vreg, inp, vrnum, ocp_intn) \
+ MT6373_LDO_VT_OPS(match, vreg, inp, mt6373_ldo_vtable_ops, \
+ vrnum, ocp_intn)
+
+#define MT6373_LDO_EI(match, vreg, inp, vrnum, ocp_intn) \
+ MT6373_LDO_VT_OPS(match, vreg, inp, mt6373_vmch_eint_ops, \
+ vrnum, ocp_intn)
+
+static const unsigned int ldos_cal_selectors[] = {
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
+};
+
+static const struct linear_range ldo_volt_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(1200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1500000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3400000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3500000, 0, 10, 10000)
+};
+
+static const struct linear_range ldo_volt_ranges2[] = {
+ REGULATOR_LINEAR_RANGE(1800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2400000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2500000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2600000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3300000, 0, 10, 10000)
+};
+
+static const struct linear_range ldo_volt_ranges3[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1400000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1500000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1600000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2100000, 0, 10, 10000)
+};
+
+static const struct linear_range ldo_volt_ranges4[] = {
+ REGULATOR_LINEAR_RANGE(1200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1500000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2500000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2600000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2700000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2800000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(2900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3300000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3400000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(3500000, 0, 10, 10000)
+};
+
+static const struct linear_range ldo_volt_ranges5[] = {
+ REGULATOR_LINEAR_RANGE(900000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1000000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1100000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1200000, 0, 10, 10000),
+ REGULATOR_LINEAR_RANGE(1300000, 0, 10, 10000),
+};
+
+static int mt6373_vreg_enable_setclr(struct regulator_dev *rdev)
+{
+ return regmap_write(rdev->regmap, rdev->desc->enable_reg + EN_SET_OFFSET,
+ rdev->desc->enable_mask);
+}
+
+static int mt6373_vreg_disable_setclr(struct regulator_dev *rdev)
+{
+ return regmap_write(rdev->regmap, rdev->desc->enable_reg + EN_CLR_OFFSET,
+ rdev->desc->enable_mask);
+}
+
+static inline unsigned int mt6373_map_mode(unsigned int mode)
+{
+ switch (mode) {
+ case MT6373_REGULATOR_MODE_NORMAL:
+ return REGULATOR_MODE_NORMAL;
+ case MT6373_REGULATOR_MODE_FCCM:
+ return REGULATOR_MODE_FAST;
+ case MT6373_REGULATOR_MODE_LP:
+ return REGULATOR_MODE_IDLE;
+ case MT6373_REGULATOR_MODE_ULP:
+ return REGULATOR_MODE_STANDBY;
+ default:
+ return REGULATOR_MODE_INVALID;
+ }
+}
+
+static int mt6373_vmch_eint_enable(struct regulator_dev *rdev)
+{
+ const struct regulator_desc *rdesc = rdev->desc;
+ unsigned int val;
+ int ret;
+
+ if (rdesc->id == MT6373_ID_VMCH_EINT_HIGH)
+ val = MT6373_PMIC_RG_LDO_VMCH_EINT_POL_BIT;
+ else
+ val = 0;
+
+ ret = regmap_update_bits(rdev->regmap,
+ MT6373_PMIC_RG_LDO_VMCH_EINT_ADDR,
+ MT6373_PMIC_RG_LDO_VMCH_EINT_POL_BIT, val);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(rdev->regmap,
+ MT6373_PMIC_RG_LDO_VMCH_ADDR,
+ rdesc->enable_mask);
+ if (ret)
+ return ret;
+
+ return regmap_set_bits(rdev->regmap, rdesc->enable_reg, rdesc->enable_mask);
+}
+
+static int mt6373_vmch_eint_disable(struct regulator_dev *rdev)
+{
+ const struct regulator_desc *rdesc = rdev->desc;
+ int ret;
+
+ ret = regmap_clear_bits(rdev->regmap,
+ MT6373_PMIC_RG_LDO_VMCH_ADDR,
+ rdesc->enable_mask);
+ if (ret)
+ return ret;
+
+ /* Wait for VMCH discharging */
+ usleep_range(1500, 1600);
+
+ return regmap_clear_bits(rdev->regmap, rdesc->enable_reg, rdesc->enable_mask);
+}
+
+static unsigned int mt6373_regulator_get_mode(struct regulator_dev *rdev)
+{
+ struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
+ unsigned int val;
+ int ret;
+
+ if (info->modeset_reg) {
+ ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+ if (ret) {
+ dev_err(&rdev->dev, "Failed to get mt6373 mode: %d\n", ret);
+ return ret;
+ }
+
+ if (val & info->modeset_mask)
+ return REGULATOR_MODE_FAST;
+ } else {
+ val = 0;
+ };
+
+ ret = regmap_read(rdev->regmap, info->lp_mode_reg, &val);
+ val &= info->lp_mode_mask;
+ if (ret) {
+ dev_err(&rdev->dev, "Failed to get lp mode: %d\n", ret);
+ return ret;
+ }
+
+ if (val)
+ return REGULATOR_MODE_IDLE;
+ else
+ return REGULATOR_MODE_NORMAL;
+}
+
+static int mt6373_buck_unlock(struct regmap *map, bool unlock)
+{
+ u16 buf = unlock ? MT6373_BUCK_TOP_UNLOCK_VALUE : 0;
+
+ return regmap_bulk_write(map, MT6373_BUCK_TOP_KEY_PROT_LO, &buf, sizeof(buf));
+}
+
+static int mt6373_regulator_set_mode(struct regulator_dev *rdev,
+ unsigned int mode)
+{
+ struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
+ struct regmap *regmap = rdev->regmap;
+ int cur_mode, ret;
+
+ if (!info->modeset_reg && mode == REGULATOR_MODE_FAST)
+ return -EOPNOTSUPP;
+
+ switch (mode) {
+ case REGULATOR_MODE_FAST:
+ ret = mt6373_buck_unlock(regmap, true);
+ if (ret)
+ break;
+
+ ret = regmap_set_bits(regmap, info->modeset_reg, info->modeset_mask);
+
+ mt6373_buck_unlock(regmap, false);
+ break;
+ case REGULATOR_MODE_NORMAL:
+ cur_mode = mt6373_regulator_get_mode(rdev);
+ if (cur_mode < 0) {
+ ret = cur_mode;
+ break;
+ }
+
+ if (cur_mode == REGULATOR_MODE_FAST) {
+ ret = mt6373_buck_unlock(regmap, true);
+ if (ret)
+ break;
+
+ ret = regmap_clear_bits(regmap, info->modeset_reg, info->modeset_mask);
+
+ mt6373_buck_unlock(regmap, false);
+ break;
+ } else if (cur_mode == REGULATOR_MODE_IDLE) {
+ ret = regmap_clear_bits(regmap, info->lp_mode_reg, info->lp_mode_mask);
+ if (ret == 0)
+ usleep_range(100, 200);
+ } else {
+ ret = 0;
+ }
+ break;
+ case REGULATOR_MODE_IDLE:
+ ret = regmap_set_bits(regmap, info->lp_mode_reg, info->lp_mode_mask);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (ret) {
+ dev_err(&rdev->dev, "Failed to set mode %u: %d\n", mode, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void mt6373_oc_irq_enable_work(struct work_struct *work)
+{
+ struct delayed_work *dwork = to_delayed_work(work);
+ struct mt6373_regulator_info *info =
+ container_of(dwork, struct mt6373_regulator_info, oc_work);
+
+ enable_irq(info->virq);
+}
+
+static irqreturn_t mt6373_oc_isr(int irq, void *data)
+{
+ struct regulator_dev *rdev = (struct regulator_dev *)data;
+ struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
+
+ disable_irq_nosync(info->virq);
+
+ if (regulator_is_enabled_regmap(rdev))
+ regulator_notifier_call_chain(rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);
+
+ schedule_delayed_work(&info->oc_work, msecs_to_jiffies(OC_IRQ_ENABLE_DELAY_MS));
+
+ return IRQ_HANDLED;
+}
+
+static int mt6373_set_ocp(struct regulator_dev *rdev, int lim, int severity, bool enable)
+{
+ struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
+
+ /* MT6373 supports only enabling protection and does not support limits */
+ if (lim || severity != REGULATOR_SEVERITY_PROT || !enable)
+ return -EINVAL;
+
+ /* If there is no OCP interrupt, there's nothing to set */
+ if (info->virq <= 0)
+ return -EINVAL;
+
+ return devm_request_threaded_irq(&rdev->dev, info->virq, NULL,
+ mt6373_oc_isr, IRQF_ONESHOT,
+ info->desc.name, rdev);
+}
+
+static const struct regulator_ops mt6373_vreg_setclr_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .map_voltage = regulator_map_voltage_linear,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = mt6373_vreg_enable_setclr,
+ .disable = mt6373_vreg_disable_setclr,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6373_regulator_set_mode,
+ .get_mode = mt6373_regulator_get_mode,
+ .set_over_current_protection = mt6373_set_ocp,
+};
+
+static const struct regulator_ops mt6373_ldo_linear_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .map_voltage = regulator_map_voltage_linear,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6373_regulator_set_mode,
+ .get_mode = mt6373_regulator_get_mode,
+ .set_over_current_protection = mt6373_set_ocp,
+};
+
+static const struct regulator_ops mt6373_ldo_vtable_ops = {
+ .list_voltage = regulator_list_voltage_pickable_linear_range,
+ .map_voltage = regulator_map_voltage_pickable_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_pickable_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_pickable_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6373_regulator_set_mode,
+ .get_mode = mt6373_regulator_get_mode,
+ .set_over_current_protection = mt6373_set_ocp,
+};
+
+static const struct regulator_ops mt6373_vmch_eint_ops = {
+ .list_voltage = regulator_list_voltage_pickable_linear_range,
+ .map_voltage = regulator_map_voltage_pickable_linear_range,
+ .set_voltage_sel = regulator_set_voltage_sel_pickable_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_pickable_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = mt6373_vmch_eint_enable,
+ .disable = mt6373_vmch_eint_disable,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = mt6373_regulator_set_mode,
+ .get_mode = mt6373_regulator_get_mode,
+ .set_over_current_protection = mt6373_set_ocp,
+};
+
+/* The array is indexed by id(MT6373_ID_XXX) */
+static struct mt6373_regulator_info mt6373_regulators[] = {
+ MT6373_BUCK("vbuck0", VBUCK0, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_FCCM_ADDR, 0),
+ MT6373_BUCK("vbuck1", VBUCK1, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_FCCM_ADDR, 1),
+ MT6373_BUCK("vbuck2", VBUCK2, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_FCCM_ADDR, 2),
+ MT6373_BUCK("vbuck3", VBUCK3, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_FCCM_ADDR, 3),
+ MT6373_BUCK("vbuck4", VBUCK4, 0, 0, 1, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_1_FCCM_ADDR, 4),
+ MT6373_BUCK("vbuck5", VBUCK5, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_1_FCCM_ADDR, 5),
+ MT6373_BUCK("vbuck6", VBUCK6, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_1_FCCM_ADDR, 6),
+ MT6373_BUCK("vbuck7", VBUCK7, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK0_EN_ADDR,
+ MT6373_PMIC_RG_BUCK0_LP_ADDR, MT6373_PMIC_RG_BUCK0_1_FCCM_ADDR, 7),
+ MT6373_BUCK("vbuck8", VBUCK8, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK1_EN_ADDR,
+ MT6373_PMIC_RG_BUCK1_LP_ADDR, MT6373_PMIC_RG_BUCK1_FCCM_ADDR, 8),
+ MT6373_BUCK("vbuck9", VBUCK9, 0, 1193750, 6250, MT6373_PMIC_RG_BUCK1_EN_ADDR,
+ MT6373_PMIC_RG_BUCK1_LP_ADDR, MT6373_PMIC_RG_BUCK1_FCCM_ADDR, 9),
+ MT6373_LDO_VT("vant18", VANT18, "vs1-ldo1", 3, 28),
+ MT6373_LDO_VT("vaud18", VAUD18, "vs1-ldo1", 3, 16),
+ MT6373_LDO_VT("vaux18", VAUX18, "vsys-ldo2", 2, 18),
+ MT6373_LDO_VT("vcn18io", VCN18IO, "vs1-ldo1", 3, 25),
+ MT6373_LDO_VT("vcn33-1", VCN33_1, "vsys-ldo1", 4, 22),
+ MT6373_LDO_VT("vcn33-2", VCN33_2, "vsys-ldo1", 4, 23),
+ MT6373_LDO_VT("vcn33-3", VCN33_3, "vsys-ldo2", 4, 24),
+ MT6373_LDO_VT("vefuse", VEFUSE, "vsys-ldo2", 1, 31),
+ MT6373_LDO_VT("vfp", VFP, "vsys-ldo2", 1, 36),
+ MT6373_LDO_VT("vibr", VIBR, "vsys-ldo2", 1, 34),
+ MT6373_LDO_VT("vio28", VIO28, "vsys-ldo2", 1, 35),
+ MT6373_LDO_VT("vmc", VMC, "vsys-ldo1", 1, 33),
+ MT6373_LDO_VT("vmch", VMCH, "vsys-ldo3", 4, 32),
+ MT6373_LDO_EI("vmch-eint-high", VMCH_EINT_HIGH, "vsys-ldo3", 4, 0),
+ MT6373_LDO_EI("vmch-eint-low", VMCH_EINT_LOW, "vsys-ldo3", 4, 0),
+ MT6373_LDO_VT("vrf09-aif", VRF09_AIF, "vs3-ldo1", 3, 26),
+ MT6373_LDO_VT("vrf12-aif", VRF12_AIF, "vs2-ldo1", 5, 27),
+ MT6373_LDO_VT("vrf13-aif", VRF13_AIF, "vs2-ldo1", 3, 19),
+ MT6373_LDO_VT("vrf18-aif", VRF18_AIF, "vs1-ldo1", 3, 20),
+ MT6373_LDO_VT("vrfio18-aif", VRFIO18_AIF, "vs1-ldo1", 3, 25),
+ MT6373_LDO_L("vsram-digrf-aif", VSRAM_DIGRF_AIF, "vs3-ldo1", 400000, 1193750, 6250, 29),
+ MT6373_LDO_VT("vtp", VTP, "vsys-ldo2", 1, 37),
+ MT6373_LDO_VT("vusb", VUSB, "vsys-ldo2", 1, 17)
+};
+
+static void mt6373_irq_remove(void *data)
+{
+ int *virq = data;
+
+ irq_dispose_mapping(*virq);
+}
+
+static void mt6373_spmi_remove(void *data)
+{
+ struct spmi_device *sdev = data;
+
+ spmi_device_remove(sdev);
+};
+
+static struct regmap *mt6373_spmi_register_regmap(struct device *dev)
+{
+ struct regmap_config mt6373_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 16,
+ .max_register = 0x1f90,
+ .fast_io = true,
+ };
+ struct spmi_device *sdev, *sparent;
+ u32 base;
+ int ret;
+
+ if (!dev->parent)
+ return ERR_PTR(-ENODEV);
+
+ ret = device_property_read_u32(dev, "reg", &base);
+ if (ret)
+ return ERR_PTR(ret);
+
+ sparent = to_spmi_device(dev->parent);
+ if (!sparent)
+ return ERR_PTR(-ENODEV);
+
+ sdev = spmi_device_alloc(sparent->ctrl);
+ if (!sdev)
+ return ERR_PTR(-ENODEV);
+
+ sdev->usid = sparent->usid;
+ dev_set_name(&sdev->dev, "%d-%02x-regulator", sdev->ctrl->nr, sdev->usid);
+ ret = device_add(&sdev->dev);
+ if (ret) {
+ put_device(&sdev->dev);
+ return ERR_PTR(ret);
+ };
+
+ ret = devm_add_action_or_reset(dev, mt6373_spmi_remove, sdev);
+ if (ret)
+ return ERR_PTR(ret);
+
+ mt6373_regmap_config.reg_base = base;
+
+ return devm_regmap_init_spmi_ext(sdev, &mt6373_regmap_config);
+}
+
+static int mt6373_regulator_probe(struct platform_device *pdev)
+{
+ struct device_node *interrupt_parent;
+ struct regulator_config config = {};
+ struct mt6373_regulator_info *info;
+ struct device *dev = &pdev->dev;
+ struct regulator_dev *rdev;
+ struct irq_domain *domain;
+ struct irq_fwspec fwspec;
+ struct spmi_device *sdev;
+ bool is_vbuck4_hw_ctrl;
+ bool is_cw_variant;
+ int i, ret;
+ u32 val;
+
+ config.regmap = mt6373_spmi_register_regmap(dev);
+ if (IS_ERR(config.regmap))
+ return dev_err_probe(dev, PTR_ERR(config.regmap),
+ "Cannot get regmap\n");
+ config.dev = dev;
+ sdev = to_spmi_device(dev->parent);
+ dev_set_drvdata(dev, config.regmap);
+
+ interrupt_parent = of_irq_find_parent(dev->of_node);
+ if (!interrupt_parent)
+ return -EINVAL;
+
+ domain = irq_find_host(interrupt_parent);
+ of_node_put(interrupt_parent);
+ fwspec.fwnode = domain->fwnode;
+
+ fwspec.param_count = 3;
+ fwspec.param[0] = sdev->usid;
+ fwspec.param[2] = IRQ_TYPE_LEVEL_HIGH;
+
+ /*
+ * The first read may fail if the bootloader sets sleep mode: wake up
+ * this PMIC with W/R on the SPMI bus and ignore the first result.
+ */
+ regmap_read(config.regmap, MT6373_PLG_CFG_ELR1, &val);
+
+ /* Read PMIC variant information */
+ ret = regmap_read(config.regmap, MT6373_PLG_CFG_ELR1, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Cannot read ID register\n");
+
+ val = FIELD_GET(MT6373_ELR_VARIANT_MASK, val);
+ is_cw_variant = (val == MT6373_ELR_VARIANT_MT6373CW);
+
+ /* Read Reserved-SW information */
+ ret = regmap_read(config.regmap, MT6373_RG_RSV_SWREG_H, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Cannot read RSV_SW register\n");
+
+ is_vbuck4_hw_ctrl = val & MT6373_RG_RSV_SWREG_VBUCK4_HW_CTRL;
+
+ for (i = 0; i < ARRAY_SIZE(mt6373_regulators); i++) {
+ info = &mt6373_regulators[i];
+
+ /* MT6373CW VBUCK4 constraints are different */
+ if (info->desc.id == MT6373_ID_VBUCK4) {
+ unsigned int vbuck4_max_uV;
+
+ /* VBUCK4 vreg software control not allowed in hw_ctrl mode */
+ if (is_vbuck4_hw_ctrl)
+ continue;
+
+ if (is_cw_variant) {
+ info->desc.uV_step = 6250;
+ vbuck4_max_uV = 1193750;
+ } else {
+ info->desc.uV_step = 13875;
+ vbuck4_max_uV = 2650125;
+ }
+ info->desc.n_voltages = vbuck4_max_uV / info->desc.uV_step + 1;
+ }
+
+ fwspec.param[0] = to_spmi_device(dev->parent)->usid;
+ fwspec.param[1] = info->hwirq;
+ info->virq = irq_create_fwspec_mapping(&fwspec);
+ if (!info->virq)
+ return dev_err_probe(dev, -EINVAL,
+ "Failed to map IRQ%d\n", info->hwirq);
+
+ ret = devm_add_action_or_reset(dev, mt6373_irq_remove, &info->virq);
+ if (ret) {
+ irq_dispose_mapping(info->virq);
+ return ret;
+ }
+
+ config.driver_data = info;
+ INIT_DELAYED_WORK(&info->oc_work, mt6373_oc_irq_enable_work);
+
+ rdev = devm_regulator_register(dev, &info->desc, &config);
+ if (IS_ERR(rdev))
+ return dev_err_probe(dev, PTR_ERR(rdev),
+ "failed to register %s\n", info->desc.name);
+ }
+
+ return 0;
+}
+
+static void mt6373_regulator_shutdown(struct platform_device *pdev)
+{
+ struct regmap *regmap = dev_get_drvdata(&pdev->dev);
+
+ regmap_write(regmap, MT6373_TOP_CFG_ELR5, MT6373_TOP_CFG_ELR5_SHUTDOWN);
+}
+
+static const struct of_device_id mt6373_regulator_match[] = {
+ { .compatible = "mediatek,mt6373-regulator" },
+ { /* sentinel */ }
+};
+
+static struct platform_driver mt6373_regulator_driver = {
+ .driver = {
+ .name = "mt6373-regulator",
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .of_match_table = mt6373_regulator_match,
+ },
+ .probe = mt6373_regulator_probe,
+ .shutdown = mt6373_regulator_shutdown
+};
+module_platform_driver(mt6373_regulator_driver);
+
+MODULE_AUTHOR("AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>");
+MODULE_DESCRIPTION("MediaTek MT6373 PMIC Regulator Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/regulator/mt6373-regulator.h b/include/linux/regulator/mt6373-regulator.h
new file mode 100644
index 000000000000..dd791717d2a1
--- /dev/null
+++ b/include/linux/regulator/mt6373-regulator.h
@@ -0,0 +1,161 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2024 MediaTek Inc.
+ * Copyright (c) 2025 Collabora Ltd
+ */
+
+#include <linux/bits.h>
+
+#ifndef __LINUX_REGULATOR_MT6373_H
+#define __LINUX_REGULATOR_MT6373_H
+
+/* Register */
+#define MT6373_TOP_CFG_ELR5 0x117
+#define MT6373_TOP_CFG_ELR5_SHUTDOWN BIT(0)
+
+#define MT6373_PMIC_RG_BUCK0_EN_ADDR 0x210
+#define MT6373_PMIC_RG_BUCK_VBUCK0_EN_BIT 0
+#define MT6373_PMIC_RG_BUCK_VBUCK1_EN_BIT 1
+#define MT6373_PMIC_RG_BUCK_VBUCK2_EN_BIT 2
+#define MT6373_PMIC_RG_BUCK_VBUCK3_EN_BIT 3
+#define MT6373_PMIC_RG_BUCK_VBUCK4_EN_BIT 4
+#define MT6373_PMIC_RG_BUCK_VBUCK5_EN_BIT 5
+#define MT6373_PMIC_RG_BUCK_VBUCK6_EN_BIT 6
+#define MT6373_PMIC_RG_BUCK_VBUCK7_EN_BIT 7
+
+#define MT6373_PMIC_RG_BUCK1_EN_ADDR 0x213
+#define MT6373_PMIC_RG_BUCK_VBUCK8_EN_BIT 0
+#define MT6373_PMIC_RG_BUCK_VBUCK9_EN_BIT 1
+
+#define MT6373_PMIC_RG_BUCK0_LP_ADDR 0x216
+#define MT6373_PMIC_RG_BUCK_VBUCK0_LP_BIT 0
+#define MT6373_PMIC_RG_BUCK_VBUCK1_LP_BIT 1
+#define MT6373_PMIC_RG_BUCK_VBUCK2_LP_BIT 2
+#define MT6373_PMIC_RG_BUCK_VBUCK3_LP_BIT 3
+#define MT6373_PMIC_RG_BUCK_VBUCK4_LP_BIT 4
+#define MT6373_PMIC_RG_BUCK_VBUCK5_LP_BIT 5
+#define MT6373_PMIC_RG_BUCK_VBUCK6_LP_BIT 6
+#define MT6373_PMIC_RG_BUCK_VBUCK7_LP_BIT 7
+
+#define MT6373_PMIC_RG_BUCK1_LP_ADDR 0x219
+#define MT6373_PMIC_RG_BUCK_VBUCK8_LP_BIT 0
+#define MT6373_PMIC_RG_BUCK_VBUCK9_LP_BIT 1
+
+#define MT6373_PMIC_RG_BUCK_VBUCK0_VOSEL_ADDR 0x21c
+#define MT6373_PMIC_RG_BUCK_VBUCK1_VOSEL_ADDR 0x21d
+#define MT6373_PMIC_RG_BUCK_VBUCK2_VOSEL_ADDR 0x21e
+#define MT6373_PMIC_RG_BUCK_VBUCK3_VOSEL_ADDR 0x21f
+#define MT6373_PMIC_RG_BUCK_VBUCK4_VOSEL_ADDR 0x220
+#define MT6373_PMIC_RG_BUCK_VBUCK5_VOSEL_ADDR 0x221
+#define MT6373_PMIC_RG_BUCK_VBUCK6_VOSEL_ADDR 0x222
+#define MT6373_PMIC_RG_BUCK_VBUCK7_VOSEL_ADDR 0x223
+#define MT6373_PMIC_RG_BUCK_VBUCK8_VOSEL_ADDR 0x224
+#define MT6373_PMIC_RG_BUCK_VBUCK9_VOSEL_ADDR 0x225
+#define MT6373_PMIC_RG_BUCK_VOSEL_MASK GENMASK(8, 0)
+
+#define MT6373_PLG_CFG_ELR1 0x37b
+#define MT6373_ELR_VARIANT_MASK GENMASK(3, 2)
+#define MT6373_ELR_VARIANT_MT6373CW 1
+#define MT6373_RG_RSV_SWREG_H 0x9d9
+#define MT6373_RG_RSV_SWREG_VBUCK4_HW_CTRL BIT(0)
+
+#define MT6373_BUCK_TOP_KEY_PROT_LO 0x13fa
+
+#define MT6373_PMIC_RG_BUCK1_FCCM_ADDR 0x196d
+#define MT6373_PMIC_RG_VBUCK8_FCCM_BIT 6
+#define MT6373_PMIC_RG_VBUCK9_FCCM_BIT 7
+
+#define MT6373_PMIC_RG_BUCK0_FCCM_ADDR 0x1a02
+#define MT6373_PMIC_RG_VBUCK0_FCCM_BIT 0
+#define MT6373_PMIC_RG_VBUCK1_FCCM_BIT 1
+#define MT6373_PMIC_RG_VBUCK2_FCCM_BIT 2
+#define MT6373_PMIC_RG_VBUCK3_FCCM_BIT 3
+
+#define MT6373_PMIC_RG_BUCK0_1_FCCM_ADDR 0x1a82
+#define MT6373_PMIC_RG_VBUCK4_FCCM_BIT 0
+#define MT6373_PMIC_RG_VBUCK5_FCCM_BIT 1
+#define MT6373_PMIC_RG_VBUCK6_FCCM_BIT 2
+#define MT6373_PMIC_RG_VBUCK7_FCCM_BIT 3
+
+#define MT6373_PMIC_RG_VSRAM_DIGRF_AIF_VOSEL_ADDR 0x1b09
+#define MT6373_PMIC_RG_VSRAM_DIGRF_AIF_VOSEL_MASK GENMASK(6, 0)
+
+#define MT6373_PMIC_RG_LDO_VAUD18_ADDR 0x1b57
+#define MT6373_PMIC_RG_LDO_VUSB_ADDR 0x1b65
+#define MT6373_PMIC_RG_LDO_VAUX18_ADDR 0x1b73
+#define MT6373_PMIC_RG_LDO_VRF13_AIF_ADDR 0x1b81
+#define MT6373_PMIC_RG_LDO_VRF18_AIF_ADDR 0x1b8f
+#define MT6373_PMIC_RG_LDO_VRFIO18_AIF_ADDR 0x1b9d
+#define MT6373_PMIC_RG_LDO_VCN33_1_ADDR 0x1bd7
+#define MT6373_PMIC_RG_LDO_VCN33_2_ADDR 0x1be5
+#define MT6373_PMIC_RG_LDO_VCN33_3_ADDR 0x1bf3
+#define MT6373_PMIC_RG_LDO_VCN18IO_ADDR 0x1c01
+#define MT6373_PMIC_RG_LDO_VRF09_AIF_ADDR 0x1c0f
+#define MT6373_PMIC_RG_LDO_VRF12_AIF_ADDR 0x1c1d
+#define MT6373_PMIC_RG_LDO_VANT18_ADDR 0x1c57
+#define MT6373_PMIC_RG_LDO_VEFUSE_ADDR 0x1c73
+#define MT6373_PMIC_RG_LDO_VMCH_ADDR 0x1c81
+#define MT6373_PMIC_RG_LDO_VMCH_EINT_ADDR 0x1c8f
+#define MT6373_PMIC_RG_LDO_VMCH_EINT_HIGH_ADDR MT6373_PMIC_RG_LDO_VMCH_EINT_ADDR
+#define MT6373_PMIC_RG_LDO_VMCH_EINT_LOW_ADDR MT6373_PMIC_RG_LDO_VMCH_EINT_ADDR
+#define MT6373_PMIC_RG_LDO_VMCH_EINT_POL_BIT BIT(2)
+#define MT6373_PMIC_RG_LDO_VMC_ADDR 0x1c90
+#define MT6373_PMIC_RG_LDO_VIBR_ADDR 0x1c9e
+#define MT6373_PMIC_RG_LDO_VIO28_ADDR 0x1cd7
+#define MT6373_PMIC_RG_LDO_VFP_ADDR 0x1ce5
+#define MT6373_PMIC_RG_LDO_VTP_ADDR 0x1cf3
+#define MT6373_PMIC_RG_LDO_VSIM1_ADDR 0x1d01
+#define MT6373_PMIC_RG_LDO_VSIM2_ADDR 0x1d10
+#define MT6373_PMIC_RG_LDO_VSIM2_LP_ADDR 0x1d10
+#define MT6373_PMIC_RG_LDO_VSRAM_DIGRF_AIF_ADDR 0x1d57
+#define MT6373_PMIC_RG_VAUX18_VOCAL_ADDR 0x1dd8
+#define MT6373_PMIC_RG_VAUX18_VOSEL_ADDR 0x1dd9
+#define MT6373_PMIC_RG_VUSB_VOCAL_ADDR 0x1ddc
+#define MT6373_PMIC_RG_VUSB_VOSEL_ADDR 0x1ddd
+#define MT6373_PMIC_RG_VCN33_1_VOCAL_ADDR 0x1de0
+#define MT6373_PMIC_RG_VCN33_1_VOSEL_ADDR 0x1de1
+#define MT6373_PMIC_RG_VCN33_2_VOCAL_ADDR 0x1de4
+#define MT6373_PMIC_RG_VCN33_2_VOSEL_ADDR 0x1de5
+#define MT6373_PMIC_RG_VCN33_3_VOCAL_ADDR 0x1de8
+#define MT6373_PMIC_RG_VCN33_3_VOSEL_ADDR 0x1de9
+#define MT6373_PMIC_RG_VMCH_VOCAL_ADDR 0x1dec
+#define MT6373_PMIC_RG_VMCH_VOSEL_ADDR 0x1ded
+#define MT6373_PMIC_RG_VMCH_EINT_HIGH_VOSEL_ADDR MT6373_PMIC_RG_VMCH_VOSEL_ADDR
+#define MT6373_PMIC_RG_VMCH_EINT_LOW_VOSEL_ADDR MT6373_PMIC_RG_VMCH_VOSEL_ADDR
+#define MT6373_PMIC_RG_VEFUSE_VOCAL_ADDR 0x1df0
+#define MT6373_PMIC_RG_VEFUSE_VOSEL_ADDR 0x1df1
+#define MT6373_PMIC_RG_VMC_VOCAL_ADDR 0x1df4
+#define MT6373_PMIC_RG_VMCH_EINT_HIGH_VOCAL_ADDR MT6373_PMIC_RG_VMC_VOCAL_ADDR
+#define MT6373_PMIC_RG_VMCH_EINT_LOW_VOCAL_ADDR MT6373_PMIC_RG_VMC_VOCAL_ADDR
+#define MT6373_PMIC_RG_VMC_VOSEL_ADDR 0x1df5
+#define MT6373_PMIC_RG_VIBR_VOCAL_ADDR 0x1df8
+#define MT6373_PMIC_RG_VIBR_VOSEL_ADDR 0x1df9
+#define MT6373_PMIC_RG_VIO28_VOCAL_ADDR 0x1dfc
+#define MT6373_PMIC_RG_VIO28_VOSEL_ADDR 0x1dfd
+#define MT6373_PMIC_RG_VFP_VOCAL_ADDR 0x1e00
+#define MT6373_PMIC_RG_VFP_VOSEL_ADDR 0x1e01
+#define MT6373_PMIC_RG_VTP_VOCAL_ADDR 0x1e04
+#define MT6373_PMIC_RG_VTP_VOSEL_ADDR 0x1e05
+#define MT6373_PMIC_RG_VSIM1_VOCAL_ADDR 0x1e08
+#define MT6373_PMIC_RG_VSIM1_VOSEL_ADDR 0x1e09
+#define MT6373_PMIC_RG_VSIM2_VOCAL_ADDR 0x1e0c
+#define MT6373_PMIC_RG_VSIM2_VOSEL_ADDR 0x1e0d
+#define MT6373_PMIC_RG_VAUD18_VOCAL_ADDR 0x1e58
+#define MT6373_PMIC_RG_VAUD18_VOSEL_ADDR 0x1e59
+#define MT6373_PMIC_RG_VRF18_AIF_VOCAL_ADDR 0x1e5c
+#define MT6373_PMIC_RG_VRF18_AIF_VOSEL_ADDR 0x1e5d
+#define MT6373_PMIC_RG_VCN18IO_VOCAL_ADDR 0x1e60
+#define MT6373_PMIC_RG_VCN18IO_VOSEL_ADDR 0x1e61
+#define MT6373_PMIC_RG_VRFIO18_AIF_VOCAL_ADDR 0x1e64
+#define MT6373_PMIC_RG_VRFIO18_AIF_VOSEL_ADDR 0x1e65
+#define MT6373_PMIC_RG_VANT18_VOCAL_ADDR 0x1e68
+#define MT6373_PMIC_RG_VANT18_VOSEL_ADDR 0x1e69
+#define MT6373_PMIC_RG_VRF13_AIF_VOCAL_ADDR 0x1ed8
+#define MT6373_PMIC_RG_VRF13_AIF_VOSEL_ADDR 0x1ed9
+#define MT6373_PMIC_RG_VRF12_AIF_VOCAL_ADDR 0x1edc
+#define MT6373_PMIC_RG_VRF12_AIF_VOSEL_ADDR 0x1edd
+#define MT6373_PMIC_RG_VRF09_AIF_VOCAL_ADDR 0x1f58
+#define MT6373_PMIC_RG_VRF09_AIF_VOSEL_ADDR 0x1f59
+#define MT6373_PMIC_RG_LDO_VT_VOCALSEL_MASK GENMASK(7, 0)
+
+#endif /* __LINUX_REGULATOR_MT6373_H */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ARM: Do not select HAVE_RUST when KASAN is enabled
From: Christian Schrefl @ 2026-05-11 13:22 UTC (permalink / raw)
To: Nathan Chancellor, Russell King, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich
Cc: linux-arm-kernel, linux-kernel, rust-for-linux, stable
In-Reply-To: <20260511-arm-avoid-rust-with-kasan-v1-1-24d55f4a900b@kernel.org>
On 5/11/26 10:02 AM, Nathan Chancellor wrote:
> When KASAN is enabled, such as with allmodconfig, the build fails when
> building the Rust code with:
>
> error: kernel-address sanitizer is not supported for this target
>
> error: aborting due to 1 previous error
>
> make[4]: *** [rust/Makefile:654: rust/core.o] Error 1
>
> The arm-unknown-linux-gnueabi target does not support KASAN, so avoid
> saying Rust is supported when it is enabled.
>
> Cc: stable@vger.kernel.org
> Fixes: ccb8ce526807 ("ARM: 9441/1: rust: Enable Rust support for ARMv7")
> Link: https://github.com/Rust-for-Linux/linux/issues/1234
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Seems fine to me either like this or as Alice mentioned in another reply.
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
From: Pranjal Shrivastava @ 2026-05-11 13:22 UTC (permalink / raw)
To: Nicolin Chen
Cc: Robin Murphy, Jason Gunthorpe, Will Deacon, Joerg Roedel,
Jean-Philippe Brucker, Catalin Marinas, Mikołaj Lenczewski,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <af7oyeleKFXpcIKu@nvidia.com>
On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote:
> On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > > Since the fault handlers are already expecting HW-triggered updates?
> > >
> > > Which means our check would be something like:
> > >
> > > if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > > if (smmu->features & FEAT_HA)
> > > ...
> > > }
> > >
> > > instead of cpu_has_hw_af()?
> >
> > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> > CPU doesn't support HAFDBS, so perhaps you were right the first time :)
>
> IIUIC, v2 should be:
>
> + /*
> + * Enable Hardware Access and Dirty updates (DBM) if supported by
> + * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
> + * if the CPU does not support it as it bypasses mm page aging.
> + */
> + if (cpu_has_hw_af()) {
Ack, yes. IMO, this is the correct system-wide gate.
> + if (master->smmu->features & ARM_SMMU_FEAT_HA)
> + target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
> + if (master->smmu->features & ARM_SMMU_FEAT_HD)
> + target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
> + }
>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: renesas: r8a77960-ulcb: Enable GPU support
From: Geert Uytterhoeven @ 2026-05-11 13:24 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Rob Herring, devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdVwXjE0Bq1KjENkN4m2h0_nN0F2S=CC8mW3B92NdpN2_g@mail.gmail.com>
On Wed, 29 Oct 2025 at 15:51, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, 27 Oct 2025 at 22:13, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
> > Enable GPU on M3ULCB with R-Car M3-W.
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Now the crash in case of missing firmware is fixed by commit
26735dfdd8930d9e ("pmdomain: core: Fix detach procedure for virtual
devices in genpd") in v7.1-rc3, I will queue this and the other patches
in this anonymous series in renesas-devel for v7.2,
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Andrew Lunn @ 2026-05-11 13:29 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Josua Mayer, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yazan Shhady, Mikhail Anikin,
Alexander Dahl, devicetree, linux-kernel, imx, linux-arm-kernel,
Conor Dooley, Krzysztof Kozlowski, netdev
In-Reply-To: <20260511112438.4fxvhelf242emzft@skbuf>
On Mon, May 11, 2026 at 02:24:38PM +0300, Vladimir Oltean wrote:
> On Mon, May 11, 2026 at 12:11:31PM +0200, Josua Mayer wrote:
> > +&eqos {
> > + /* delays are added by connected ethernet-switch cpu port */
> > + phy-mode = "rgmii";
For ethernet-phy combinations i'm pretty strict, but i'm more
forgiving when switches are involved.
If rx/tx-internal-delays-ps work, that would be better, but i'm
willing to accept this, with the comment in place.
Andrew
^ permalink raw reply
* Re: [PATCH v7 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-05-11 13:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann, driver-core,
linux-kernel, linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <20260430-nokia770-gpio-swnodes-v7-0-c88f74c90dd6@oss.qualcomm.com>
On Thu, Apr 30, 2026 at 9:31 AM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> This converts Nokia 770 to using real firmware node lookup for GPIOs by
> attaching the software nodes describing GPIO controllers to their target
> devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
Hi!
Gentle ping, can this be queued now for v7.2?
Thanks,
Bart
^ permalink raw reply
* Re: [PATCH v3 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-05-11 13:35 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij, linux-arm-kernel,
linux-gpio, linux-kernel
In-Reply-To: <20260430-pxa-gpio-swnodes-v3-0-5142e95f0eca@oss.qualcomm.com>
On Thu, Apr 30, 2026 at 2:57 PM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> Convert GPIO controllers and their consumers on the PXA platform to using
> "attached" software nodes. Since everything happens in a bord-file, it's
> quite straightforward. We technically now have a way of passing an
> unregistered software node to platform_device_register_full() but that
> requires using struct platform_device_info and since the existing
> platform devices are either referenced from other places or defined in a
> different compilation unit, I wanted to reduce the impact of the changes
> I can't test and went with the older method.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
If there are no other comments, can this be queued for v7.2?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH] irqchip/mvebu: Allow EBU irqchips to be compile-tested
From: Thomas Gleixner @ 2026-05-11 13:45 UTC (permalink / raw)
To: Rosen Penev, linux-kernel
Cc: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260510195047.10143-1-rosenp@gmail.com>
On Sun, May 10 2026 at 12:50, Rosen Penev wrote:
> The Marvell EBU interrupt controller Kconfig symbols are hidden and
> selected only by platform code. This prevents build coverage for the
> drivers on other architectures even though the code only needs OF and
> MMIO support.
>
> Add COMPILE_TEST prompts and the required dependencies for the GICP,
> ICU, ODMI, PIC and SEI irqchips. While touching PIC for this coverage,
> use GENMASK() and BIT() for its masks so that 32-bit platforms can
> compile this safely without running into issues.
While touching PIC? That's related, but you want to prepare the PIC code
first in order to enable the compile test and not burry that change
within a gazillion lines of Kconfig muck.
> config MVEBU_GICP
> + bool "Marvell EBU GICP interrupt controller" if COMPILE_TEST
> + depends on OF
> + depends on HAS_IOMEM
depends on OF && HAS_IOMEM
> select IRQ_MSI_LIB
> - bool
> + help
> + Support the Marvell EBU GICP interrupt controller.
>
> config MVEBU_ICU
> - bool
> + bool "Marvell EBU ICU interrupt controller" if COMPILE_TEST
> + depends on OF
> + depends on HAS_IOMEM
> + select GENERIC_MSI_IRQ
> + help
> + Support the Marvell EBU ICU interrupt controller.
>
> config MVEBU_ODMI
> - bool
> + bool "Marvell EBU ODMI interrupt controller" if COMPILE_TEST
> + depends on OF
> + depends on HAS_IOMEM
> select IRQ_MSI_LIB
> select GENERIC_MSI_IRQ
So while at it you can mop up this too. IRQ_MSI_LIB already selects
GENERIC_MSI_IRQ
> + help
> + Support the Marvell EBU ODMI interrupt controller.
>
> config MVEBU_PIC
> - bool
> + bool "Marvell EBU PIC interrupt controller" if COMPILE_TEST
> + depends on OF
> + depends on HAS_IOMEM
> + help
> + Support the Marvell EBU PIC interrupt controller.
>
> config MVEBU_SEI
> - bool
> + bool "Marvell EBU SEI interrupt controller" if COMPILE_TEST
> + depends on OF
> + depends on HAS_IOMEM
> + help
> + Support the Marvell EBU SEI interrupt controller.
What ensures that IRQ_MSI_LIB is selected, when MVEBU_SEI is selected?
> config LS_EXTIRQ
> bool "Freescale Layerscape external IRQ support" if COMPILE_TEST
> diff --git a/drivers/irqchip/irq-mvebu-pic.c b/drivers/irqchip/irq-mvebu-pic.c
> index 10b85128183a..95090d8efc06 100644
> --- a/drivers/irqchip/irq-mvebu-pic.c
> +++ b/drivers/irqchip/irq-mvebu-pic.c
> @@ -24,7 +24,7 @@
> #define PIC_MASK 0x4
>
> #define PIC_MAX_IRQS 32
> -#define PIC_MAX_IRQ_MASK ((1UL << PIC_MAX_IRQS) - 1)
> +#define PIC_MAX_IRQ_MASK GENMASK(PIC_MAX_IRQS - 1, 0)
What guarantees that 'linux/bits.h' is included under all circumstances?
I'm really not impressed by this AI assisted slop at all.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] watchdog: apple: Add "apple,t8103-wdt" compatible
From: Guenter Roeck @ 2026-05-11 14:04 UTC (permalink / raw)
To: Janne Grunau
Cc: Sven Peter, Neal Gompa, Wim Van Sebroeck, asahi, linux-arm-kernel,
linux-watchdog, linux-kernel, stable
In-Reply-To: <20251231-watchdog-apple-t8103-base-compat-v1-1-1702a02e0c45@jannau.net>
On Wed, Dec 31, 2025 at 01:07:21PM +0100, Janne Grunau wrote:
> After discussion with the devicetree maintainers we agreed to not extend
> lists with the generic compatible "apple,wdt" anymore [1]. Use
> "apple,t8103-wdt" as base compatible as it is the SoC the driver and
> bindings were written for.
>
> [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
>
> Fixes: 4ed224aeaf66 ("watchdog: Add Apple SoC watchdog driver")
> Cc: stable@vger.kernel.org
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Janne Grunau <j@jannau.net>
Applied to my hwmon-next branch.
Thanks,
Guenter
> ---
> This is split off from the v1 series adding Apple M2 Pro/Max/Ultra
> device trees in [2].
>
> 2: https://lore.kernel.org/r/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net
> ---
> drivers/watchdog/apple_wdt.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251231-watchdog-apple-t8103-base-compat-8a623e9831b6
>
> Best regards,
>
> diff --git a/drivers/watchdog/apple_wdt.c b/drivers/watchdog/apple_wdt.c
> index 66a158f67a712bbed394d660071e02140e66c2e5..6b9b0f9b05cedfd7fc5d0d79ba19ab356dc2a080 100644
> --- a/drivers/watchdog/apple_wdt.c
> +++ b/drivers/watchdog/apple_wdt.c
> @@ -218,6 +218,7 @@ static int apple_wdt_suspend(struct device *dev)
> static DEFINE_SIMPLE_DEV_PM_OPS(apple_wdt_pm_ops, apple_wdt_suspend, apple_wdt_resume);
>
> static const struct of_device_id apple_wdt_of_match[] = {
> + { .compatible = "apple,t8103-wdt" },
> { .compatible = "apple,wdt" },
> {},
> };
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: watchdog: apple,wdt: Add t8122 compatible
From: Guenter Roeck @ 2026-05-11 14:06 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, devicetree,
linux-kernel, asahi, linux-arm-kernel, linux-watchdog, linux-pwm,
Joshua Peisach
In-Reply-To: <20260507-apple-m3-initial-devicetrees-v3-2-ca07c81b5dc7@jannau.net>
On Thu, May 07, 2026 at 09:33:08AM +0200, Janne Grunau wrote:
> The watchdog on the Apple silicon t8122 (M3) SoC is compatible with the
> existing driver. Add "apple,t8122-wdt" as SoC specific compatible under
> "apple,t8103-wdt" used by the driver.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Janne Grunau <j@jannau.net>
Applied to my watchdog-next branch.
Thanks,
Guenter
> ---
> Documentation/devicetree/bindings/watchdog/apple,wdt.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> index 05602678c070..845b5e8b5abc 100644
> --- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
> @@ -16,7 +16,9 @@ properties:
> compatible:
> oneOf:
> - items:
> - - const: apple,t6020-wdt
> + - enum:
> + - apple,t6020-wdt
> + - apple,t8122-wdt
> - const: apple,t8103-wdt
> - items:
> - enum:
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: watchdog: apple,wdt: Add t8122 compatible
From: Guenter Roeck @ 2026-05-11 14:07 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Mark Kettenis,
Sasha Finkelstein, Uwe Kleine-König, devicetree,
linux-kernel, asahi, linux-arm-kernel, linux-watchdog, linux-pwm,
Joshua Peisach
In-Reply-To: <20260511085028.GA192358@robin.jannau.net>
On 5/11/26 01:50, Janne Grunau wrote:
> On Sun, May 10, 2026 at 08:29:39AM -0700, Guenter Roeck wrote:
>> On Thu, May 07, 2026 at 09:33:08AM +0200, Janne Grunau wrote:
>>> The watchdog on the Apple silicon t8122 (M3) SoC is compatible with the
>>> existing driver. Add "apple,t8122-wdt" as SoC specific compatible under
>>> "apple,t8103-wdt" used by the driver.
>>
>> '"apple,t8103-wdt" used by the driver' is not true. The watchdog driver
>> only supports "apple,wdt".
>
> It slipped my mind that
> https://lore.kernel.org/linux-watchdog/20251231-watchdog-apple-t8103-base-compat-v1-1-1702a02e0c45@jannau.net/
> wasn't picked up yet.
>
Me too. Applied both.
Thanks,
Guenter
>>
>>>
>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
>>> Reviewed-by: Neal Gompa <neal@gompa.dev>
>>> Signed-off-by: Janne Grunau <j@jannau.net>
>>> ---
>>> Documentation/devicetree/bindings/watchdog/apple,wdt.yaml | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>> index 05602678c070..845b5e8b5abc 100644
>>> --- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>> +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml
>>> @@ -16,7 +16,9 @@ properties:
>>> compatible:
>>> oneOf:
>>> - items:
>>> - - const: apple,t6020-wdt
>>> + - enum:
>>> + - apple,t6020-wdt
>>> + - apple,t8122-wdt
>>> - const: apple,t8103-wdt
>>> - items:
>>> - enum:
>>
>> I second Sashiko's findings that the driver will fail to bind because it
>> only supports "apple,wdt". I would not mind and apply the patch anyway,
>> but the statement in the description is just plain wrong and thus
>> misleading. Please fix.
>
> I would prefer if the addition of the "apple,t8103-wdt" to the driver is
> picked.
>
> Thanks,
>
> Janne
>
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: dts: aspeed-g6: add AST2600 I3C nodes and bindings
From: Dawid Glazik @ 2026-05-11 14:14 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, maciej.lawniczak
In-Reply-To: <cover.1777058942.git.dawid.glazik@linux.intel.com>
On 4/24/2026 10:20 PM, Dawid Glazik wrote:
> This series reworks and resubmits AST2600 I3C DTS updates that were
> originally posted in 2024, but stalled without further upstream
> progress.[1] The series was rebased onto the current tree and merge
> conflicts were resolved.
>
> The patches first move I2C controller nodes under the APB simple-bus
> for layout consistency, then document aspeed,ast2600-i3c-global in
> the syscon binding, and finally add AST2600 I3C controller nodes in
> aspeed-g6.dtsi.
>
> Jeremy agreed in a separate email thread that I can continue this
> series under my authorship.
>
> Link: https://lore.kernel.org/all/9d8c03d742fa9767f30e23d75ddf0baf4296c88e.1714647917.git.jk@codeconstruct.com.au/
>
> Dawid Glazik (3):
> ARM: dts: aspeed-g6: move i2c controllers directly into apb node
> dt-bindings: mfd: syscon: add aspeed,ast2600-i3c-global compatible
> ARM: dts: aspeed-g6: Add nodes for i3c controllers
>
> .../devicetree/bindings/mfd/syscon.yaml | 2 +
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 543 ++++++++++--------
> 2 files changed, 318 insertions(+), 227 deletions(-)
>
>
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
Hi all,
Gentle ping for this series:
https://lore.kernel.org/all/cover.1777058942.git.dawid.glazik@linux.intel.com/#t
I received Reviewed-by from Krzysztof Kozlowski (thank you).
Could I please get feedback/ack from maintainers on the remaining parts,
especially ASPEED DTS?
If preferred, I can respin/rebase the series.
Thanks,
Dawid Glazik
^ permalink raw reply
* Re: [PATCH v10 15/30] KVM: arm64: Support SME control registers
From: Mark Brown @ 2026-05-11 14:17 UTC (permalink / raw)
To: Mark Rutland
Cc: Marc Zyngier, Joey Gouly, Catalin Marinas, Suzuki K Poulose,
Will Deacon, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
Oliver Upton, Dave Martin, Fuad Tabba, Ben Horgan,
linux-arm-kernel, kvmarm, linux-kernel, kvm, linux-doc,
linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <af4bWxiOogfPz_dp@J2N7QTR9R3>
[-- Attachment #1: Type: text/plain, Size: 3635 bytes --]
On Fri, May 08, 2026 at 06:20:27PM +0100, Mark Rutland wrote:
> > +static bool access_smcr_el2(struct kvm_vcpu *vcpu,
> > + struct sys_reg_params *p,
> > + const struct sys_reg_desc *r)
> > +{
> > + vq = SYS_FIELD_GET(SMCR_ELx, LEN, smcr) + 1;
> > + vq = min(vq, vcpu_sme_max_vq(vcpu));
> > + smcr &= ~SMCR_ELx_LEN_MASK;
> > + smcr |= SYS_FIELD_PREP(SMCR_ELx, LEN, vq - 1);
> I'm not sure this sanitization is correct or necessary, and the same
> concern applies to ZCR_ELx.LEN.
> AFAICT, none of the values for the SMCR_ELx.LEN and ZCR_ELx.LEN fields
> are reserved or unallocated. Thus all the bits of those fields should be
> stateful, and a read should observe the last value written, regardless
> of the effective value of the field.
...
> Either what we're doing is wrong, or the architcture requires a
> clarification to say that values corresponding to unimplmented vector
> lengths are reserved.
> If those bit are always stateful, the the logic to sanitize the LEN
> field shouldn't live here, and that will need to happen when consuming
> the effective value.
Your understanding of how these fields work matches mine, and writing
unimplemented values is part of the documented procedure for enumerating
the set of supported vector lengths.
As you note this is duplicated from the handling of ZCR_ELx, it's not
clear to me why the code does this but I figured there must be some good
reason for doing things this way that I just wasn't seeing and that it
was safer to fit in with the existing code. The handling for vector
lengths in general and especially with NV was quite unclear,
particularly prior to your fixes in 59419f10045b (KVM: arm64: Eagerly
switch ZCR_EL{1,2}).
The changelog for b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
which introduced this for ZCR_ELx has a mention of mapping the requested
VL but it's not entirely clear to me what it means by that. It does
mean that we can just load guest ZCR_EL2 and get the correct behaviour
for guest EL1 and EL0 when loading the guest state so perhaps that might
be all there is to it.
My expectation would have been to restrict the guest EL1/0 VL when we
load state into the registers as you allude to, something more like the
below (off the top of my head and completely untested, I'll pull this
into a proper patch later):
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 98b2976837b1..ddf8c2246139 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
return;
if (vcpu_has_sve(vcpu)) {
+ zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+
/* A guest hypervisor may restrict the effective max VL. */
- if (is_nested_ctxt(vcpu))
- zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
- else
- zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
+ if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
+ zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
write_sysreg_el2(zcr_el2, SYS_ZCR);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 148fc3400ea8..b48f41acff82 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2874,9 +2874,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
return true;
}
- vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
- vq = min(vq, vcpu_sve_max_vq(vcpu));
- __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
+ __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval);
return true;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH v6 06/25] iommu/io-pgtable-arm: Rework to use the iommu-pages API
From: Jason Gunthorpe @ 2026-05-11 14:18 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <agG6n4CeuIMD57G1@google.com>
On Mon, May 11, 2026 at 11:16:47AM +0000, Mostafa Saleh wrote:
> > IDK, why? virt_to_phys() is part of the iommu-pages API, I'd just
> > leave it.. If you want to narrow it then #define it for pkvm when
> > compiling this file..
>
> It is not going to be part of the iommu-pages API, I meant in
> io-pgtable-arm, we will use something arm_lpae_virt_to_phys()...
> which is then implemented differently for pkvm.
Again why? I think the main goal should be to not mess up the normal
code.
#define virt_to_phys pkvm_virt_to_phys
Does that, we should be leaning into this pattern I think, not adding
unnecessary churn...
If anything is needed then it should be an iommu_pages function to
wrapper virt_to_phys() for use by iommu_pages uses but I'd rather
not..
Jason
^ permalink raw reply
* Re: [PATCH v6 08/25] KVM: arm64: iommu: Shadow host stage-2 page table
From: Jason Gunthorpe @ 2026-05-11 14:22 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <agG8XtrHUfWGy-kd@google.com>
On Mon, May 11, 2026 at 11:24:14AM +0000, Mostafa Saleh wrote:
> On Sat, May 09, 2026 at 08:27:14PM -0300, Jason Gunthorpe wrote:
> > On Mon, May 04, 2026 at 12:28:55PM +0000, Mostafa Saleh wrote:
> > > So far this is the list of requirements/changes needed share the
> > > stage-2 page table (besides the obvious: same page table format,
> > > granularity, endianness...)
> > >
> > > 1) HW BBM is not supported in the hypervisor page table, that’s
> > > because it can generate TLB conflict aborts, which the hypervisor
> > > can not handle because of the limited syndrome information.
> > > We can rely on FEAT_BBML3 which was newly introduced to work
> > > around that, it’s quite niche and not supported in KVM yet or
> > > have an allow list similar to the kernel
> > > (as in cpu_supports_bbml2_noabort()) which also limits the number
> > > of CPUs that can run this.
> >
> > Do you think pkvm will need BBM? Hitless replace of a PTE is already a
> > pretty advanced feature and the SMMU has its own support matrix there
> > too. Is it for shared/private conversion?
>
> Yes, we can break block on memory donation which is transfer of
> ownership to the hypervisor or a guest.
So you need BBM support on the SMMU too? That is probably a big
problem because the SMMU is often mismatched to the CPU :\
Also io-pgtable arm cannot trigger BBM behaviors, so how do you
implement it?
> > No.. once you turn on IO like this you don't have page faults
> > anymore. Everything must be permantently mapped into the SMMU view, it
> > can never be made non-present and you must run without page
> > faults. That's what you have in the io-pgtable constructed table,
> > right?
>
> Exactly, but the CPU page table doesn’t guarantee that, so we either
> have to handle page faults in the IOMMU, or completely change how KVM
> deals with stage-2 if we want to share the page table with the CPU.
So that's the real explanation, KVM cannot manage the S2 in the right
way so you can't share it. RMM/etc are managing the S2 without
pointless page faults so they can share it.
> > > Alternatively, we can pin the stage-2 pages, that would require some
> > > hypercalls, hacks to the driver/IOMMU API and possibly new semantics
> > > in the DMA-API for IDENTITY devices as they will still need to pin
> > > the pages as they are actually in stage-2 translation and not bypass.
> >
> > ?? Then how does this series work?
>
> This series works fine as it shadows the page table and doesn't share it
> with the CPU, so it fully populates the address space.
Which is why it is so weird that KVM is using a partially populated S2
when there is, and must, be a fully populated one for the SMMU. But I
understand there are reasons fo rthis.
Jason
^ permalink raw reply
* Re: [PATCH] watchdog: apple: Add "apple,t8103-wdt" compatible
From: Guenter Roeck @ 2026-05-11 14:22 UTC (permalink / raw)
To: Janne Grunau
Cc: Sven Peter, Neal Gompa, Wim Van Sebroeck, asahi, linux-arm-kernel,
linux-watchdog, linux-kernel, stable
In-Reply-To: <87766879-ca5e-44cc-a341-87b2afa70910@roeck-us.net>
On 5/11/26 07:04, Guenter Roeck wrote:
> On Wed, Dec 31, 2025 at 01:07:21PM +0100, Janne Grunau wrote:
>> After discussion with the devicetree maintainers we agreed to not extend
>> lists with the generic compatible "apple,wdt" anymore [1]. Use
>> "apple,t8103-wdt" as base compatible as it is the SoC the driver and
>> bindings were written for.
>>
>> [1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
>>
>> Fixes: 4ed224aeaf66 ("watchdog: Add Apple SoC watchdog driver")
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Neal Gompa <neal@gompa.dev>
>> Signed-off-by: Janne Grunau <j@jannau.net>
>
> Applied to my hwmon-next branch.
>
watchdog-next. Sorry for the confusion.
Guenter
> Thanks,
> Guenter
>
>> ---
>> This is split off from the v1 series adding Apple M2 Pro/Max/Ultra
>> device trees in [2].
>>
>> 2: https://lore.kernel.org/r/20250828-dt-apple-t6020-v1-0-507ba4c4b98e@jannau.net
>> ---
>> drivers/watchdog/apple_wdt.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>>
>> ---
>> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
>> change-id: 20251231-watchdog-apple-t8103-base-compat-8a623e9831b6
>>
>> Best regards,
>>
>> diff --git a/drivers/watchdog/apple_wdt.c b/drivers/watchdog/apple_wdt.c
>> index 66a158f67a712bbed394d660071e02140e66c2e5..6b9b0f9b05cedfd7fc5d0d79ba19ab356dc2a080 100644
>> --- a/drivers/watchdog/apple_wdt.c
>> +++ b/drivers/watchdog/apple_wdt.c
>> @@ -218,6 +218,7 @@ static int apple_wdt_suspend(struct device *dev)
>> static DEFINE_SIMPLE_DEV_PM_OPS(apple_wdt_pm_ops, apple_wdt_suspend, apple_wdt_resume);
>>
>> static const struct of_device_id apple_wdt_of_match[] = {
>> + { .compatible = "apple,t8103-wdt" },
>> { .compatible = "apple,wdt" },
>> {},
>> };
>
^ permalink raw reply
* Re: [PATCH v6 04/25] iommu/arm-smmu-v3: Move TLB range invalidation into common code
From: Jason Gunthorpe @ 2026-05-11 14:24 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <agHBby1qBvR6cmJY@google.com>
On Mon, May 11, 2026 at 11:45:51AM +0000, Mostafa Saleh wrote:
> On Sat, May 09, 2026 at 08:29:31PM -0300, Jason Gunthorpe wrote:
> > On Thu, May 07, 2026 at 09:40:00AM +0000, Mostafa Saleh wrote:
> > > But that doesn’t solve the problem, which is: At some point, whether
> > > eagerly from the page table code, through gather sync or a fancy
> > > invalidation array, the driver will need to populate a range
> > > invalidation command (tg, ttl, scale...) and this logic is better
> > > shared with the main driver which is this patch does.
> >
> > My point is this patch doesn't share enough. If you do need to issue
> > invalidations then share everything below the top level tlbi entry
> > point and don't try to make a pkvm version of the entire logic just by
> > ripping out the range logic.
> >
> > There is no reason for pkvm to need a different algorithm
> > here. Especially when you get to supporting ATS and multiple devices
> > and smmus you may as well just use the whole thing.
> >
> > Which is why I suggested to copy the entire call chain into a shared
> > file
>
> Agh, actually this seires doesn't deal with ATS, which I think is
> wrong, propably we have to issue CMDQ_OP_ATC_INV for the whole
> space on every S2 invalidation which has to be done per-SID and
> as it can't be done by VMID :/ or just hide ATS support from host for
> now, I will look into more for v7.
Hiding from the host is a fine solution to start with.
> But anyway, we don’t have to share any logic, the kernel driver
> is quite complicated as it is designed for a different use-case.
> Doing that makes the hypervisor unnecessary complicated and
> oversharing this logic makes the kernel driver less maintainable IMO.
invalidation is complicated, you should not try to open code your own
version. You really cannot make it any simpler than what is in the
driver, just use the code it is already decently modular.
Jason
^ permalink raw reply
* Re: [PATCH v6 05/25] iommu/arm-smmu-v3: Move IDR parsing to common functions
From: Jason Gunthorpe @ 2026-05-11 14:30 UTC (permalink / raw)
To: Mostafa Saleh
Cc: linux-arm-kernel, linux-kernel, kvmarm, iommu, catalin.marinas,
will, maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
joro, jean-philippe, mark.rutland, qperret, tabba, vdonnefort,
sebastianene, keirf
In-Reply-To: <CAFgf54rJqq_bJONpx85p+uB68i1oVAGZW40aZA1ufid_5fqwQw@mail.gmail.com>
> > Copying a bunch of functions into a shared .c file exactly as it is,
> > then compiling the shared file with some #ifdef'ery at is going to be
> > long term better than trying to mangle the whole thing to avoid using
> > any of the core types and not directly share the code, IMHO.
> >
>
> There isn't #ifdef'ery at the moment, that's what I was trying to
> avoid by introducing shared code.
Yeah, I think that may be a bad direction. Ultimately it feels like it
will be more burden to maintain this careful split, while some small
list of carefully selected #defines will let you reuse alot more with
no code changes and I think that is ultimately going to be better.
> What concerns me is how fragile that is, any change in the main struct
> can easily break the hypervisor, unlike if we have a clear shared code
> and defined API that is used by 2 entities.
> I will think more about this before v7 and see how intrusive it is.
IMHO so long as it is easy to include pkvm in the compilation I see no
issue with build testing the pkvm driver when working on smmuv3
driver. So I'm not worried about this, any breaks will be compile
breaks and can be delt with.
What I'd like is to minimize logic changes and maximimize re-use so
you don't have to make bad re-implementations. Like pkvm shouldn't be
building a weaker tlbi, it shouldn't have different logic for errata
and FEAT, it shouldn't be doing STE changes without the
hitless logic, etc, etc. All these things are easier to solve with
greater direct code re-use..
Thus I feel the trade of off 'use the code with no changed via
#define' is better than 'try to carefully cut away and avoid #define'
Jason
^ permalink raw reply
* Re: [PATCH 00/10] spi: Use FIELD_MODIFY() for bitfield operations
From: Mark Brown @ 2026-05-11 12:05 UTC (permalink / raw)
To: sunny.luo, xianwei.zhao, neil.armstrong, khilman, han.xu,
haibo.chen, mcoquelin.stm32, alexandre.torgue, lhjeff911,
hayashi.kunihiko, mhiramat, jbrunet, martin.blumenstingl,
Hans Zhang
Cc: linux-spi, linux-kernel, linux-amlogic, linux-arm-kernel, imx,
linux-stm32
In-Reply-To: <20260430155456.36998-1-18255117159@163.com>
On Thu, 30 Apr 2026 23:54:46 +0800, Hans Zhang wrote:
> spi: Use FIELD_MODIFY() for bitfield operations
>
> Replace open-coded bitfield modifications with the standard FIELD_MODIFY()
> macro across multiple SPI controller drivers. This improves readability and
> adds compile-time checking without functional changes.
>
> Each patch modifies a single driver, allowing independent review and
> application.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[01/10] spi: amlogic-spifc-a1: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/8262b1421ddd
[02/10] spi: amlogic-spisg: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/b69bfa593329
[03/10] spi: cadence-xspi: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/6fa473f4c5dc
[04/10] spi: meson-spicc: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/cfdab17cd2d7
[05/10] spi: nxp-xspi: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/0f2efc6d4938
[06/10] spi: sn-f-ospi: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/579fcc06576d
[07/10] spi: stm32-ospi: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/21ee6902a576
[08/10] spi: stm32-qspi: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/3e0530c087a9
[09/10] spi: sunplus-sp7021: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/673214ac9bcd
[10/10] spi: uniphier: Use FIELD_MODIFY()
https://git.kernel.org/broonie/spi/c/ce7984bea2a1
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Brian Masney @ 2026-05-11 14:36 UTC (permalink / raw)
To: a-christidis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp
In-Reply-To: <20260507-clk-sci-v2-1-38f59b48777a@ti.com>
On Thu, May 07, 2026 at 11:09:34AM -0500, a-christidis@ti.com wrote:
> From: Michael Walle <mwalle@kernel.org>
>
> The TISCI firmware will return 0 if the clock or consumer is not
> enabled although there is a stored value in the firmware. IOW a call to
> set rate will work but at get rate will always return 0 if the clock is
> disabled.
> The clk framework will try to cache the clock rate when it's requested
> by a consumer. If the clock or consumer is not enabled at that point,
> the cached value is 0, which is wrong. Thus, disable the cache
> altogether.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> Reviewed-by: Randolph Sapp <rs@ti.com>
> Reviewed-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Antonios Christidis <a-christidis@ti.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Jann Horn @ 2026-05-11 14:40 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Ard Biesheuvel, linux-arm-kernel, linux-kernel, Will Deacon,
Catalin Marinas, Mark Rutland, Ryan Roberts, Anshuman Khandual,
Liz Prucka, Seth Jenkins, Kees Cook, Mike Rapoport,
David Hildenbrand, Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <31252c1d-a98d-4635-ab61-ce5b649e256f@app.fastmail.com>
On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> I think we should simply do something along the lines of the below,
> considering that the size of a data object tends to correlate with
> its minimum alignment.
>
> I do find it rather puzzling that the compiler emits empty_zero_page
> *after* zero_page_pfn - ideally, we'd combine the below with
> -fdata-sections so that the linker sees all individual objects, but
> I suspect that would create some problems elsewhere.
>
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -452,7 +452,7 @@
> #define RO_AFTER_INIT_DATA \
> . = ALIGN(8); \
> __start_ro_after_init = .; \
> - *(.data..ro_after_init) \
> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
Oh, neat, I didn't realize that's possible. That seems like a nicer
approach... (Assuming that it doesn't cause cache efficiency issues
somehow, I imagine it could be possible that source-code-adjacent
objects should also be located next to each other for cache/TLB
efficiency... but I have no concrete reason to think that, just a
thought.)
^ permalink raw reply
* Re: [PATCH v4 01/15] clk: scmi: Fix clock rate rounding
From: Brian Masney @ 2026-05-11 14:44 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, sudeep.holla, philip.radford, james.quinlan,
f.fainelli, vincent.guittot, etienne.carriere, peng.fan,
michal.simek, geert+renesas, kuninori.morimoto.gx,
marek.vasut+renesas, Michael Turquette, Stephen Boyd
In-Reply-To: <20260508153300.2224715-2-cristian.marussi@arm.com>
On Fri, May 08, 2026 at 04:32:46PM +0100, Cristian Marussi wrote:
> While the do_div() helper used for rounding expects its divisor argument
> to be a 32bits quantity, the currently provided divisor parameter is a
> 64bit value that, as a consequence, is silently truncated and a possible
> source of bugs.
>
> Fix by using the proper div64_ul helper.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Fixes: 7a8655e19bdb ("clk: scmi: Fix the rounding of clock rate")
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ 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