* Re: [PATCH RFC v5 05/12] clk: zte: Add Clock registration infrastructure.
From: Philipp Zabel @ 2026-07-02 9:01 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <84C4450E-7355-48CD-BCBB-CF619C27EBED@gmail.com>
On Di, 2026-06-30 at 11:53 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> > Am 30.06.2026 um 11:27 schrieb Philipp Zabel <p.zabel@pengutronix.de>:
> >
> > I think the MFD driver is unnecessary overhead. Can't you just keep the
> > reset controllers as auxdev and use of_platform_populate() to create
> > devices for clock-controller child nodes such as syscon-reboot?
>
> MFD for top and matrix was the suggestion of Conor:
>
> https://lore.kernel.org/linux-arm-kernel/20260618-fantasy-estimate-6c52edbc6890@spud/
>
> To quote:
>
> > I think aux bus makes perfect sense when you have a clock/reset
> > controller, but once you start expanding past that and you have reboot
> > or hwmon or hwspinlock then mfd starts to make sense.
Note how the example Conor gives is introduced with:
> > Because I messed up stuff in the past, reset-mpfs.c has both aux bus
> > and mfd probing in it, [...]
So while, yes, this is possible, I'd like to avoid it if not necessary.
> I can go either way. To me aux vs mfd seems like a distinction without a difference.
I think that's because the main difference doesn't apply here:
MFD comes from aggregate devices where a shared register space
accessible via a physical bus (which we have) can be partitioned out to
child devices. Reset controls are often just individual registers or
even bits scattered around the CRU register space, so we can't make use
of the MFD framework's IO/IRQ resource partitioning infrastructure at
all.
Auxiliary devices were introduced to separate functionality of a single
device into subsystem drivers (which applies here) for devices that are
not just controlled via direct register access, for example via a
firmware interface. That's not the case here, we usually can just share
a regmap.
Either way, I'd prefer the reset driver to not carry more boilerplate
than actual reset code, so if you can either put all of them into a
single auxiliary_driver or into a single platform_driver, I would be
happier.
regards
Philipp
^ permalink raw reply
* Re: [PATCH] futex: Optimise the size check get_futex_key()
From: Peter Zijlstra @ 2026-07-02 8:59 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: K Prateek Nayak, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Catalin Marinas, Will Deacon,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Darren Hart, Davidlohr Bueso,
André Almeida, linux-arch, linux-kernel, Samuel Holland,
Charlie Jenkins, linux-arm-kernel, linux-riscv, linux-s390,
H. Peter Anvin, Thomas Huth, Sean Christopherson, Jisheng Zhang,
Alexandre Ghiti, Christian Borntraeger, Sven Schnelle
In-Reply-To: <20260701161736.xYYizA0e@linutronix.de>
On Wed, Jul 01, 2026 at 06:17:36PM +0200, Sebastian Andrzej Siewior wrote:
> The futex address must be naturally aligned and this is checked via
> "address % size" where `address' is the supplied address and `size' is
> the expected size of futex. It is guaranteed that `size' is power of two
> but the compiler does not see it and creates here a `div' operation
> (x86, arm, gcc-15).
That's pretty stupid, since size = futex_size() := 1 << (blah); so it
has every opportunity to actually see this. Also, see below, clang does!
> We can take advantage of the pow2 property and rewrite it as
> "address & (size-1)".
>
> As per testing, the command
> |perf bench futex hash -f 1 -b 16384 -t 1 -r 30
>
> improved from
> | [thread 0] futex: 0x5619f931f740 [ 7001583 ops/sec ]
> to
> | [thread 0] futex: 0x55da173e5740 [ 7376137 ops/sec ]
>
> or by 5.3%
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>
> Could someone verify this, please? The 5% look a bit high. This is on
> top of the series (but not worsen by the series).
Bah, I tried to reproduce and couldn't. Then I noticed I did a clang
build and that is in fact clever enough to do this optimization itself.
/me tries again with a GCC build.
pre: [thread 0] futex: 0x561f14430680 [ 9021408 ops/sec ]
post: [thread 0] futex: 0x55feadbbb680 [ 8977527 ops/sec ]
(and this seems to be well inside the error threshold of this test).
So I see the GCC build do the DIV, and no longer with his patch applied,
but for some reason I cannot get the runtime performance to actually
improve much of anything on my system.
^ permalink raw reply
* Re: [PATCH v4] KVM: arm64: Record whether pKVM stage 2 mapping is cacheable
From: Marc Zyngier @ 2026-07-02 8:59 UTC (permalink / raw)
To: Bradley Morgan
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Quentin Perret, Vincent Donnefort, Leonardo Bras,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701192428.17430-1-include@grrlz.net>
+ Vincent, Leo
On Wed, 01 Jul 2026 20:24:28 +0100,
Bradley Morgan <include@grrlz.net> wrote:
>
> pKVM keeps its own mapping list for stage 2 operations. Its flush path
> uses that list directly, so it lost the PTE attribute check done by the
> generic stage 2 walker.
>
> Record whether a mapping is cacheable and skip cache maintenance for
> mappings that are not cacheable.
>
> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> ---
> Changes since V3:
> - addressed some review :)
This isn't a change log. If you want to be taken seriously, I'd
suggest you start by following the process. You are otherwise wasting
people's time. Again.
You also failed to Cc people who have provided feedback on previous
versions. That's not right.
>
> arch/arm64/kvm/pkvm.c | 51 ++++++++++++++++++++++++++++++++++---------
> 1 file changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..6d1cad890c7e 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct pkvm_mapping *m)
> return m->gfn * PAGE_SIZE;
> }
>
> +#define PKVM_MAPPING_NR_PAGES_MASK GENMASK_ULL(47, 0)
> +#define PKVM_MAPPING_NC BIT_ULL(48)
> +
> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> +{
> + return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> +}
No. You've been pointed to the correct data structure (an anonymous
structure containing bit fields). Please consider taking the review
comments into account.
This would avoid most of the churn in this patch, and make it easy to
backport. Something like the untested hack below.
M.
diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 74fedd9c5ff02..cdddc9e3a11f5 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h
@@ -195,7 +195,10 @@ struct pkvm_mapping {
struct rb_node node;
u64 gfn;
u64 pfn;
- u64 nr_pages;
+ struct {
+ unsigned long nr_pages:48;
+ unsigned int nc:1;
+ };
u64 __subtree_last; /* Internal member for interval tree */
};
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 428723b1b0f5c..5932b93bded58 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -369,7 +369,7 @@ static int __pkvm_pgtable_stage2_unshare(struct kvm_pgtable *pgt, u64 start, u64
for_each_mapping_in_range_safe(pgt, start, end, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ (u64)mapping->nr_pages);
if (WARN_ON(ret))
return ret;
pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
@@ -473,6 +473,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
mapping->gfn = gfn;
mapping->pfn = pfn;
mapping->nr_pages = size / PAGE_SIZE;
+ mapping->nc = !!(prot & (KVM_PGTABLE_PROT_DEVICE | KVM_PGTABLE_PROT_NORMAL_NC));
pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
return ret;
@@ -503,7 +504,7 @@ int pkvm_pgtable_stage2_wrprotect(struct kvm_pgtable *pgt, u64 addr, u64 size)
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
- mapping->nr_pages);
+ (u64)mapping->nr_pages);
if (WARN_ON(ret))
break;
}
@@ -517,10 +518,11 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable *pgt, u64 addr, u64 size)
struct pkvm_mapping *mapping;
lockdep_assert_held(&kvm->mmu_lock);
- for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
- __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
- PAGE_SIZE * mapping->nr_pages);
-
+ for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
+ if (!mapping->nc)
+ __clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
+ PAGE_SIZE * mapping->nr_pages);
+ }
return 0;
}
@@ -537,7 +539,7 @@ bool pkvm_pgtable_stage2_test_clear_young(struct kvm_pgtable *pgt, u64 addr, u64
lockdep_assert_held(&kvm->mmu_lock);
for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
- mapping->nr_pages, mkold);
+ (u64)mapping->nr_pages, mkold);
return young;
}
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH RFC 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM
From: Andre Przywara @ 2026-07-02 8:57 UTC (permalink / raw)
To: Enzo Adriano, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jerome Brunet, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev
In-Reply-To: <20260701160055.320000-a733-ccu-status-enzo.adriano.code@gmail.com>
Hi Enzo,
On 7/1/26 18:07, Enzo Adriano wrote:
> Hi Junhui,
>
> Thanks for the A733 CCU/PRCM RFC v1. I've been reading through the
> series and the review feedback, including the NSI clock/reset handling,
> the binding naming and ordering comments, the SDM macro cleanup, and the
> question around modeled but otherwise-unused clocks such as the GIC clock.
that's great, but please tell the list, by replying to the respective
patches. There are still a few patches left that haven't been checked
against the manual or otherwise reviewed. I will probably do this at
some point in time, but we could use any help here.
You don't need to be an expert for this: just comparing the numbers in
the struct (register offsets and bit positions) against the manual is
already very helpful, and can be done by most people, just with some
endurance ;-)
Thanks,
Andre
> I do not see a v2 on the list yet, so I wanted to check in: are you still
> planning to take this series forward? No rush at all, and I am happy to
> leave it entirely with you if so.
>
> If you have moved on to other things, I would be glad to help carry the
> series forward and address the review comments, keeping your authorship
> and prior work intact. I have A733 hardware here and can help test the
> changes.
>
> Either way, please let me know what works best for you.
>
> Thanks,
> Enzo
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v3 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Wu. JackBB (GSM) @ 2026-07-02 8:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <92b1e341-31a1-4f60-80d5-ccf8f742a38a@lunn.ch>
Hi Andrew,
> > mtk_dev_alloc/mtk_dev_free are paired wrappers so the caller
> > doesn't need to know the underlying allocation mechanism.
> > The devm_kfree is still called inside mtk_dev_free.
>
> Two different issues here:
>
> 1) If you don't want to use devm_, don't use devm_ from the
> beginning. A patch should not change how a previous patch works, since
> you are wasting reviewer time reviewing code which you later change.
>
> 2) Do you understand what devm_ actually does? Since you use
> devm_free() i don't think you actually understand what devm_ is all
> about.
Thank you for the explanation. You are right.
we will remove the mtk_dev_alloc/mtk_dev_free wrappers and use
devm_kzalloc directly from the beginning.
We will also remove all unnecessary devm_kfree() calls from probe
error paths and remove paths, keeping them only where resources
are freed and re-allocated at runtime (e.g., CLDMA queue lifecycle
during modem reset cycles).
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Gokul Praveen @ 2026-07-02 8:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, Gokul Praveen
In-Reply-To: <20260702-vigilant-tody-of-inquire-ffbede@quoll>
Hi Krzysztof,
On 02/07/26 11:53, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
>> Update maxItems value of "clocks" property to 3 as description of
>> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
>> and phy_en_refclk(optional)).
> But what if description is wrong? You need to provide rationale why you
> are doing it and you cannot use existing code alone as that rationale,
> because as you pointed out - existing code is not fully correct.
>
>> Update the maxItems and items value of "clock-names" property with multiple
>> combination of clock-names possible since pll1_refclk and phy_en_refclk are
>> optional clocks.
> Why? You need to describe why you are doing this, not what you are
> doing.
>
Would the below commit description be good enough ? Please feel free to
give any suggestions on this:
''
dt-bindings: phy: cadence-torrent: Update property values to support 3
clocks
Increase the maxItems value of "clocks" property to 3 to support
2 input clocks(refclk,pll1_refclk) and 1 output clock(phy_en_refclk).
For multilink SERDES configurations where the links require 2
different input clock speeds,
2 different input reference clocks and 1 output clock is needed so
as to cater to this requirement.
For eg: Considering the USXGMII+SGMII multilink SERDES
configuration usecase ,
having only 1 input reference clock fails because USXGMII requires
an input clock speed of 156.25 Mhz and
SGMII protocol requires an input clock speed of 100 Mhz.
Since one input reference clock(refclk) alone cannot cater to the 2
different clock speed requirements
of these protocols, the second input reference clock(pll1_refclk)
has to be added.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
''
>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>> ---
>> .../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> index 9af39b33646a..96c664d50629 100644
>> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> @@ -34,7 +34,7 @@ properties:
>>
>> clocks:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>> description:
>> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
>> pll1_refclk is optional and used for multi-protocol configurations requiring
>> @@ -45,9 +45,17 @@ properties:
>>
>> clock-names:
>> minItems: 1
>> - items:
>> - - const: refclk
>> - - enum: [ pll1_refclk, phy_en_refclk ]
>> + maxItems: 3
> Drop
sure krzysztof.
>> + oneOf:
>> + - items:
>> + - const: refclk
>> + - items:
>> + - const: refclk
>> + - enum: [ pll1_refclk, phy_en_refclk ]
> Drop these, pointless. You were supposed to grow existing syntax.
>
Sure Krzysztof
>> + - items:
>> + - const: refclk
>> + - const: pll1_refclk
> So here is the enum.
>
>> + - const: phy_en_refclk
>>
>> And this stays.
SUre Krzysztof
>>
>> You make changes which do not make the binding better and are not
>> explained in commit msg. Focus on WHY you are doing things and also
>> explain WHY you did such complicated syntax (if you insist on rewriting
>> correct code into something odd we do not expect).
>>
>> Best regards,
>> Krzysztof
Best Regards
Gokul Praveen
>
^ permalink raw reply
* [PATCH v2 2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
In-Reply-To: <20260702-fix-clock-refcount-unbalance-v2-0-2383fbb9952e@oss.qualcomm.com>
coresight_get_enable_clocks() enables the programming clock through
devm_clk_get_optional_enabled(), which also registers a devm action to
call clk_disable_unprepare() when the driver detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the clock. During remove the device is
left runtime suspended, so pm_runtime_disable() freezes it with the
clock already disabled. The devm cleanup that runs afterwards calls
clk_disable_unprepare() a second time, underflowing the clock enable
refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clock is enabled again and balances the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clock.
Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tnoc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 9e8de4323d28..eddfdcbaa3ec 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -282,42 +282,50 @@ static int itnoc_probe(struct platform_device *pdev)
{
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int ret;
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = _tnoc_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void itnoc_remove(struct platform_device *pdev)
{
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
coresight_unregister(drvdata->csdev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int itnoc_runtime_suspend(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int itnoc_runtime_resume(struct device *dev)
{
struct trace_noc_drvdata *drvdata = dev_get_drvdata(dev);
return clk_prepare_enable(drvdata->pclk);
}
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] coresight: Fix clock refcount imbalance on platform remove
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
In-Reply-To: <20260702-fix-clock-refcount-unbalance-v2-0-2383fbb9952e@oss.qualcomm.com>
coresight_get_enable_clocks() enables the programming clock and the
optional AT clock through devm_clk_get_optional_enabled(), which also
registers a devm action to call clk_disable_unprepare() when the driver
detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the same clocks. During remove the
device is left runtime suspended, so pm_runtime_disable() freezes it
with the clocks already disabled. The devm cleanup that runs afterwards
calls clk_disable_unprepare() a second time, underflowing the clock
enable refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clocks are enabled again and balance the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clocks.
This affects all CoreSight platform drivers that obtain their clocks
through coresight_get_enable_clocks(): catu, cpu-debug, ctcu, etm4x,
funnel, replicator, stm, tmc and tpiu.
Fixes: 1abc1b212eff ("coresight: Appropriately disable programming clocks")
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-catu.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-cpu-debug.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-funnel.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-replicator.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-stm.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tmc-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tpiu.c | 8 ++++++++
9 files changed, 72 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c b/drivers/hwtracing/coresight/coresight-catu.c
index ad8dafea7d2f..b72fa7f4bdeb 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -629,42 +629,50 @@ static int catu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __catu_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void catu_platform_remove(struct platform_device *pdev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__catu_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int catu_runtime_suspend(struct device *dev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int catu_runtime_resume(struct device *dev)
{
struct catu_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
index 3a806c1d50ea..87b39874461e 100644
--- a/drivers/hwtracing/coresight/coresight-cpu-debug.c
+++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
@@ -693,42 +693,50 @@ static int debug_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __debug_probe(&pdev->dev, res);
if (ret) {
pm_runtime_put_noidle(&pdev->dev);
pm_runtime_disable(&pdev->dev);
}
return ret;
}
static void debug_platform_remove(struct platform_device *pdev)
{
struct debug_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__debug_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id debug_platform_ids[] = {
{"ARMHC503", 0, 0, 0}, /* ARM CoreSight Debug */
{},
};
MODULE_DEVICE_TABLE(acpi, debug_platform_ids);
#endif
#ifdef CONFIG_PM
static int debug_runtime_suspend(struct device *dev)
{
struct debug_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
diff --git a/drivers/hwtracing/coresight/coresight-ctcu-core.c b/drivers/hwtracing/coresight/coresight-ctcu-core.c
index 9043cad42f01..e0e33e3ca5bf 100644
--- a/drivers/hwtracing/coresight/coresight-ctcu-core.c
+++ b/drivers/hwtracing/coresight/coresight-ctcu-core.c
@@ -248,42 +248,50 @@ static int ctcu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = ctcu_probe(pdev);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void ctcu_platform_remove(struct platform_device *pdev)
{
struct ctcu_drvdata *drvdata = platform_get_drvdata(pdev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
ctcu_remove(pdev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int ctcu_runtime_suspend(struct device *dev)
{
struct ctcu_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->apb_clk);
return 0;
}
static int ctcu_runtime_resume(struct device *dev)
{
struct ctcu_drvdata *drvdata = dev_get_drvdata(dev);
return clk_prepare_enable(drvdata->apb_clk);
}
#endif
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 14bb31bd6a0b..a3ae8e1e3a1b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -2399,41 +2399,49 @@ static void etm4_remove_dev(struct etmv4_drvdata *drvdata)
etm_perf_symlink(drvdata->csdev, false);
cscfg_unregister_csdev(drvdata->csdev);
coresight_unregister(drvdata->csdev);
}
}
static void etm4_remove_amba(struct amba_device *adev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(&adev->dev);
if (drvdata)
etm4_remove_dev(drvdata);
}
static void etm4_remove_platform_dev(struct platform_device *pdev)
{
struct etmv4_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (drvdata)
etm4_remove_dev(drvdata);
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static const struct amba_id etm4_ids[] = {
CS_AMBA_ID(0x000bb95d), /* Cortex-A53 */
CS_AMBA_ID(0x000bb95e), /* Cortex-A57 */
CS_AMBA_ID(0x000bb95a), /* Cortex-A72 */
CS_AMBA_ID(0x000bb959), /* Cortex-A73 */
CS_AMBA_UCI_ID(0x000bb9da, uci_id_etm4),/* Cortex-A35 */
CS_AMBA_UCI_ID(0x000bbd05, uci_id_etm4),/* Cortex-A55 */
CS_AMBA_UCI_ID(0x000bbd0a, uci_id_etm4),/* Cortex-A75 */
CS_AMBA_UCI_ID(0x000bbd0c, uci_id_etm4),/* Neoverse N1 */
CS_AMBA_UCI_ID(0x000bbd41, uci_id_etm4),/* Cortex-A78 */
CS_AMBA_UCI_ID(0x000f0205, uci_id_etm4),/* Qualcomm Kryo */
CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
CS_AMBA_UCI_ID(0x000bb802, uci_id_etm4),/* Qualcomm Kryo 385 Cortex-A55 */
CS_AMBA_UCI_ID(0x000bb803, uci_id_etm4),/* Qualcomm Kryo 385 Cortex-A75 */
CS_AMBA_UCI_ID(0x000bb805, uci_id_etm4),/* Qualcomm Kryo 4XX Cortex-A55 */
CS_AMBA_UCI_ID(0x000bb804, uci_id_etm4),/* Qualcomm Kryo 4XX Cortex-A76 */
CS_AMBA_UCI_ID(0x000bbd0d, uci_id_etm4),/* Qualcomm Kryo 5XX Cortex-A77 */
CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 0abc11f0690c..d69cd66e8394 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -316,42 +316,50 @@ static int funnel_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = funnel_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void funnel_platform_remove(struct platform_device *pdev)
{
struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
funnel_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
static const struct of_device_id funnel_match[] = {
{.compatible = "arm,coresight-static-funnel"},
{}
};
MODULE_DEVICE_TABLE(of, funnel_match);
#ifdef CONFIG_ACPI
static const struct acpi_device_id funnel_acpi_ids[] = {
{"ARMHC9FE", 0, 0, 0}, /* ARM Coresight Static Funnel */
{"ARMHC9FF", 0, 0, 0}, /* ARM CoreSight Dynamic Funnel */
{},
};
MODULE_DEVICE_TABLE(acpi, funnel_acpi_ids);
#endif
static struct platform_driver funnel_driver = {
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 2f382de357ee..1df01deb2f69 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -295,42 +295,50 @@ static int replicator_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = replicator_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void replicator_platform_remove(struct platform_device *pdev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
replicator_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int replicator_runtime_suspend(struct device *dev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int replicator_runtime_resume(struct device *dev)
{
struct replicator_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 4e860519a73f..a75b1c56a867 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -1008,42 +1008,50 @@ static int stm_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __stm_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void stm_platform_remove(struct platform_device *pdev)
{
struct stm_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__stm_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id stm_acpi_ids[] = {
{"ARMHC502", 0, 0, 0}, /* ARM CoreSight STM */
{},
};
MODULE_DEVICE_TABLE(acpi, stm_acpi_ids);
#endif
static struct platform_driver stm_platform_driver = {
.probe = stm_platform_probe,
.remove = stm_platform_remove,
.driver = {
.name = "coresight-stm-platform",
.acpi_match_table = ACPI_PTR(stm_acpi_ids),
.suppress_bind_attrs = true,
.pm = &stm_dev_pm_ops,
},
};
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index bc5a133ada3e..ed40bfea32f9 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -971,42 +971,50 @@ static int tmc_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __tmc_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void tmc_platform_remove(struct platform_device *pdev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__tmc_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_PM
static int tmc_runtime_suspend(struct device *dev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
clk_disable_unprepare(drvdata->atclk);
clk_disable_unprepare(drvdata->pclk);
return 0;
}
static int tmc_runtime_resume(struct device *dev)
{
struct tmc_drvdata *drvdata = dev_get_drvdata(dev);
int ret;
ret = clk_prepare_enable(drvdata->pclk);
if (ret)
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 7b029d2eb389..775507d0bb36 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -268,42 +268,50 @@ static int tpiu_platform_probe(struct platform_device *pdev)
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
ret = __tpiu_probe(&pdev->dev, res);
pm_runtime_put(&pdev->dev);
if (ret)
pm_runtime_disable(&pdev->dev);
return ret;
}
static void tpiu_platform_remove(struct platform_device *pdev)
{
struct tpiu_drvdata *drvdata = dev_get_drvdata(&pdev->dev);
if (WARN_ON(!drvdata))
return;
+ /*
+ * Resume the device so its clocks are enabled again, balancing the
+ * clk_disable_unprepare() that devm runs when the driver detaches.
+ * Then mark it suspended and drop the usage count taken here.
+ */
+ pm_runtime_get_sync(&pdev->dev);
__tpiu_remove(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_put_noidle(&pdev->dev);
}
#ifdef CONFIG_ACPI
static const struct acpi_device_id tpiu_acpi_ids[] = {
{"ARMHC979", 0, 0, 0}, /* ARM CoreSight TPIU */
{}
};
MODULE_DEVICE_TABLE(acpi, tpiu_acpi_ids);
#endif
static struct platform_driver tpiu_platform_driver = {
.probe = tpiu_platform_probe,
.remove = tpiu_platform_remove,
.driver = {
.name = "coresight-tpiu-platform",
.acpi_match_table = ACPI_PTR(tpiu_acpi_ids),
.suppress_bind_attrs = true,
.pm = &tpiu_dev_pm_ops,
},
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] fix clock refcount imbalance for all Coresight platform drivers
From: Jie Gan @ 2026-07-02 8:54 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
Found a clock imbalance issue when remove the CTCU module.
coresight_get_enable_clocks() enables the programming clock and the
optional AT clock through devm_clk_get_optional_enabled(), which also
registers a devm action to call clk_disable_unprepare() when the driver
detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the same clocks. During remove the
device is left runtime suspended, so pm_runtime_disable() freezes it
with the clocks already disabled. The devm cleanup that runs afterwards
calls clk_disable_unprepare() a second time, underflowing the clock
enable refcount.
Resume the device with pm_runtime_get_sync() before tearing it down so
the clocks are enabled again and balance the devm-managed disable. Then
pm_runtime_set_suspended() and pm_runtime_put_noidle() leave the device
in a coherent runtime PM state (suspended, usage count balanced) once
the devm action has disabled the clocks.
Calltrace:
[ 194.074015] ------------[ cut here ]------------
[ 194.078779] qdss already disabled
[ 194.082210] WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x238/0x240, CPU#4: rmmod/508
[ 194.090976] Modules linked in: coresight_ctcu(-) snd_soc_hdmi_codec snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore 8021q garp mrp phy_qcom_edp stp af_alg llc anx7625 typec pci_pwrctrl_pwrseq hci_uart qcom_iris v4l2_mem2mem btqca btbcm qcom_pon videobuf2_dma_contig rtc_pm8xxx nvmem_qcom_spmi_sdam qcom_spmi_temp_alarm videobuf2_memops qrtr videobuf2_v4l2 bluetooth msm qcom_stats pwrseq_qcom_wcn ubwc_config videodev ocmem ecdh_generic drm_gpuvm videobuf2_common drm_exec gpu_sched qcom_q6v5_pas kpp marvell videocc_sa8775p camcc_sa8775p ecc drm_dp_aux_bus dispcc0_sa8775p spi_geni_qcom i2c_qcom_geni llcc_qcom mc qcom_refgen_regulator phy_qcom_snps_femto_v2 phy_qcom_qmp_usb icc_bwmon phy_qcom_sgmii_eth dwmac_qcom_ethqos qcom_pil_info gpucc_sa8775p qcom_q6v5 stmmac_platform stmmac ufs_qcom qcom_sysmon drm_display_helper qcom_common pcs_xpcs phylink cec qcom_glink_smem qcrypto drm_client_lib mdt_loader dispcc1_sa8775p qmi_helpers phy_qcom_qmp_ufs libdes qcom_ice display_connector phy_qcom_qmp_pcie
[ 194.091130] qcom_wdt qcomtee nvmem_reboot_mode icc_osm_l3 qcom_rng drm_kms_helper cfg80211 rfkill socinfo fuse drm backlight stm_p_basic
[ 194.196124] CPU: 4 UID: 0 PID: 508 Comm: rmmod Not tainted 7.1.0-next-20260623-00008-ga4671328ba36 #831 PREEMPT
[ 194.206566] Hardware name: Qualcomm SA8775P Ride (DT)
[ 194.211771] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 194.218938] pc : clk_core_disable+0x238/0x240
[ 194.223426] lr : clk_core_disable+0x238/0x240
[ 194.227908] sp : ffff8000889fbb40
[ 194.231327] x29: ffff8000889fbb40 x28: ffff0000972eb580 x27: 0000000000000000
[ 194.238662] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 194.245995] x23: ffffd181d3de4620 x22: ffff8000889fbc28 x21: ffff000082382810
[ 194.253322] x20: ffff000082334a00 x19: ffff000082334a00 x18: 0000000000000006
[ 194.260658] x17: ffffd181d293fb18 x16: ffffd181d295c3c8 x15: ffff8000889fb550
[ 194.267991] x14: 0000000000000000 x13: ffffd181d4eea620 x12: 00000000000004cf
[ 194.275346] x11: 0000000000000e6d x10: ffffd181d4f42620 x9 : ffffd181d4eea620
[ 194.282676] x8 : 3fffffffffffefff x7 : ffffd181d4f42620 x6 : bffffffffffff000
[ 194.290007] x5 : ffff000ead974248 x4 : 0000000000000000 x3 : ffff2e8cd9611000
[ 194.297338] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000972eb580
[ 194.304671] Call trace:
[ 194.307199] clk_core_disable+0x238/0x240 (P)
[ 194.311687] clk_disable+0x30/0x4c
[ 194.315192] clk_disable_unprepare+0x18/0x30
[ 194.319596] devm_clk_release+0x24/0x3c
[ 194.323578] dr_node_release+0x1c/0x28
[ 194.327466] release_nodes+0x5c/0x90
[ 194.331147] devres_release_all+0x90/0x104
[ 194.335364] device_unbind_cleanup+0x2c/0x84
[ 194.339762] device_release_driver_internal+0x200/0x23c
[ 194.345153] driver_detach+0x4c/0x94
[ 194.348835] bus_remove_driver+0x6c/0xbc
[ 194.352872] driver_unregister+0x30/0x60
[ 194.356914] platform_driver_unregister+0x14/0x20
[ 194.361753] ctcu_driver_exit+0x18/0xdf8 [coresight_ctcu]
[ 194.367308] __arm64_sys_delete_module+0x1bc/0x298
[ 194.372240] invoke_syscall+0x54/0x10c
[ 194.376114] el0_svc_common.constprop.0+0xc0/0xe0
[ 194.380956] do_el0_svc+0x1c/0x28
[ 194.384374] el0_svc+0x54/0x3a0
[ 194.387626] el0t_64_sync_handler+0xa0/0xe4
[ 194.391951] el0t_64_sync+0x198/0x19c
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v2:
- Balance the runtime PM state in the remove path: after
pm_runtime_get_sync() and pm_runtime_disable(), also call
pm_runtime_set_suspended() and pm_runtime_put_noidle() so the device is
left suspended with a balanced usage count once the devm action has
disabled the clocks.
- Picked up Reviewed-by from Yeoreum Yun on patch 1.
- Link to v1: https://lore.kernel.org/r/20260701-fix-clock-refcount-unbalance-v1-0-321dc63c1f90@oss.qualcomm.com
---
Jie Gan (2):
coresight: Fix clock refcount imbalance on platform remove
coresight: tnoc: Fix clock refcount imbalance on platform remove
drivers/hwtracing/coresight/coresight-catu.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-cpu-debug.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-ctcu-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-funnel.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-replicator.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-stm.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tmc-core.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tnoc.c | 8 ++++++++
drivers/hwtracing/coresight/coresight-tpiu.c | 8 ++++++++
10 files changed, 80 insertions(+)
---
base-commit: be5c93fa674f0fc3c8f359c2143abce6bbb422e6
change-id: 20260701-fix-clock-refcount-unbalance-e7c467136a86
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
From: Marc Kleine-Budde @ 2026-07-02 8:49 UTC (permalink / raw)
To: Cunhao Lu
Cc: krzk, heiko, linux-can, mailhol, kernel, robh, krzk+dt, conor+dt,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
shawn.lin
In-Reply-To: <tencent_97F21396469202221027FD429A6E69DA6409@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On 02.07.2026 16:17:25, Cunhao Lu wrote:
> > And why is this different from rk3588?
>
> The reason I used rk3588v2 is that this is how the controller identifies
> itself at runtime:
There are 2 silicon revision (v2 and v3) of the rk3568 available on the
market. The v2 has several errata in the CAN-FD core, the v3 has some of
them fixed...
> rockchip_canfd fea60000.can can0: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
> rockchip_canfd fea70000.can can1: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
However, the version register _in_ the CAN-FD was not changed. :/
This is why we have a rockchip,rk3568v2-canfd and a
rockchip,rk3568v3-canfd compatible.
> I also checked Rockchip's vendor kernel 6.1 sources. The RK3588 DTS uses
> the binding name "rockchip,can-2.0" for these controllers, while the
> upstream driver has SoC-specific compatibles for the Rockchip CAN-FD IP.
> That is why I chose the SoC/IP variant name rockchip,rk3588v2-canfd.
>
> If the preferred binding name is rockchip,rk3588-canfd instead, I can
> change the compatible in v2.
Yes, please use rockchip,rk3588-canfd, unless we get information from
rockchips about CAN-FD errata and SoC silicon revisions.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Muchun Song @ 2026-07-02 8:47 UTC (permalink / raw)
To: Dev Jain
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, david, liam
In-Reply-To: <20260702051341.126509-3-dev.jain@arm.com>
On 2026/7/2 13:13, Dev Jain wrote:
> try_to_unmap_one() handles hugetlb folios when memory failure needs
> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
> in pvmw.pte, but the code reads it with ptep_get().
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
> etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>
> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Reported-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> include/linux/hugetlb.h | 3 +++
> mm/rmap.c | 16 ++++++++++------
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 2abaf99321e90..fdb7bdf7645c5 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
> {
> }
>
> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep);
> +
Maybe I didn't express my thoughts clearly in the first version, let me
explain in more detail.
We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
in your previous version). Currently, you've added a declaration, but the
function itself doesn't actually exist, which seems quite strange to me.
Muchun,
Thanks.
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1c77d5dc06e9f..aa8a254efaecc 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> /* Unexpected PMD-mapped THP? */
> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>
> - /*
> - * Handle PFN swap PTEs, such as device-exclusive ones, that
> - * actually map pages.
> - */
> - pteval = ptep_get(pvmw.pte);
> + address = pvmw.address;
> + if (folio_test_hugetlb(folio)) {
> + pteval = huge_ptep_get(mm, address, pvmw.pte);
> + } else {
> + /*
> + * Handle PFN swap PTEs, such as device-exclusive ones,
> + * that actually map pages.
> + */
> + pteval = ptep_get(pvmw.pte);
> + }
> if (likely(pte_present(pteval))) {
> pfn = pte_pfn(pteval);
> } else {
> @@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> }
>
> subpage = folio_page(folio, pfn - folio_pfn(folio));
> - address = pvmw.address;
> anon_exclusive = folio_test_anon(folio) &&
> PageAnonExclusive(subpage);
>
^ permalink raw reply
* Re: [PATCH v2 17/19] ARM: mark Cortex-M3/M4/M7 based boards as deprecated
From: Vladimir Murzin @ 2026-07-02 8:43 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Arnd Bergmann, Aaro Koskinen, Alexander Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Ethan Nelson-Moore, Frank Li,
Gregory Clement, Haojian Zhuang, Jeremy J. Peper,
Kristoffer Ericson, Krzysztof Kozlowski, Linus Walleij,
Mark Brown, Marc Zyngier, Mike Rapoport, Nicolas Ferre,
Patrice Chotard, Ralph Siemsen, Robert Jarzmik, Russell King,
Sascha Hauer, Sebastian Hesselbarth, Stefan Agner, Stefan Wiehler,
Tony Lindgren, Vladimir Zapolskiy, Will Deacon
In-Reply-To: <20260701212353.2196041-18-arnd@kernel.org>
On 7/1/26 22:23, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The Cortex-M3/M4/M7 cores were designed as a replacement for the earlier
> ARM7TDMI and ARM9TDMI microarchitectures used in older microcontrollers.
>
> At the moment, Linux can run these cores either when they are integrated
> into a larger SoC, or as standalone microcontrollers. While there was
> a lot of development work going into Cortex-M support from 2011 to 2016,
> this largely stopped when it became clear that Zephyr and other RTOS
> had taken over that market. To date, the only Cortex-M based based
> microcontroller boards supported upstream are reference implementations.
>
> Schedule these for removal after the next LTS kernel, so if any users
> remain that want to update their kernels, they can stay on that
> version for a few years before having to maintain the platform support
> out of tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 8 ++++++--
> arch/arm/mach-at91/Kconfig | 4 +++-
> arch/arm/mach-imx/Kconfig | 4 +++-
> arch/arm/mach-stm32/Kconfig | 14 ++++++++------
> 4 files changed, 20 insertions(+), 10 deletions(-)
>
[snip]
> config ARCH_MPS2
> - bool "ARM MPS2 platform"
> + bool "ARM MPS2 platform (DEPRECATED)"
> depends on ARM_SINGLE_ARMV7M
> select ARM_AMBA
> select CLKSRC_MPS2
> @@ -493,6 +495,8 @@ config ARCH_MPS2
> Please, note that depends which Application Note is used memory map
> for the platform may vary, so adjustment of RAM base might be needed.
>
> + This platform is scheduled for removal in early 2027
> +
> # Definitions to make life easier
> config ARCH_ACORN
> bool
Acked-by: Vladimir Murzin <vladimir.murzin@arm.com> # MPS2
Thanks
Vladimir
^ permalink raw reply
* [soc:rfc-arm-deprecation-7.2] BUILD SUCCESS 3be9b90e0ec1b72b270cb6f77e136afed2238891
From: kernel test robot @ 2026-07-02 8:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rfc-arm-deprecation-7.2
branch HEAD: 3be9b90e0ec1b72b270cb6f77e136afed2238891 ARM: mark mv78xx0 support as deprecated
elapsed time: 728m
configs tested: 196
configs skipped: 158
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260702 gcc-8.5.0
arc randconfig-002-20260702 gcc-8.5.0
arm allnoconfig clang-17
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260702 gcc-8.5.0
arm randconfig-002-20260702 gcc-8.5.0
arm randconfig-003-20260702 gcc-8.5.0
arm randconfig-004-20260702 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260702 gcc-15.2.0
arm64 randconfig-002-20260702 gcc-15.2.0
arm64 randconfig-003-20260702 gcc-15.2.0
arm64 randconfig-004-20260702 gcc-15.2.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260702 gcc-15.2.0
csky randconfig-002-20260702 gcc-15.2.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260702 clang-23
hexagon randconfig-002-20260702 clang-23
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260702 clang-22
i386 buildonly-randconfig-002-20260702 clang-22
i386 buildonly-randconfig-003-20260702 clang-22
i386 buildonly-randconfig-004-20260702 clang-22
i386 buildonly-randconfig-005-20260702 clang-22
i386 buildonly-randconfig-006-20260702 clang-22
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260702 gcc-14
i386 randconfig-002-20260702 gcc-14
i386 randconfig-003-20260702 gcc-14
i386 randconfig-004-20260702 gcc-14
i386 randconfig-005-20260702 gcc-14
i386 randconfig-006-20260702 gcc-14
i386 randconfig-007-20260702 gcc-14
i386 randconfig-011-20260702 clang-22
i386 randconfig-012-20260702 clang-22
i386 randconfig-013-20260702 clang-22
i386 randconfig-014-20260702 clang-22
i386 randconfig-015-20260702 clang-22
i386 randconfig-016-20260702 clang-22
i386 randconfig-017-20260702 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch loongson32_defconfig clang-18
loongarch randconfig-001-20260702 clang-23
loongarch randconfig-002-20260702 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips ci20_defconfig clang-23
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260702 clang-23
nios2 randconfig-002-20260702 clang-23
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001 clang-17
parisc randconfig-001-20260702 clang-17
parisc randconfig-002 clang-17
parisc randconfig-002-20260702 clang-17
parisc64 defconfig clang-23
powerpc adder875_defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc randconfig-001 clang-17
powerpc randconfig-001-20260702 clang-17
powerpc randconfig-002 clang-17
powerpc randconfig-002-20260702 clang-17
powerpc64 randconfig-001 clang-17
powerpc64 randconfig-001-20260702 clang-17
powerpc64 randconfig-002 clang-17
powerpc64 randconfig-002-20260702 clang-17
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-12.5.0
riscv randconfig-001-20260702 gcc-12.5.0
riscv randconfig-002 gcc-12.5.0
riscv randconfig-002-20260702 gcc-12.5.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-12.5.0
s390 randconfig-001-20260702 gcc-12.5.0
s390 randconfig-002 gcc-12.5.0
s390 randconfig-002-20260702 gcc-12.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 gcc-12.5.0
sh randconfig-001-20260702 gcc-12.5.0
sh randconfig-002 gcc-12.5.0
sh randconfig-002-20260702 gcc-12.5.0
sh se7619_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260702 gcc-16.1.0
sparc randconfig-002-20260702 gcc-16.1.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260702 gcc-16.1.0
sparc64 randconfig-002-20260702 gcc-16.1.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260702 gcc-16.1.0
um randconfig-002-20260702 gcc-16.1.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 clang-22
x86_64 buildonly-randconfig-001-20260702 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260702 clang-22
x86_64 buildonly-randconfig-003 clang-22
x86_64 buildonly-randconfig-003-20260702 clang-22
x86_64 buildonly-randconfig-004 clang-22
x86_64 buildonly-randconfig-004-20260702 clang-22
x86_64 buildonly-randconfig-005 clang-22
x86_64 buildonly-randconfig-005-20260702 clang-22
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260702 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 clang-22
x86_64 randconfig-001-20260702 clang-22
x86_64 randconfig-002 clang-22
x86_64 randconfig-002-20260702 clang-22
x86_64 randconfig-003 clang-22
x86_64 randconfig-003-20260702 clang-22
x86_64 randconfig-004 clang-22
x86_64 randconfig-004-20260702 clang-22
x86_64 randconfig-005 clang-22
x86_64 randconfig-005-20260702 clang-22
x86_64 randconfig-006 clang-22
x86_64 randconfig-006-20260702 clang-22
x86_64 randconfig-011-20260702 clang-22
x86_64 randconfig-012-20260702 clang-22
x86_64 randconfig-013-20260702 clang-22
x86_64 randconfig-014-20260702 clang-22
x86_64 randconfig-015-20260702 clang-22
x86_64 randconfig-016-20260702 clang-22
x86_64 randconfig-071-20260702 clang-22
x86_64 randconfig-072-20260702 clang-22
x86_64 randconfig-073-20260702 clang-22
x86_64 randconfig-074-20260702 clang-22
x86_64 randconfig-075-20260702 clang-22
x86_64 randconfig-076-20260702 clang-22
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001-20260702 gcc-16.1.0
xtensa randconfig-002-20260702 gcc-16.1.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
From: Chen-Yu Tsai @ 2026-07-02 8:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
The SPI NOR flash is powered the "always on" 1.8V LDO regulated power
rail.
Add the supply for the SPI NOR flash.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
index 4cb23595d17b..f382f90c48f5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
@@ -645,6 +645,7 @@ flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <52000000>;
+ vcc-supply = <&pp1800_ldo_z1>;
};
};
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
From: Chen-Yu Tsai @ 2026-07-02 8:37 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-mediatek, devicetree, linux-arm-kernel,
linux-kernel
The SPI NOR flash is powered from the always on 1.8V power rail through
a load switch that is controlled by the security chip.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index b8d261b375d4..ed552f023cb4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -980,6 +980,8 @@ w25q64dw: flash@0 {
compatible = "winbond,w25q64dw", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
+ /* Power actually controlled by security chip */
+ vcc-supply = <&pp1800_alw>;
};
};
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH v2 01/19] ARM: use CONFIG_AEABI by default everywhere
From: Arnd Bergmann @ 2026-07-02 8:34 UTC (permalink / raw)
To: Nicolas Ferre, Arnd Bergmann, linux-arm-kernel, soc
Cc: linux-kernel, Aaro Koskinen, A. Sverdlin, Alexandre Belloni,
Alexandre Torgue, Andrew Lunn, Ard Biesheuvel, Claudiu Beznea,
Daniel Mack, Ethan Nelson-Moore, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Patrice Chotard, Ralph Siemsen, Robert Jarzmik,
Russell King, Sascha Hauer, Sebastian Hesselbarth, Stefan Agner,
Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy, Will Deacon,
Linus Walleij
In-Reply-To: <d48d79ad-6a30-4a86-8895-17d4e4fa2940@microchip.com>
On Thu, Jul 2, 2026, at 09:42, Nicolas Ferre wrote:
> On 01/07/2026 at 23:23, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> - All machines that used to explicitly enable EABI can drop that line now
>> - Machines that are likely to actually use old distros and had NWFPE
>> enabled in combination with OABI (rpc, footrbridge, netwinder,
>> assabet, neponset) explicitly turn it on now.
>> - Machines that already had both EABI and NWFPE disabled in defconfig
>> (at91_dt, collie, ep93xx, gemini, h3600, imx_v4_v5, integrator, jornada,
>
> For at91_dt, EABI was explicitly enabled (see below)...
Right. I don't know how I got to that list originally, but looking again
now, the only configs that I see using OABI but not NWFPE here are
spear3xx and spear6xx. I've updated the text now, thanks!
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-02 8:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <887cb4e9-d60d-47b5-9110-e00d18e9e46c@kernel.org>
On 02/07/2026 10:20:20+0200, Krzysztof Kozlowski wrote:
> On 02/07/2026 10:17, Alexandre Belloni wrote:
> > On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
> >>>> Then you need proper wakeup-source support
> >>> Wouldn't that break existing devicetrees?
> >>
> >> How?
> >>
> >>>
> >>> The current driver allows to wake up the system, even without
> >>> having wakeup-source set.
> >>
> >> Anyway, wakeup-source is already there in rtc, so this would be done. I
> >> don't get though, why there is no benefit of routing it to interrupt
> >> controller (interrupt controllers do wake up the system). Additionally,
> >> if you do not connect it to any interrupt, then how does it wake up the
> >> system?
> >>
> >
> > Some systems are routing the interrupt output of the RTC directly to the
> > PMIC and the PMIC is the one responsible for waking the rest of the
> > system, including the SoC.
>
> Yeah, then the PMIC has interrupt line to the SoC and the PMIC is the
> wakeup-source, not RTC.
>
This would be case 3 of Documentation/devicetree/bindings/power/wakeup-source.txt
> Best regards,
> Krzysztof
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 5/5] gpio: nomadik: drop "chip registered" log on probe success
From: Théo Lebrun @ 2026-07-02 8:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Philipp Zabel, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <CAD++jLmmHXBC9ni0pcVoB2HNK+osBzgirxH7vLHZaANmoe-tpQ@mail.gmail.com>
Hello Linus,
On Thu Jul 2, 2026 at 10:00 AM CEST, Linus Walleij wrote:
> On Wed, Jul 1, 2026 at 6:57 PM Théo Lebrun <theo.lebrun@bootlin.com> wrote:
>
>> Successful driver probing should be silent. Drop unconditional
>> dev_info() call that is done at nmk_gpio_probe() exit.
>>
>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>
> I actually don't generally agree, but you are using this driver more than
> me now so let's go with your minimalist dmesg style for this driver.
I get from where you stand, but the info level is somewhat strong.
Documentation/process/coding-style.rst agrees ("When drivers are
working properly they are quiet").
If you like this log line we can turn it into a lower debug level?
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Thanks for the reviews Linus!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 5/6] mm/page_vma_mapped: use huge_ptep_get() for hugetlb
From: Muchun Song @ 2026-07-02 8:33 UTC (permalink / raw)
To: Dev Jain
Cc: osalvador, akpm, ljs, david, liam, riel, vbabka, harry, jannh,
lance.yang, kas, linux-mm, linux-kernel, rcampbell, apopple, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, j-nomura, nao.horiguchi, ak, mel, pfalcato, jpoimboe,
dave.hansen, tglx, catalin.marinas, will, linux-arm-kernel,
ryan.roberts, anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-6-dev.jain@arm.com>
> On Jul 2, 2026, at 13:13, Dev Jain <dev.jain@arm.com> wrote:
>
> check_pte() is the final validation step in page_vma_mapped_walk().
> It reads pvmw->pte with ptep_get() to decide whether the entry maps
> the PFN range being walked. For hugetlb VMAs, that pointer refers
> to a hugetlb entry.
>
> On arches which provide their own huge_ptep_get() to dereference a huge
> pte pointer, accessing via ptep_get() would cause pte_pfn(),
> pte_present() etc to misbehave.
>
> It is not clear whether this has a trivially visible effect to userspace.
>
> Use huge_ptep_get() to dereference a huge pte pointer.
>
> Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dev Jain <dev.jain@arm.com>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-02 8:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <187099d0-5e09-49c2-b67d-8bd4366ff1a0@kernel.org>
On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
> >> Then you need proper wakeup-source support
> > Wouldn't that break existing devicetrees?
>
> How?
>
> >
> > The current driver allows to wake up the system, even without
> > having wakeup-source set.
>
> Anyway, wakeup-source is already there in rtc, so this would be done. I
> don't get though, why there is no benefit of routing it to interrupt
> controller (interrupt controllers do wake up the system). Additionally,
> if you do not connect it to any interrupt, then how does it wake up the
> system?
>
Some systems are routing the interrupt output of the RTC directly to the
PMIC and the PMIC is the one responsible for waking the rest of the
system, including the SoC.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Muchun Song @ 2026-07-02 8:30 UTC (permalink / raw)
To: Dev Jain
Cc: osalvador, akpm, ljs, david, liam, riel, vbabka, harry, jannh,
lance.yang, kas, linux-mm, linux-kernel, rcampbell, apopple, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, j-nomura, nao.horiguchi, ak, mel, pfalcato, jpoimboe,
dave.hansen, tglx, catalin.marinas, will, linux-arm-kernel,
ryan.roberts, anshuman.khandual
In-Reply-To: <20260702051341.126509-7-dev.jain@arm.com>
> On Jul 2, 2026, at 13:13, Dev Jain <dev.jain@arm.com> wrote:
>
> prot_none_hugetlb_entry() is the hugetlb callback for the early
> mprotect(PROT_NONE) PFN permission walk on x86.
>
> The callback passes the decoded PFN to pfn_modify_allowed(). For a
> hugetlb callback, the pte pointer refers to a hugetlb entry. On
> architectures where hugetlb entries need huge_ptep_get(), reading that
> entry with ptep_get() can make the permission check use the wrong PFN.
>
> Use huge_ptep_get() before decoding the hugetlb PFN.
>
> Currently there is no path which can trigger a bug: huge_ptep_get() is a
> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
>
> So no need to backport - use the correct helper anyways.
>
> Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
> Signed-off-by: Dev Jain <dev.jain@arm.com>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Thanks.
^ permalink raw reply
* Re: [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Muchun Song @ 2026-07-02 8:29 UTC (permalink / raw)
To: Dev Jain
Cc: osalvador, akpm, ljs, david, liam, riel, vbabka, harry, jannh,
lance.yang, kas, linux-mm, linux-kernel, rcampbell, apopple, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, j-nomura, nao.horiguchi, ak, mel, pfalcato, jpoimboe,
dave.hansen, tglx, catalin.marinas, will, linux-arm-kernel,
ryan.roberts, anshuman.khandual
In-Reply-To: <555ccf16-3abf-4f82-9ebd-5df970e9de53@arm.com>
> On Jul 2, 2026, at 13:18, Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 02/07/26 10:43 am, Dev Jain wrote:
>> prot_none_hugetlb_entry() is the hugetlb callback for the early
>> mprotect(PROT_NONE) PFN permission walk on x86.
>>
>> The callback passes the decoded PFN to pfn_modify_allowed(). For a
>> hugetlb callback, the pte pointer refers to a hugetlb entry. On
>> architectures where hugetlb entries need huge_ptep_get(), reading that
>> entry with ptep_get() can make the permission check use the wrong PFN.
>>
>> Use huge_ptep_get() before decoding the hugetlb PFN.
>>
>> Currently there is no path which can trigger a bug: huge_ptep_get() is a
>> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
>>
>> So no need to backport - use the correct helper anyways.
>>
>> Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
>> Signed-off-by: Dev Jain <dev.jain@arm.com>
>> ---
>
> @Muchun, I did not do the change you suggested: if we do #ifdef around
> the hugetlb callback, then for CONFIG_HUGETLB_PAGE=n, prot_none_hugetlb_entry()
> is defined but not used, giving compile error.
>
Got it. Thanks for your explanation.
^ permalink raw reply
* [PATCH v15 08/12] media: mediatek: jpeg: fix remove buffer removal timing for multi-core
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Move calls to v4l2_m2m_src/dst_buf_remove() inside of the spinlock
protected scope to ensure all necessary operations are performed
before buffers are removed from their queues and ensure proper
synchronization of buffer handling to avoid buffer lost.
Fixes: 86379bd9d399 ("media: mtk-jpeg: Fixes jpeg enc&dec worker sw flow")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 02efaed198b8..0b9a3b66895a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1653,9 +1653,6 @@ static void mtk_jpegenc_worker(struct work_struct *work)
goto enc_end;
}
- v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
-
schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
@@ -1673,6 +1670,8 @@ static void mtk_jpegenc_worker(struct work_struct *work)
&src_buf->vb2_buf);
mtk_jpeg_set_enc_params(ctx, comp_jpeg[hw_id]->reg_base);
mtk_jpeg_enc_start(comp_jpeg[hw_id]->reg_base);
+ v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
spin_unlock_irqrestore(&comp_jpeg[hw_id]->hw_lock, flags);
@@ -1754,9 +1753,6 @@ static void mtk_jpegdec_worker(struct work_struct *work)
goto dec_end;
}
- v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
-
mtk_jpeg_set_dec_src(ctx, &src_buf->vb2_buf, &bs);
if (mtk_jpeg_set_dec_dst(ctx,
&jpeg_src_buf->dec_param,
@@ -1781,6 +1777,8 @@ static void mtk_jpegdec_worker(struct work_struct *work)
jpeg_src_buf->bs_size,
&bs,
&fb);
+ v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
mtk_jpeg_dec_start(comp_jpeg[hw_id]->reg_base);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
spin_unlock_irqrestore(&comp_jpeg[hw_id]->hw_lock, flags);
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v10 0/9] perf cs-etm: Support thread stack and callchain
From: Leo Yan @ 2026-07-02 8:30 UTC (permalink / raw)
To: Namhyung Kim
Cc: Arnaldo Carvalho de Melo, John Garry, Will Deacon, James Clark,
Mike Leach, Suzuki K Poulose, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov, linux-arm-kernel, coresight, linux-perf-users,
Leo Yan
In-Reply-To: <akRX7gwfDh01AD4-@google.com>
On Tue, Jun 30, 2026 at 04:57:34PM -0700, Namhyung Kim wrote:
[...]
> Hmm.. it's not applying anymore.. Please rebase.
Thanks for reminding. I'll rebase it and resend today.
^ permalink raw reply
* [PATCH v15 09/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgdec compatible
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Krzysztof Kozlowski
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Compared to the previous generation IC, the MT8196 uses SMMU
instead of IOMMU and supports features such as dynamic voltage
and frequency scaling. Therefore, add "mediatek,mt8196-jpgdec"
compatible to the binding document.
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../bindings/media/mediatek,mt8195-jpegdec.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
index e5448c60e3eb..28a9a9bfdbf8 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml
@@ -14,7 +14,9 @@ description:
properties:
compatible:
- const: mediatek,mt8195-jpgdec
+ enum:
+ - mediatek,mt8195-jpgdec
+ - mediatek,mt8196-jpgdec
power-domains:
maxItems: 1
@@ -44,7 +46,9 @@ patternProperties:
properties:
compatible:
- const: mediatek,mt8195-jpgdec-hw
+ enum:
+ - mediatek,mt8195-jpgdec-hw
+ - mediatek,mt8196-jpgdec-hw
reg:
maxItems: 1
--
2.45.2
^ 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