* [PATCH] ARM: select HAVE_POSIX_CPU_TIMERS_TASK_WORK
From: Karl Mehltretter @ 2026-07-18 21:45 UTC (permalink / raw)
To: Russell King, Sebastian Andrzej Siewior
Cc: Karl Mehltretter, Arnd Bergmann, linux-rt-devel, linux-arm-kernel
Commit c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") enabled PREEMPT_RT
on ARM but did not select HAVE_POSIX_CPU_TIMERS_TASK_WORK. This leaves
CONFIG_POSIX_CPU_TIMERS_TASK_WORK disabled, so CPU timers expire in hard
IRQ context.
On PREEMPT_RT this makes run_posix_cpu_timers() take the sleeping
sighand->siglock:
BUG: sleeping function called from invalid context at spinlock_rt.c:48
rt_spin_lock from lock_task_sighand
lock_task_sighand from run_posix_cpu_timers
run_posix_cpu_timers from update_process_times
ARM handles TIF_NOTIFY_RESUME on all return-to-user paths, including v7-M.
ARM32 KVM host support was removed by commit 541ad0150ca4 ("arm: Remove
32bit KVM host support"), so the select need not be conditional on KVM.
Select it to defer POSIX CPU timer expiry to task context.
Reproduced with setrlimit(RLIMIT_CPU, ...) and a busy loop. The same path
is used by setitimer(ITIMER_PROF or ITIMER_VIRTUAL) and POSIX CPU timers
created with timer_create().
Fixes: c6e61c06d606 ("ARM: 9463/1: Allow to enable RT")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Found with a self-hosted syzkaller instance patched to fuzz kernels on
QEMU's versatilepb machine (ARM926EJ-S, ARMv5TE). Runtime-tested before
and after the change on that setup, and compile-tested mps2_defconfig
with PREEMPT_RT (NOMMU, CPU_V7M).
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9187240a02db..f073b5102d4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -133,6 +133,7 @@ config ARM
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_POSIX_CPU_TIMERS_TASK_WORK
select MMU_GATHER_RCU_TABLE_FREE if SMP && ARM_LPAE
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RSEQ
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ASoC: uniphier: Drop redundant error messages in probe
From: Mark Brown @ 2026-07-18 12:23 UTC (permalink / raw)
To: Kunihiko Hayashi, Jaroslav Kysela, Takashi Iwai, Liam Girdwood,
Masami Hiramatsu, phucduc.bui
Cc: Kuninori Morimoto, linux-sound, linux-kernel, linux-arm-kernel
In-Reply-To: <20260710110249.31830-1-phucduc.bui@gmail.com>
On Fri, 10 Jul 2026 18:02:49 +0700, phucduc.bui@gmail.com wrote:
> ASoC: uniphier: Drop redundant error messages in probe
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[1/1] ASoC: uniphier: Drop redundant error messages in probe
https://git.kernel.org/broonie/sound/c/c89b22faa9ba
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] iommu/io-pgtable-arm: Add support for contiguous hint bit
From: Jason Gunthorpe @ 2026-07-18 23:09 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Will Deacon, Vijayanand Jitta, Joerg Roedel (AMD), Robin Murphy,
linux-arm-msm, iommu, linux-kernel, linux-arm-kernel,
Prakash Gupta
In-Reply-To: <alvd9zPeXQVQ7l2l@google.com>
On Sat, Jul 18, 2026 at 08:11:35PM +0000, Mostafa Saleh wrote:
> On Wed, Jul 15, 2026 at 09:28:30AM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 15, 2026 at 01:03:22PM +0100, Will Deacon wrote:
> >
> > > From what I can tell, the fiddly parts for iommupt will be:
> > >
> > > 1. Hardware bugs / quirks. Some of the simpler ones could probably be
> > > handled but for the more invasive stuff like the Mali format
> > > format, io-pgtable will probably need to hang around. Perhaps
> > > it becomes io-pgtable-mali.c?
> >
> > I briefly looked at Mali a while back and it didn't seem so bad, but
> > that was for a GPU driver not the iommu so a bit different
> > issue. Exactly what the GPU drivers should be doing is less clear to
> > me, they don't really fit well with the iommu focused interface (eg
> > the memory preload issues/etc).
> >
> > > 2. The pKVM work from Mostafa. We'll probably end up with something
> > > separate at EL2 for this (ideally, just reusing the CPU page-table
> > > code when it learns about BBML3).
> >
> > Yeah, I'm not sure here, it isn't great that is adding another user
> > and open coding some of the logic (eg smmu_pgsize_idmap). It would be
> > much better if it could just use all the existing flow more directly
> > somehow.
>
> I was under the impression that io-pgtable-arm will remain the same,
> but if it is going to be removed (or at least the LPAE format) I need
> to figure out an alternative for pKVM:
I wasn't going to suggest you change anything with your series at this
point, just opining it is "not great", but I wouldn't object to
merging it as you've constructed it right now.
> - Compile iommupt for the hypervisor (similar to what we do with
> io-pgtable-arm in the SMMUv3 pKVM series which compiles in both)
> I am not sure how easy is that for iommupt, I have the SMMUv3
> iommupt series on my review list, I will check that.
It is probably similarish, I thought your new version was pretty clean
when I glanced at it.
> - Write a small IO page table implementation just for the hypervisor,
> that's not ideal as it would benefit also from features as CONTPTE.
You can do this pretty easially with the generic_pt and you can write
the thing exactly as you need. I wouldn't do this unless there was a
big mismatch with what iommu_domain provides.
Jason
^ permalink raw reply
* Re: [PATCH v7 2/3] iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround infrastructure
From: Jason Gunthorpe @ 2026-07-18 16:45 UTC (permalink / raw)
To: Nicolin Chen
Cc: Ashish Mhetre, catalin.marinas, will, corbet, skhan, robin.murphy,
joro, linux-arm-kernel, linux-doc, linux-kernel, iommu,
linux-tegra
In-Reply-To: <alqbxaKVYFX1BZR5@nvidia.com>
On Fri, Jul 17, 2026 at 02:16:53PM -0700, Nicolin Chen wrote:
> Given the use cases on Tegra264, instead of patching the iommufd
> path as this patch does, perhaps we should simply spit a WARN in
> arm_vsmmu_init():
Nope, in this case you need to make the errata discoverable through
the viommu info so the VMM can validate the right DT is used, or apply
the WAR itself before submitting commands to the kernel.
Some kind of new flag in the viommu struct I guess
Jason
^ permalink raw reply
* Re: [PATCH v8 0/9] iommu/arm-smmu-v3: Adopt the crashed kernel's stream table for kdump
From: Jason Gunthorpe @ 2026-07-18 16:20 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Nicolin Chen, will, robin.murphy, joro, kevin.tian, smostafa,
linux-arm-kernel, iommu, linux-kernel, jamien
In-Reply-To: <alqh_NVatGn84o0i@google.com>
On Fri, Jul 17, 2026 at 09:43:24PM +0000, Pranjal Shrivastava wrote:
> However, looking at your approach, I think I can slightly rework my
> preservation logic and instead of bloating the KHO ABI with physical
> addresses, I could re-use your exact table-walking logic during probe
> to parse the live L1/L2 structures directly from registers, identify
> the valid tables, and kho/dma_restore them. There could me small
> differences though, for example instead of memremap stuff, we'd have to
> use the kho/dma_restore API (which can be done by passing some op like
> the data structure writers we have?) Similarly, maybe reserving ASID/VMID
> can be potentially re-used as well..
I think this will be true for all the iommu drivers as they pretty
much all have this same kind of kdumpish adoption logic in one way or
another.
> for KHO), I wanted to start a discussion to see if it makes sense to
> factor this common code out into an arm-smmu-v3-kexec.c (or similar)?
Yeah maybe so
It sounds great this helps the live update project as well!
Jason
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: rockchip: enable HDMI RX audio capture on Orange Pi 5 Plus
From: Sebastian Reichel @ 2026-07-18 23:31 UTC (permalink / raw)
To: Igor Paunovic
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <20260718085728.6797-5-royalnet026@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
Hi,
On Sat, Jul 18, 2026 at 10:57:28AM +0200, Igor Paunovic wrote:
> Route the HDMI receiver audio to i2s7_8ch, the receive-only I2S
> interface dedicated to HDMI RX, through a simple-audio-card with the
> receiver as bitclock and frame master. Together with the audio
> capture support in the snps_hdmirx driver this exposes a capture-only
> ALSA card fed by the HDMI input.
>
> Tested on the Orange Pi 5 Plus with multiple HDMI sources: capture
> follows the source sample rate and stays in sync via the FIFO-level
> clock tracking in the driver.
>
> Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> ---
> New in v3.
>
> .../dts/rockchip/rk3588-orangepi-5-plus.dts | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> index 9950d11..d5840e1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> @@ -37,6 +37,22 @@
> };
> };
>
> + hdmiin-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "rockchip,hdmiin";
The name is exposed to userspace and visible to the user (e.g.
in alsamixer), but also used by Alsa UCM2. I suggest to use
"RK3588 HDMI-IN".
> + simple-audio-card,format = "i2s";
> + simple-audio-card,bitclock-master = <&hdmiin_codec>;
> + simple-audio-card,frame-master = <&hdmiin_codec>;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s7_8ch>;
> + };
> +
> + hdmiin_codec: simple-audio-card,codec {
> + sound-dai = <&hdmi_receiver 0>;
> + };
> + };
> +
Move the whole card definition to rk3588-extra.dtsi with a new label
(e.g. hdmi_receiver_sound) and add status = "disabled"; Then just do
&hdmi_receiver_sound {
status = "okay";
};
in the Orange Pi 5+ DT, i.e. just like the soundcards for HDMI
output. This reduces a lot of duplication as the soundcard is the
same on all boards considering there is a dedicated I2S channel for
it. It's disabled by default as some boards do not route the HDMI
receiver at all.
Greetings,
-- Sebastian
> ir-receiver {
> compatible = "gpio-ir-receiver";
> gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> @@ -247,6 +263,10 @@
> status = "okay";
> };
>
> +&i2s7_8ch {
> + status = "okay";
> +};
> +
> &led_blue_gpio {
> gpios = <&gpio3 RK_PA6 GPIO_ACTIVE_HIGH>;
> status = "okay";
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] PCI: imx6: enable ASPM L1 only iff CLKREQ# is supported
From: Michal Gorlas @ 2026-07-19 0:47 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Bjorn Helgaas, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel
Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM
states for devicetree platforms"), ASPM states are force enabled
on all devicetree platforms. This causes PCI devices on some iMX SoCs
(for e.g. iMX 8M Plus Kontron SMARC eval carrier) to enter L1 even
though CLKREQ# is not supported (and consequently supports-clkreq is
not set in pcie controller node of their DT), which causes the device to
never wake up from L1.
Hence, disable L1 capability in the LINKCAP register if supports-clkreq
is not set in the DT explicitly.
Note, the logic here is very similar to 613f3255a35a, only difference
is that leaving L0s enabled does not cause issues (at least
I never encountered them myself when testing on the device) as its
not dependent on CLKREQ# being physically there.
Since there is already a way of specifying its presence in the DT,
the driver should be aware and disable L1.
Fixes: f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms")
Signed-off-by: Michal Gorlas <michal.gorlas@9elements.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 98e1db751132..7471501fbf04 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1318,6 +1318,22 @@ static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool assert)
}
}
+static void imx_pcie_disable_l1(struct dw_pcie *pci)
+{
+ u32 val;
+ u8 offset;
+
+ offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+
+ dw_pcie_dbi_ro_wr_en(pci);
+
+ val = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
+ val &= ~PCI_EXP_LNKCAP_ASPM_L1;
+ dw_pcie_writel_dbi(pci, offset + PCI_EXP_LNKCAP, val);
+
+ dw_pcie_dbi_ro_wr_dis(pci);
+}
+
static int imx_pcie_host_init(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -1442,6 +1458,9 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
imx_setup_phy_mpll(imx_pcie);
+ if (!imx_pcie->supports_clkreq)
+ imx_pcie_disable_l1(pci);
+
return 0;
err_phy_off:
---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260713-l1-conditional-imx-c2bfd20ae085
Best regards,
--
Michal Gorlas <michal.gorlas@9elements.com>
^ permalink raw reply related
* [PATCH RESEND mt76 v2] wifi: mt76: mt7915: add thermal zone device registration
From: Ryan Leung @ 2026-07-19 2:14 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Ryan Leung
Register the mt7915 phy as a thermal zone sensor using
devm_thermal_of_zone_register() so that device tree thermal-zones
nodes can reference the Wi-Fi chip as a temperature source. This
allows the kernel thermal governor to control external cooling
devices such as PWM fans based on Wi-Fi chip temperature.
Registration is non-fatal: -ENODEV is returned when no
thermal-sensors DT property references this device, which is the
expected case on platforms without a thermal zone configured.
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
---
v2: Use phy->mt76->band_idx instead of hardcoded 0 as sensor ID
---
drivers/net/wireless/mediatek/mt76/mt7915/init.c | 30 ++++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/init.c b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
index 250c2d2479b0..6568d7b6bc0a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/init.c
@@ -177,6 +177,25 @@ static const struct thermal_cooling_device_ops mt7915_thermal_ops = {
.set_cur_state = mt7915_thermal_set_cur_throttle_state,
};
+static int mt7915_thermal_get_temp(struct thermal_zone_device *tz, int *temp)
+{
+ struct mt7915_phy *phy = thermal_zone_device_priv(tz);
+ int val;
+
+ mutex_lock(&phy->dev->mt76.mutex);
+ val = mt7915_mcu_get_temperature(phy);
+ mutex_unlock(&phy->dev->mt76.mutex);
+ if (val < 0)
+ return val;
+
+ *temp = val * 1000;
+ return 0;
+}
+
+static const struct thermal_zone_device_ops mt7915_tz_ops = {
+ .get_temp = mt7915_thermal_get_temp,
+};
+
static void mt7915_unregister_thermal(struct mt7915_phy *phy)
{
struct wiphy *wiphy = phy->mt76->hw->wiphy;
@@ -213,6 +232,17 @@ static int mt7915_thermal_init(struct mt7915_phy *phy)
phy->throttle_temp[MT7915_CRIT_TEMP_IDX] = MT7915_CRIT_TEMP;
phy->throttle_temp[MT7915_MAX_TEMP_IDX] = MT7915_MAX_TEMP;
+ phy->tzone = devm_thermal_of_zone_register(phy->dev->mt76.dev,
+ phy->mt76->band_idx, phy,
+ &mt7915_tz_ops);
+ if (IS_ERR(phy->tzone)) {
+ if (PTR_ERR(phy->tzone) != -ENODEV)
+ dev_warn(phy->dev->mt76.dev,
+ "failed to register thermal zone: %ld\n",
+ PTR_ERR(phy->tzone));
+ phy->tzone = NULL;
+ }
+
if (!IS_REACHABLE(CONFIG_HWMON))
return 0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h b/drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h
index bf1d915a3ca2..92e0f9f0169c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h
@@ -205,6 +205,7 @@ struct mt7915_phy {
struct ieee80211_vif *monitor_vif;
+ struct thermal_zone_device *tzone;
struct thermal_cooling_device *cdev;
u8 cdev_state;
u8 throttle_state;
---
base-commit: ac798f757d6475dc6fee2ec899980d6740714596
change-id: 20260718-mt7915-thermal-zone-device-registration-e6d7bdc80aa5
Best regards,
--
Ryan Leung <untilscour@protonmail.com>
^ permalink raw reply related
* [PATCH RFC] arm64: dts: allwinner: a523: Add SPDIF to x96qproplus device
From: Per Larsson @ 2026-07-19 3:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Cc: Per Larsson
When spdif support was added for the Allwinner A523 family of SoCs, only
two of the three possible pins were added to the dtsi, since the third
would clash with the first ethernet port (emac0)
However, some devices don't use emac0 and instead use emac1 for the only
available ethernet port, leaving the pin free to use for spdif.
Add it to the dtsi, and to such a device where this pin is used for spdif
Signed-off-by: Per Larsson <per@palvencia.se>
---
Marking this as RFC for a few reasons
1. This is my first submission, hoping everything is properly organized.
2. My testing setup is not the best: I get sound with this patch, but
the pulseaudio daemon needs to be restarted far too often.
Hopefully it's just something on this minirootfs. Testing welcome.
3. Not sure where to get the hash for a fixes tag or if that's even OK
---
.../arm64/boot/dts/allwinner/sun55i-a523.dtsi | 7 ++++++
.../dts/allwinner/sun55i-h728-x96qpro+.dts | 24 +++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index ca6a16807049..7370e8ed24ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -216,6 +216,13 @@ spdif_out_pb_pin: spdif-pb-pin {
allwinner,pinmux = <2>;
};
+ /omit-if-no-ref/
+ spdif_out_ph_pin: spdif-ph-pin {
+ pins = "PH7";
+ function = "spdif";
+ allwinner,pinmux = <4>;
+ };
+
/omit-if-no-ref/
spdif_out_pi_pin: spdif-pi-pin {
pins = "PI10";
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
index a96927fbdadd..b172985583f8 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
@@ -44,6 +44,24 @@ reg_vcc3v3: vcc3v3 {
vin-supply = <®_vcc5v>;
regulator-always-on;
};
+
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "spdif-out";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
&ehci0 {
@@ -275,6 +293,12 @@ &r_pio {
vcc-pm-supply = <®_aldo3>;
};
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_out_ph_pin>;
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.48.1
^ permalink raw reply related
* [PATCH v5 0/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu
Add mainline support for the ArmSoM CM5, an RK3576 compute module, and
its CM5-IO carrier board.
Patch 1 adds the binding, patch 2 the module dtsi and the carrier dts.
The on-module YT8531 PHY has no crystal and takes its 25 MHz reference
from the SoC. Following review of v4, the reference is now handled the
way Andrew Lunn and Maxime Chevallier asked for: the PHY is the consumer
and enables the clock itself. That needs a small motorcomm change sent
to netdev [1]; the clock is optional so this DTS still applies without
it. The earlier dwmac-rk MAC-side patch is dropped.
Tested on a CM5-IO with [1] applied: the YT8531 links at 1000 Mbit/s;
RK806, HYM8563, eMMC, microSD, the USB3 hub and PCIe all probe.
dtbs_check is clean.
Changes in v5:
- The 25 MHz reference is now consumed by the PHY, not the MAC. The PHY
node gets its clock back (clocks = <&cru REFCLKO25M_GMAC0_OUT>) and is
named explicitly (ethernet-phy-id4f51.e91b) so it is instantiated from
the DT without an MDIO ID probe, which it cannot answer before the
clock runs. &gmac0 drops clk_mac_refout and inherits the SoC clocks.
This reverses the v4 removal of the PHY-node clock, which was the wrong
direction.
- Enable &sai6, the I2S CPU DAI the HDMI sound card needs (already in v4;
re-tested here, HDMI audio card registers).
Changes in v4:
- phy-mode = "rgmii-id", drop the MAC tx_delay/rx_delay; the PHY adds
both delays (Andrew Lunn). Re-tested at 1000 Mbit/s.
- Pick up Krzysztof's Acked-by on patch 1.
Changes in v3:
- Remove the ES8388 codec from the header and the i2c0 comment; use gpios
in the vcc_3v3_pcie regulator.
Changes in v2:
- Fix the Type-C DP alt-mode node, move the FUSB302 role-switch endpoint
into the connector, drop the ES8388 node and dead pinctrls, rename the
wifi pinctrl node, and describe the PHY reset at the MDIO bus level.
[1] net: phy: motorcomm: enable the reference clock for YT8531
Jiaxing Hu (2):
dt-bindings: arm: rockchip: Add ArmSoM CM5 and CM5-IO
arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
.../devicetree/bindings/arm/rockchip.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3576-armsom-cm5-io.dts | 402 +++++++++++++
.../boot/dts/rockchip/rk3576-armsom-cm5.dtsi | 558 ++++++++++++++++++
4 files changed, 968 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: arm: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu, Krzysztof Kozlowski
In-Reply-To: <20260719034611.3623066-1-gahing@gahingwoo.com>
Add compatibles for the ArmSoM CM5, an RK3576 compute module, and its
CM5-IO carrier board.
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde186..5c7697f4d 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -71,6 +71,13 @@ properties:
- const: ariaboard,photonicat
- const: rockchip,rk3568
+ - description: ArmSoM CM5 Module based boards
+ items:
+ - enum:
+ - armsom,cm5-io
+ - const: armsom,cm5
+ - const: rockchip,rk3576
+
- description: ArmSoM Sige1 board
items:
- const: armsom,sige1
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu
In-Reply-To: <20260719034611.3623066-1-gahing@gahingwoo.com>
Add the ArmSoM CM5, an RK3576 compute module (rk3576-armsom-cm5.dtsi),
and its CM5-IO carrier (rk3576-armsom-cm5-io.dts). The module has the
RK806 PMIC, HYM8563 RTC, eMMC, GMAC0 with an on-module MotorComm YT8531
PHY, and the SDIO bus for the on-module WiFi. The carrier adds HDMI, a
GbE RJ45, two USB-A ports behind a USB3 hub, USB-C with FUSB302 and DP
alt-mode, a PCIe 2.0 x1 M.2 slot, microSD, status LEDs and a 40-pin
header.
The YT8531 has no crystal and takes the SoC 25 MHz reference
(REFCLKO25M_GMAC0_OUT), described as a clock on the PHY node and enabled
by the PHY driver. The PHY is named explicitly so it is instantiated
from the device tree without an MDIO ID probe, which the PHY cannot
answer until that clock is running. Its reset is described at the MDIO
bus level so mdiobus releases it before the scan.
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3576-armsom-cm5-io.dts | 402 +++++++++++++
.../boot/dts/rockchip/rk3576-armsom-cm5.dtsi | 558 ++++++++++++++++++
3 files changed, 961 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70..3ec0b6e20 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-display-vz.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-100ask-dshanpi-a1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
new file mode 100644
index 000000000..40d9be0c6
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * ArmSoM CM5-IO - official carrier board for the ArmSoM CM5 (RK3576) module.
+ *
+ * Carrier provides:
+ * - Full-size HDMI 2.1 (HDMI TX via HDPTX PHY)
+ * - Gigabit Ethernet RJ45 (GMAC0 + on-module YT8531)
+ * - 2x USB-A behind a USB3 hub (combphy1 + u2phy1)
+ * - USB-C with PD/altmode (FUSB302 on i2c0, combphy0 + USBDP PHY)
+ * - M.2 PCIe 2.0 x1 slot (combphy0 as PCIe lane)
+ * - microSD card slot
+ * - Green/red status LEDs, 40-pin RPi-compatible header
+ * - 12 V DC barrel jack
+ *
+ * Copyright (c) 2024 ArmSoM
+ * Copyright (c) 2026 Jiaxing Hu <gahing@gahingwoo.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3576-armsom-cm5.dtsi"
+
+/ {
+ model = "ArmSoM CM5-IO";
+ compatible = "armsom,cm5-io", "armsom,cm5", "rockchip,rk3576";
+
+ aliases {
+ ethernet0 = &gmac0;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial0:1500000n8";
+ };
+
+ /* Full-size HDMI Type-A connector, driven by the SoC HDMI TX. */
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ /*
+ * Carrier status LEDs (schematic ARMSOM-CM5-IO-1V1_20240829):
+ * green - GPIO2 PD0 (net LED_GREEN_EN)
+ * red - GPIO2 PD1 (net LED_RED_EN)
+ */
+ leds: leds {
+ compatible = "gpio-leds";
+
+ led_green: led-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio2 RK_PD0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_green_en>;
+ default-state = "on";
+ };
+
+ led_red: led-red {
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_FAULT;
+ gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_red_en>;
+ default-state = "off";
+ };
+ };
+
+ /* Carrier power tree: 12 V barrel jack -> 5 V -> peripheral rails. */
+ vcc_12v0_dcin: regulator-vcc-12v0-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_12v0_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc_5v0_sys: regulator-vcc-5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_12v0_dcin>;
+ };
+
+ vcc_5v0_device: regulator-vcc-5v0-device {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0_device";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_12v0_dcin>;
+ };
+
+ /* PCIe 3.3 V for the M.2 slot, gated by GPIO0 PC3. */
+ vcc_3v3_pcie: regulator-vcc-3v3-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_pwr_en>;
+ regulator-name = "vcc_3v3_pcie";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpios = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <5000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ /* USB-C / OTG 5 V, gated by GPIO2 PB6. */
+ vcc_5v0_typec0: regulator-vcc-5v0-typec0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio2 RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_otg0_pwren>;
+ regulator-name = "vcc_5v0_typec0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0_device>;
+ };
+
+ /* USB-A host 5 V (through the hub), gated by GPIO4 PB0. */
+ vcc_5v0_usbhost: regulator-vcc-5v0-usbhost {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_host_pwren>;
+ regulator-name = "vcc_5v0_usbhost";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0_device>;
+ };
+};
+
+/*
+ * ComboPHY0 -> PCIe lane (M.2 slot); ComboPHY1 -> USB3 lane (USB-A hub).
+ */
+&combphy0_ps {
+ status = "okay";
+};
+
+&combphy1_psu {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&hdptxphy {
+ status = "okay";
+};
+
+/* SAI6 is the I2S CPU DAI feeding the HDMI audio path. */
+&sai6 {
+ status = "okay";
+};
+
+/* I2C0: FUSB302 USB-C PD controller @ 0x22, pinctrl i2c0m1 (PC4/PC5). */
+&i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0m1_xfer>;
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vcc_5v0_typec0>;
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ op-sink-microwatt = <1000000>;
+ sink-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_FIXED(9000, 3000, PDO_FIXED_USB_COMM)
+ PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+
+ altmodes {
+ displayport {
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0xffffffff>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_orien_sw: endpoint {
+ remote-endpoint = <&usbdp_phy_orientation_switch>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_role_sw: endpoint {
+ remote-endpoint = <&usb_drd0_role_switch>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dp_altmode_mux: endpoint {
+ remote-endpoint = <&usbdp_phy_dp_altmode_mux>;
+ };
+ };
+ };
+ };
+ };
+};
+
+/*
+ * PCIe 2.0 x1 M.2 slot. Reset GPIO2 PB1, power vcc_3v3_pcie (GPIO0 PC3).
+ */
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_reset>;
+ reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3_pcie>;
+ status = "okay";
+};
+
+/* microSD card slot. */
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-sdio;
+ no-mmc;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+};
+
+&u2phy0_otg {
+ phy-supply = <&vcc_5v0_typec0>;
+ status = "okay";
+};
+
+&u2phy1 {
+ status = "okay";
+};
+
+&u2phy1_otg {
+ phy-supply = <&vcc_5v0_usbhost>;
+ status = "okay";
+};
+
+/* Debug UART0 on the 40-pin header. */
+&uart0 {
+ pinctrl-0 = <&uart0m0_xfer>;
+ status = "okay";
+};
+
+/* USB DRD0: USB-C (USBDP SuperSpeed + USB2 HS), OTG with FUSB302 role-switch. */
+&usb_drd0_dwc3 {
+ dr_mode = "otg";
+ usb-role-switch;
+ status = "okay";
+
+ port {
+ usb_drd0_role_switch: endpoint {
+ remote-endpoint = <&usbc0_role_sw>;
+ };
+ };
+};
+
+/* USB DRD1: USB-A ports behind the hub (combphy1 SuperSpeed + USB2 HS). */
+&usb_drd1_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbdp_phy {
+ status = "okay";
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy_orientation_switch: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_orien_sw>;
+ };
+
+ usbdp_phy_dp_altmode_mux: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dp_altmode_mux>;
+ };
+ };
+};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
+
+&pinctrl {
+ leds {
+ /* GPIO2 PD0 - green carrier LED */
+ led_green_en: led-green-en {
+ rockchip,pins = <2 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ /* GPIO2 PD1 - red carrier LED */
+ led_red_en: led-red-en {
+ rockchip,pins = <2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ /* GPIO0 PC3 - PCIe power enable */
+ pcie_pwr_en: pcie-pwr-en {
+ rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ /* GPIO2 PB1 - PCIe PERST# */
+ pcie_reset: pcie-reset {
+ rockchip,pins = <2 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb {
+ /* GPIO4 PB0 - USB host 5V enable */
+ usb_host_pwren: usb-host-pwren {
+ rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ /* GPIO2 PB6 - USB OTG / Type-C 5V enable */
+ usb_otg0_pwren: usb-otg0-pwren {
+ rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ /* GPIO0 PB4 - FUSB302 INT# (active-low) */
+ usbc0_int: usbc0-int {
+ rockchip,pins = <0 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
new file mode 100644
index 000000000..b6977b973
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
@@ -0,0 +1,558 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * ArmSoM CM5 - Rockchip RK3576 compute module (Raspberry Pi CM4 form factor).
+ *
+ * Common to all CM5 carriers. The carrier .dts includes this file, sets the
+ * board model/compatible, and adds carrier-specific peripherals.
+ *
+ * On-module devices:
+ * - RK806 PMIC on I2C1
+ * - HYM8563 RTC on I2C2
+ * - eMMC (SDHCI)
+ * - GMAC0 + MotorComm YT8531 Gigabit Ethernet PHY (RGMII)
+ * - SYN43752 WiFi 6 + BT 5.x (SDIO + UART4)
+ *
+ * Copyright (c) 2024 ArmSoM
+ * Copyright (c) 2026 Jiaxing Hu <gahing@gahingwoo.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3576.dtsi"
+
+/ {
+ compatible = "armsom,cm5", "rockchip,rk3576";
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_1v2_ufs_vccq_s0: regulator-vcc-1v2-ufs-vccq-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v2_ufs_vccq_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_1v8_s0: regulator-vcc-1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
+
+ vcc_1v8_ufs_vccq2_s0: regulator-vcc-1v8-ufs-vccq2-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8_ufs_vccq2_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
+
+ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_2v0_pldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_3v3_s0: regulator-vcc-3v3-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_ufs_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ /*
+ * WiFi power sequencer for SYN43752. Reset GPIO1 PC6 active-low,
+ * clock from the HYM8563 RTC oscillator.
+ */
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_reg_on>;
+ reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+/*
+ * GMAC0 drives an on-module MotorComm YT8531. The PHY has no local crystal and
+ * takes the SoC 25 MHz reference (REFCLKO25M_GMAC0_OUT); ethm0_clk0_25m_out
+ * routes that clock to the pad, and the PHY node consumes and enables it.
+ */
+&gmac0 {
+ phy-mode = "rgmii-id";
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy0>;
+ phy-supply = <&vcc_3v3_s3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð0m0_miim
+ ð0m0_tx_bus2
+ ð0m0_rx_bus2
+ ð0m0_rgmii_clk
+ ð0m0_rgmii_bus
+ ðm0_clk0_25m_out>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
+/* I2C1: RK806 PMIC @ 0x23 (interrupt on GPIO0 PA6). */
+&i2c1 {
+ status = "okay";
+
+ pmic@23 {
+ compatible = "rockchip,rk806";
+ reg = <0x23>;
+
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA6 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+ system-power-controller;
+
+ vcc1-supply = <&vcc_5v0_sys>;
+ vcc2-supply = <&vcc_5v0_sys>;
+ vcc3-supply = <&vcc_5v0_sys>;
+ vcc4-supply = <&vcc_5v0_sys>;
+ vcc5-supply = <&vcc_5v0_sys>;
+ vcc6-supply = <&vcc_5v0_sys>;
+ vcc7-supply = <&vcc_5v0_sys>;
+ vcc8-supply = <&vcc_5v0_sys>;
+ vcc9-supply = <&vcc_5v0_sys>;
+ vcc10-supply = <&vcc_5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc_5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc_5v0_sys>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_cpu_big_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_big_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd_gpu_s0: dcdc-reg5 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic_s0: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <800000>;
+ regulator-name = "vdd_logic_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd_ddr_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca_1v8_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo2_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo2_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdda_1v2_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcca_3v3_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo6_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdda_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_ddr_pll_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v75_hdmi_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "vdda0v75_hdmi_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_0v85_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdda_0v75_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+/* I2C2: HYM8563 RTC @ 0x51 (interrupt on GPIO0 PA0). */
+&i2c2 {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hym8563_int>;
+ wakeup-source;
+ #clock-cells = <0>;
+ };
+};
+
+/*
+ * The PHY reset has to be described at the MDIO bus level: mdiobus releases a
+ * bus level reset before it scans for PHY IDs, whereas the per-PHY reset-gpios
+ * is only applied by phylib once the PHY has already been found, which never
+ * happens while the YT8531 is still held in reset.
+ *
+ * The compatible names the YT8531 explicitly so phylib instantiates the PHY
+ * from the device tree without an MDIO ID probe; the crystal-less PHY does not
+ * answer on MDIO until its driver has enabled the reference clock below.
+ */
+&mdio0 {
+ reset-gpios = <&gpio2 RK_PB3 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <20000>;
+ reset-post-delay-us = <100000>;
+
+ rgmii_phy0: phy@1 {
+ compatible = "ethernet-phy-id4f51.e91b",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ clocks = <&cru REFCLKO25M_GMAC0_OUT>;
+ };
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8_s0>;
+ status = "okay";
+};
+
+/* eMMC: on-module, HS400 200 MHz with enhanced strobe. */
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ max-frequency = <200000000>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sdio;
+ no-sd;
+ non-removable;
+ /delete-property/ supports-cqe;
+ status = "okay";
+};
+
+/* SDIO: SYN43752 WiFi, power-sequenced by sdio_pwrseq, clock from HYM8563. */
+&sdio {
+ bus-width = <4>;
+ cap-sdio-irq;
+ disable-wp;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-sd;
+ no-mmc;
+ non-removable;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ wakeup-source;
+ status = "okay";
+};
+
+/* UART4: Bluetooth (SYN43752). */
+&uart4 {
+ pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn &uart4m1_rtsn>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&pinctrl {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ wireless-wlan {
+ /* GPIO1 PC6 - WiFi power enable / reset (sdio_pwrseq) */
+ wifi_reg_on: wifi-reg-on {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] net: stmmac: dwmac-rk: enable the reference clock for output mode
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: maxime.chevallier
Cc: andrew, davem, edumazet, kuba, pabeni, heiko, netdev,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <da7d4ee0-8122-4839-b807-5d23ee6aeef7@bootlin.com>
> You've taken my review into account (thanks :) ), but you're failing to
> address Andrew's comment.
>
> The PHY should be the one requesting the MAC to output the refclk, in
> that case the MAC will act as a clock provider [...]
You are both right, and I am sorry I missed Andrew's point on v1. The MAC
should not own the PHY's clock.
I have dropped this series. Instead the motorcomm driver now enables the
reference clock itself, which is the consumer that needs it:
https://lore.kernel.org/all/20260719034555.3623003-1-gahing@gahingwoo.com/
The device tree names the YT8531 explicitly so the PHY is instantiated
without an MDIO ID probe, which it cannot answer before that clock runs;
the DTS goes to the rockchip tree. Tested on an ArmSoM CM5-IO: the PHY
links at 1000 Mbit/s with no dwmac-rk change at all.
Thanks for the review,
Jiaxing
^ permalink raw reply
* [PATCH] usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed
From: Fan Wu @ 2026-07-19 4:28 UTC (permalink / raw)
To: linux-usb
Cc: gregkh, nicolas.ferre, alexandre.belloni, claudiu.beznea,
linux-arm-kernel, linux-kernel, stable, Fan Wu
In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a
self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and
at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via
mod_timer(). Both recover the same udc through container_of and dereference
it on every iteration.
Neither teardown path cancels this cycle. udc is devm-allocated, so it is
freed after at91udc_remove() returns, and is likewise freed when probe
fails and devres runs. A timer callback or work item that is pending or
running at either point dereferences the freed udc.
Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and
from the usb_add_gadget_udc() failure path in probe; the remaining probe
error paths fail before the timer is armed. timer_shutdown_sync() waits
for a running callback and clears timer->function, which makes the work
handler's mod_timer() a permanent no-op; cancel_work_sync() then drains
any pending or running work whose re-arm attempt now does nothing. The
timer must be shut down first, since cancelling the work alone would let
the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and
work_struct are never initialized.
This does not require a fault; a normal driver unbind can interleave with
an already queued work item.
This issue was found by an in-house static analysis tool.
Fixes: 4037242c4f5f ("ARM: 6209/3: at91_udc: Add vbus polarity and polling mode")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
drivers/usb/gadget/udc/at91_udc.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c
index 5aa360ba4..8e5d7fb71 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1794,6 +1794,19 @@ static void at91udc_of_init(struct at91_udc *udc, struct device_node *np)
udc->caps = match->data;
}
+/*
+ * The work handler re-arms this timer, so shut the timer down before
+ * draining the work; otherwise it restarts the polling cycle.
+ */
+static void at91_udc_shutdown_vbus_timer(struct at91_udc *udc)
+{
+ if (!(udc->board.vbus_pin && udc->board.vbus_polled))
+ return;
+
+ timer_shutdown_sync(&udc->vbus_timer);
+ cancel_work_sync(&udc->vbus_timer_work);
+}
+
static int at91udc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1907,7 +1920,7 @@ static int at91udc_probe(struct platform_device *pdev)
}
retval = usb_add_gadget_udc(dev, &udc->gadget);
if (retval)
- goto err_unprepare_iclk;
+ goto err_shutdown_vbus;
dev_set_drvdata(dev, udc);
device_init_wakeup(dev, 1);
create_debug_file(udc);
@@ -1915,6 +1928,8 @@ static int at91udc_probe(struct platform_device *pdev)
INFO("%s version %s\n", driver_name, DRIVER_VERSION);
return 0;
+err_shutdown_vbus:
+ at91_udc_shutdown_vbus_timer(udc);
err_unprepare_iclk:
clk_unprepare(udc->iclk);
err_unprepare_fclk:
@@ -1933,6 +1948,9 @@ static void at91udc_remove(struct platform_device *pdev)
DBG("remove\n");
usb_del_gadget_udc(&udc->gadget);
+
+ at91_udc_shutdown_vbus_timer(udc);
+
if (udc->driver) {
dev_err(&pdev->dev,
"Driver still in use but removing anyhow\n");
--
2.34.1
^ permalink raw reply related
* Re: [RFC v3 2/2] arm64: kprobes: Allow reentering kprobes while single-stepping
From: Masami Hiramatsu @ 2026-07-19 5:51 UTC (permalink / raw)
To: Hongyan Xia
Cc: Pu Hu, Jiazi Li, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org, naveen@kernel.org,
mhiramat@kernel.org, yang@os.amperecomputing.com, Will Deacon,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org,
linux-trace-kernel@vger.kernel.org
In-Reply-To: <be182a18-4cea-445d-a319-1ed3a6c17598@transsion.com>
On Fri, 17 Jul 2026 11:31:31 +0000
Hongyan Xia <hongyan.xia@transsion.com> wrote:
> On 7/17/2026 7:01 PM, Will Deacon wrote:
> > On Fri, Jul 17, 2026 at 01:51:12AM +0000, Hongyan Xia wrote:
> >> On 7/16/2026 11:20 PM, Will Deacon wrote:
> >>> On Thu, Jul 16, 2026 at 02:38:58PM +0000, Pu Hu wrote:
> >>>> On 7/16/2026 9:24 PM, Will Deacon wrote:
> >>>>> On Fri, Jul 10, 2026 at 06:32:55AM +0000, Pu Hu wrote:
> >>>>>> From: Pu Hu <hupu@transsion.com>
> >>>>>>
> >>>>>> A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This
> >>>>>> can happen when tracing or perf code runs from the debug exception path
> >>>>>> while the first kprobe is preparing or executing its out-of-line
> >>>>>> single-step instruction.
> >>>>>
> >>>>> I don't understand this part. The single-step runs with debug exceptions
> >>>>> disabled (kprobes_save_local_irqflag() sets PSTATE.D) so how do we end
> >>>>> up taking one?
> >>>>
> >>>> You are right that the single-step runs with debug exceptions disabled.
> >>>> However, the case I was referring to is not a hardware breakpoint or a
> >>>> software-step exception, but another Breakpoint Instruction exception
> >>>> generated by executing a BRK instruction. A BRK instruction exception is
> >>>> not masked by PSTATE.D, so it can still be taken while handling a kprobe.
> >>>>
> >>>> As far as I understand the architecture, there are two different cases here:
> >>>>
> >>>> - Breakpoint Instruction exceptions, generated by executing a BRK
> >>>> instruction.
> >>>> - Breakpoint exceptions, generated by the debug logic, for example by
> >>>> programmed breakpoint registers.
> >>>>
> >>>> PSTATE.D masks debug exceptions such as hardware breakpoints,
> >>>> watchpoints and software-step exceptions, but it does not mask
> >>>> Breakpoint Instruction exceptions generated by BRK. This also seems
> >>>> consistent with the pseudocode for BRK,
> >>>> Arch64.SoftwareBreakpoint(imm16), which does not appear to check
> >>>> PSTATE.D before taking the exception.
> >>>>
> >>>> Therefore, even if kprobes_save_local_irqflag() sets PSTATE.D while
> >>>> handling the first kprobe, if the code executed from that path reaches
> >>>> another instruction patched with BRK, it can still take a Breakpoint
> >>>> Instruction exception. In other words, the nested case I mentioned is
> >>>> another kprobe BRK being hit, not a hardware debug exception or a
> >>>> software-step exception.
> >>>
> >>> Yes, that's correct, but if we're doing the out-of-line step, how do we
> >>> end up executing a BRK? Or are you saying that it's the kprobes
> >>> BRK64_OPCODE_KPROBES_SS instruction that we use to implement the
> >>> single-step that is the problem? If so, how does taking that exception
> >>> result in us executing tracing or perf code?
> >>>
> >>> Sorry for all the questions, I just haven't understood what's going on
> >>> here from the commit message.
> >>
> >> The key is that, when you use 'perf --call-graph dwarf' to sample
> >> certain events, kernel perf code will sample a piece of user stack each
> >> time those events are hit, and copy_to/from_user() triggers page faults.
> >> Say you are profiling preempt_enable events:
> >>
> >> 1st BRK -> preempt_disable() -> debug_exception() -> set SS state ->
> >> preempt_enable() -> triggers perf -> perf_sample() -> sample user stack
> >> using copy_to/from_user() -> page fault or 2nd BRK on the page fault path.
> >>
> >> The key is perf sampling the user stack while the 1st BRK is still
> >> running. When a page fault is hit, a can of worms is released, including
> >> a possible 2nd BRK.
> >
> > Thanks. So perf is run synchronously from the debug exception entry path,
>
> Yes, exactly.
>
> > rather than because of a second exception taking place. Got it. But then
> > it sounds like we should really make the debug exception handling path (at
> > least, the part that runs for handling the kprobe step) noinstr to avoid
> > getting into this state to begin with. Is that practical?
>
> Not sure about making the whole path noinstr (@Masami might have a
> better opinion on this than me). Personally I don't mind either
> disallowing it or making it correct.
Yeah I agree with making it noinstr.
>
> But it might be a good idea not to diverge too much between ISAs. This
> patch is pretty much mirroring what the x86 side handles this situation.
I don't mind modifying how it is handled in each architecture, since
this part is too much depending on the ISA.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 4/4] arm64: dts: rockchip: enable HDMI RX audio capture on Orange Pi 5 Plus
From: Igor Paunovic @ 2026-07-19 7:12 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <alwKdkNsMi9L4ZiY@venus>
Hi Sebastian,
Thanks -- both make sense and both are done for v4:
The card is renamed to "RK3588 HDMI-IN".
The card definition moved into rk3588-extra.dtsi as
hdmi_receiver_sound, disabled by default, mirroring the hdmi1_sound
node that already lives in that file -- and the Orange Pi 5 Plus dts
now only flips it (and i2s7_8ch) to "okay".
I'll hold v4 until Dmitry's testing round on the driver side so
everything lands in one respin.
Igor
On Sun, Jul 19, 2026 at 1:32 AM Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hi,
>
> On Sat, Jul 18, 2026 at 10:57:28AM +0200, Igor Paunovic wrote:
> > Route the HDMI receiver audio to i2s7_8ch, the receive-only I2S
> > interface dedicated to HDMI RX, through a simple-audio-card with the
> > receiver as bitclock and frame master. Together with the audio
> > capture support in the snps_hdmirx driver this exposes a capture-only
> > ALSA card fed by the HDMI input.
> >
> > Tested on the Orange Pi 5 Plus with multiple HDMI sources: capture
> > follows the source sample rate and stays in sync via the FIFO-level
> > clock tracking in the driver.
> >
> > Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> > ---
> > New in v3.
> >
> > .../dts/rockchip/rk3588-orangepi-5-plus.dts | 20 +++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > index 9950d11..d5840e1 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> > @@ -37,6 +37,22 @@
> > };
> > };
> >
> > + hdmiin-sound {
> > + compatible = "simple-audio-card";
> > + simple-audio-card,name = "rockchip,hdmiin";
>
> The name is exposed to userspace and visible to the user (e.g.
> in alsamixer), but also used by Alsa UCM2. I suggest to use
> "RK3588 HDMI-IN".
>
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,bitclock-master = <&hdmiin_codec>;
> > + simple-audio-card,frame-master = <&hdmiin_codec>;
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <&i2s7_8ch>;
> > + };
> > +
> > + hdmiin_codec: simple-audio-card,codec {
> > + sound-dai = <&hdmi_receiver 0>;
> > + };
> > + };
> > +
>
> Move the whole card definition to rk3588-extra.dtsi with a new label
> (e.g. hdmi_receiver_sound) and add status = "disabled"; Then just do
>
> &hdmi_receiver_sound {
> status = "okay";
> };
>
> in the Orange Pi 5+ DT, i.e. just like the soundcards for HDMI
> output. This reduces a lot of duplication as the soundcard is the
> same on all boards considering there is a dedicated I2S channel for
> it. It's disabled by default as some boards do not route the HDMI
> receiver at all.
>
> Greetings,
>
> -- Sebastian
>
> > ir-receiver {
> > compatible = "gpio-ir-receiver";
> > gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> > @@ -247,6 +263,10 @@
> > status = "okay";
> > };
> >
> > +&i2s7_8ch {
> > + status = "okay";
> > +};
> > +
> > &led_blue_gpio {
> > gpios = <&gpio3 RK_PA6 GPIO_ACTIVE_HIGH>;
> > status = "okay";
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver
From: Marc Zyngier @ 2026-07-19 7:47 UTC (permalink / raw)
To: Ryan Roberts
Cc: Will Deacon, Greg Kroah-Hartman, Arnd Bergmann, Catalin Marinas,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet,
linux-kernel, linux-arm-kernel, dri-devel, linux-doc, oupton, hch,
jgg
In-Reply-To: <a39b2bef-8fb5-444d-8ab8-3882224a3311@arm.com>
On Fri, 17 Jul 2026 13:33:07 +0100,
Ryan Roberts <ryan.roberts@arm.com> wrote:
>
> On 17/07/2026 13:09, Marc Zyngier wrote:
> > Thanks Will for roping me in.
>
> Sorry - I intentionally didn't include you because last time we spoke you said
> you were only really interested in discussions on the virt side of things and I
> didn't want to spam your inbox. Perhaps the wrong decision...
I'm indeed mostly interested in the impacts on the KVM side. However,
a lot of the decisions that you make on the non-virt side of the
kernel have a two-pronged effect:
- both memory management and scheduling changes have a direct impact
on KVM because of the intricate weaving of KVM's own MM with the
kernel's.
- most of the requirements that you define for bare-metal will have to
be enforced by KVM, because it is not conceivable that you'd have a
different behaviour between host and guest.
For these reasons, I think it is necessary to involve KVM reviewers
from the beginning, rather than after everything has already been set
in stone. Unless you say upfront that virtualisation of CLA will never
be supported. And even then, you'd have to look into the effects of a
CLA user also being a VMM...
And please don't worry about my Inbox ;-).
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH mt76] wifi: mt76: mt7603: add 0x7592 EEPROM chip ID
From: Ahmed Naseef @ 2026-07-19 8:25 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Ahmed Naseef
Some EcoNet based routers ship an on-flash EEPROM whose chip-id is
0x7592 instead of the expected 0x7603. The device probes as PCI
14c3:7603 and the hardware MT_HW_CHIPID register reports 0x7603,
independent of the EEPROM value.
This is seen across multiple EcoNet EN751221 and EN7528 based devices
(for example the Genexis Platinum 4410).
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c
index b89db2db6573..05f7aaefaf89 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c
@@ -142,6 +142,7 @@ static int mt7603_check_eeprom(struct mt76_dev *dev)
case 0x7628:
case 0x7603:
case 0x7600:
+ case 0x7592:
return 0;
default:
return -EINVAL;
base-commit: 50a7f9f9d48eb50c0e95bef53358acb5af5cb3c6
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v12 02/29] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state
From: Marc Zyngier @ 2026-07-19 8:35 UTC (permalink / raw)
To: Mark Brown
Cc: Fuad Tabba, Mark Rutland, Joey Gouly, Catalin Marinas,
Suzuki K Poulose, Will Deacon, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, Oliver Upton, Dave Martin, Ben Horgan,
Jean-Philippe Brucker, linux-arm-kernel, kvmarm, linux-kernel,
kvm, linux-doc, linux-kselftest, Peter Maydell, Eric Auger
In-Reply-To: <43f21c65-c5ba-44a3-9741-548390df369b@sirena.org.uk>
On Sat, 18 Jul 2026 15:24:20 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> On Sat, Jul 18, 2026 at 02:30:04PM +0100, Fuad Tabba wrote:
> > On Sat, 18 Jul 2026 at 01:35, Mark Brown <broonie@kernel.org> wrote:
>
> > > Actually I remembered: while SCMR_EL1.LEN is self synchronising the
> > > "without the need for explict synchronization" wording is not present
> > > for SMCR_EL1.{FA64,EZT0} and this is no longer explicitly just an update
> > > of LEN. It's possible I'm being overly paranoid here, I'll leave the
> > > isb() and add a comment for the next version.
>
> > I went through the ARM ARM (DDI 0487 M.c) on this and I don't think
> > you're being overly paranoid, I believe the isb() is needed here.
>
> Thanks for double checking so thoroughly.
>
> > And task_fpsimd_load() does make indirect reads of both fields before
> > the next context synchronization event: sme_load_state() executes LDR
> > ZT0, whose execution at EL1 is trapped when SMCR_EL1.EZT0 is 0, and
> > when PSTATE.SM is set sve_load_state() executes WRFFR, which is
> > "illegal when executed in Streaming SVE mode, unless FEAT_SME_FA64 is
> > implemented and enabled" (from the WRFFR description). The MSR SVCR in
> > between doesn't provide the synchronization, since SVCR's
> > self-synchronisation wording covers reads of its own SM and ZA fields
> > only.
>
> Yeah. We should be able to optimise this:
>
> - If there is no change we don't need the isb().
> - If only EZT0 changes and we load state where ZA is disabled then we
> won't try to access ZT0.
> - If only FA64 changes and we load state where streaming mode is
> disabled then we won't try to access streaming mode FFR.
>
> I've gone and implemented the first which will suppress the isb() for
> current host kernel SME usage, the second two are starting to get more
> fiddly than seems sensible to do right now.
I really wish you didn't optimise anything at all at this stage.
"Optimisation" is exactly what got us into so much trouble over the
past two years, and I really don't want SME in KVM to follow the same
trajectory.
So leave this is a straight ISB, no optimisation. Once you come back
with actual data showing that this is a terrible bottleneck affecting
real workloads on real HW, we'll look at it. But until then, please
keep it as stupid as possible.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: media: snps,dw-hdmi-rx: add #sound-dai-cells
From: Krzysztof Kozlowski @ 2026-07-19 8:54 UTC (permalink / raw)
To: Igor Paunovic
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Sebastian Reichel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
linux-media, linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <20260718085728.6797-2-royalnet026@gmail.com>
On Sat, Jul 18, 2026 at 10:57:25AM +0200, Igor Paunovic wrote:
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> index b7f6c87..fa6cd0d 100644
> --- a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> @@ -78,6 +78,13 @@ properties:
> The phandle of the syscon node for the Video Output GRF register
> to enable EDID transfer through SDAIN and SCLIN.
>
> + "#sound-dai-cells":
> + const: 1
> + description:
> + The HDMI RX controller has two digital audio interfaces, one for
> + I2S and one for S/PDIF. The DAI cell selects the interface, 0 for
> + I2S and 1 for S/PDIF.
> +
Schema should also reference dai-common.yaml and use
"unevaluatedProperties: false".
> required:
> - compatible
> - reg
> @@ -129,4 +136,6 @@ examples:
> pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> pinctrl-names = "default";
> hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> + /* referenced by a sound card as <&hdmi_receiver 0> (0: I2S, 1: S/PDIF) */
Drop comment, not needed. Consumer is not really relevant.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] coresight: Fix scheduling while atomic in coresight_cpu_pm_notify()
From: MOHAMED AYMAN @ 2026-07-19 9:33 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Leo Yan, Suzuki K Poulose, Mike Leach, James Clark,
Alexander Shishkin, Clark Williams, Steven Rostedt,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS,
moderated list:ARM/CORESIGHT FRAMEWORK AND DRIVERS, open list,
open list:Real-time Linux (PREEMPT_RT):Keyword:PREEMPT_RT
In-Reply-To: <20260717161201.3jkO5o71@linutronix.de>
Hi Leo, Sebastian,
Thank you both for the deep architectural insights.
Leo, your point about the parent device unbinding and tearing down the
data while the PM notifier holds a raw pointer makes perfect sense.
Trading a "scheduling while atomic" panic for a potential
Use-After-Free is certainly not the goal. I clearly see why the raw
spinlock isn't enough to protect the underlying memory lifetime
against a concurrent driver unbind.
I am closely following your discussion regarding the
`device_link_add()` approach. Once you reach a consensus on the best
lifetime model for the active session, please let me know how you
would like to proceed.
I would be more than happy to help implement the new design and
prepare the necessary patches, or I can gladly step back if you prefer
to handle this broader architectural refactoring yourself, Leo.
Thanks again for your time and guidance on this!
Best regards,
Mohamed Ayman
On Fri, Jul 17, 2026 at 7:12 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2026-07-17 16:58:48 [+0100], Leo Yan wrote:
> > > static struct coresight_path *coresight_cpu_get_active_path(enum cs_mode mode)
> > > {
> > > struct coresight_device *source;
> > > - bool is_active = false;
> > > + struct coresight_path *path = NULL;
> > >
> > > - source = coresight_get_percpu_source_ref(smp_processor_id());
> > > - if (!source)
> > > - return NULL;
> > > -
> > > - if (coresight_get_mode(source) & mode)
> > > - is_active = true;
> > > + guard(raw_spinlock_irqsave)(&coresight_dev_lock);
> > >
> > > - coresight_put_percpu_source_ref(source);
> > > + source = per_cpu(csdev_source, smp_processor_id());
> > > + if (source && (coresight_get_mode(source) & mode))
> > > + path = source->path;
> >
> > I agree the get_device()/put_device() pair in
> > coresight_cpu_get_active_path() is not a good fit for CPU PM notifier,
> > because the put_device() can become the final put while IRQ is disabled.
> >
> > However, my understanding is this patch might cause UAF issue that the
> > existing code is intended to prevent.
> >
> > The raw spinlock (coresight_dev_lock) serializes access to the per-CPU
> > csdev_source pointer. It does not guarantee the lifetime of the source
> > or its _parent_ device. coresight_unregister() is not only reached from
> > module unload; it can also be called when a driver is unbind, for
> > example DT overlay removal or device hotplug/unplug.
>
> But doesn't coresight_unregister() block on the coresight_dev_lock here?
>
> > This is why the UAF issue Sashiko mentioned in patch 03 of [1]. A built
> > CoreSight path currently grabs references for the path components, which
> > keeps module alive, but that is not the same as preventing the parent
> > device/driver from being unbound and tearing down CoreSight device data
> > while an active session still has raw pointers.
> >
> > There are also similar race window before the path is built: for
> > example etm_setup_aux() has to look up source/sink state before
> > coresight_build_path() establishes the path, so it might access
> > released source/sink data if device is unbound.
> >
> > I think a proper fix needs a clearer lifetime model for an active
> > session. E.g., we could consider to call device_link_add() to prevent
> > device unbind / unregister, and unlink device when the session is
> > finished. Once that is in place, the CPU PM notifier can safely use the
> > active path without get_device()/put_device() pair anymore.
>
> Right. I am also not sure about lifetime of coresight_device::path.
>
> > Hope this is clear and makes sense.
> >
> > Thanks,
> > Leo
>
> Sebastian
^ permalink raw reply
* Re: [PATCH v2 09/10] arm64: dts: apple: Initial T603[124] (M3 Max and Ultra) device trees
From: Yureka Lilian @ 2026-07-19 9:40 UTC (permalink / raw)
To: Janne Grunau, Sven Peter, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner,
Wim Van Sebroeck, Guenter Roeck, Andi Shyti,
Uwe Kleine-König, Sasha Finkelstein
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-watchdog,
linux-i2c, linux-pwm
In-Reply-To: <20260715-apple-t603x-initial-devices-v2-9-df65b2485710@jannau.net>
On 7/15/26 11:11, Janne Grunau wrote:
> Contains minimal device trees for all M3 Max and Ultra Apple silicon
> devices. Those are 14-inch and 16-inch MacBook Pros with M3 Max released
> in November 2023 and Mac Studio with M3 Ultra released in 2025.
> This does not include M3 Pro since it is separate SoC and not a smaller
> variant of the M3 Max contrary to the M1 and M2 generations.
> The smaller M3 Max variant (10 performance cores) has its own chip
> variant (T6034) but is clearly the same design as T6031. Besides fewer
> CPU performance cores and GPU cores it misses also on fourth of the
> memory controllers and thus has an aggregated bus width of 384 bit
> instead of 512 bit.
> Both M3 Ultra variants (28 or 32 CPU cores) are based on T6031 judging
> by the advertised memory bandwidth of 819GB/s.
> This uses the same multi-die macros as t600x*.dtsi and t602x.dtsi to
> support M3 Max and M3 Ultra without duplicating device nodes. Since the
> M3 Pro can't use the same .dtsi files "t6031*.dtsi" are used to define
> common nodes for T6031, T6032 and T6034.
> The device trees have devices nodes for CPU cores, timer, interrupt
> controller, power states, watchdog, serial, pin controller, i2c,
> PWM based keyboard LED illumination and the boot framebuffer.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> arch/arm64/boot/dts/apple/Makefile | 5 +
> arch/arm64/boot/dts/apple/t6031-base.dtsi | 297 +++
> arch/arm64/boot/dts/apple/t6031-die0.dtsi | 197 ++
> arch/arm64/boot/dts/apple/t6031-dieX.dtsi | 107 ++
> arch/arm64/boot/dts/apple/t6031-gpio-pins.dtsi | 53 +
> arch/arm64/boot/dts/apple/t6031-j514c.dts | 18 +
> arch/arm64/boot/dts/apple/t6031-j516c.dts | 18 +
> arch/arm64/boot/dts/apple/t6031-pmgr.dtsi | 2400 ++++++++++++++++++++++++
> arch/arm64/boot/dts/apple/t6031.dtsi | 48 +
> arch/arm64/boot/dts/apple/t6032-j575d.dts | 46 +
> arch/arm64/boot/dts/apple/t6032.dtsi | 416 ++++
> arch/arm64/boot/dts/apple/t6034-j514m.dts | 18 +
> arch/arm64/boot/dts/apple/t6034-j516m.dts | 18 +
> arch/arm64/boot/dts/apple/t6034.dtsi | 12 +
> arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi | 66 +
> 15 files changed, 3719 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apple/Makefile b/arch/arm64/boot/dts/apple/Makefile
> index 6fc3349a5842..a22b4a8068b6 100644
> --- a/arch/arm64/boot/dts/apple/Makefile
> +++ b/arch/arm64/boot/dts/apple/Makefile
> @@ -87,6 +87,11 @@ dtb-$(CONFIG_ARCH_APPLE) += t6021-j416c.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t6020-j474s.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t6021-j475c.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t6022-j475d.dtb
> +dtb-$(CONFIG_ARCH_APPLE) += t6031-j514c.dtb
> +dtb-$(CONFIG_ARCH_APPLE) += t6031-j516c.dtb
> +dtb-$(CONFIG_ARCH_APPLE) += t6032-j575d.dtb
> +dtb-$(CONFIG_ARCH_APPLE) += t6034-j514m.dtb
> +dtb-$(CONFIG_ARCH_APPLE) += t6034-j516m.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t8112-j413.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t8112-j415.dtb
> dtb-$(CONFIG_ARCH_APPLE) += t8112-j473.dtb
> diff --git a/arch/arm64/boot/dts/apple/t6031-base.dtsi b/arch/arm64/boot/dts/apple/t6031-base.dtsi
> new file mode 100644
> index 000000000000..0bb7373b3f06
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t6031-base.dtsi
> @@ -0,0 +1,297 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Nodes common for T6031, T6032 and T6034 family SoCs (M3 Max/Ultra)
> + *
> + * Other names: H15J, H15S, "Palma"
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu_e00>;
> + };
> + core1 {
> + cpu = <&cpu_e01>;
> + };
> + core2 {
> + cpu = <&cpu_e02>;
> + };
> + core3 {
> + cpu = <&cpu_e03>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu_p00>;
> + };
> + core1 {
> + cpu = <&cpu_p01>;
> + };
> + core2 {
> + cpu = <&cpu_p02>;
> + };
> + core3 {
> + cpu = <&cpu_p03>;
> + };
> + core4 {
> + cpu = <&cpu_p04>;
> + };
> + core5 {
> + cpu = <&cpu_p05>;
> + };
> + };
> +
> + cluster2 {
> + core0 {
> + cpu = <&cpu_p10>;
> + };
> + core1 {
> + cpu = <&cpu_p11>;
> + };
> + core2 {
> + cpu = <&cpu_p12>;
> + };
> + core3 {
> + cpu = <&cpu_p13>;
> + };
> + core4 {
> + cpu = <&cpu_p14>;
> + };
> + core5 {
> + cpu = <&cpu_p15>;
> + };
> + };
> + };
> +
> + cpu_e00: cpu@0 {
> + compatible = "apple,sawtooth";
> + device_type = "cpu";
> + reg = <0x0 0x0>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* to be filled by loader */
> + next-level-cache = <&l2_cache_0>;
> + i-cache-size = <0x20000>;
> + d-cache-size = <0x10000>;
> + };
> +
> + cpu_e01: cpu@1 {
> + compatible = "apple,sawtooth";
> + device_type = "cpu";
> + reg = <0x0 0x1>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* to be filled by loader */
> + next-level-cache = <&l2_cache_0>;
> + i-cache-size = <0x20000>;
> + d-cache-size = <0x10000>;
> + };
> +
> + cpu_e02: cpu@2 {
> + compatible = "apple,sawtooth";
> + device_type = "cpu";
> + reg = <0x0 0x2>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* to be filled by loader */
> + next-level-cache = <&l2_cache_0>;
> + i-cache-size = <0x20000>;
> + d-cache-size = <0x10000>;
> + };
> +
> + cpu_e03: cpu@3 {
> + compatible = "apple,sawtooth";
> + device_type = "cpu";
> + reg = <0x0 0x3>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* to be filled by loader */
> + next-level-cache = <&l2_cache_0>;
> + i-cache-size = <0x20000>;
> + d-cache-size = <0x10000>;
> + };
> +
> + cpu_p00: cpu@10100 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10100>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p01: cpu@10101 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10101>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p02: cpu@10102 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10102>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p03: cpu@10103 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10103>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p04: cpu@10104 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10104>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p05: cpu@10105 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10105>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_1>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p10: cpu@10200 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10200>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p11: cpu@10201 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10201>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p12: cpu@10202 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10202>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p13: cpu@10203 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10203>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p14: cpu@10204 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10204>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + cpu_p15: cpu@10205 {
> + compatible = "apple,everest";
> + device_type = "cpu";
> + reg = <0x0 0x10205>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0>; /* To be filled by loader */
> + next-level-cache = <&l2_cache_2>;
> + i-cache-size = <0x30000>;
> + d-cache-size = <0x20000>;
> + };
> +
> + l2_cache_0: l2-cache-0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-unified;
> + cache-size = <0x400000>;
> + };
> +
> + l2_cache_1: l2-cache-1 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-unified;
> + cache-size = <0x1000000>;
> + };
> +
> + l2_cache_2: l2-cache-2 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-unified;
> + cache-size = <0x1000000>;
> + };
> + };
Nit: The indentation is weird here. The parenthesis close is not aligned
with the "timer" in the next section.
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <&aic>;
> + interrupt-names = "phys", "virt", "hyp-phys", "hyp-virt";
> + interrupts = <AIC_FIQ 0 AIC_TMR_GUEST_PHYS IRQ_TYPE_LEVEL_HIGH>,
> + <AIC_FIQ 0 AIC_TMR_GUEST_VIRT IRQ_TYPE_LEVEL_HIGH>,
> + <AIC_FIQ 0 AIC_TMR_HV_PHYS IRQ_TYPE_LEVEL_HIGH>,
> + <AIC_FIQ 0 AIC_TMR_HV_VIRT IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + clkref: clock-ref {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24000000>;
> + clock-output-names = "clkref";
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + };
> +};
>
[...]
> diff --git a/arch/arm64/boot/dts/apple/t6034.dtsi b/arch/arm64/boot/dts/apple/t6034.dtsi
> new file mode 100644
> index 000000000000..aa73af9c512d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t6034.dtsi
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Apple T6034 "M3 Max" SoC
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include "t6031.dtsi"
> +
> +/ {
> + compatible = "apple,t6034", "apple,arm-platform";
> +};
You mentioned the reduced number of memory channels on the 14-core
variant, but the corresponding pmgr nodes are not disabled here.
> diff --git a/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi b/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi
> new file mode 100644
> index 000000000000..517b84c183ca
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/t603x-j514-j516.dtsi
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * MacBook Pro (14/16-inch, 2023)
> + *
> + * This file contains the parts common to J514 and J516 devices with t6030,
> + * t6031 and t6034.
> + *
> + * target-type: J514s / J514m / J514c / J516s / J516m / J516c
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +/*
> + * These models are essentially identical to the previous generations, other
> + * than the GPIO indices and using SPMI based USB Type-C port controllers.
> + */
> +
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> + chassis-type = "laptop";
> +
> + aliases {
> + serial0 = &serial0;
> + };
> +
> + chosen {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + stdout-path = "serial0";
> +
> + framebuffer0: framebuffer@0 {
> + compatible = "apple,simple-framebuffer", "simple-framebuffer";
> + reg = <0 0 0 0>; /* To be filled by loader */
> + /* Format properties will be added by loader */
> + status = "disabled";
> + power-domains = <&ps_disp_fe>;
> + };
> + };
> +
> + memory@10000000000 {
> + device_type = "memory";
> + reg = <0x100 0 0x2 0>; /* To be filled by loader */
> + };
> +
> + led-controller {
> + compatible = "pwm-leds";
> + led-0 {
> + pwms = <&fpwm0 0 40000>;
> + function = LED_FUNCTION_KBD_BACKLIGHT;
> + color = <LED_COLOR_ID_WHITE>;
> + max-brightness = <255>;
> + default-state = "keep";
> + };
> + };
> +};
> +
> +&serial0 {
> + status = "okay";
> +};
> +
> +&fpwm0 {
> + status = "okay";
> +};
Thanks!
— Yureka
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: media: snps,dw-hdmi-rx: add #sound-dai-cells
From: Igor Paunovic @ 2026-07-19 9:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Sebastian Reichel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
linux-media, linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <20260719-sassy-muskrat-of-finesse-b426b0@quoll>
Hi Krzysztof,
Thanks -- both done for v4: the schema now references
/schemas/sound/dai-common.yaml# with unevaluatedProperties: false, and
the consumer comment is dropped from the example.
I'll fold this into the v4 respin together with Sebastian's dts
comments, holding it for Dmitry's testing round on the driver side so
everything lands in one go.
Igor
On Sun, Jul 19, 2026 at 10:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sat, Jul 18, 2026 at 10:57:25AM +0200, Igor Paunovic wrote:
>
> > diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > index b7f6c87..fa6cd0d 100644
> > --- a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > @@ -78,6 +78,13 @@ properties:
> > The phandle of the syscon node for the Video Output GRF register
> > to enable EDID transfer through SDAIN and SCLIN.
> >
> > + "#sound-dai-cells":
> > + const: 1
> > + description:
> > + The HDMI RX controller has two digital audio interfaces, one for
> > + I2S and one for S/PDIF. The DAI cell selects the interface, 0 for
> > + I2S and 1 for S/PDIF.
> > +
>
> Schema should also reference dai-common.yaml and use
> "unevaluatedProperties: false".
>
> > required:
> > - compatible
> > - reg
> > @@ -129,4 +136,6 @@ examples:
> > pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> > pinctrl-names = "default";
> > hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> > + /* referenced by a sound card as <&hdmi_receiver 0> (0: I2S, 1: S/PDIF) */
>
> Drop comment, not needed. Consumer is not really relevant.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v5 1/4] clk: sunxi-ng: mux: fix determine helper rate propagation
From: Chen-Yu Tsai @ 2026-07-19 10:53 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <20260717-a733-rtc-v5-1-3874cc26abf7@baylibre.com>
On Fri, Jul 17, 2026 at 11:25 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> Applying the pre divider on the parent rate is wrong because, while
> handling rate propagation through determine_rate(), the framework will
> likely round the parent rate again while cycling through the possibilities,
> throwing away the prediv applied. This means, the parent rate will then
> be wrong when the prediv is unapplied from a parent rate on which it
> was never applied to begin with.
>
> The right way to do it is to unapply the prediv from the requested rate,
> which is the wanted rate at the input on the clock element, and pass this
> to framework to do its thing.
>
> Change the determine rate mux helper in this way.
>
> Fixes: 1c8d7af61b37 ("clk: sunxi-ng: convert from divider_round_rate_parent() to divider_determine_rate()")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Will wait a few more days before merging the series in case anyone
else spots anything.
^ permalink raw reply
* Re: [PATCH v11 2/7] i2c: mux: add idle_state property to i2c_mux_core
From: Peter Rosin @ 2026-07-19 12:39 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Wolfram Sang, Michael Hennerich, Bartosz Golaszewski, Andi Shyti,
Andy Shevchenko, Bartosz Golaszewski, linux-i2c, linux-kernel,
linux-arm-kernel
In-Reply-To: <alfZYOKCjf6CKN6i@gmail.com>
On 2026-07-15 21:02, Marcus Folkesson wrote:
> Hi Peter,
>
> On Tue, Jul 14, 2026 at 01:29:01PM +0200, Peter Rosin wrote:
>> Hi Marcus,
>>
>> Sorry for the very late feedback.
>>
>> On 2026-07-13 09:19, Marcus Folkesson wrote:
>>> Muxes treat their channels differently when idle.
>>> Let the mux core have this information to make it available for
>>> internal use.
>>> Reuse the same state values used by CONFIG_MULTIPLEXER.
>>>
>>> Possible idle states are:
>>> - MUX_IDLE_AS_IS: Leave channels as is when idle
>>> - MUX_IDLE_DISCONNECT: Disconnect channel (set HiZ when idle)
>>> - <n>: Enable channel n when idle
>>>
>>> Default value is set to MUX_IDLE_AS_IS.
>>>
>>> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
>>> ---
>>> drivers/i2c/i2c-mux.c | 1 +
>>> include/linux/i2c-mux.h | 26 ++++++++++++++++++++++++++
>>> 2 files changed, 27 insertions(+)
>>>
>>> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
>>> index 681a201c239b..edf16683dc83 100644
>>> --- a/drivers/i2c/i2c-mux.c
>>> +++ b/drivers/i2c/i2c-mux.c
>>> @@ -247,6 +247,7 @@ struct i2c_mux_core *i2c_mux_alloc(struct i2c_adapter *parent,
>>> muxc->select = select;
>>> muxc->deselect = deselect;
>>> muxc->max_adapters = max_adapters;
>>> + muxc->idle_state = MUX_IDLE_AS_IS;
>>
>> This is insufficient. AS_IS is simply not an adequate default.
>>
>> For i2c-mux-gpmux, there is currently no way to dig out what
>> the idle state is, as it is not exposed by the mux subsystem. For
>> i2c-mux-gpio, the idle state depends on both the idle-state /and/
>> the i2c-mux-idle-disconnect props. For i2c-mux-pca954x the idle
>> state can be adjusted at runtime. Etc.
>>
>> In short, idle state handling is a bit diverse, and I think this
>> adds to that mess.
>>
>> I think it will be a bit of work to come up with a scheme for the
>> I2C mux core to accurately keep track of what the idle state is.
>> One way to deal with that is to introduce a new "unknown" value
>> that can be the default for all drivers that has not yet figured
>> out how to feed the correct idle state to the core.
>>
>> And that hints at why I think reusing the mux.h bindings #include
>> is bad. The mux subsystem simply has no need for an unknown state,
>> and adding that to mux.h is therefore out of place.
>
> I see.
>
> I think I will introduce a few defines in i2c-mux.c then;
>
>
> #define I2C_MUX_IDLE_UNKNOWN (-1)
> #define I2C_MUX_IDLE_AS_IS (-2)
> #define I2C_MUX_IDLE_DISCONNECT (-3)
Hi!
Please keep AS_IS as -1 and DISCONNECT as -2. Using different
values will make it difficult to get rid of the use of the
defines belonging to the mux subsystem in case the actual
value has crept into some .dtb or something like that.
Also, I think the right thing to do is to put these defines
in the i2c-mux.h header so that the drivers can find them.
I assume .c was a typo?
> [...]
>
> struct i2c_mux_core {
>
> [...]
>
> /*
> * The mux state to use when not active.
This is not 100% accurate. The value stored here is never
actually used to set the idle state. The idle_state here is
only what the driver has declared that the idle_state is.
Perhaps word it like this instead?
* The mux state used by the driver when idle.
Agreed, subtle difference, but...
In the future, drivers (most of them) could be changed to
use this variable to store the actual idle state. But, as
mentioned, that's not easy for i2c-mux-gpmux since the idle
state is under the control of the the mux subsystem in that
case.
Cheers,
Peter
> * Possible idle states are:
> * - I2C_MUX_IDLE_UNKNOWN: Unknown idle state
> * - I2C_MUX_IDLE_AS_IS: Leave channels as is when idle
> * - I2C_MUX_IDLE_DISCONNECT: Disconnect channel (set HiZ when idle)
> * - <n>: Enable channel n (starting from 0) when idle"
> *
> * Default value is set to I2C_MUX_IDLE_UNKNOWN.
> */
> int idle_state;
>
> [...]
> };
^ 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