* Re: [PATCH v2] iommu/arm-smmu-v3: Shrink command/event/PRI queues in kdump kernel
From: Nicolin Chen @ 2026-07-02 18:54 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Jason Gunthorpe,
Kyle McMartin, Breno Leitao, Usama Arif, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <20260702112825.781750-1-kas@kernel.org>
On Thu, Jul 02, 2026 at 12:28:25PM +0100, Kiryl Shutsemau (Meta) wrote:
> The command, event and PRI queues are sized from the maxima the hardware
> advertises in IDR1, which can be several megabytes each. On systems with
> many SMMUv3 instances that cost is paid per instance and adds up to tens
> of megabytes of coherent DMA in the capture kernel.
>
> A kdump capture kernel runs from a small crashkernel reservation and only
> has to drive the few devices used to save the dump, so deep queues serve
> no purpose. The queues carry invalidation commands and fault records, not
> DMA data, so dump throughput is unaffected; a shallower queue only bounds
> how many commands may be in flight before a sync, which does not matter for
> the capture kernel's small device count and modest I/O.
>
> Clamp every queue to a single page when is_kdump_kernel() is true. Doing
> it in arm_smmu_init_one_queue() covers the command, event and PRI queues
> in one place. The command queue still holds at least one batch plus a sync
> (256 entries on a 4K-page kernel, well above CMDQ_BATCH_ENTRIES), so
> command batching keeps working.
>
> Suggested-by: Kyle McMartin <jkkm@meta.com>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3 2/8] dt-bindings: rtc: sun6i: add sun60i-a733 support
From: Conor Dooley @ 2026-07-02 18:45 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, 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: <20260702-a733-rtc-v3-2-eb2580374de6@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
From: Conor Dooley @ 2026-07-02 18:44 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard, linux-rtc,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-clk, Sashiko
In-Reply-To: <20260702-a733-rtc-v3-1-eb2580374de6@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 13/28] arm64: sysreg: Add NVHCR_EL2 description as a mirror of HCR_EL2
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
FEAT_NV3 introduces a new register that contains the HCR_EL2 value
exposed to a NV guest. As such, it has the exact same layout as
HCR_EL2.
Describe NVHCR_EL2 as a mapping to HCR_EL2.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/tools/sysreg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index c6e8117a6f9cd..31e4ea455a9ce 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -4266,6 +4266,9 @@ Field 1 E2TRE
Field 0 E0HTRE
EndSysreg
+Sysreg NVHCR_EL2 3 4 1 5 0
+Mapping HCR_EL2
+EndSysreg
Sysreg HDFGRTR2_EL2 3 4 3 1 0
Res0 63:25
--
2.47.3
^ permalink raw reply related
* [PATCH 07/28] KVM: arm64: Don't evaluate HCR_EL2.NV on ERET fast path
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
We currently avoid using the ERET fast path if the guest has HCR_EL2.NV
set. This is an odd check, as NV doesn't mean much if HCR_EL2.TGE==1.
Replace this bizarre check with is_nested_ctxt() which makes a lot
more sense: if we are running an L2, the ERET trap must go to L1.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/hyp/vhe/switch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index bbe9cebd3d9d5..3b76e0468317b 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -349,8 +349,8 @@ static bool kvm_hyp_handle_eret(struct kvm_vcpu *vcpu, u64 *exit_code)
* Unless the trap has to be forwarded further down the line,
* of course...
*/
- if ((__vcpu_sys_reg(vcpu, HCR_EL2) & HCR_NV) ||
- (__vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET))
+ if (is_nested_ctxt(vcpu) ||
+ __vcpu_sys_reg(vcpu, HFGITR_EL2) & HFGITR_EL2_ERET)
return false;
spsr = read_sysreg_el1(SYS_SPSR);
--
2.47.3
^ permalink raw reply related
* [PATCH 12/28] arm64: Add FEAT_NV2p1 detection
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
Add the necessary NV2p1 probing to the cpufeature infrastructure.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/cpufeature.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9a22df0c5120f..c9c124b0ccc8e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2620,6 +2620,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
{ /* Sentinel */ }
},
},
+ {
+ .desc = "FEAT_NV2p1",
+ .capability = ARM64_HAS_NV2P1,
+ .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .matches = has_cpuid_feature,
+ ARM64_CPUID_FIELDS(ID_AA64MMFR4_EL1, NV_frac, NV2P1)
+ },
{
.capability = ARM64_HAS_32BIT_EL0_DO_NOT_USE,
.type = ARM64_CPUCAP_SYSTEM_FEATURE,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro"
From: Heiko Stuebner @ 2026-07-02 18:23 UTC (permalink / raw)
To: oklopfer37, Oren Klopfer
Cc: linux-arm-kernel, linux-rockchip, linux-kernel, Peter Robinson,
Thorsten Leemhuis, stable
In-Reply-To: <20260615225014.219115-1-oklopfer37@gmail.com>
Hi Oren,
Am Dienstag, 16. Juni 2026, 00:50:13 Mitteleuropäische Sommerzeit schrieb Oren Klopfer:
> This reverts commit 096bd8c679185f898cae9933c6a68650fa26ea4f.
>
> Just as with the Pinebook Pro, there are multiple chipset variants for the Pinephone Pro, and multiple firmware binaries for different distributions. The change causes issues with some of these combinations, and reverting it resolves the issues. See the Closes below for the full report.
>
> Similarly with the Pinebook Pro adjustment, the original commit only indicates "further description" and not indicative of fixing any existing issues, so reverting should not kick any back up.
The commit message did not get any line breaks, 72 character
is the preferred line length.
Also the patch contents itself got mangled.
All the indentation is set as spaces, so that patch won't apply.
Please try using b4 or at least git send-email for sending patches.
Thanks a lot
Heiko
> Fixes: 096bd8c67918 ("arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro")
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Thorsten Leemhuis <regressions@leemhuis.info>
> Cc: stable@vger.kernel.org
> Closes: https://lore.kernel.org/r/20260607225901.64019-1-oklopfer37@gmail.com/
> Signed-off-by: Oren Klopfer <oklopfer37@gmail.com>
> ---
> .../boot/dts/rockchip/rk3399-pinephone-pro.dts | 18 ------------------
> 1 file changed, 18 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> index 8d26bd9b7500..d46cdfe3f784 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> @@ -734,12 +734,6 @@ light_int_l: light-int-l {
> };
> };
>
> - wifi {
> - wifi_host_wake_l: wifi-host-wake-l {
> - rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -
> wireless-bluetooth {
> bt_wake_pin: bt-wake-pin {
> rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> @@ -766,19 +760,7 @@ &sdio0 {
> pinctrl-names = "default";
> pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> sd-uhs-sdr104;
> - #address-cells = <1>;
> - #size-cells = <0>;
> status = "okay";
> -
> - brcmf: wifi@1 {
> - compatible = "brcm,bcm4329-fmac";
> - reg = <1>;
> - interrupt-parent = <&gpio4>;
> - interrupts = <RK_PD0 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "host-wake";
> - pinctrl-names = "default";
> - pinctrl-0 = <&wifi_host_wake_l>;
> - };
> };
>
> &pwm0 {
>
^ permalink raw reply
* [PATCH 08/28] arm64: Add ARM64_HAS_NV2P1 capability
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
As we're about to deal with FEAT_NV2P1, add a new capability that
will be used to key any support for it.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/tools/cpucaps | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 9b85a84f6fd49..242dc211d8efa 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -51,6 +51,7 @@ HAS_LS64_V
HAS_LSUI
HAS_MOPS
HAS_NESTED_VIRT
+HAS_NV2P1
HAS_BBML2_NOABORT
HAS_PAN
HAS_PMUV3
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v7 2/8] media: subdev: Add media_async_register_subdev() helper
From: Frank Li @ 2026-07-02 18:11 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sakari Ailus, Mauro Carvalho Chehab, Michael Riesch, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, Guoniu Zhou, devicetree, linux-arm-kernel
In-Reply-To: <20260702161519.GI3534761@killaraus.ideasonboard.com>
On Thu, Jul 02, 2026 at 07:15:19PM +0300, Laurent Pinchart wrote:
> Hi Frank,
>
> Have you missed the comment in v6 ?
>
> https://lore.kernel.org/all/20260629084654.GB3054459@killaraus.ideasonboard.com/
Sorry, I forget emphased it in change log.
"For the reason stated by Sakari in patch 1/9 (dependency from MC to
V4L2), I don't think a "media_async_register_subdev()" function is a
good idea."
The reason already NOT existed in v7, I removed v4l2_fwnode_endpoint from
media_pad. So MC will not depdent to V4L2.
So this comments is not suit for this version.
Frank
^ permalink raw reply
* Re: [PATCH v7 2/8] media: subdev: Add media_async_register_subdev() helper
From: Laurent Pinchart @ 2026-07-02 18:19 UTC (permalink / raw)
To: Frank Li
Cc: Sakari Ailus, Mauro Carvalho Chehab, Michael Riesch, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, Guoniu Zhou, devicetree, linux-arm-kernel
In-Reply-To: <akapt6v_DBJSAnj0@SMW015318>
On Thu, Jul 02, 2026 at 01:11:03PM -0500, Frank Li wrote:
> On Thu, Jul 02, 2026 at 07:15:19PM +0300, Laurent Pinchart wrote:
> > Hi Frank,
> >
> > Have you missed the comment in v6 ?
> >
> > https://lore.kernel.org/all/20260629084654.GB3054459@killaraus.ideasonboard.com/
>
> Sorry, I forget emphased it in change log.
>
> "For the reason stated by Sakari in patch 1/9 (dependency from MC to
> V4L2), I don't think a "media_async_register_subdev()" function is a
> good idea."
>
> The reason already NOT existed in v7, I removed v4l2_fwnode_endpoint from
> media_pad. So MC will not depdent to V4L2.
>
> So this comments is not suit for this version.
media_async_register_subdev(), with its "media_" prefix, appears part of
the MC API, but it operates on a subdev. At least the function name
should be changed in my opinion.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v8 14/39] drm/display: bridge_connector: Use cached connector status in .get_modes()
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
Dmitry Baryshkov
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Replace the active drm_bridge_connector_detect() call in get_modes()
with a read of the already-cached connector->status.
The .get_modes() callback is only invoked from
drm_helper_probe_single_connector_modes(), which has already retrieved
the connector status. Calling detect again is redundant and triggers a
duplicate hotplug event. This is also a prerequisite for switching to
the .detect_ctx() hook, which requires a drm_modeset_acquire_ctx not
available in the .get_modes() path.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 46104506fe32..57238ba49d70 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -326,12 +326,10 @@ static const struct drm_connector_funcs drm_bridge_connector_funcs = {
static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
struct drm_bridge *bridge)
{
- enum drm_connector_status status;
const struct drm_edid *drm_edid;
int n;
- status = drm_bridge_connector_detect(connector, false);
- if (status != connector_status_connected)
+ if (connector->status != connector_status_connected)
goto no_edid;
drm_edid = drm_bridge_edid_read(bridge, connector);
--
2.54.0
^ permalink raw reply related
* [PATCH 17/28] KVM: arm64: Add NV3 control bits to HCRX_EL2 sanitisation
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
Expose the FEAT_NV3 control bits to the sanitisation code so that
KVM stops moaning about the unattributed bits.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/config.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
index 8d5e4aacf49c4..b9a9d65b973e6 100644
--- a/arch/arm64/kvm/config.c
+++ b/arch/arm64/kvm/config.c
@@ -225,6 +225,7 @@ struct reg_feat_map_desc {
#define FEAT_HCX ID_AA64MMFR1_EL1, HCX, IMP
#define FEAT_S2PIE ID_AA64MMFR3_EL1, S2PIE, IMP
#define FEAT_GCIE ID_AA64PFR2_EL1, GCIE, IMP
+#define FEAT_NV3 ID_AA64MMFR4_EL1, NV_frac, NV3
static bool not_feat_aa64el3(struct kvm *kvm)
{
@@ -904,6 +905,11 @@ static const DECLARE_FEAT_MAP_FGT(hdfgwtr2_desc, hdfgwtr2_masks,
static const struct reg_bits_to_feat_map hcrx_feat_map[] = {
+ NEEDS_FEAT(HCRX_EL2_NVTGE |
+ HCRX_EL2_NVnTTLB |
+ HCRX_EL2_NVnTTLBIS |
+ HCRX_EL2_NVnTTLBOS,
+ FEAT_NV3),
NEEDS_FEAT(HCRX_EL2_SRMASKEn, FEAT_SRMASK),
NEEDS_FEAT(HCRX_EL2_PACMEn, feat_pauth_lr),
NEEDS_FEAT(HCRX_EL2_EnFPM, FEAT_FPMR),
--
2.47.3
^ permalink raw reply related
* Re: [PATCH RFC 8/8] clk: sunxi-ng: a733: Add reset lines
From: Enzo Adriano @ 2026-07-02 18:11 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-8-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Same exercise for the reset map: I compared all 121 entries' offsets
and bit positions against the public A733 User Manual V0.92. 115 match
the manual exactly (including the multi-bit GMAC0 entry - 0x141C bits
16/17 per section 4.1.6.212 - and RST_BUS_SYSDAP at 0x7ac, which is
what makes the gate offset in patch 7/8 stand out).
The six that have no register in the public manual, in case you want
to add provenance notes near them (as already discussed for other
undocumented IDs in this series):
- RST_BUS_SPI4 { 0x0F2C, BIT(16) }
- RST_BUS_SGPIO { 0x1064, BIT(16) }
- RST_BUS_LPC { 0x1084, BIT(16) }
- RST_BUS_GMAC1 { 0x142C, BIT(16) } [GMAC1 question]
- RST_BUS_GMAC1_AXI { 0x142C, BIT(17) } [GMAC1 question]
- RST_BUS_TCON_LCD2 { 0x1514, BIT(16) } - the manual documents only
VO0_TCONLCD0_BGR (0x1504) and VO0_TCONLCD1_BGR (0x150C); there is
no TCONLCD2 register set in V0.92
Everything else in the reset map checks out against the manual.
This analysis was done with AI assistance (Claude Code, claude-fable-5)
and each finding was checked against the cited sources.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH v2 0/2] rockchip: Fix devices suspend freeze on RK3568/RK3566
From: Heiko Stuebner @ 2026-07-02 18:00 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonas Karlman
Cc: Diederik de Haas, Greg Kroah-Hartman, devicetree, linux-rockchip,
linux-usb, linux-arm-kernel, linux-kernel, Jonas Karlman
In-Reply-To: <20260624192726.781864-1-jonas@kwiboo.se>
Hi Jonas,
Am Mittwoch, 24. Juni 2026, 21:27:23 Mitteleuropäische Sommerzeit schrieb Jonas Karlman:
> This series fixes a system freeze during suspend in ohci_suspend() due
> to clk_usbphy1_480m not being enabled when EHCI/OHCI registers are
> accessed on e.g. a Raxa ROCK 3C board.
>
> Following pm_test modes work on my ROCK 3C with the missing usbphy clk
> refs added:
>
> echo N > /sys/module/printk/parameters/console_suspend
>
> echo devices > /sys/power/pm_test
> echo platform > /sys/power/pm_test
> echo processors > /sys/power/pm_test
> echo core > /sys/power/pm_test
>
> echo mem > /sys/power/state
>
> Changes in v2:
> - Include rockchip,rk3588-ehci in the EHCI constraint
> - Make clocks prop required for EHCI and OHCI
> - Collect t-b tag
>
> Jonas Karlman (2):
> dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
it seems I wasn't in Cc for the first patch, so can't know if and when
that gets/got applied.
Also I think I remember Greg preferring not having to split apart patch
series', so I think the binding patch might be better off standing alone.
Heiko
^ permalink raw reply
* Re: [PATCH] media: rkvdec: Propagate platform_get_irq() errors
From: Detlev Casanova @ 2026-07-02 17:57 UTC (permalink / raw)
To: Narasimharao Vadlamudi
Cc: Ezequiel Garcia, Mauro Carvalho Chehab, Heiko Stuebner,
Hans Verkuil, Boris Brezillon, linux-media, linux-rockchip,
linux-arm-kernel, linux-kernel, Narasimharao Vadlamudi
In-Reply-To: <20260701111203.62092-1-ahmisaranrao@gmail.com>
Hi Vadlamudi,
On Wednesday, July 1, 2026 7:12:03 a.m. Eastern Daylight Time Narasimharao
Vadlamudi wrote:
> platform_get_irq() returns a positive IRQ number on success and a
> negative error code on failure. It no longer returns zero. The driver
> currently returns -ENXIO for all failures, which loses useful errors
> such as -EPROBE_DEFER.
>
> Return the error from platform_get_irq() directly.
>
> Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
> Signed-off-by: Narasimharao Vadlamudi <ahmisaranrao@gmail.com>
> ---
> drivers/media/platform/rockchip/rkvdec/rkvdec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> b/drivers/media/platform/rockchip/rkvdec/rkvdec.c index
> 1d1e9bfef8e9..37683a6bb40f 100644
> --- a/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec.c
> @@ -1818,8 +1818,8 @@ static int rkvdec_probe(struct platform_device *pdev)
> vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
>
> irq = platform_get_irq(pdev, 0);
> - if (irq <= 0)
> - return -ENXIO;
> + if (irq < 0)
> + return irq;
>
> ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
> rkvdec_irq_handler,
IRQF_ONESHOT,
Thank you for the patch ! And sorry for the HTML email before. So for the
record:
Reviewed-by: Detlev Casanova <detlev.casanova@collabora.com>
--
Detlev.
^ permalink raw reply
* [PATCH 11/28] KVM: arm64: Expose FEAT_NV2p1 to NV guests
From: Marc Zyngier @ 2026-07-02 16:02 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu
In-Reply-To: <20260702160248.1377250-1-maz@kernel.org>
Since NV2p1 is reducing the number of traps, it is valuable to expose
it to NV guests. Do so.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/nested.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index dfb96edbdc43c..9972dea42d12a 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -1728,7 +1728,7 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
* You get EITHER
*
* - FEAT_VHE without FEAT_E2H0
- * - FEAT_NV limited to FEAT_NV2
+ * - FEAT_NV limited to FEAT_NV2(p1)
* - HCR_EL2.NV1 being RES0
*
* OR
@@ -1740,7 +1740,11 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
if (test_bit(KVM_ARM_VCPU_HAS_EL2_E2H0, kvm->arch.vcpu_features)) {
val = 0;
} else {
- val = SYS_FIELD_PREP_ENUM(ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY);
+ if (cpus_have_final_cap(ARM64_HAS_NV2P1))
+ val = ID_REG_LIMIT_FIELD_ENUM(val, ID_AA64MMFR4_EL1, NV_frac, NV2P1);
+ else
+ val = SYS_FIELD_PREP_ENUM(ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY);
+ val &= ~ID_AA64MMFR4_EL1_E2H0;
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR4_EL1, E2H0, NI_NV1);
}
break;
--
2.47.3
^ permalink raw reply related
* [PATCH v8 28/39] drm/bridge: dw-hdmi-qp: Drop unused .setup_hpd() phy op
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
With the transition to .{enable|disable}_hpd() phy ops complete in both
the bridge and platform drivers, .setup_hpd() has no remaining callers.
Drop it.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 3 ---
include/drm/bridge/dw_hdmi_qp.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
index 4d41ad7319a5..8ce005673517 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
@@ -1314,9 +1314,6 @@ static void dw_hdmi_qp_init_hw(struct dw_hdmi_qp *hdmi)
/* Clear DONE and ERROR interrupts */
dw_hdmi_qp_write(hdmi, I2CM_OP_DONE_CLEAR | I2CM_NACK_RCVD_CLEAR,
MAINUNIT_1_INT_CLEAR);
-
- if (hdmi->phy.ops->setup_hpd)
- hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
}
struct dw_hdmi_qp *dw_hdmi_qp_bind(struct platform_device *pdev,
diff --git a/include/drm/bridge/dw_hdmi_qp.h b/include/drm/bridge/dw_hdmi_qp.h
index b4fb1c578a5b..ad33f9cafdeb 100644
--- a/include/drm/bridge/dw_hdmi_qp.h
+++ b/include/drm/bridge/dw_hdmi_qp.h
@@ -16,7 +16,6 @@ struct dw_hdmi_qp_phy_ops {
int (*init)(struct dw_hdmi_qp *hdmi, void *data);
void (*disable)(struct dw_hdmi_qp *hdmi, void *data);
enum drm_connector_status (*read_hpd)(struct dw_hdmi_qp *hdmi, void *data);
- void (*setup_hpd)(struct dw_hdmi_qp *hdmi, void *data);
void (*enable_hpd)(struct dw_hdmi_qp *hdmi, void *data);
void (*disable_hpd)(struct dw_hdmi_qp *hdmi, void *data);
};
--
2.54.0
^ permalink raw reply related
* ✅ PASS: Test report for for-kernelci (7.2.0-rc1, upstream-arm-next, a52d6c71)
From: cki-project @ 2026-07-02 17:43 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: selftests/arm64: fix spelling errors in comments
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2647180691
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Karthikeyan KS @ 2026-07-02 17:35 UTC (permalink / raw)
To: andrew
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <033f2657ae6a94ad13d22f717a2900afb75d892d.camel@codeconstruct.com.au>
Hi Andrew,
Thanks for your consistent support and guidance.
I learned a lot from you.
Much Appreciated.
Thanks,
Karthikeyan
^ permalink raw reply
* Re: [PATCH v2 net-next 08/14] net: enetc: remove invalid code from enetc4_pl_mac_link_up()
From: Maxime Chevallier @ 2026-07-02 17:35 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-9-wei.fang@oss.nxp.com>
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> When adding phylink MAC operations support to the NETC switch driver,
> Russell King pointed out several pieces of invalid logic in the
> .mac_link_up() implementation (see [1] and [2]):
>
> 1) Half-duplex backpressure is not supported by the kernel, Ethernet
> relies on packet dropping for congestion management.
>
> 2) phylink_autoneg_inband() is unnecessary, as RGMII in-band status is
> not supported.
>
> 3) TX and RX pause are disabled in half-duplex mode, so there is no
> need to override them in .mac_link_up().
>
> The same invalid logic is also present in enetc4_pl_mac_link_up(), so
> remove the invalid code from it.
>
> Link: https://lore.kernel.org/imx/acEIQqI-_oyCym8O@shell.armlinux.org.uk/ # 1
> Link: https://lore.kernel.org/imx/acEFwqmAvWls_9Ef@shell.armlinux.org.uk/ # 2
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH RFC 7/8] clk: sunxi-ng: a733: Add bus clock gates
From: Enzo Adriano @ 2026-07-02 17:34 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-7-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Following Andre's suggestion I went through the bus gates in this patch
and compared every register offset and bit position against the public
A733 User Manual V0.92. Findings below; everything not listed matched
the manual (122 of the 135 gate entries verified clean).
1) UART1-UART6 gate bits look wrong:
> +static SUNXI_CCU_GATE_HWS(bus_uart1_clk, "bus-uart1", apb_uart_hws, 0xe04, BIT(1), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart2_clk, "bus-uart2", apb_uart_hws, 0xe08, BIT(2), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart3_clk, "bus-uart3", apb_uart_hws, 0xe0c, BIT(3), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart4_clk, "bus-uart4", apb_uart_hws, 0xe10, BIT(4), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart5_clk, "bus-uart5", apb_uart_hws, 0xe14, BIT(5), 0);
> +static SUNXI_CCU_GATE_HWS(bus_uart6_clk, "bus-uart6", apb_uart_hws, 0xe18, BIT(6), 0);
Each UART has its own BGR register, and in every one of them the
gating bit is bit 0. Manual section 4.1.6.141 (0x0E04 UART1 Bus Gating
Reset Register): bit 16 "UART1_RST", bits 15:1 reserved ("/"), bit 0
"UART1_GATING - Gating Clock for UART1, 0: Mask, 1: Pass". Sections
4.1.6.142-4.1.6.146 have the same layout for UART2-UART6. So these six
entries should all use BIT(0); as written, enabling any of bus-uart1..6
sets a reserved bit and the UART clock stays gated. (bus-uart0 at 0xe00
BIT(0) and the uartN resets at bit 16 all match the manual.)
2) SYSDAP gate offset looks wrong:
> +static SUNXI_CCU_GATE_HWS(bus_sysdap_clk, "bus-sysdap", apb1_hws,
> + 0x88c, BIT(0), 0);
Manual section 4.1.6.92 puts SYSDAP_BGR_REG at 0x07AC (bit 16
"SYSDAP_RST", bit 0 "SYSDAP_GATING"), and patch 8/8's reset map already
uses { 0x7ac, BIT(16) } for RST_BUS_SYSDAP, so the gate here presumably
wants 0x7ac as well. There is no CCU register at 0x88C in the manual.
3) Gates without a register in the public manual (V0.92) - these could
use a short provenance note near the entry, as discussed for other IDs:
- bus-spi4 (0x0F2C)
- bus-sgpio (0x1064)
- bus-lpc (0x1084)
- bus-gmac1 (0x142C) [same question as the GMAC1 clock IDs]
- bus-tcon-lcd2 (0x1514, and the tcon-lcd2 mod clock at 0x1510) - the
manual documents only VO0_TCONLCD0 (0x1500/0x1504) and VO0_TCONLCD1
(0x1508/0x150C)
- mbus-gmac1 (0x05E4 bit 12) - bit 12 is not described in the MBUS
Gate Enable Register section
The remaining bus/mbus gate entries in this patch all match the manual's
offsets and bit positions.
Thanks,
Enzo
^ permalink raw reply
* Re: [PATCH v2 net-next 06/14] net: enetc: simplify enetc4_set_port_speed()
From: Maxime Chevallier @ 2026-07-02 17:32 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-7-wei.fang@oss.nxp.com>
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> Since phylink only passes valid speed values to mac_link_up, the switch
> statement with its default fallback to SPEED_10 is unnecessary. Replace
> it with a direct call to PCR_PSPEED_VAL(). Also update PCR_PSPEED_VAL()
> to use FIELD_PREP() for proper field masking instead of an open-coded
> shift.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH v2 net-next 07/14] net: enetc: differentiate phylink capabilities for pseudo-MAC and standalone MAC
From: Maxime Chevallier @ 2026-07-02 17:30 UTC (permalink / raw)
To: wei.fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, linux, wei.fang,
chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-8-wei.fang@oss.nxp.com>
Hi,
On 7/2/26 04:57, wei.fang@oss.nxp.com wrote:
> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>
> The ENETC pseudo-MACs are proprietary internal links that do not
> implement any standard MII interface, so restrict their supported PHY
> interface modes to PHY_INTERFACE_MODE_INTERNAL only.
>
> Since pseudo-MACs can operate at any speed between 10Mbps and 25Gbps
> in multiples of 10Mbps, set their MAC capabilities to cover the full
> range of standard full-duplex speeds: 10/100/1000/2500/5000/10000/
> 20000/25000 Mbps.
>
> For standalone ENETC, expand the supported interface modes to include
> 10GBASER and XGMII in addition to the existing RGMII, SGMII, 1000BASEX,
> 2500BASEX and USXGMII modes, with MAC capabilities up to 10G. MAC_1000
> is replaced with MAC_1000FD to explicitly exclude 1000M half-duplex,
> which is not supported.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* [PATCH v8 16/39] drm/display: bridge_connector: Wire up HDMI 2.0 scrambler callbacks
From: Cristian Ciocaltea @ 2026-07-02 14:46 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Sandy Huang, Heiko Stübner, Andy Yan, Daniel Stone,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance
Cc: kernel, dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com>
Connect the bridge connector's .scrambler_{enable|disable} callbacks to
the underlying bridge's .hdmi_scrambler_{enable|disable} funcs when
HDMI 2.0 conformance is advertised.
This completes the bridge connector plumbing so that the SCDC
scrambling helpers can control source-side scrambling through the
bridge chain.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 40 +++++++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 17eb2548efad..ceb961a9adb5 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -578,6 +578,32 @@ static int drm_bridge_connector_write_spd_infoframe(struct drm_connector *connec
return bridge->funcs->hdmi_write_spd_infoframe(bridge, buffer, len);
}
+static int drm_bridge_connector_scrambler_enable(struct drm_connector *connector)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ return bridge->funcs->hdmi_scrambler_enable(bridge);
+}
+
+static int drm_bridge_connector_scrambler_disable(struct drm_connector *connector)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(connector);
+ struct drm_bridge *bridge;
+
+ bridge = bridge_connector->bridge_hdmi;
+ if (!bridge)
+ return -EINVAL;
+
+ return bridge->funcs->hdmi_scrambler_disable(bridge);
+}
+
static const struct drm_edid *
drm_bridge_connector_read_edid(struct drm_connector *connector)
{
@@ -603,7 +629,7 @@ static const struct drm_connector_hdmi_funcs drm_bridge_connector_hdmi_funcs = {
.clear_infoframe = drm_bridge_connector_clear_hdmi_infoframe,
.write_infoframe = drm_bridge_connector_write_hdmi_infoframe,
},
- /* audio, hdr_drm and spd are set dynamically during init */
+ /* scrambler, audio, hdr_drm and spd are set dynamically during init */
};
static const struct drm_connector_infoframe_funcs drm_bridge_connector_hdmi_audio_infoframe = {
@@ -912,6 +938,11 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
!bridge->funcs->hdmi_clear_spd_infoframe))
return ERR_PTR(-EINVAL);
+ if (bridge->supported_hdmi_ver >= HDMI_VERSION_2_0 &&
+ (!bridge->funcs->hdmi_scrambler_enable ||
+ !bridge->funcs->hdmi_scrambler_disable))
+ return ERR_PTR(-EINVAL);
+
bridge_connector->bridge_hdmi = drm_bridge_get(bridge);
if (bridge->supported_hdmi_ver)
@@ -1018,6 +1049,13 @@ struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
bridge_connector->hdmi_funcs.spd =
drm_bridge_connector_hdmi_spd_infoframe;
+ if (bridge_connector->bridge_hdmi->supported_hdmi_ver >= HDMI_VERSION_2_0) {
+ bridge_connector->hdmi_funcs.scrambler_enable =
+ drm_bridge_connector_scrambler_enable;
+ bridge_connector->hdmi_funcs.scrambler_disable =
+ drm_bridge_connector_scrambler_disable;
+ }
+
ret = drmm_connector_hdmi_init_with_caps(drm, connector,
bridge_connector->bridge_hdmi->vendor,
bridge_connector->bridge_hdmi->product,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 6/8] clk: sunxi-ng: a733: Add mod clocks support
From: Enzo Adriano @ 2026-07-02 17:24 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Brian Masney, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, linux-arm-kernel, linux-sunxi, linux-riscv, devicetree,
netdev, linux-kernel
In-Reply-To: <20260310-a733-clk-v1-6-36b4e9b24457@pigmoral.tech>
Hi Junhui,
Register check for the mod clocks in this patch against the public A733
User Manual V0.92: 88 of the 94 mod/mux clock entries match the manual's
register offsets, with the documented gating/mux/divider layout at each
offset. The six that have no register in the public manual are the set
already discussed in this thread for provenance notes - avs (0x0880),
spi4 (0x0F28), sgpio (0x1060), lpc (0x1080), gmac1-phy (0x1420) - plus
one more: tcon-lcd2 (0x1510); the manual only documents VO0_TCONLCD0
(0x1500) and VO0_TCONLCD1 (0x1508).
Thanks,
Enzo
^ 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