* Re: [PATCH] soc: dove: pmu: fix device_node refcount leaks in dove_init_pmu()
From: Markus Elfring @ 2026-06-21 19:20 UTC (permalink / raw)
To: Weigang He, linux-arm-kernel, Andrew Lunn
Cc: LKML, kernel-janitors, Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20260610041536.2164285-1-geoffreyhe2@gmail.com>
…
> Release np_pmu on the two early error returns and via pmu->of_node on the
> iomap-failure return, and release domains_node on every path once it is
> no longer needed.
…
* Would you like to complete the exception handling by using another goto chain?
* How do you think about to increase the application of scope-based resource management?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-21 17:00 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-4-marek.vasut+renesas@mailbox.org>
On Thu, 18 Jun 2026 23:02:01 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
With the SoB chain issue addressed:
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marc Zyngier @ 2026-06-21 16:59 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
On Thu, 18 Jun 2026 23:02:00 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v1] irqchip/gic-v3-its: Fix OF node reference leak
From: Zenghui Yu @ 2026-06-21 15:17 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Yuho Choi, Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <877bnt8u5k.wl-maz@kernel.org>
On 6/20/26 4:59 PM, Marc Zyngier wrote:
> On Fri, 19 Jun 2026 19:58:08 +0100,
> Yuho Choi <dbgh9129@gmail.com> wrote:
> >
> > of_get_cpu_node() returns a referenced device node. In
> > its_cpu_init_collection(), the node is only used to get the CPU NUMA
> > node for the Cavium 23144 workaround, but the reference is never
> > dropped.
> >
> > Store the NUMA node locally and call of_node_put() before either
> > continuing with collection setup or returning early for a NUMA mismatch.
> >
> > Fixes: 920181ce8469 ("irqchip/gic-v3-its: Add ability to resend MAPC on resume")
It looks to me that this issue was introduced in fbf8f40e1658
("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum
23144"). What am I missing?
> > Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> > ---
> > drivers/irqchip/irq-gic-v3-its.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index b57d81ad33a0..f82035eb77e5 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -3291,10 +3291,14 @@ static void its_cpu_init_collection(struct its_node *its)
> > /* avoid cross node collections and its mapping */
> > if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> > struct device_node *cpu_node;
> > + int cpu_nid;
> >
> > cpu_node = of_get_cpu_node(cpu, NULL);
> > + cpu_nid = of_node_to_nid(cpu_node);
> > + of_node_put(cpu_node);
> > +
> > if (its->numa_node != NUMA_NO_NODE &&
> > - its->numa_node != of_node_to_nid(cpu_node))
> > + its->numa_node != cpu_nid)
> > return;
> > }
> >
>
> Please consider using the cleanup infrastructure instead, something
> like the untested hack below.
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..947a15bb42012 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3290,11 +3290,10 @@ static void its_cpu_init_collection(struct its_node *its)
>
> /* avoid cross node collections and its mapping */
> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> - struct device_node *cpu_node;
> + struct device_node *cpu_node __free(device_node) = of_get_cpu_node(cpu, NULL);
>
> - cpu_node = of_get_cpu_node(cpu, NULL);
> if (its->numa_node != NUMA_NO_NODE &&
> - its->numa_node != of_node_to_nid(cpu_node))
> + its->numa_node != of_node_to_nid(cpu_node))
> return;
> }
>
Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Ben Hutchings @ 2026-06-21 15:02 UTC (permalink / raw)
To: Anshuman Khandual, Catalin Marinas, David Hildenbrand (Arm),
Ryan Roberts
Cc: patches, Will Deacon, linux-arm-kernel, linux-kernel, Sasha Levin,
Greg Kroah-Hartman, stable
In-Reply-To: <20260616145141.584613180@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]
On Tue, 2026-06-16 at 20:28 +0530, Greg Kroah-Hartman wrote:
> 6.1-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Anshuman Khandual <anshuman.khandual@arm.com>
>
> [ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
[...]
> @@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_
> WARN_ON(!pmd_present(pmd));
> if (pmd_sect(pmd)) {
> pmd_clear(pmdp);
> -
> - /*
> - * One TLBI should be sufficient here as the PMD_SIZE
> - * range is mapped with a single block entry.
> - */
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> - if (free_mapped)
> + if (free_mapped) {
> + /* CONT blocks are not supported in the vmemmap */
> + WARN_ON(pmd_cont(pmd));
> + flush_tlb_kernel_range(addr, addr + PMD_SIZE);
It wasn't clear to me from the commit message why this now adds PMD_SIZE
rather than PAGE_SIZE. It seems like this change is fine for Linux
6.13+ with a CPU that supports TLB range flushing, but otherwise results
in unnecessarily executing multiple TLB invalidations at intervals of
the base page size.
> free_hotplug_page_range(pmd_page(pmd),
> PMD_SIZE, altmap);
> + }
> + /* unmap_hotplug_range() flushes TLB for !free_mapped */
> continue;
> }
> WARN_ON(!pmd_table(pmd));
> @@ -982,15 +985,12 @@ static void unmap_hotplug_pud_range(p4d_
> WARN_ON(!pud_present(pud));
> if (pud_sect(pud)) {
> pud_clear(pudp);
> -
> - /*
> - * One TLBI should be sufficient here as the PUD_SIZE
> - * range is mapped with a single block entry.
> - */
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> - if (free_mapped)
> + if (free_mapped) {
> + flush_tlb_kernel_range(addr, addr + PUD_SIZE);
[...]
Similarly here, but this is effectively flush_tlb_all() instead.
Ben.
--
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 1/6] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
From: Sang-Heon Jeon @ 2026-06-21 14:59 UTC (permalink / raw)
To: Andrey Ryabinin, Catalin Marinas, Will Deacon
Cc: Sang-Heon Jeon, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, kasan-dev, linux-arm-kernel, Vincenzo Frascino
In-Reply-To: <20260621145919.1453-1-ekffu200098@gmail.com>
kasan_init_shadow() maps each memblock region with for_each_mem_range()
and breaks the loop when start >= end. for_each_mem_range() never returns
an invalid range, so start < end always.
Therefore the start >= end check is unreachable, so remove it.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
---
arch/arm64/mm/kasan_init.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index 3fcad956fdf7..45fbdce684c8 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -353,9 +353,6 @@ static void __init kasan_init_shadow(void)
void *start = (void *)__phys_to_virt(pa_start);
void *end = (void *)__phys_to_virt(pa_end);
- if (start >= end)
- break;
-
kasan_map_populate((unsigned long)kasan_mem_to_shadow(start),
(unsigned long)kasan_mem_to_shadow(end),
early_pfn_to_nid(virt_to_pfn(start)));
--
2.43.0
^ permalink raw reply related
* [PATCH 0/6] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Sang-Heon Jeon @ 2026-06-21 14:59 UTC (permalink / raw)
To: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Mike Rapoport, Muchun Song, Oscar Salvador,
Palmer Dabbelt, Paul Walmsley, Will Deacon
Cc: Sang-Heon Jeon, Alexander Potapenko, Alexandre Ghiti,
Andrey Konovalov, David Hildenbrand, Dmitry Vyukov, kasan-dev,
linux-arm-kernel, linux-mm, linux-riscv, loongarch,
Vincenzo Frascino, WANG Xuerui
The memblock API guarantees that for_each_mem_range() and
for_each_mem_pfn_range() never return an invalid range, meaning start is
always less than end.
Several memblock callers still have unnecessary invalid range checks in
their loop bodies, so remove them.
Patches 1-4 cover for_each_mem_range() callers. memblock never stores a
zero-size region, so the range it returns always has start < end. Some
callers apply __va() or __phys_to_virt() before comparing, but these keep
start < end too, so the check is unreachable.
Patches 5-6 cover for_each_mem_pfn_range() callers. __next_mem_pfn_range()
skips any region that contains no whole page, so it only ever returns
start_pfn < end_pfn and the check is unnecessary.
For reference, commit 36ca7f4be809 ("arm64: mm: Remove bogus stop
condition from map_mem() loop") did a similar cleanup in arm64 map_mem().
All these checks are in different trees, so I split the change into one
patch per arch/subsystem. The patches are independent and can be applied
separately.
Sang-Heon Jeon (6):
arm64: mm: remove unreachable invalid range check in
kasan_init_shadow()
LoongArch: remove unreachable invalid range check in kasan_init()
riscv: remove unreachable invalid range check in
create_linear_mapping_page_table()
riscv: remove unreachable invalid range check in kasan_init()
mm: remove unnecessary empty range check in
early_calculate_totalpages()
mm/hugetlb: remove unnecessary empty range check in
hugetlb_bootmem_set_nodes()
arch/arm64/mm/kasan_init.c | 3 ---
arch/loongarch/mm/kasan_init.c | 3 ---
arch/riscv/mm/init.c | 2 --
arch/riscv/mm/kasan_init.c | 3 ---
mm/hugetlb.c | 3 +--
mm/mm_init.c | 3 +--
6 files changed, 2 insertions(+), 15 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Steven Rostedt @ 2026-06-21 13:24 UTC (permalink / raw)
To: Yury Norov, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <ajfiVTlCIVlqW3sh@yury>
On June 21, 2026 2:08:37 PM GMT+01:00, Yury Norov <yury.norov@gmail.com> wrote:
>On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
>> From: Steven Rostedt <rostedt@goodmis.org>
>>
>> In order to remove the include to trace_printk.h from kernel.h the tracing
>> control prototypes need to be moved back into kernel.h. That's because
>
>Please don't. Instead, you can split them out to trace_control.h, and
>include where needed. I actually have a prototype for it, FYI:
>
>https://github.com/norov/linux/tree/trace_pritk3
>
Sure, I have no problem adding another header for this.
>> they are used in other common header files like rcu.h. There's no point in
>> removing trace_printk.h from kernel.h if it just gets added back to other
>> common headers.
>>
>> Prototypes are very cheap for the compiler and should not be an issue.
>
>It's not about cost, it's about mess. kernel.h is included everywhere.
>Is that API needed everywhere? No, it's needed in literally 10 files.
>So, no place in kernel.h.
>
Well one of those files is rcu.h which is also pretty much included everywhere. But OK.
-- Steve
>>
>> 2.53.0
>>
^ permalink raw reply
* [PATCH 1/4] wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv()
From: Lorenzo Bianconi @ 2026-06-21 13:24 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Leon Yen, Hao Zhang,
Nelson Yu, Rong Yan, Money Wang, Bo Jiao, StanleyYP Wang,
Howard Hsu, Evelyn Tsai, Lorenzo Bianconi, Mingyen Hsieh
Cc: linux-wireless, linux-arm-kernel, linux-mediatek, Quan Zhou,
Deren Wu, MeiChia Chiu
In-Reply-To: <20260621-mt76_connac_get_he_phy_cap-fix-v1-0-ed4ccf7a0363@kernel.org>
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it.
Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index 6596c9e198f4..58b0b15e4fd6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -1458,6 +1458,8 @@ mt76_connac_mcu_uni_bss_he_tlv(struct mt76_phy *phy, struct ieee80211_vif *vif,
struct bss_info_uni_he *he;
cap = mt76_connac_get_he_phy_cap(phy, vif);
+ if (!cap)
+ return;
he = (struct bss_info_uni_he *)tlv;
he->he_pe_duration = vif->bss_conf.htc_trig_based_pkt_ext;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] iio: stm32-dfsdm: Treat flags as booleans
From: Jonathan Cameron @ 2026-06-21 14:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring (Arm), David Lechner, Nuno Sá, Andy Shevchenko,
Maxime Coquelin, Alexandre Torgue, linux-iio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <ai1dhJWb9vKqxEEe@ashevche-desk.local>
On Sat, 13 Jun 2026 16:39:16 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Jun 12, 2026 at 04:51:50PM -0500, Rob Herring (Arm) wrote:
> > The "st,adc-alt-channel" and "st,filter0-sync" properties are
> > documented as boolean flags. The legacy parser read them as integer
> > cells, unlike the child-node parser which already checks only for
> > presence.
> >
> > Use presence and boolean helpers so both parsers follow the binding and
> > the property type checker no longer reports the flags.
>
> For the patch
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> However one interesting remark below.
>
> ...
>
> > - ret = of_property_read_u32_index(indio_dev->dev.of_node,
> > - "st,adc-alt-channel", chan_idx,
> > - &df_ch->alt_si);
>
> > + df_ch->alt_si = of_property_present(indio_dev->dev.of_node,
>
> I believe it still has another (serious?) issue. We usually don't use indio_dev
> for device properties. It's not a device that is described in DT.
> It seems the only driver in IIO that does that. Note, I haven't conducted any
> deeper research, it might be (however I'm quite in doubt) that this is correct
> use and one device registers a few indio_dev:s.
It is curious. The registration sequence in this driver is complex, but I'm not
seeing anything that sets the fwnode for the struct iio_dev->dev before calling
the init() callbacks that end up in this code. It is set later by iio_device_register()
(iirc that has something to do with consumers turning up later).
St folk could you take a look at this and see what we are missing
if it does currently work?
For now I'll apply this patch but might need to drop it if a fix clashes
with it.
Thanks,
Jonathan
>
> > + "st,adc-alt-channel");
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621054721.7cde38f0@fedora>
On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> On Sun, 21 Jun 2026 05:34:32 -0400
> Steven Rostedt <rostedt@kernel.org> wrote:
>
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> Bah, I only tested with the config option enabled, and missed some
> dependencies with it disabled.
Yes you did.
> For instance, rcu.h also uses ftrace_dump() so that too needs to go
> into kernel.h.
No, it shouldn't.
> I also need to add a few more includes to trace_printk.h.
> OK, I need to run this through all my tests to find where else I missed
> adding the includes. But the idea should hopefully satisfy everyone.
If you include it under config in kernel.h, to make the kernel buildable,
you need to include trace_printk.h explicitly where it's actually used.
IOW, apply my patch v4-7.
Then, developers who use trace_printk() on their development machine,
will be really frustrated when their debugging code will break client
build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
They will spend a day, at best, communicating with remote managers,
and end up with adding #include <linux/trace_printk.h> in the files
they touch. Is that your plan?
If I was one of those developers, the solution would be simple for me:
don't use trace_printk() at all.
Thanks,
Yury
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7915: guard HE capability lookups
From: Lorenzo Bianconi @ 2026-06-21 13:32 UTC (permalink / raw)
To: Ruoyu Wang
Cc: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260620155332.81120-1-ruoyuw560@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]
> mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after
> checking HE support, then dereference the HE PHY capability returned by
> mt76_connac_get_he_phy_cap(). That helper can return NULL when no
> capability entry matches the vif type.
>
> Fetch the capability before appending the TLV and skip the HE-specific
> setup when no matching capability is available.
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Fixes: e6d557a78b60 ("mt76: mt7915: rely on mt76_connac_get_phy utilities")
> Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
> ---
> .../net/wireless/mediatek/mt76/mt7915/mcu.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> index 318c38149463..391c91675130 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> @@ -595,6 +595,8 @@ mt7915_mcu_bss_he_tlv(struct sk_buff *skb, struct ieee80211_vif *vif,
> struct tlv *tlv;
>
> cap = mt76_connac_get_he_phy_cap(phy->mt76, vif);
> + if (!cap)
> + return;
>
> tlv = mt76_connac_mcu_add_tlv(skb, BSS_INFO_HE_BASIC, sizeof(*he));
>
> @@ -1177,13 +1179,12 @@ mt7915_mcu_sta_bfer_vht(struct ieee80211_sta *sta, struct mt7915_phy *phy,
> }
>
> static void
> -mt7915_mcu_sta_bfer_he(struct ieee80211_sta *sta, struct ieee80211_vif *vif,
> - struct mt7915_phy *phy, struct sta_rec_bf *bf)
> +mt7915_mcu_sta_bfer_he(struct ieee80211_sta *sta,
> + const struct ieee80211_sta_he_cap *vc,
> + struct sta_rec_bf *bf)
> {
> struct ieee80211_sta_he_cap *pc = &sta->deflink.he_cap;
> struct ieee80211_he_cap_elem *pe = &pc->he_cap_elem;
> - const struct ieee80211_sta_he_cap *vc =
> - mt76_connac_get_he_phy_cap(phy->mt76, vif);
> const struct ieee80211_he_cap_elem *ve = &vc->he_cap_elem;
> u16 mcs_map = le16_to_cpu(pc->he_mcs_nss_supp.rx_mcs_80);
> u8 nss_mcs = mt7915_mcu_get_sta_nss(mcs_map);
> @@ -1242,6 +1243,7 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb,
> {
> struct mt7915_vif *mvif = (struct mt7915_vif *)vif->drv_priv;
> struct mt7915_phy *phy = mvif->phy;
> + const struct ieee80211_sta_he_cap *vc = NULL;
> int tx_ant = hweight8(phy->mt76->chainmask) - 1;
> struct sta_rec_bf *bf;
> struct tlv *tlv;
> @@ -1260,6 +1262,12 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb,
> if (!ebf && !dev->ibf)
> return;
>
> + if (sta->deflink.he_cap.has_he && ebf) {
> + vc = mt76_connac_get_he_phy_cap(phy->mt76, vif);
> + if (!vc)
> + return;
> + }
> +
> tlv = mt76_connac_mcu_add_tlv(skb, STA_REC_BF, sizeof(*bf));
> bf = (struct sta_rec_bf *)tlv;
>
> @@ -1268,7 +1276,7 @@ mt7915_mcu_sta_bfer_tlv(struct mt7915_dev *dev, struct sk_buff *skb,
> * ht: iBF only, since mac80211 lacks of eBF support
> */
> if (sta->deflink.he_cap.has_he && ebf)
> - mt7915_mcu_sta_bfer_he(sta, vif, phy, bf);
> + mt7915_mcu_sta_bfer_he(sta, vc, bf);
> else if (sta->deflink.vht_cap.vht_supported)
> mt7915_mcu_sta_bfer_vht(sta, phy, bf, ebf);
> else if (sta->deflink.ht_cap.ht_supported)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:57 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <ajfphe4Z8BrfYoUX@yury>
On Sun, Jun 21, 2026 at 09:39:17AM -0400, Yury Norov wrote:
> On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> > On Sun, 21 Jun 2026 05:34:32 -0400
> > Steven Rostedt <rostedt@kernel.org> wrote:
> >
> > > Instead of having trace_printk.h included in kernel.h, create a config
> > > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > > Makefile to allow developers to add trace_printk() without the need to add
> > > the include for it. Having it included in the Makefile keeps it from being
> > > in the dependency chain and it will not waste extra CPU cycles for those
> > > building the kernel without using trace_printk.
> >
> > Bah, I only tested with the config option enabled, and missed some
> > dependencies with it disabled.
>
> Yes you did.
>
> > For instance, rcu.h also uses ftrace_dump() so that too needs to go
> > into kernel.h.
>
> No, it shouldn't.
>
> > I also need to add a few more includes to trace_printk.h.
>
> > OK, I need to run this through all my tests to find where else I missed
> > adding the includes. But the idea should hopefully satisfy everyone.
>
> If you include it under config in kernel.h, to make the kernel buildable,
I mean: in kernel.h or in Makefile.
> you need to include trace_printk.h explicitly where it's actually used.
> IOW, apply my patch v4-7.
>
> Then, developers who use trace_printk() on their development machine,
> will be really frustrated when their debugging code will break client
> build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
> They will spend a day, at best, communicating with remote managers,
> and end up with adding #include <linux/trace_printk.h> in the files
> they touch. Is that your plan?
>
> If I was one of those developers, the solution would be simple for me:
> don't use trace_printk() at all.
>
> Thanks,
> Yury
^ permalink raw reply
* [PATCH 4/4] wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht()
From: Lorenzo Bianconi @ 2026-06-21 13:25 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Leon Yen, Hao Zhang,
Nelson Yu, Rong Yan, Money Wang, Bo Jiao, StanleyYP Wang,
Howard Hsu, Evelyn Tsai, Lorenzo Bianconi, Mingyen Hsieh
Cc: linux-wireless, linux-arm-kernel, linux-mediatek, Quan Zhou,
Deren Wu, MeiChia Chiu
In-Reply-To: <20260621-mt76_connac_get_he_phy_cap-fix-v1-0-ed4ccf7a0363@kernel.org>
mt76_connac_get_eht_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it.
Fixes: ba01944adee9f ("wifi: mt76: mt7996: add EHT beamforming support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
index c868b1356894..063097fad825 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
@@ -1924,14 +1924,19 @@ mt7996_mcu_sta_bfer_eht(struct ieee80211_link_sta *link_sta,
struct ieee80211_sta_eht_cap *pc = &link_sta->eht_cap;
struct ieee80211_eht_cap_elem_fixed *pe = &pc->eht_cap_elem;
struct ieee80211_eht_mcs_nss_supp *eht_nss = &pc->eht_mcs_nss_supp;
- const struct ieee80211_sta_eht_cap *vc =
mt76_connac_get_eht_phy_cap(phy->mt76, vif);
- const struct ieee80211_eht_cap_elem_fixed *ve = &vc->eht_cap_elem;
u8 nss_mcs = u8_get_bits(eht_nss->bw._80.rx_tx_mcs9_max_nss,
IEEE80211_EHT_MCS_NSS_RX) - 1;
+ const struct ieee80211_eht_cap_elem_fixed *ve;
+ const struct ieee80211_sta_eht_cap *vc;
u8 snd_dim, sts;
+ vc = mt76_connac_get_eht_phy_cap(phy->mt76, vif);
+ if (!vc)
+ return;
+
bf->tx_mode = MT_PHY_TYPE_EHT_MU;
+ ve = &vc->eht_cap_elem;
mt7996_mcu_sta_sounding_rate(bf, phy);
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv()
From: Lorenzo Bianconi @ 2026-06-21 13:25 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Leon Yen, Hao Zhang,
Nelson Yu, Rong Yan, Money Wang, Bo Jiao, StanleyYP Wang,
Howard Hsu, Evelyn Tsai, Lorenzo Bianconi, Mingyen Hsieh
Cc: linux-wireless, linux-arm-kernel, linux-mediatek, Quan Zhou,
Deren Wu, MeiChia Chiu
In-Reply-To: <20260621-mt76_connac_get_he_phy_cap-fix-v1-0-ed4ccf7a0363@kernel.org>
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it.
Fixes: c948b5da6bbec ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index e94fa544ff20..cb265a6fc7ad 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -2773,6 +2773,8 @@ mt7925_mcu_bss_he_tlv(struct sk_buff *skb, struct ieee80211_bss_conf *link_conf,
struct tlv *tlv;
cap = mt76_connac_get_he_phy_cap(phy->mt76, link_conf->vif);
+ if (!cap)
+ return;
tlv = mt76_connac_mcu_add_tlv(skb, UNI_BSS_INFO_HE_BASIC, sizeof(*he));
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap()
From: Lorenzo Bianconi @ 2026-06-21 13:25 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Leon Yen, Hao Zhang,
Nelson Yu, Rong Yan, Money Wang, Bo Jiao, StanleyYP Wang,
Howard Hsu, Evelyn Tsai, Lorenzo Bianconi, Mingyen Hsieh
Cc: linux-wireless, linux-arm-kernel, linux-mediatek, Quan Zhou,
Deren Wu, MeiChia Chiu
In-Reply-To: <20260621-mt76_connac_get_he_phy_cap-fix-v1-0-ed4ccf7a0363@kernel.org>
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it.
Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
index f119f023bcd5..c868b1356894 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c
@@ -935,6 +935,8 @@ mt7996_mcu_bss_he_tlv(struct sk_buff *skb, struct ieee80211_vif *vif,
struct tlv *tlv;
cap = mt76_connac_get_he_phy_cap(phy->mt76, vif);
+ if (!cap)
+ return;
tlv = mt7996_mcu_add_uni_tlv(skb, UNI_BSS_INFO_HE_BASIC, sizeof(*he));
@@ -1855,17 +1857,18 @@ mt7996_mcu_sta_bfer_he(struct ieee80211_link_sta *link_sta,
{
struct ieee80211_sta_he_cap *pc = &link_sta->he_cap;
struct ieee80211_he_cap_elem *pe = &pc->he_cap_elem;
- const struct ieee80211_sta_he_cap *vc =
- mt76_connac_get_he_phy_cap(phy->mt76, vif);
- const struct ieee80211_he_cap_elem *ve = &vc->he_cap_elem;
u16 mcs_map = le16_to_cpu(pc->he_mcs_nss_supp.rx_mcs_80);
u8 nss_mcs = mt7996_mcu_get_sta_nss(mcs_map);
+ const struct ieee80211_he_cap_elem *ve;
+ const struct ieee80211_sta_he_cap *vc;
u8 snd_dim, sts;
+ vc = mt76_connac_get_he_phy_cap(phy->mt76, vif);
if (!vc)
return;
bf->tx_mode = MT_PHY_TYPE_HE_SU;
+ ve = &vc->he_cap_elem;
mt7996_mcu_sta_sounding_rate(bf, phy);
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] wifi: mt76: fix some possible NULL-pointer dereferences
From: Lorenzo Bianconi @ 2026-06-21 13:24 UTC (permalink / raw)
To: Felix Fietkau, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Leon Yen, Hao Zhang,
Nelson Yu, Rong Yan, Money Wang, Bo Jiao, StanleyYP Wang,
Howard Hsu, Evelyn Tsai, Lorenzo Bianconi, Mingyen Hsieh
Cc: linux-wireless, linux-arm-kernel, linux-mediatek, Quan Zhou,
Deren Wu, MeiChia Chiu
---
Lorenzo Bianconi (4):
wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv()
wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv()
wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap()
wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht()
drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 ++
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 ++
drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 18 +++++++++++++-----
3 files changed, 17 insertions(+), 5 deletions(-)
---
base-commit: 50a7f9f9d48eb50c0e95bef53358acb5af5cb3c6
change-id: 20260621-mt76_connac_get_he_phy_cap-fix-2b3068d4d074
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Yury Norov @ 2026-06-21 13:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.007634476@kernel.org>
On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> In order to remove the include to trace_printk.h from kernel.h the tracing
> control prototypes need to be moved back into kernel.h. That's because
Please don't. Instead, you can split them out to trace_control.h, and
include where needed. I actually have a prototype for it, FYI:
https://github.com/norov/linux/tree/trace_pritk3
> they are used in other common header files like rcu.h. There's no point in
> removing trace_printk.h from kernel.h if it just gets added back to other
> common headers.
>
> Prototypes are very cheap for the compiler and should not be an issue.
It's not about cost, it's about mess. kernel.h is included everywhere.
Is that API needed everywhere? No, it's needed in literally 10 files.
So, no place in kernel.h.
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> include/linux/kernel.h | 18 ++++++++++++++++++
> include/linux/trace_printk.h | 17 -----------------
> 2 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e5570a16cbb1..c3c68128827c 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -194,4 +194,22 @@ extern enum system_states system_state;
> # define REBUILD_DUE_TO_DYNAMIC_FTRACE
> #endif
>
> +#ifdef CONFIG_TRACING
> +void tracing_on(void);
> +void tracing_off(void);
> +int tracing_is_on(void);
> +void tracing_snapshot(void);
> +void tracing_snapshot_alloc(void);
> +void tracing_start(void);
> +void tracing_stop(void);
> +#else
> +static inline void tracing_start(void) { }
> +static inline void tracing_stop(void) { }
> +static inline void tracing_on(void) { }
> +static inline void tracing_off(void) { }
> +static inline int tracing_is_on(void) { return 0; }
> +static inline void tracing_snapshot(void) { }
> +static inline void tracing_snapshot_alloc(void) { }
> +#endif
> +
> #endif
> diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
> index 3d54f440dccf..879fed0805fd 100644
> --- a/include/linux/trace_printk.h
> +++ b/include/linux/trace_printk.h
> @@ -35,15 +35,6 @@ enum ftrace_dump_mode {
> };
>
> #ifdef CONFIG_TRACING
> -void tracing_on(void);
> -void tracing_off(void);
> -int tracing_is_on(void);
> -void tracing_snapshot(void);
> -void tracing_snapshot_alloc(void);
> -
> -extern void tracing_start(void);
> -extern void tracing_stop(void);
> -
> static inline __printf(1, 2)
> void ____trace_printk_check_format(const char *fmt, ...)
> {
> @@ -176,16 +167,8 @@ __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
>
> extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
> #else
> -static inline void tracing_start(void) { }
> -static inline void tracing_stop(void) { }
> static inline void trace_dump_stack(int skip) { }
>
> -static inline void tracing_on(void) { }
> -static inline void tracing_off(void) { }
> -static inline int tracing_is_on(void) { return 0; }
> -static inline void tracing_snapshot(void) { }
> -static inline void tracing_snapshot_alloc(void) { }
> -
> static inline __printf(1, 2)
> int trace_printk(const char *fmt, ...)
> {
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 13:03 UTC (permalink / raw)
To: David Laight
Cc: Thomas Gleixner, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621135531.243375d9@pumpkin>
On Sun, 21 Jun 2026 13:55:31 +0100
David Laight <david.laight.linux@gmail.com> wrote:
> Indeed...
> Isn't trace_printk() just an extern?
> Having it defined somewhere isn't going to make any difference to build times.
No it is not. It is a macro to cut as many nanoseconds as possible as
trace_printk() was created to debug tight race conditions and any added
latency can make the race go away.
-- Steve
^ permalink raw reply
* Re: [PATCH v5 09/10] iio: dac: add mcf54415 DAC
From: Jonathan Cameron @ 2026-06-21 12:55 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, David Lechner, Nuno Sá,
Andy Shevchenko, Greg Ungerer, linux-m68k, linux-kernel,
linux-stm32, linux-arm-kernel, linux-iio, Michael Turquette,
Stephen Boyd, Brian Masney
In-Reply-To: <CALSJ-wC9Rsq6WJ_=X87R74jPrg2Y+=L8m0wRRp=1zvN5vSOw6A@mail.gmail.com>
On Mon, 15 Jun 2026 20:20:21 +0900
Angelo Dureghello <adureghello@baylibre.com> wrote:
> Hi Jonathan,
>
> On Thu, Jun 11, 2026 at 11:48:00AM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 22:35:14 +0200
> > Angelo Dureghello <adureghello@baylibre.com> wrote:
> >
> > > From: Angelo Dureghello <adureghello@baylibre.com>
> > >
> > > Add basic version of mcf54415 DAC driver. DAC is embedded in the SoC and
> > > DAC configuration registers are mapped in the internal IO address space.
> > >
> > > The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit
> > > analog output varying from DAC_VREFL to DAC_VREFH. The DAC module
> > > consists of a conversion unit, an output amplifier, and the associated
> > > digital control blocks. Default register values for DAC_VREFL and DAC_VREFH
> > > are respectively 0 and 0xfff, left untouched in this initial version.
> > >
> > > This initial version of the driver is minimalistic, "output raw" only, to
> > > be extended in the future. DMA and external sync are disabled, default mode
> > > is high speed, default format is right-justified 12-bit on 16-bit word.
> > >
> > > Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
> > I'm lazy so didn't check earlier versions but assume the two bits
> > of feedback from Sashiko are false positives:
> > https://sashiko.dev/#/patchset/20260610-wip-stmark2-dac-v5-0-b76b83366d5c%40baylibre.com
> >
> > The one about clock underflow if resume fails, and then devm cleanup happens later
> > is a bit nasty.
> >
> > I did a bit of digging and maybe it is better to just leave the clock on?
> > The status dev.power.is_suspended is set to false whether or not resume succeeded
> > and I believe a following suspend will not take into account that resume failed.
> >
> > I'm not set up to poke the combinations but it might be worth trying that.
> > +CC common clk people who may immediately know what the right answer is.
> >
>
> was about testing this, there are no bus faults on read/write of registers
> with clock disabled, nor warnings in dmesg on double disable.
Great. That makes life easier. I'm curious to why we don't get a double disable
though... Guess I'm missing something in the flows.
>
> Anyway, i see now from arch Kconfig that is not possible to have CONFIG_PM
> for this specifig CPU (with MMU, PM is force-disabled), so would remove pm_ops.
> Ok ?
I suspect that's something that might get 'fixed' at somepoint, so I'd keep
the PM stuff in this driver as long as you can check it basically works.
Jonathan
>
> Will fix all other things you pointyed out in v6.
>
> > Otherwise just a few minor style comments inline.
> >
> > Thanks,
> >
> > Jonathan
> >
>
> thanks,
> regards,
> angelo
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: David Laight @ 2026-06-21 12:55 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On Sun, 21 Jun 2026 12:13:00 +0200
Thomas Gleixner <tglx@kernel.org> wrote:
> On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> IOW, you make it worse just because.
>
> With the header being separate I add the three trace_printk()s and the
> include to the source file I'm investigating. The recompile will build
> exactly this source file.
>
> Having to enable the config knob will result in a full kernel rebuild
> for no value.
Indeed...
Isn't trace_printk() just an extern?
Having it defined somewhere isn't going to make any difference to build times.
David
>
> Seriously?
>
> Thanks,
>
> tglx
>
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Thomas Gleixner @ 2026-06-21 10:59 UTC (permalink / raw)
To: Marek Vasut, linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-4-marek.vasut+renesas@mailbox.org>
On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This SOB chain is broken.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 10:38 UTC (permalink / raw)
To: Thomas Gleixner, Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On June 21, 2026 11:13:00 AM GMT+01:00, Thomas Gleixner <tglx@kernel.org> wrote:
>On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
>> Instead of having trace_printk.h included in kernel.h, create a config
>> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
>> Makefile to allow developers to add trace_printk() without the need to add
>> the include for it. Having it included in the Makefile keeps it from being
>> in the dependency chain and it will not waste extra CPU cycles for those
>> building the kernel without using trace_printk.
>
>IOW, you make it worse just because.
>
>With the header being separate I add the three trace_printk()s and the
>include to the source file I'm investigating. The recompile will build
>exactly this source file.
>
>Having to enable the config knob will result in a full kernel rebuild
>for no value.
>
>Seriously?
Like having lockdep enabled, this would always be set in the development environment. It's not something to only enable when you need to add a trace_printk. If you don't want to rebuild everything, by all means add the include file by file. There's nothing preventing you to do that with this solution.
-- Steve
P.S. I'm replying on my phone as I'm in the London Tube. Thus why I'm not trimming my email.
>
>Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Thomas Gleixner @ 2026-06-21 10:13 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
IOW, you make it worse just because.
With the header being separate I add the three trace_printk()s and the
include to the source file I'm investigating. The recompile will build
exactly this source file.
Having to enable the config knob will result in a full kernel rebuild
for no value.
Seriously?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 9:47 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, 21 Jun 2026 05:34:32 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
Bah, I only tested with the config option enabled, and missed some
dependencies with it disabled.
For instance, rcu.h also uses ftrace_dump() so that too needs to go
into kernel.h. I also need to add a few more includes to trace_printk.h.
OK, I need to run this through all my tests to find where else I missed
adding the includes. But the idea should hopefully satisfy everyone.
-- Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox