* [PATCH v3 2/3] pmdomain: mediatek: Add support for secure modem power domain control
From: Nikolai Burov via B4 Relay @ 2026-07-20 20:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Ulf Hansson
Cc: Matthias Brugger, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-pm, Nikolai Burov, Nikolai Burov
In-Reply-To: <20260720-mt6858-pmdomain-v3-0-8966d8de93c8@jolla.com>
From: Nikolai Burov <nikolai.burov@jolla.com>
On recent MediaTek SoCs such as MT6858, the kernel is required to use
a secure monitor call (SMC) to enable or disable the modem power domain.
The power domain control register can be read, but firmware prevents it
from being modified directly. Some other parts of the power sequence,
such as setting the ext_buck_iso register, still need to be performed on
the kernel side.
In preparation for modem support, add a flag to enable this new power
sequence for SoCs that need it. Power domains using this flag are not
expected to configure any bus protection registers, since these are
handled internally by the SMC call.
Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
---
drivers/pmdomain/mediatek/mtk-pm-domains.c | 50 +++++++++++++++++++++++++++---
drivers/pmdomain/mediatek/mtk-pm-domains.h | 1 +
include/linux/soc/mediatek/mtk_sip_svc.h | 3 ++
3 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index 8309a4b46afb..5b4d860318a4 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -57,6 +57,10 @@
#define MTK_SIP_KERNEL_HWCCF_CONTROL MTK_SIP_SMC_CMD(0x540)
+/* Secure MTCMOS commands for modem subsystem */
+#define MTK_MD_MTCMOS_ENABLE 18
+#define MTK_MD_MTCMOS_DISABLE 19
+
struct scpsys_domain {
struct generic_pm_domain genpd;
const struct scpsys_domain_data *data;
@@ -668,6 +672,34 @@ static int scpsys_modem_pwrseq_off(struct scpsys_domain *pd)
return 0;
}
+static bool scpsys_modem_sec_poll(unsigned long cmd)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(MTK_SIP_KERNEL_CCCI_CONTROL, cmd, 1, 0, 0, 0, 0, 0, &res);
+
+ return res.a0 == 0;
+}
+
+static int scpsys_modem_sec_power_on(bool on)
+{
+ struct arm_smccc_res res;
+ unsigned long cmd = on ? MTK_MD_MTCMOS_ENABLE : MTK_MD_MTCMOS_DISABLE;
+ bool tmp;
+ int ret;
+
+ arm_smccc_smc(MTK_SIP_KERNEL_CCCI_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
+ if (res.a0 == 0)
+ return 0;
+
+ ret = readx_poll_timeout(scpsys_modem_sec_poll, cmd, tmp, tmp,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int scpsys_power_on(struct generic_pm_domain *genpd)
{
struct scpsys_domain *pd = container_of(genpd, struct scpsys_domain, genpd);
@@ -686,7 +718,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
regmap_clear_bits(scpsys->base, pd->data->ext_buck_iso_offs,
pd->data->ext_buck_iso_mask);
- if (MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_PWRSEQ))
+ if (MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ))
+ ret = scpsys_modem_sec_power_on(true);
+ else if (MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_PWRSEQ))
ret = scpsys_modem_pwrseq_on(pd);
else if (MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ))
ret = scpsys_simple_pwrseq_on(pd);
@@ -717,7 +751,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
goto err_pwr_ack;
}
- if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ)) {
+ if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ) &&
+ !MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ)) {
ret = scpsys_sram_enable(pd);
if (ret < 0)
goto err_disable_subsys_clks;
@@ -739,7 +774,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
err_enable_bus_protect:
scpsys_bus_protect_enable(pd, 0);
err_disable_sram:
- if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ))
+ if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ) &&
+ !MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ))
scpsys_sram_disable(pd);
err_disable_subsys_clks:
if (!MTK_SCPD_CAPS(pd, MTK_SCPD_STRICT_BUS_PROTECTION))
@@ -761,7 +797,11 @@ static int scpsys_power_off_internal(struct scpsys_domain *pd)
if (ret < 0)
return ret;
- if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ)) {
+ if (MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ)) {
+ ret = scpsys_modem_sec_power_on(false);
+ if (ret)
+ return ret;
+ } else if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ)) {
ret = scpsys_sram_disable(pd);
if (ret < 0)
return ret;
@@ -781,7 +821,7 @@ static int scpsys_power_off_internal(struct scpsys_domain *pd)
ret = scpsys_modem_pwrseq_off(pd);
else if (MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ))
ret = scpsys_simple_pwrseq_off(pd);
- else
+ else if (!MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ))
ret = scpsys_ctl_pwrseq_off(pd);
if (ret < 0) {
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.h b/drivers/pmdomain/mediatek/mtk-pm-domains.h
index 092403de66fa..8690690335ad 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.h
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.h
@@ -18,6 +18,7 @@
#define MTK_SCPD_SKIP_RESET_B BIT(11)
#define MTK_SCPD_INFRA_PWR_CTL BIT(12)
#define MTK_SCPD_SIMPLE_PWRSEQ BIT(13)
+#define MTK_SCPD_MODEM_SECURE_PWRSEQ BIT(14)
#define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data ? \
(_scpd)->data->caps & (_x) : \
(_scpd)->hwv_data->caps & (_x))
diff --git a/include/linux/soc/mediatek/mtk_sip_svc.h b/include/linux/soc/mediatek/mtk_sip_svc.h
index abe24a73ee19..6c95a29b79fa 100644
--- a/include/linux/soc/mediatek/mtk_sip_svc.h
+++ b/include/linux/soc/mediatek/mtk_sip_svc.h
@@ -22,6 +22,9 @@
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, MTK_SIP_SMC_CONVENTION, \
ARM_SMCCC_OWNER_SIP, fn_id)
+/* Modem related SMC call */
+#define MTK_SIP_KERNEL_CCCI_CONTROL MTK_SIP_SMC_CMD(0x505)
+
/* DVFSRC SMC calls */
#define MTK_SIP_DVFSRC_VCOREFS_CONTROL MTK_SIP_SMC_CMD(0x506)
--
2.54.0
^ permalink raw reply related
* Re: [RFC PATCH 2/2] KVM: arm64: Support BBM level 3
From: Mostafa Saleh @ 2026-07-20 20:41 UTC (permalink / raw)
To: Oliver Upton
Cc: linux-kernel, kvmarm, linux-arm-kernel, maz, seiden, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, vdonnefort,
tabba
In-Reply-To: <alvaEgJFJ5DaQaac@google.com>
On Sat, Jul 18, 2026 at 8:55 PM Mostafa Saleh <smostafa@google.com> wrote:
>
> Hi Oliver,
>
> On Fri, Jul 17, 2026 at 01:56:03PM -0700, Oliver Upton wrote:
> > Hi Mostafa,
> >
> > On Fri, Jul 17, 2026 at 01:09:00PM +0000, Mostafa Saleh wrote:
> > > If the system supports hardware Break-Before-Make (BBM) level 3, use it
> > > to replace stage-2 PTEs directly instead of falling back to the software
> > > break-before-make sequence.
> > >
> > > 1) Get a reference count on the containing table for the new PTE.
> > > 2) Atomically update the PTE with the new valid descriptor.
> > > 3) Invalidate the TLB for the old PTE.
> > > 4) Drop the reference count holding the old PTE.
> > >
> > > One interesting case, as BBML3 will update the PTE atomically, it
> > > can only know it raced with another core at the point of the cmpxchg
> > > failing, unlike the SW implementation which locks the PTE first.
> > > And as we must issue CMOs to the new mapped page before the update,
> > > that means with BBML3 racing cores will issue redundant CMOs,
> >
> > I'd rather we just predicate BBML3-style transformations on an
> > implementation having FEAT_S2FWB and DIC. You can definitely come along
> > later and enable it when using a stage-2 in an SMMU makes this
> > mandatory, possibly at the expense of some extra CMOs.
>
> Makes sense, I will do that in v2.
>
Looking into this, I see some existing inefficiencies (or maybe I do
not understand it well)
- pKVM still do some work for dcache with FWB I posted a patch for that:
https://lore.kernel.org/all/20260720203529.1276355-1-smostafa@google.com/
- KVM does not elide the icache maintainence with DIC, it seems we
should have something similar for the FWB check in
__clean_dcache_guest_page() as
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 6eae7e7e2a68..d0a4ae66b069 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -247,6 +247,9 @@ static inline size_t __invalidate_icache_max_range(void)
static inline void __invalidate_icache_guest_page(void *va, size_t size)
{
+ if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
+ return;
+
/*
* Blow the whole I-cache if it is aliasing (i.e. VIPT) or the
* invalidation range exceeds our arbitrary limit on invadations by
or I am missing something?
Thanks,
Mostafa
^ permalink raw reply related
* [PATCH] KVM: arm64: Optimize protected mode and FWB
From: Mostafa Saleh @ 2026-07-20 20:35 UTC (permalink / raw)
To: linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, seiden, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, vdonnefort, tabba, sebastianene, keirf,
Mostafa Saleh
KVM opportunistically enables FWB if supported by the system for guest
VMs, which allows it to elude cache maintenance for data as they are
forced to be cacheable from stage-2.
In that case, __clean_dcache_guest_page() will immediately return.
However in protected mode, before calling __clean_dcache_guest_page()
it loops over the range and fix_map/unmap it, issuing TLB
invalidations, dsb() and isb() unnecessarily.
This can be optimized by returning early if FWB is supported,
kvm_pgtable_stage2_map() already issues dsb() and tlb invalidation
functions issue dsb() for the unmap path.
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 4e329e39a695..6e9229106a25 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -261,6 +261,10 @@ static void __apply_guest_page(void *va, size_t size,
static void clean_dcache_guest_page(void *va, size_t size)
{
+ /* See __clean_dcache_guest_page() */
+ if (cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
+ return;
+
__apply_guest_page(va, size, __clean_dcache_guest_page);
}
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: allwinner: a523: Add missing SPDIF pin
From: Andre Przywara @ 2026-07-20 20:24 UTC (permalink / raw)
To: Per Larsson
Cc: 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
In-Reply-To: <20260720174253.7686-1-per@palvencia.se>
On Mon, 20 Jul 2026 19:42:42 +0200
Per Larsson <per@palvencia.se> wrote:
Hi,
thanks for takign the time to send a patch!
> 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.
Not sure we need such an elaborate excuse to add a pinmux that is
used on one device - you could just say *that* instead.
But that's not a big issue, as the patch itself is correct.
> Add the missing pin to the dtsi so such devices can (later) use it
>
> Signed-off-by: Per Larsson <per@palvencia.se>
Checked the details against the user manual: they match:
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 7 +++++++
> 1 file changed, 7 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";
^ permalink raw reply
* Re: [PATCH] Documentation/devicetree/bindings: update Sudeep Holla's email address
From: Sudeep Holla @ 2026-07-20 20:21 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Conor Dooley, Cristian Marussi, Jassi Brar, Krzysztof Kozlowski,
Linus Walleij, Liviu Dudau, Lorenzo Pieralisi, Rob Herring,
arm-scmi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260720160235.36592-1-laszlo.ersek@arm.com>
On Mon, Jul 20, 2026 at 06:02:30PM +0200, Laszlo Ersek wrote:
> MAINTAINERS disagrees with Documentation/devicetree/bindings on Sudeep's
> email address; fix the latter.
>
$subject is bit of a deviation from normal practice. Otherwise looks
good to me and thanks for updating it.
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v3 phy-next 8/8] phy: lynx-10g: use RCW override procedure for dynamic protocol change
From: Vladimir Oltean @ 2026-07-20 20:12 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-phy, devicetree, linuxppc-dev, linux-arm-kernel,
Ioana Ciornei, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel
In-Reply-To: <al5ODzYhpE-wHSSN@vaman>
Hi Vinod,
On Mon, Jul 20, 2026 at 10:04:23PM +0530, Vinod Koul wrote:
> On 20-07-26, 16:36, Vladimir Oltean wrote:
> > Up until this patch, the only protocol change supported was between
> > 1000Base-X/SGMII and 2500Base-X. The others require an RCW override
> > procedure which was lacking.
> >
> > Since now the guts driver provides the means of applying this procedure,
> > make use of it and remove any comment which mentioned the limitation.
>
> lgtm, is there any dependency. If not I can pick it
>
> --
> ~Vinod
There is no other direct dependency, but I need to send a v4 tomorrow
due to some valid Sashiko comments.
There is also this patch which seems to have been forgotten:
https://patchwork.kernel.org/project/linux-phy/patch/20260612125731.133330-1-vladimir.oltean@nxp.com/
Thanks,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller
From: Krzysztof Kozlowski @ 2026-07-20 20:09 UTC (permalink / raw)
To: Nikolai Burov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Ulf Hansson, Matthias Brugger,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-pm, Nikolai Burov
In-Reply-To: <db76f500-0db5-4c5f-b4cb-60818702787e@abscue.de>
On 20/07/2026 21:09, Nikolai Burov wrote:
> On 7/20/26 8:05 AM, Krzysztof Kozlowski wrote:
>> On Wed, Jul 15, 2026 at 04:54:05PM +0300, Nikolai Burov wrote:
>>> Add a new compatible and document bindings for the power domain
>>> controller of the MT6858 SoC.
>>>
>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>
>> To provide review, please open and read the entire file.
>>
>>> Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
>>> ---
>>> .../bindings/power/mediatek,power-controller.yaml | 21 +++++++++++++++++++-
>>> include/dt-bindings/power/mediatek,mt6858-power.h | 23 ++++++++++++++++++++++
>>> 2 files changed, 43 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>>> index 070c6e5666dc..d03e4a925163 100644
>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>>> @@ -25,6 +25,7 @@ properties:
>>> enum:
>>> - mediatek,mt6735-power-controller
>>> - mediatek,mt6795-power-controller
>>> + - mediatek,mt6858-power-controller
>>> - mediatek,mt6893-power-controller
>>> - mediatek,mt8167-power-controller
>>> - mediatek,mt8173-power-controller
>>> @@ -56,7 +57,7 @@ properties:
>>> faults while enabling or disabling a power domain.
>>> For example, this may hold phandles to INFRACFG and SMI.
>>> minItems: 1
>>> - maxItems: 3
>>> + maxItems: 6
>>
>> And the rest? Why does this device have flexible number of access
>> controllers?
>
> For mt6858, the "items" list I provided already overrides both minItems
> and maxItems, so it has a fixed number (6) of access controllers.
Correct, somehow I missed that part of the diff for this file.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller
From: Krzysztof Kozlowski @ 2026-07-20 20:09 UTC (permalink / raw)
To: nikolai.burov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Ulf Hansson
Cc: Matthias Brugger, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-pm, Nikolai Burov
In-Reply-To: <20260715-mt6858-pmdomain-v2-1-6293e87fc093@jolla.com>
On 15/07/2026 15:54, Nikolai Burov via B4 Relay wrote:
> From: Nikolai Burov <nikolai.burov@jolla.com>
>
> Add a new compatible and document bindings for the power domain
> controller of the MT6858 SoC.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
> ---
> .../bindings/power/mediatek,power-controller.yaml | 21 +++++++++++++++++++-
> include/dt-bindings/power/mediatek,mt6858-power.h | 23 ++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] clk: mmp: allow COMPILE_TEST builds
From: Brian Masney @ 2026-07-20 20:08 UTC (permalink / raw)
To: Duje Mihanović
Cc: linux-clk, Rosen Penev, Michael Turquette, Stephen Boyd,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
open list, moderated list:ARM/Marvell PXA1908 SOC support,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <YBsaITDCQyaUWFnnWTe4Fw@gmail.com>
Hi Duje,
On Mon, Jul 20, 2026 at 04:46:40PM +0200, Duje Mihanović wrote:
> On Sunday, 19 July 2026 23:43:49 Central European Summer Time Rosen Penev
> wrote:
>
> [...]
>
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index 4b2c089f46a1..8383f9f1da51 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -130,7 +130,7 @@ obj-y +=
> mediatek/
> > obj-$(CONFIG_ARCH_MESON) += meson/
> > obj-y += microchip/
> > ifeq ($(CONFIG_COMMON_CLK), y)
> > -obj-$(CONFIG_ARCH_MMP) += mmp/
> > +obj-$(CONFIG_COMMON_CLK_MMP) += mmp/
>
> Could it be possible to select mmp unconditionally, like most of the other
> subtrees are? AFAICT, that would also require creating new Kconfig symbols for
> the PXA168, PXA910 and PXA1928 clocks, but I suspect it may be the more proper
> choice in the long term.
Just by sheer numbers, the CONFIG_COMMON_CLK_XXX approach is the most
common use case right now.
x1:~/src/linux/linux-next ((next-20260720) %)$ grep "CONFIG_COMMON_CLK" drivers/clk/Makefile | grep "+=" | wc -l
68
x1:~/src/linux/linux-next ((next-20260720) %)$ grep "obj-y" drivers/clk/Makefile | wc -l
25
I have no strong opinions about this either way other than to drive
consistency across various drivers as much as possible.
Currently the mmp directory currently only has COMMON_CLK_PXA1908
defined. When the other PXA* drivers are introduced, will there be a
CONFIG_COMMON_CLK_MMA_COMMON that all of the drivers will use?
If so, we could put that MMA_COMMON in the toplevel clk Makefile.
If not, then yes I agree that obj-y will be fine.
Brian
^ permalink raw reply
* Re: [PATCHv2 2/2] clk: stm32: allow STM32MP COMPILE_TEST builds
From: Brian Masney @ 2026-07-20 20:01 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Gabriel Fernandez, Nicolas Le Bayon,
Alok Tiwari, open list, moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260719215040.767232-3-rosenp@gmail.com>
On Sun, Jul 19, 2026 at 02:50:40PM -0700, Rosen Penev wrote:
> COMMON_CLK_STM32MP already allows COMPILE_TEST, but the parent clock
> Makefile only descends into drivers/clk/stm32 for ARCH_STM32. Use the
> STM32MP clock symbol for that directory gate instead.
>
> Tested with:
> make LLVM=1 ARCH=loongarch drivers/clk/stm32/
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCHv2 1/2] clk: stm32: add missing bitfield.h header
From: Brian Masney @ 2026-07-20 20:00 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Gabriel Fernandez, Nicolas Le Bayon,
Alok Tiwari, open list, moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260719215040.767232-2-rosenp@gmail.com>
On Sun, Jul 19, 2026 at 02:50:39PM -0700, Rosen Penev wrote:
> It seems some ARM header includes this and the build passes there, but
> nowhere else. Note that the driver has COMPILE_TEST in depends.
>
> Fixes: 37ae8501cdb0 ("clk: stm32: introduce clocks for STM32MP21 platfor")
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v16 6/7] spi: pxa2xx: restore LPSS private register state on S3 resume
From: Andy Shevchenko @ 2026-07-20 19:59 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-7-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:15AM +0800, Shih-Yuan Lee wrote:
Is this series AI-assisted?
> Intel LPSS SPI controllers lose all private register state across S3
> suspend because the LPSS power domain is fully removed. On resume the
> driver only re-enables the SSP clock, leaving the LPSS private registers
> in their power-on-reset state, which causes two problems:
>
> 1. LPSS_PRIV_RESETS (offset 0x04 within the LPSS private space) stays
> zero, keeping the functional block in reset. Any MMIO access while
> the block is held in reset causes a PCIe Completion Timeout and a
> watchdog-triggered system reset. LPSS_PRIV_RESETS_FUNC and
> LPSS_PRIV_RESETS_IDMA must be de-asserted before any other register
> access on resume.
>
> 2. The LPSS software chip-select control register must not be blindly
> restored from its suspend-time snapshot: if CS was asserted at the
> moment of suspend, restoring that state corrupts the first
> post-resume SPI transaction. Instead, call lpss_ssp_setup() which
> unconditionally writes SW_MODE | CS_HIGH (idle/deasserted), matching
> the state established at probe time.
>
> To resolve these issues safely:
> - Wrap S3 suspend/resume with pm_runtime_resume_and_get() and
> pm_runtime_put_noidle() to guarantee active clocks during MMIO
> access and preserve PM reference counting.
> - Restrict LPSS private register save/restore to LPT, BYT, and BSW
^^^^ (1)
> platforms via pxa2xx_spi_need_lpss_restore() (newer platforms are
> handled by intel-lpss.c).
> - Save only the first 6 LPSS private registers (offsets 0x00..0x14) in
> drv_data during suspend, avoiding reserved offsets beyond 0x14.
> - On resume, de-assert resets first, restore saved registers, call
> lpss_ssp_setup(), and clear drv_data->suspended to prevent unclocked
> IRQ access.
> - Add error recovery paths for spi_controller_suspend/resume failures.
> - On the resume error path, call pm_runtime_set_suspended() before
> pm_runtime_put_noidle() to align the PM runtime state with the
> already-disabled hardware clock, preventing pxa2xx_spi_runtime_suspend()
> from attempting unclocked MMIO via pxa2xx_spi_off().
This is an ugly hack.
Saving context is done in drivers/acpi/x86/lpss.c (see #1 why this file).
If something wrong in the flow it has to be fixed there, not here.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v16 7/7] spi: pxa2xx: rename local status variable to ret
From: Andy Shevchenko @ 2026-07-20 19:56 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-8-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:16AM +0800, Shih-Yuan Lee wrote:
> Rename the return value variable name from 'status' to 'ret' in the
> pxa2xx_spi_probe(), pxa2xx_spi_suspend(), pxa2xx_spi_resume(), and
> pxa2xx_spi_runtime_resume() functions to conform to standard Linux kernel
> coding conventions.
It makes a ping-pong style of changes: Previous patches add more status uses
and moves, and so on. Instead, this patch should go before all that.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v16 4/7] spi: pxa2xx: lock out runtime autosuspend for Intel LPSS SPI in PIO mode
From: Andy Shevchenko @ 2026-07-20 19:55 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-5-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:13AM +0800, Shih-Yuan Lee wrote:
> When operating in PIO mode on Intel LPSS SPI controllers, runtime PM
> autosuspend clock-gates the hardware block when idle. On subsequent
> transfers, MMIO accesses to trigger resume are performed before the runtime
> PM state machine can wake the controller, causing PCIe Completion Timeouts.
> This issue does not affect DMA mode, where the DMA engine holds the required
> resources, nor does it affect non-LPSS controllers.
>
> Lock out runtime PM autosuspend for LPSS SPI controllers specifically
> when operating in PIO mode.
>
> Acquire a runtime PM reference via pm_runtime_get_noresume() in
> pxa2xx_spi_probe() after registration, and release it via
> pm_runtime_put_noidle() in pxa2xx_spi_remove() before hardware teardown to
> ensure the runtime PM reference held in probe is released without invoking
> runtime_suspend on already-unclocked hardware.
.runtime_suspend()
// this is how we refer to the callbacks.
...
> + /* Release the PM reference held in probe for LPSS PIO mode before
> + * hardware teardown so the PM core does not invoke runtime_suspend
> + * on already-unclocked hardware.
> + */
/*
* Keep the comment style as per SPI and many other subsystems
* and as in this example.
*/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v16 3/7] spi: pxa2xx: overhaul teardown and suspend sequence using pxa2xx_spi_off
From: Andy Shevchenko @ 2026-07-20 19:53 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-4-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:12AM +0800, Shih-Yuan Lee wrote:
> When removing the driver or suspending the device, the clock must not
> be disabled while shared interrupts are still active. Gating the clock
> before waiting for in-flight interrupt handlers to complete results
> in race conditions where the handler performs unclocked MMIO accesses,
> causing PCIe Completion Timeouts.
>
> Overhaul the remove, suspend, and runtime_suspend paths to use a strict
> synchronized teardown order:
> 1. Disable hardware interrupt generation at the controller level.
> 2. Mark the device state as suspended (suspended = true) to prevent
> subsequent interrupt handlers from attempting MMIO reads.
> 3. Call synchronize_irq() to wait for any active interrupt handlers
> to drain completely.
> 4. Gate the clock via pxa2xx_spi_clk_disable().
>
> Additionally, commit 29d7e05c5f75 ("spi: pxa2xx: Avoid touching
> SSCR0_SSE on MMP2") documented that disabling the hardware block via SSE on
> MMP2 SoC platforms corrupts the RX/TX FIFO. Instead of calling
> pxa_ssp_disable() directly, use the helper function pxa2xx_spi_off(),
> which respects the MMP2 platform quirk by bypassing SSE register writes.
...
> + /* Wait for any pending interrupt handlers to complete */
> + synchronize_irq(ssp->irq);
Unneeded. free_irq() implies that.
> + /* Release IRQ */
> + free_irq(ssp->irq, drv_data);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Fix hyp_trace clock disabling
From: Fuad Tabba @ 2026-07-20 19:45 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oupton, kvmarm, linux-arm-kernel, joey.gouly, seiden,
suzuki.poulose, yuzenghui, catalin.marinas, will, kernel-team
In-Reply-To: <20260715105100.3178255-1-vdonnefort@google.com>
Hi Vincent,
On Wed, 15 Jul 2026 at 11:51, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> Fix the disable path in hyp_trace_clock_enable(), which fell through to
> re-initialize and reschedule the clock after cancelling the work. Return
> early instead.
>
> While at it, cleanup hyp_trace_clock::lock which is unused and
> hyp_trace_clock::running which is redundant: the trace_remote framework
> already serializes calls to the callback enable_tracing.
Although the cleanup and the fix are to the same commit, could this be
split into the fix and the lock/running cleanup as a separate patch?
Since b22888917fa41 is already in a released kernel, the fix will
likely go to stable, and it'd be nice to keep that backport to just
the behavioural change.
Cheers,
/fuad
>
> Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp")
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> ---
>
> v1 -> v2:
> * Rollback hyp_trace_clock_enable() on __tracing_enable error (Sashiko)
>
> v1: https://lore.kernel.org/all/alczBmnItMwq8xj4@google.com/
>
> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index 2411b4c32932..9bfa368dd841 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c
> @@ -37,8 +37,6 @@ static struct hyp_trace_clock {
> u32 shift;
> struct delayed_work work;
> struct completion ready;
> - struct mutex lock;
> - bool running;
> } hyp_clock;
>
> static void __hyp_clock_work(struct work_struct *work)
> @@ -110,12 +108,9 @@ static void hyp_trace_clock_enable(struct hyp_trace_clock *hyp_clock, bool enabl
> {
> struct system_time_snapshot snap;
>
> - if (hyp_clock->running == enable)
> - return;
> -
> if (!enable) {
> cancel_delayed_work_sync(&hyp_clock->work);
> - hyp_clock->running = false;
> + return;
> }
>
> ktime_get_snapshot_id(CLOCK_BOOTTIME, &snap);
> @@ -128,7 +123,6 @@ static void hyp_trace_clock_enable(struct hyp_trace_clock *hyp_clock, bool enabl
> INIT_DELAYED_WORK(&hyp_clock->work, __hyp_clock_work);
> schedule_delayed_work(&hyp_clock->work, msecs_to_jiffies(CLOCK_INIT_MS));
> wait_for_completion(&hyp_clock->ready);
> - hyp_clock->running = true;
> }
>
> /* Access to this struct within the trace_remote_callbacks are protected by the trace_remote lock */
> @@ -304,9 +298,15 @@ static void hyp_trace_unload(struct trace_buffer_desc *desc, void *priv)
>
> static int hyp_trace_enable_tracing(bool enable, void *priv)
> {
> + int ret;
> +
> hyp_trace_clock_enable(&hyp_clock, enable);
>
> - return kvm_call_hyp_nvhe(__tracing_enable, enable);
> + ret = kvm_call_hyp_nvhe(__tracing_enable, enable);
> + if (ret)
> + hyp_trace_clock_enable(&hyp_clock, !enable);
> +
> + return ret;
> }
>
> static int hyp_trace_swap_reader_page(unsigned int cpu, void *priv)
>
> base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
> --
> 2.55.0.141.g00534a21ce-goog
>
^ permalink raw reply
* Re: [PATCH v3] ARM: imx: Fix suspend/resume crash with Clang CFI
From: Sami Tolvanen @ 2026-07-20 19:29 UTC (permalink / raw)
To: Yo'av Moshe
Cc: Frank Li, Sascha Hauer, Russell King, Pengutronix Kernel Team,
Fabio Estevam, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, imx, linux-arm-kernel, llvm, stable, linux-kernel
In-Reply-To: <20260718111340.159896-1-linux@yoavmoshe.com>
On Sat, Jul 18, 2026 at 4:14 AM Yo'av Moshe <linux@yoavmoshe.com> wrote:
>
> Relocated suspend code in OCRAM lacks compiler-generated CFI type
> signatures. When CONFIG_CFI=y is active, the indirect call to
> imx6_suspend_in_ocram_fn triggers a strict CFI violation panic.
Would it be possible to just copy the 4-byte CFI hash prefix to OCRAM
when relocating the function? If not, the __nocfi approach seems
reasonable to me.
Sami
^ permalink raw reply
* Re: [PATCH v16 5/7] spi: pxa2xx: disable DMA for Apple MacBook8,1
From: Andy Shevchenko @ 2026-07-20 19:27 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-6-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:14AM +0800, Shih-Yuan Lee wrote:
> On MacBook8,1 (early 2015 12" MacBook), the LPSS SPI controller at
> 00:15.4 suffers from hardware DMA handshake failures and interrupt
> routing bugs, causing keyboard/touchpad transactions to fail when
> DMA is enabled.
Why? The thing like this I noticed on some other HW which required different
DMA settings. Have you tried to investigate the issue more?
> Move the forced PIO mode DMI quirk to spi-pxa2xx-pci.c (the LPSS host
> controller PCI glue driver) to avoid layering violations in client
> drivers (such as applespi).
>
> Add an explicit DMI match table for MacBook8,1 and a module parameter
> spi_pxa2xx_force_pio to allow forcing PIO mode on demand.
This looks like a hack. Please, if you have a hardware, try to dump the errors,
collect the data corruption or timeouts and provide more information. DMA for
SPI on LPSS hardware never was a problem (unlike UART in some cases). I'm almost
100% sure the problem is in DMA configuration / setting bits.
...
> #include <linux/dmaengine.h>
> #include <linux/platform_data/dma-dw.h>
> +#include <linux/dmi.h>
Keep list ordered.
> #include "spi-pxa2xx.h"
...
> +static bool spi_pxa2xx_force_pio;
> +module_param_named(force_pio, spi_pxa2xx_force_pio, bool, 0444);
> +MODULE_PARM_DESC(force_pio, "Force PIO mode (disables DMA) for SPI transfers. ([0] = disabled, 1 = enabled)");
No. There is no room for module parameters like this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 5/8] phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
From: Cristian Ciocaltea @ 2026-07-20 19:24 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov, kernel, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, Thomas Niederprüm,
Simon Wright
In-Reply-To: <al4ujA5d6B5s23C4@umbar.lan>
On 7/20/26 5:19 PM, Dmitry Baryshkov wrote:
> On Fri, Jun 12, 2026 at 02:45:24AM +0300, Cristian Ciocaltea wrote:
>> Since commit ba9c2fe18c17 ("drm/rockchip: dw_hdmi_qp: Switch to
>> phy_configure()") the TMDS rate setup doesn't rely anymore on the
>> unconventional usage of the bus width, instead it is managed exclusively
>> through the HDMI PHY configuration API.
>>
>> Drop the now obsolete workaround to retrieve the TMDS character rate via
>> phy_get_bus_width() during power_on().
>>
>> While at it, get rid of the extra call to rk_hdptx_phy_consumer_put() by
>> moving the statement at the end of the function.
>>
>> Tested-by: Thomas Niederprüm <dubito@online.de>
>> Tested-by: Simon Wright <simon@symple.nz>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 27 +++++------------------
>> 1 file changed, 6 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> index 25bd821cd039..35997087d61c 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> @@ -1660,22 +1660,6 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
>> enum phy_mode mode = phy_get_mode(phy);
>> int ret, lane;
>>
>> - if (mode != PHY_MODE_DP) {
>> - if (!hdptx->hdmi_cfg.rate && hdptx->hdmi_cfg.mode != PHY_HDMI_MODE_FRL) {
>> - /*
>> - * FIXME: Temporary workaround to setup TMDS char rate
>> - * from the RK DW HDMI QP bridge driver.
>> - * Will be removed as soon the switch to the HDMI PHY
>> - * configuration API has been completed on both ends.
>> - */
>> - hdptx->hdmi_cfg.rate = phy_get_bus_width(hdptx->phy) & 0xfffffff;
>> - hdptx->hdmi_cfg.rate *= 100;
>> - }
>> -
>> - dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
>> - hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
>> - }
>> -
>> ret = rk_hdptx_phy_consumer_get(hdptx);
>> if (ret)
>> return ret;
>> @@ -1701,9 +1685,10 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
>> rk_hdptx_dp_pll_init(hdptx);
>>
>> ret = rk_hdptx_dp_aux_init(hdptx);
>> - if (ret)
>> - rk_hdptx_phy_consumer_put(hdptx, true);
>> } else {
>> + dev_dbg(hdptx->dev, "%s rate=%llu bpc=%u\n", __func__,
>> + hdptx->hdmi_cfg.rate, hdptx->hdmi_cfg.bpc);
>> +
>> if (hdptx->pll_config_dirty)
>> ret = rk_hdptx_pll_cmn_config(hdptx);
>>
>> @@ -1716,11 +1701,11 @@ static int rk_hdptx_phy_power_on(struct phy *phy)
>> else
>> ret = rk_hdptx_tmds_ropll_mode_config(hdptx);
>> }
>> -
>> - if (ret)
>> - rk_hdptx_phy_consumer_put(hdptx, true);
>> }
>>
>> + if (ret)
>> + rk_hdptx_phy_consumer_put(hdptx, true);
>
> This looks likes an unrelated change. Could you please split it to a
> separate commit?
Ack.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v4 4/8] phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
From: Cristian Ciocaltea @ 2026-07-20 19:22 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov, kernel, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, Thomas Niederprüm,
Simon Wright
In-Reply-To: <al4t4aN01iiUKff_@umbar.lan>
On 7/20/26 5:17 PM, Dmitry Baryshkov wrote:
> On Fri, Jun 12, 2026 at 02:45:23AM +0300, Cristian Ciocaltea wrote:
>> Any changes to the PHY link rate and/or color depth done via the HDMI
>> PHY configuration API are not immediately programmed into the hardware,
>> but are delayed until the PHY usage count gets incremented from 0 to 1,
>> that is when it is powered on or when the PLL clock exposed through
>> the CCF API is prepared, whichever comes first.
>
> Why do you need either-of here? Can it be just one path?
The thing is that PLL clock usage is dynamic, depending on the rate, but it can
also be disabled permanently. When it's in use, it triggers before power on,
hence the hardware must be programmed at that time.
>>
>> Since the clock might remain in prepared state after subsequent PHY
>> config changes, the programming can also be triggered via
>> clk_ops.set_rate(). However, from the clock consumer perspective (i.e.
>> VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
>> as that is handled internally by the PHY and reflected in the TDMS
>> character rate only.
>>
>> As a consequence, changing the bpc while preserving the modeline may
>> lead to out-of-sync issues between CCF and HDMI PHY config state,
>> because the .set_rate() callback is not invoked when clock rate remains
>> constant. This may also happen when the PHY PLL has been pre-programmed
>> by an external entity, e.g. the bootloader, which is actually a
>> regression introduced by the recent FRL patches.
>>
>> Introduce a pll_config_dirty flag to keep track of uncommitted PHY
>> config changes and use it in clk_ops.determine_rate() to invalidate the
>> current clock rate (as known by CCF) and, consequently, ensure those
>> changes are programmed into hardware via clk_ops.set_rate().
>>
>> Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
>> handle the scenario where the CCF API is not used due to operating in
>> FRL mode, while the clock is still in a prepared state and thus
>> preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
>> configuration.
>>
>> Fixes: de5dba833118 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
>> Fixes: 9d0ec51d7c22 ("phy: rockchip: samsung-hdptx: Add high color depth management")
>> Tested-by: Thomas Niederprüm <dubito@online.de>
>> Tested-by: Simon Wright <simon@symple.nz>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 84 +++++++++++++----------
>> 1 file changed, 48 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> index b210c1a88b25..25bd821cd039 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c
>> @@ -413,6 +413,7 @@ struct rk_hdptx_phy {
>>
>> /* clk provider */
>> struct clk_hw hw;
>> + bool pll_config_dirty;
>
> Which lock protects it?
This is not protected by a driver-local lock, as the impacted calls are
orchestrated by the DRM core, which should guaranty the expected sequence of
operations:
1. encoder-check -> phy_configure -> no HW programming, pll_config_dirty=true
2. VOP2 crtc-enable -> set_rate -> HW commit, pll_config_dirty=false
3. bridge-enable -> phy_power_on, no HW programming (pll_config_dirty already
false)
>
>> bool restrict_rate_change;
>>
>> atomic_t usage_count;
>
^ permalink raw reply
* Re: [PATCH v16 1/7] spi: pxa2xx: introduce clock enable and disable helper functions
From: Andy Shevchenko @ 2026-07-20 19:22 UTC (permalink / raw)
To: Shih-Yuan Lee
Cc: Mark Brown, Mika Westerberg, Lukas Wunner, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, linux-arm-kernel, linux-spi,
linux-kernel
In-Reply-To: <20260720162117.32304-2-fourdollars@debian.org>
On Tue, Jul 21, 2026 at 12:21:10AM +0800, Shih-Yuan Lee wrote:
> The driver disables the clock during PM runtime suspend, PM system
> suspend, and device unbinding (remove). It also disables the clock
> on various error unwinding paths in pxa2xx_spi_probe().
>
> However, if the clock is already disabled (for example, if the device is
> already runtime-suspended during driver unbinding), calling the common
> clock framework's clk_disable_unprepare() again leads to clock prepare/enable
> count underflows, generating kernel warnings.
Any real life example here?
> Introduce pxa2xx_spi_clk_enable() and pxa2xx_spi_clk_disable() helper
> functions that track the clock enable state using a new 'clk_enabled'
> boolean flag in struct driver_data.
>
> This ensures clk_disable_unprepare() is called only when the clock is
> active, preventing clock underflows during suspend transitions and unbind.
> It also allows the probe function to safely unwind resource allocations
> without triggering clock underflows.
...
Same issue, I have no cover letter in my mailbox. Please, slow down and check
your email setup. Something is wrong.
...
> +static int pxa2xx_spi_clk_enable(struct driver_data *drv_data)
> +{
> + int ret;
> +
> + if (drv_data->clk_enabled)
> + return 0;
> +
> + ret = clk_prepare_enable(drv_data->ssp->clk);
> + if (ret == 0)
> + drv_data->clk_enabled = true;
> +
> + return ret;
Use usual pattern
if (ret)
return ret;
...
return 0;
> +}
> +static void pxa2xx_spi_clk_disable(struct driver_data *drv_data)
> +{
> + if (drv_data->clk_enabled) {
if (!drv_data->clk_enabled)
return;
> + clk_disable_unprepare(drv_data->ssp->clk);
> + drv_data->clk_enabled = false;
> + }
> +}
...
> struct driver_data {
> void __iomem *lpss_base;
>
> + bool clk_enabled;
How is this protected against simultaneously called enable/disable on different
CPUs?
> /* Optional slave FIFO ready signal */
> struct gpio_desc *gpiod_ready;
> };
Whenever you add the field, check with `pahole` that the layout is optimal.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: Add MediaTek MT6858 power domain controller
From: Nikolai Burov @ 2026-07-20 19:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Ulf Hansson, Matthias Brugger,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-pm, Nikolai Burov
In-Reply-To: <20260720-vigorous-groovy-cassowary-9912d9@quoll>
On 7/20/26 8:05 AM, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 04:54:05PM +0300, Nikolai Burov wrote:
>> Add a new compatible and document bindings for the power domain
>> controller of the MT6858 SoC.
>>
>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> To provide review, please open and read the entire file.
>
>> Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
>> ---
>> .../bindings/power/mediatek,power-controller.yaml | 21 +++++++++++++++++++-
>> include/dt-bindings/power/mediatek,mt6858-power.h | 23 ++++++++++++++++++++++
>> 2 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> index 070c6e5666dc..d03e4a925163 100644
>> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> @@ -25,6 +25,7 @@ properties:
>> enum:
>> - mediatek,mt6735-power-controller
>> - mediatek,mt6795-power-controller
>> + - mediatek,mt6858-power-controller
>> - mediatek,mt6893-power-controller
>> - mediatek,mt8167-power-controller
>> - mediatek,mt8173-power-controller
>> @@ -56,7 +57,7 @@ properties:
>> faults while enabling or disabling a power domain.
>> For example, this may hold phandles to INFRACFG and SMI.
>> minItems: 1
>> - maxItems: 3
>> + maxItems: 6
>
> And the rest? Why does this device have flexible number of access
> controllers?
For mt6858, the "items" list I provided already overrides both minItems
and maxItems, so it has a fixed number (6) of access controllers.
The top-level constraints are intentionally broad so that the
SoC-specific constraints below, which all have minItems == maxItems,
don't contradict them. Those are missing for some SoCs, but isn't that
an existing weakness in the bindings?
Looking at the driver, apparently those missing SoCs are the ones that
only need infracfg. That's a single access controller. So they would
never have 3 or 2 items, only 1. This is not specified in the bindings
though.
If you mean that it can't stay like this, I could change the bindings to
add such a constraint for the remaining SoCs, provided that this is
allowed - theoretically it could break some hypothetical device trees
with excess items in access-controllers.
Alternatively, I guess one solution would be to add a minItems: 1 and
maxItems: 3 constraint for the remaining SoCs to keep their bindings
unaffected, even though that seems wrong from a HW point of view. But
I'm not sure if that is what you mean.
--
Best regards,
Nikolai
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Stop the hyp trace clock worker on disable
From: Fuad Tabba @ 2026-07-20 19:04 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oupton, linux-arm-kernel, kvmarm, will, joey.gouly, seiden,
suzuki.poulose, yuzenghui, linux-kernel
In-Reply-To: <al5w4wn9ZhPsZYUR@google.com>
On Mon, 20 Jul 2026 at 20:03, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> On Mon, Jul 20, 2026 at 08:01:55PM +0100, Vincent Donnefort wrote:
> > On Mon, Jul 20, 2026 at 07:48:50PM +0100, Fuad Tabba wrote:
> > > When disabling, hyp_trace_clock_enable() cancels the clock work but then
> > > falls through into the enable path, which re-schedules it and marks the
> > > clock running again, so the worker never stops. Return once the work is
> > > cancelled.
> > >
> > > Fixes: b22888917fa41 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp")
> > > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > > Closes: https://lore.kernel.org/all/20260720172923.E4F161F000E9@smtp.kernel.org/
> > > Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> >
> > Done here already https://lore.kernel.org/all/alczBmnItMwq8xj4@google.com/
>
> sorry I meant here:
>
> https://lore.kernel.org/all/20260715105100.3178255-1-vdonnefort@google.com/
Thanks, and sorry for the noise!
/fuad
>
>
> >
> > > ---
> > > arch/arm64/kvm/hyp_trace.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> > > index 2411b4c32932c..27367843fd211 100644
> > > --- a/arch/arm64/kvm/hyp_trace.c
> > > +++ b/arch/arm64/kvm/hyp_trace.c
> > > @@ -116,6 +116,7 @@ static void hyp_trace_clock_enable(struct hyp_trace_clock *hyp_clock, bool enabl
> > > if (!enable) {
> > > cancel_delayed_work_sync(&hyp_clock->work);
> > > hyp_clock->running = false;
> > > + return;
> > > }
> > >
> > > ktime_get_snapshot_id(CLOCK_BOOTTIME, &snap);
> > >
> > > base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
> > > --
> > > 2.39.5
> > >
^ permalink raw reply
* [PATCH v3 3/3] ARM/arm64: defconfig: Drop redundant Qualcomm interconnect entries
From: Krzysztof Kozlowski @ 2026-07-20 19:03 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260720-interconnect-qcom-clean-arm64-v3-0-942e8ee7ebda@oss.qualcomm.com>
Drop all drivers from defconfig which have defaults in Kconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/configs/qcom_defconfig | 3 ---
arch/arm64/configs/defconfig | 31 -------------------------------
2 files changed, 34 deletions(-)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index df0a0ce5b097..630e31c036a9 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -272,9 +272,6 @@ CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=y
CONFIG_PHY_QCOM_USB_HSIC=y
CONFIG_NVMEM_QCOM_QFPROM=y
CONFIG_INTERCONNECT=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_MSM8974=m
-CONFIG_INTERCONNECT_QCOM_SDX55=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT4_FS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 91a3b2cd10b3..b11040fa9cfd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1863,37 +1863,6 @@ CONFIG_INTERCONNECT_IMX8MM=m
CONFIG_INTERCONNECT_IMX8MN=m
CONFIG_INTERCONNECT_IMX8MQ=m
CONFIG_INTERCONNECT_IMX8MP=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_ELIZA=y
-CONFIG_INTERCONNECT_QCOM_GLYMUR=y
-CONFIG_INTERCONNECT_QCOM_KAANAPALI=y
-CONFIG_INTERCONNECT_QCOM_MSM8916=m
-CONFIG_INTERCONNECT_QCOM_MSM8953=y
-CONFIG_INTERCONNECT_QCOM_MSM8996=y
-CONFIG_INTERCONNECT_QCOM_OSM_L3=m
-CONFIG_INTERCONNECT_QCOM_QCM2290=y
-CONFIG_INTERCONNECT_QCOM_QCS404=m
-CONFIG_INTERCONNECT_QCOM_QCS615=y
-CONFIG_INTERCONNECT_QCOM_QCS8300=y
-CONFIG_INTERCONNECT_QCOM_QDU1000=y
-CONFIG_INTERCONNECT_QCOM_SA8775P=y
-CONFIG_INTERCONNECT_QCOM_SC7180=y
-CONFIG_INTERCONNECT_QCOM_SC7280=y
-CONFIG_INTERCONNECT_QCOM_SC8180X=y
-CONFIG_INTERCONNECT_QCOM_SC8280XP=y
-CONFIG_INTERCONNECT_QCOM_SDM845=y
-CONFIG_INTERCONNECT_QCOM_SDX75=y
-CONFIG_INTERCONNECT_QCOM_SM6115=y
-CONFIG_INTERCONNECT_QCOM_SM6350=y
-CONFIG_INTERCONNECT_QCOM_MILOS=y
-CONFIG_INTERCONNECT_QCOM_SM8150=y
-CONFIG_INTERCONNECT_QCOM_SM8250=y
-CONFIG_INTERCONNECT_QCOM_SM8350=y
-CONFIG_INTERCONNECT_QCOM_SM8450=y
-CONFIG_INTERCONNECT_QCOM_SM8550=y
-CONFIG_INTERCONNECT_QCOM_SM8650=y
-CONFIG_INTERCONNECT_QCOM_SM8750=y
-CONFIG_INTERCONNECT_QCOM_X1E80100=y
CONFIG_COUNTER=m
CONFIG_RZ_MTU3_CNT=m
CONFIG_STM32_TIMER_CNT=m
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] interconnect: qcom: Add missing depends to Hawi, Maili, Nord and Shikra
From: Krzysztof Kozlowski @ 2026-07-20 19:03 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260720-interconnect-qcom-clean-arm64-v3-0-942e8ee7ebda@oss.qualcomm.com>
Hawi, Maili, Nord and Shikra were added in parallel or after
commit 5b696f065843 ("interconnect: qcom: Restrict drivers per
ARM/ARM64"), thus they missed the update restricting them per
architecture (with the same rationale).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/qcom/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index dd8774d84321..6bc2038de28a 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -34,6 +34,7 @@ config INTERCONNECT_QCOM_GLYMUR
config INTERCONNECT_QCOM_HAWI
tristate "Qualcomm HAWI interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
default ARCH_QCOM
@@ -55,6 +56,7 @@ config INTERCONNECT_QCOM_KAANAPALI
config INTERCONNECT_QCOM_MAILI
tristate "Qualcomm MAILI interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
default ARCH_QCOM
@@ -146,6 +148,7 @@ config INTERCONNECT_QCOM_MSM8996
config INTERCONNECT_QCOM_NORD
tristate "Qualcomm Nord interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
default ARCH_QCOM
@@ -370,6 +373,7 @@ config INTERCONNECT_QCOM_SHIKRA
tristate "Qualcomm SHIKRA interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
default ARCH_QCOM
select INTERCONNECT_QCOM_SMD_RPM
help
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox