* [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 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 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
* 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
* 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: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] 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
* [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 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 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
* [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
* 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
* 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 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 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] 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
* [PATCH] crypto: mxs-dcp - fix source scatterlist length access
From: Thorsten Blum @ 2026-06-21 19:26 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Marek Vasut
Cc: Thorsten Blum, stable, linux-crypto, imx, linux-arm-kernel,
linux-kernel
mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source
scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid
and could return zero or a stale DMA length, causing encryption and
decryption to process the wrong number of bytes when
CONFIG_NEED_SG_DMA_LENGTH=y.
Use the original scatterlist length instead.
Fixes: 15b59e7c3733 ("crypto: mxs - Add Freescale MXS DCP driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/mxs-dcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index 133ebc998236..595b2fd84667 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -353,7 +353,7 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
for_each_sg(req->src, src, sg_nents(req->src), i) {
src_buf = sg_virt(src);
- len = sg_dma_len(src);
+ len = src->length;
tlen += len;
limit_hit = tlen > req->cryptlen;
^ permalink raw reply related
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-21 18:58 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <vYm1twErR8mp-Fjgbvf-MQ@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]
On Sat, Jun 20, 2026 at 08:28:03PM +0300, Stefan Dösinger wrote:
> Hi Conor,
> Am Donnerstag, 18. Juni 2026, 22:54:53 Ostafrikanische Zeit schrieb Conor
> Dooley:
>
> I think I get the gist of your suggestions. I have a few follow-up questions
> to make sure I understand things right:
>
> > 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.
>
> At what point does it make sense to move the bindings from bindings/clock to
> bindings/mfd? The controllers are still very clock-heavy. allwinner,*-
> prcm.yaml look like clock, reset, misc controllers in mfd/ whereas
> ingenic,cgu.yaml, sprd,sc9863a-clk.yaml and da8xx-cfgchip.txt are clock + misc
> drivers in clock/.
Yeah, to bindings/mfd or bindings/soc/<vendor>. Which I think is mostly
a judgement call. Two of your devices have at least three functions,
which I think is enough to make the claim that it's not just a clock
controller.
> Likewise for the node names: syscon@ or clock-controller@?
If you have syscon in the compatible, then I think it should be syscon
in the node name as it's more general and makes it clear the device
isn't just a clock controller.
> > You'd then have topclock that is a syscon + simple-mfd, matrixclk that is
> > a syscon and lsp that's using the aux bus. The topclock and matrixclock
> > would have dedicated and trivial drivers somewhere that have the mfd_cells
> > and call mfd_add_devices().
>
> Do I even need simple-mfd? It seems I can add the syscon-reboot node via
> mfd_cells too by setting .of_compatible. It seems once it has a driver (even a
> very short one) simple-mfd is misplaced.
If you don't need child nodes in dt, you don't need simple-mfd.
Whether setting of_compatible is a correct thing to do, I do not know,
sorry.
> What about syscon? Topclk needs it for syscon-reboot and the watchdog
> controls. For the other two I only want a regmap. Afaiu device_node_to_regmap
> works without a "syscon" compatible. There's also regmap_init_mmio, but afaics
> I only want this when my driver is the only one using the regmap.
If it is a miscellaneous system register region, then it should be a
syscon. These devices that perform multiple functions like hwspinlock,
clocks and resets fit that bill. Whether or not you "need" it for linux to
work, if it is a correct description of your hardware you need to use
that compatible.
>
> > Probably the compatibles you've chosen start to make less sense at this
> > point though, but probably "topclk" and "matrixclk" are not what the
> > documentation for this device calls these register regions?
>
> Yeah I'll rename them top topcrm / matrixcrm / lspcrm. I just stuck to the old
> names for this email.
>
> > I think the priority is having something that reflects the hardware
> > accurately, I wouldn't compromise on that just to have the same design
> > for all three drivers.
>
> As far as I can see the primary difference between mfd_add_devices and simple-
> mfd + child nodes is that the latter makes the MFD composition visible in the
> device tree and the former keeps it a driver implementation detail. My sense
> is that the latter is preferred unless a subcomponent of the MFD might be
> reused in other components - e.g. an ADC is used in PMIC-abc and PMIC-xyz and
> thus the driver can be reused as well.
Correct. The other reason for doing it the devicetree way is if there
are conflicting property requirements. E.g. two of the same class of
device, like a pair of pin control functions or devices that use
different #address-cells to one another.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] pmdomain: bcm: bcm2835-power: Raise ASB poll timeout to 100us
From: Florian Fainelli @ 2026-06-21 20:13 UTC (permalink / raw)
To: Maíra Canal, Stefan Wahren, Ulf Hansson,
Broadcom internal kernel review list, Ray Jui, Scott Branden
Cc: linux-pm, linux-rpi-kernel, linux-arm-kernel, kernel-dev
In-Reply-To: <4af63689-e08c-406e-9ec3-f56dcbfb6f91@igalia.com>
On 6/19/2026 2:57 PM, Maíra Canal wrote:
> Hi,
>
> On 31/05/26 09:18, Maíra Canal wrote:
>> Hi Stefan,
>>
>> On 31/05/26 07:41, Stefan Wahren wrote:
>>> Hi Maíra,
>>>
>>> Am 30.05.26 um 22:46 schrieb Maíra Canal:
>>>> Commit 18605b1b936b ("pmdomain: bcm: bcm2835-power: Increase ASB
>>>> control
>>>> timeout") raised the ASB handshake polling budget from 1us to 5us.
>>>> Surveying the pmdomain subsystem, 5us is still one of the smallest
>>>> polling
>>>> budgets by a wide margin. Comparable handshakes in other drivers use:
>>>>
>>>> - 100us : starfive jh71xx-pmu, apple pmgr-pwrstate
>>>> - 1ms : renesas rcar-sysc, rmobile-sysc (power-on)
>>>> - 10ms : renesas rcar-gen4-sysc, sunxi sun55i-pck600
>>>> - 1s : mediatek mtk-pm-domains, mtk-scpsys
>>>>
>>>> Raise the BCM2835 timeout to 100us, matching analogous drivers.
>>>> 100us is
>>>> still negligible relative to a power-domain transition and gives the
>>>> V3D
>>>> master ASB substantially more headroom to drain under heavy workloads,
>>>> assuring us that the timeout is enough for any scenario.
>>> tbh I'm not convinced by this explanation. Starting with a timeout
>>> comparison across different pmdomain driver looks strange to me.
>>>
>>> My expectation that the reason for such a patch is that there is some
>>> kind of scenario to trigger unexpected timeouts.
>>> If this is the case, please provide more information about the
>>> scenario (specific platform, scenario, link to the bug report).
>>
>> The context: I was debugging this issue [1] and initially I had the
>> intuition that it could be related to a timeout in the ASB polling loop.
>> As I don't have access to the BCM2835 SoC datasheet (the public one
>> doesn't have PM information), I started to check other driver's
>> handshake timeout to see if ours was comparable to similar drivers. As
>> you can see, our timeout is much smaller.
>>
>> In the end, issue [1] wasn't related to the pmdomain driver, so I don't
>> have a specific scenario to trigger this issue. Even though, I sent this
>> patch considering the comparison to other drivers with the goal to be
>> conservative and use a larger timeout that could accommodate an extreme
>> scenario. However, if you believe it's unreasonable, I'm okay dropping
>> this patch.
>>
>> Ideally, it would be great to have information from Broadcom on what's
>> the largest possible time required to perform a power transition. Maybe
>> Florian could help us with that?
>>
>
> Gentle ping, any ideas about this?
I think it's reasonable in the sense that if there is a lot of traffic
posted on the AXI asynchronous bridge it will take longer for the
acknowledgement to come, I asked the designers whether 100us is
reasonable or not and will get back to you as soon as I get an answer.
--
Florian
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-06-21 20:49 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Barry Song, Lorenzo Stoakes, David Hildenbrand (Arm),
Liam R. Howlett, akpm, linux-mm, vbabka, rppt, mhocko, jack,
pfalcato, wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1,
chrisl, kasong, shikemeng, nphamcs, bhe, youngjun.park,
linux-arm-kernel, linux-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <CAJuCfpHTxaU4KdNmefU7C7cWZSLCFDLPdUrnqV6yzxzN+8RQ0Q@mail.gmail.com>
On Sat, Jun 20, 2026 at 04:48:57PM -0700, Suren Baghdasaryan wrote:
> Just checking in on the followup plans. IIUC the RFC mentioned will
> try to implement the solution we discussed at LSFMM: splitting
> VM_FAULT_RETRY into two flags - one for retrying under per-VMA locks
> and another one to fallback to mmap_lock.
I continue to hate this idea. I don't believe that those who were
pushing for it have ever tried to understand the whole fault path.
It's utterly byzantine.
I defy anyone to make sense of this:
/*
* NOTE! This will make us return with VM_FAULT_RETRY, but with
* the fault lock still held. That's how FAULT_FLAG_RETRY_NOWAIT
* is supposed to work. We have way too many special cases..
*/
if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT)
return 0;
*fpin = maybe_unlock_mmap_for_io(vmf, *fpin);
if (vmf->flags & FAULT_FLAG_KILLABLE) {
if (__folio_lock_killable(folio)) {
/*
* We didn't have the right flags to drop the
* fault lock, but all fault_handlers only check
* for fatal signals if we return VM_FAULT_RETRY,
* so we need to drop the fault lock here and
* return 0 if we don't have a fpin.
*/
if (*fpin == NULL)
release_fault_lock(vmf);
return 0;
}
Wed need to simplify the fault path, not add additional complexity.
Josef has said he wouldn't've done the lock dropping had we had per-VMA
locks. We should rip it out.
^ permalink raw reply
* Re: [PATCH] arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer
From: Florian Fainelli @ 2026-06-21 20:03 UTC (permalink / raw)
To: Marc Zyngier, Daniel Drake
Cc: robh, krzk+dt, conor+dt, bcm-kernel-feedback-list, devicetree,
linux-rpi-kernel, linux-arm-kernel, m.szyprowski, andrea.porta
In-Reply-To: <878q898ulx.wl-maz@kernel.org>
On 6/20/2026 9:49 AM, Marc Zyngier wrote:
> Hi Daniel,
>
> Thanks for posting this.
>
> On Fri, 19 Jun 2026 21:48:32 +0100,
> Daniel Drake <dan@reactivated.net> wrote:
>>
>> Commit d87773de9efe1 ("clocksource/drivers/arm_arch_timer: Default to
>> EL2 virtual timer when running VHE") causes boot to hang on
>> Raspberry Pi 5. The newly-selected EL2 virtual timer does not generate
>> any interrupts, even though the GIC_DIST_ENABLE_SET flag has been
>> confirmed set via readback.
>>
>> The reasons for this failure are unknown, however it is likely that
>> this timer was never tested. Raspberry Pi's original devicetree did
>
> The timer is part of the CPU, and there are enough A76 implementations
> around to prove that it actually works. The same can be said for the
> GIC400 this is (supposedly) attached to.
> >> not include this timer interrupt; it was only introduced via a
>> suggestion[1] made in code review as part of the upstreaming process.
>> (Current RPi firmware versions do include this timer, but only because
>> they rebased on top of the upstreamed devicetree starting with
>> Linux 6.12)
>>
>> Until more is known about this non-firing timer interrupt, remove
>> the devicetree entry to enable RPi5 devices to boot.
>
> I'd like to understand the reason why the timer interrupt isn't being
> delivered *before* we paper over it, and not the other way
> around. Each of the CPUs definitely have an EL2 virtual timer, the GIC
> has a per-CPU interrupt, but somehow the two don't seem to be linked.
>
> Since DT is supposed to describe the HW, I'd expect someone from
> Broadcom or RPi to shine a light on this issue. Integration mistakes
> happen, and we work around them (see the handful of Samsung SoCs where
> the timer interrupt was simply not wired). But we absolutely need to
> know what we are dealing with beforehand.
>
> Finally, just hacking the DT is not enough. Assuming that the timer is
> indeed unusable, we need to cope with the fact that there are DTs
> describing it in the wild, as nobody should be forced to upgrade their
> DT in lockstep with the kernel. For that, you'd also need something
> like the patch below (untested, and in need of a proper commit
> message, which I expect the SoC vendor to provide).
Daniel, do you happen to know which 2712 SoC revision you have, whether
this is a C0 or D0 stepping?
We have an internal bug tracker item pertaining exactly to the virtual
timer interrupt connection however it affected a sister chip (77122) and
not 2712 AFAICT, now checking with the design team whether the same
happened on 2712.
Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH] arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer
From: Daniel Drake @ 2026-06-21 20:58 UTC (permalink / raw)
To: Florian Fainelli, Marc Zyngier
Cc: robh, krzk+dt, conor+dt, bcm-kernel-feedback-list, devicetree,
linux-rpi-kernel, linux-arm-kernel, m.szyprowski, andrea.porta
In-Reply-To: <223cd514-41b3-45b9-8617-b54d379d5091@broadcom.com>
On 21/06/2026 21:03, Florian Fainelli wrote:
> Daniel, do you happen to know which 2712 SoC revision you have, whether
> this is a C0 or D0 stepping?
>
> We have an internal bug tracker item pertaining exactly to the virtual
> timer interrupt connection however it affected a sister chip (77122) and
> not 2712 AFAICT, now checking with the design team whether the same
> happened on 2712.
Thanks for looking into this! I am using Raspberry Pi 500 with D0 stepping.
Daniel
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
From: patchwork-bot+netdevbpf @ 2026-06-21 21:40 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178167550101.2217645.14579307712717502425@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 13:48:13 +0800 you wrote:
> In mtk_ppe_init(), when accounting is enabled, the error paths for
> dmam_alloc_coherent(mib) and devm_kzalloc(acct) failures return NULL
> directly, bypassing the err_free_l2_flows label that destroys the
> rhashtable initialized earlier.
>
> While this leak only occurs during probe (not runtime) and the leaked
> memory is minimal (an empty rhash table), fixing it ensures proper
> error path cleanup consistency.
>
> [...]
Here is the summary with links:
- [net] net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths
https://git.kernel.org/netdev/net/c/41782770be56
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-21 21:31 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel, Bradley Morgan
Protected guest faults charge long term pins to the VM's mm. Teardown
can run later from file release, where current->mm may be unrelated.
Drop the charge from kvm->mm instead.
Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
arch/arm64/kvm/pkvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
index 053e4f733e4b..428723b1b0f5 100644
--- a/arch/arm64/kvm/pkvm.c
+++ b/arch/arm64/kvm/pkvm.c
@@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
page = pfn_to_page(mapping->pfn);
WARN_ON_ONCE(mapping->nr_pages != 1);
unpin_user_pages_dirty_lock(&page, 1, true);
- account_locked_vm(current->mm, 1, false);
+ account_locked_vm(kvm->mm, 1, false);
pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
kfree(mapping);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/5] dmaengine: sun6i-dma: Add support for Allwinner A733 DMA controller
From: Yuanshen Cao @ 2026-06-21 21:40 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard
Cc: Yuanshen Cao, dmaengine, linux-arm-kernel, linux-sunxi,
linux-kernel, devicetree
Hi everyone,
This patch series introduces support for the Allwinner A733 DMA
controller in the `sun6i-dma` driver.
The A733 DMA controller differs from previous generations in several key
ways:
1. It supports higher address (up to 32G).
2. It uses a different interrupt register layout and mapping.
3. It has a different number of channels per interrupt register.
To support these differences without introducing complex conditional
logic throughout the driver, this series first refactors the
`sun6i_dma_config` structure. By moving interrupt handling, register
dumping, and address configuration into function pointers within the
configuration structure. This allows the driver to support the A733
and future hardware revisions. It also aligns with the DMA drivers in
Radxa BSP Package[1].
The series is organized as follows:
- Refactors the configuration structure to include function pointers for
interrupt and register operations.
- Moves address setting logic into the configuration structure to handle
varying address widths.
- Adds support for variable channels per interrupt register.
- Updates the device tree bindings documentation.
- Implements the A733-specific configuration and register mappings.
Tested on Radxa Cubie A7Z.
[1] https://github.com/radxa/allwinner-bsp/blob/cubie-aiot-v1.4.8/drivers/dma/sunxi-dma.c
Thanks!
Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
---
Changes in v2:
- Implement SUN6I_DMA_IRQ_A31_COMMON_OPS macro to avoid duplicate.
- Move set_addr into helper function and revert back sun6i_dma_set_addr.
- Rename chan_num to irq_req to avoid misleading name as suggested by
sashiko.
- Reorder and reword the dtbinding patch for more clarity.
- Link to v1: https://patch.msgid.link/20260619-sun60i-a733-dma-v1-0-da4b649fc72a@gmail.com
To: Vinod Koul <vkoul@kernel.org>
To: Frank Li <Frank.Li@kernel.org>
To: Chen-Yu Tsai <wens@kernel.org>
To: Jernej Skrabec <jernej.skrabec@gmail.com>
To: Samuel Holland <samuel@sholland.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Maxime Ripard <mripard@kernel.org>
Cc: dmaengine@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-sunxi@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Yuanshen Cao (5):
dmaengine: sun6i-dma: Refactor to support A733 interrupt and register handling
dmaengine: sun6i-dma: Add set_addr function pointer for variable address widths
dmaengine: sun6i-dma: Add num_channels_per_reg for flexible interrupt mapping
dt-bindings: dma: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
dmaengine: sun6i-dma: Implement support for Allwinner A733 DMA controller
.../bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 +
drivers/dma/sun6i-dma.c | 197 +++++++++++++++++++--
2 files changed, 181 insertions(+), 18 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260619-sun60i-a733-dma-c2455149165d
Best regards,
--
Yuanshen Cao <alex.caoys@gmail.com>
^ 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