* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-02 6:09 UTC (permalink / raw)
To: Markus Probst, Alexandre Belloni
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <74b32ed0a700e3900c0f34d730b2b5b69eb2ca19.camel@posteo.de>
On 01/07/2026 19:08, Markus Probst wrote:
> On Wed, 2026-07-01 at 18:48 +0200, Alexandre Belloni wrote:
>> On 01/07/2026 16:43:07+0000, Markus Probst wrote:
>>> On Wed, 2026-07-01 at 17:14 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/07/2026 15:25, Markus Probst wrote:
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>>>>
>>>>>> This should be someone caring about this hardware.
>>>>> He does have the majority of commits on this driver (excluding merge
>>>>> commits and commits not exclusive to this driver), although most of
>>>>> them are pretty tiny.
>>>>>
>>>>> Who would you suggest instead?
>>>>
>>>> Someone adding features for this driver, maybe driver maintainers. But
>>>> if Alexandre is fine, you can leave him.
>>>>
>>>>>>
>>>>>>> +
>>>>>>> +description:
>>>>>>> + The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
>>>>>>> + very low current consumption in the wide range of operation voltage.
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> + - $ref: rtc.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> + compatible:
>>>>>>> + const: sii,s35390a
>>>>>>> +
>>>>>>> + reg:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + sii,wakealarm-output-pin:
>>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>> + enum: [1, 2]
>>>>>>> + description: |
>>>>>>> + The output pin to wake up the system.
>>>>>>> + Default will use the output pin for interrupt signal 2.
>>>>>>> + <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
>>>>>>> + <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
>>>>>>
>>>>>> Does that mean device generates the interrupts?
>>>>> Yes.
>>>>>
>>>>
>>>>
>>>> Then I think you miss interrupts property.
>>> From what I can tell the line is used to generate a system wakeup
>>> event.
>>>
>>> There would be no obvious benefit of connecting it to an interrupt
>>> controller, so this property would be obsolete?
>>>
>>
>> Then you need proper wakeup-source support
> Wouldn't that break existing devicetrees?
How?
>
> The current driver allows to wake up the system, even without
> having wakeup-source set.
Anyway, wakeup-source is already there in rtc, so this would be done. I
don't get though, why there is no benefit of routing it to interrupt
controller (interrupt controllers do wake up the system). Additionally,
if you do not connect it to any interrupt, then how does it wake up the
system?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 06/19] ARM: mark CPU_ENDIAN_BE8 as deprecated
From: Arnd Bergmann @ 2026-07-02 6:02 UTC (permalink / raw)
To: Ethan Nelson-Moore, Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
Will Deacon
In-Reply-To: <CADkSEUgm4yX36W6dG-5WOm42Z3iDpHVcz73suWDN3=bsGgq+0g@mail.gmail.com>
On Wed, Jul 1, 2026, at 23:57, Ethan Nelson-Moore wrote:
>> At the moment, there are no known bugs with big-endian ARMv7 mode, but
>> it does break occasionally and require someone to fix it. By marking
>> the code as 'depends on BROKEN' now, it will no longer be covered by CI
>> testing. If any users remain, they can keep patching out the dependency
>> but are more likely to run into regressions.
>>
>> The big-endian ARMv5 support (CONFIG_CPU_ENDIAN_BE32) in contrast is
>> still used on Intel IXP4xx platform, and is the only currently supported
>> mode there, so this one can still be enabled.
>
> If IXP4xx is the only known remaining user, would it make sense for
> CPU_BIG_ENDIAN to instead depend on ARCH_IXP4XX || BROKEN? Is BE32
> mode known to work correctly on any other platforms?
This is essentially what we have, just expressed the other way round:
all ARMv4/v4t/v5 platforms depend on CONFIG_CPU_LITTLE_ENDIAN, except
for IXP4xx, which depends on CONFIG_CPU_BIG_ENDIAN.
Arnd
^ permalink raw reply
* Re: [PATCH v2 18/19] ARM: mark axxia platform as deprecated
From: Arnd Bergmann @ 2026-07-02 5:57 UTC (permalink / raw)
To: Ethan Nelson-Moore, Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
Will Deacon, Andre Przywara
In-Reply-To: <CADkSEUhWe9aLuM7AURDKjMkrpEKOog9X59fWuZXvUVjkT9BuBw@mail.gmail.com>
On Thu, Jul 2, 2026, at 00:41, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Wed, Jul 1, 2026 at 2:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>
> All of these patches have this line at the beginning but were sent
> from your kernel.org email - did something go wrong with git
> send-email?
I should fix this, but it's been like this for a while after
I had patch emails get rejected too much for coming from my
arndb.de domain.
>> config ARCH_AXXIA
>> - bool "LSI Axxia platforms"
>> + bool "LSI Axxia platforms (DEPRECATED)"
>> depends on ARCH_MULTI_V7 && ARM_LPAE
>
> The dependency on LPAE reminded me of two other 32-bit ARM platforms
> with lots of memory: Calxeda Midway and Highbank. Is anyone still
> using those? Maybe they could be removed, since people seem to want to
> remove highmem:
> https://lwn.net/Articles/813201/
> https://static.linaro.org/connect/lvc20/presentations/LVC20-106-0.pdf
Andre Przywara used to use those for testing, I don't think anyone
else has powered them on for a while, see
https://lore.kernel.org/all/9723b5df-e218-1ea9-e8eb-9e781b23af49@arm.com/
If it gets in the way, or Andre gets tired of maintaining it,
we can remove it, until then I would keep it. Axxia is different
because it's neither maintained nor functional.
There are a few more platforms that need highmem for the time
being:
- TI keystone2 has users and is well maintained, so this will
stay as long as we can justify holding up highmem removal
for it. This one has a unique way of dealing with coherent
DMA that requires LPAE and possibly highmem.
- Renesas R-Car M1 need lpae support for (IIRC) >1GB
configurations, and I have a prototype patch
to make that one work with a modified virt_to_phys()
implementation.
- Amazon/Annapurna Alpine is similar to Axxia in the
current state of upstream support, but has someone
working on an OpenWRT port using the downstream
patches. The OpenWRT supported devices all have 2GB
or less.
A few others need highmem for large memory configs
with more than 2GB of RAM but would stay working for
the common configurations with 2GB or less, using
CONFIG_VMSPLIT_2G_OPT.
Arnd
^ permalink raw reply
* Re: [PATCH v5 11/14] dt-bindings: media: mediatek: vcodec: add decoder dt-bindings for mt8196
From: Kyrie Wu (吴晗) @ 2026-07-02 5:39 UTC (permalink / raw)
To: conor@kernel.org
Cc: AngeloGioacchino Del Regno, Kyrie Wu (吴晗),
laurent.pinchart+renesas@ideasonboard.com,
nicolas.dufresne@collabora.com, jacopo.mondi@ideasonboard.com,
Yunfei Dong (董云飞), conor+dt@kernel.org,
Irui Wang (王瑞), rongqianfeng@vivo.com,
tzungbi@kernel.org, tfiga@chromium.org, robh@kernel.org,
wenst@chromium.org, benjamin.gaignard@collabora.com,
matthias.bgg@gmail.com, haoxiang_li2024@163.com,
ribalda@chromium.org, Tiffany Lin (林慧珊),
linux-mediatek@lists.infradead.org, p.zabel@pengutronix.de,
sebastian.fricke@collabora.com, fshao@chromium.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
mchehab@kernel.org, fanwu01@zju.edu.cn,
linux-arm-kernel@lists.infradead.org,
Andrew-CT Chen (陳智迪), krzk+dt@kernel.org,
hverkuil+cisco@kernel.org, linux-kernel@vger.kernel.org,
kees@kernel.org, sakari.ailus@linux.intel.com
In-Reply-To: <20260603-pentagram-unleveled-8729d0003aa7@spud>
On Wed, 2026-06-03 at 17:14 +0100, Conor Dooley wrote:
> On Wed, Jun 03, 2026 at 04:40:41PM +0800, Kyrie Wu wrote:
> > From: Yunfei Dong <yunfei.dong@mediatek.com>
> >
> > The MT8196 decoder differs from previous generations in several
> > key aspects, most notably in its use of VCP instead of SCP.
> > Additionally, the MT8196 enhances codec capabilities by supporting
> > HEVC Main10 profile decoding. To accommodate these hardware
> > changes,
> > the binding constraints specify a total of 12 clock inputs,
> > consisting of 9 decoder clocks and 3 VCP interface clocks,
> > along with 2 power domains covering both the decoder and VCP
> > subsystems.
>
> I'm pretty pretty confused by this statement about constraints, since
> there's none added?
> The vcodec-dec node doesn't even seem to permit clocks at all?
>
Dear Conor,
I apologize for any confusion my commit message caused. What I wanted
to convey was the hardware differences between the MT8196 and previous
ICs. If you feel that the VCP and clock information are not suitable
for this location, I would like to rewrite the commit message as
follows:
Compared to previous ICs, the MT8196 supports a 10-bit decoder and has
a decoding capability of 4K@120fps, using a dual hardware decoding
architecture of LAT+CORE.
Thanks.
Regards,
Kyrie.
> >
> > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > ---
> > .../bindings/media/mediatek,vcodec-subdev-decoder.yaml |
> > 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-
> > decoder.yaml
> > index bf8082d87ac0..74e1d88d3056 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-
> > subdev-decoder.yaml
> > +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-
> > subdev-decoder.yaml
> > @@ -76,6 +76,7 @@ properties:
> > - mediatek,mt8186-vcodec-dec
> > - mediatek,mt8188-vcodec-dec
> > - mediatek,mt8195-vcodec-dec
> > + - mediatek,mt8196-vcodec-dec
> >
> > reg:
> > minItems: 1
> > --
> > 2.45.2
> >
^ permalink raw reply
* Re: [PATCH v2 07/19] ARM: update DEPRECATED_PARAM_STRUCT removal timeline
From: Arnd Bergmann @ 2026-07-02 5:36 UTC (permalink / raw)
To: Ethan Nelson-Moore, Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
Will Deacon
In-Reply-To: <CADkSEUhO9nhzQZCS7ZziCtMna+ibfj9_PbSH5R+c0pyi5viCvg@mail.gmail.com>
On Thu, Jul 2, 2026, at 02:54, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Wed, Jul 1, 2026 at 2:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> This configuration option is for the older boot method that preceeded
>> ATAGS. This was scheduled for removal back in 2001, but the removal
>> never happened, presumably because nobody cared enough to actually do it,
>> not because there are any users left.
>
> Only netwinder_defconfig selects this option. Do the most recent
> NetWinder firmware versions actually need it? (LinusW, do you know
> this?) If not, can't we just drop it entirely?
If all StrongARM platforms are on the way out after the LTS kernel,
I don't see a need to remove this any earlier, even if the chance
that it's still needed is low.
Arnd
^ permalink raw reply
* Re: [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Dev Jain @ 2026-07-02 5:18 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual
In-Reply-To: <20260702051341.126509-7-dev.jain@arm.com>
On 02/07/26 10:43 am, Dev Jain wrote:
> prot_none_hugetlb_entry() is the hugetlb callback for the early
> mprotect(PROT_NONE) PFN permission walk on x86.
>
> The callback passes the decoded PFN to pfn_modify_allowed(). For a
> hugetlb callback, the pte pointer refers to a hugetlb entry. On
> architectures where hugetlb entries need huge_ptep_get(), reading that
> entry with ptep_get() can make the permission check use the wrong PFN.
>
> Use huge_ptep_get() before decoding the hugetlb PFN.
>
> Currently there is no path which can trigger a bug: huge_ptep_get() is a
> simple ptep_get() for x86, and the prot_none walk occurs only for x86.
>
> So no need to backport - use the correct helper anyways.
>
> Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
@Muchun, I did not do the change you suggested: if we do #ifdef around
the hugetlb callback, then for CONFIG_HUGETLB_PAGE=n, prot_none_hugetlb_entry()
is defined but not used, giving compile error.
> mm/mprotect.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 9cbf932b028cf..23779632d18bf 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
> 0 : -EACCES;
> }
>
> +#ifdef CONFIG_HUGETLB_PAGE
> static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
> unsigned long addr, unsigned long next,
> struct mm_walk *walk)
> {
> - return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
> + pte_t entry = huge_ptep_get(walk->mm, addr, pte);
> +
> + return pfn_modify_allowed(pte_pfn(entry),
> *(pgprot_t *)(walk->private)) ?
> 0 : -EACCES;
> }
> +#else
> +#define prot_none_hugetlb_entry NULL
> +#endif
>
> static int prot_none_test(unsigned long addr, unsigned long next,
> struct mm_walk *walk)
^ permalink raw reply
* [PATCH v2 6/6] mm/mprotect: use huge_ptep_get() for hugetlb
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
prot_none_hugetlb_entry() is the hugetlb callback for the early
mprotect(PROT_NONE) PFN permission walk on x86.
The callback passes the decoded PFN to pfn_modify_allowed(). For a
hugetlb callback, the pte pointer refers to a hugetlb entry. On
architectures where hugetlb entries need huge_ptep_get(), reading that
entry with ptep_get() can make the permission check use the wrong PFN.
Use huge_ptep_get() before decoding the hugetlb PFN.
Currently there is no path which can trigger a bug: huge_ptep_get() is a
simple ptep_get() for x86, and the prot_none walk occurs only for x86.
So no need to backport - use the correct helper anyways.
Fixes: 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings")
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
mm/mprotect.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 9cbf932b028cf..23779632d18bf 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -699,14 +699,20 @@ static int prot_none_pte_entry(pte_t *pte, unsigned long addr,
0 : -EACCES;
}
+#ifdef CONFIG_HUGETLB_PAGE
static int prot_none_hugetlb_entry(pte_t *pte, unsigned long hmask,
unsigned long addr, unsigned long next,
struct mm_walk *walk)
{
- return pfn_modify_allowed(pte_pfn(ptep_get(pte)),
+ pte_t entry = huge_ptep_get(walk->mm, addr, pte);
+
+ return pfn_modify_allowed(pte_pfn(entry),
*(pgprot_t *)(walk->private)) ?
0 : -EACCES;
}
+#else
+#define prot_none_hugetlb_entry NULL
+#endif
static int prot_none_test(unsigned long addr, unsigned long next,
struct mm_walk *walk)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] mm/page_vma_mapped: use huge_ptep_get() for hugetlb
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
check_pte() is the final validation step in page_vma_mapped_walk().
It reads pvmw->pte with ptep_get() to decide whether the entry maps
the PFN range being walked. For hugetlb VMAs, that pointer refers
to a hugetlb entry.
On arches which provide their own huge_ptep_get() to dereference a huge
pte pointer, accessing via ptep_get() would cause pte_pfn(),
pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.
Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
Cc: stable@vger.kernel.org
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
mm/page_vma_mapped.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
index 2ccbabfb2cc17..18e1d341f463c 100644
--- a/mm/page_vma_mapped.c
+++ b/mm/page_vma_mapped.c
@@ -107,7 +107,13 @@ static bool map_pte(struct page_vma_mapped_walk *pvmw, pmd_t *pmdvalp,
static bool check_pte(struct page_vma_mapped_walk *pvmw, unsigned long pte_nr)
{
unsigned long pfn;
- pte_t ptent = ptep_get(pvmw->pte);
+ pte_t ptent;
+
+ if (is_vm_hugetlb_page(pvmw->vma))
+ ptent = huge_ptep_get(pvmw->vma->vm_mm, pvmw->address,
+ pvmw->pte);
+ else
+ ptent = ptep_get(pvmw->pte);
if (pvmw->flags & PVMW_MIGRATION) {
const softleaf_t entry = softleaf_from_pte(ptent);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] mm/migrate: use huge_ptep_get() in remove_migration_pte()
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
remove_migration_pte() converts migration entries back to present PTEs
after folio migration completes. For hugetlb folios,
page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in
pvmw.pte, but the code reads it with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge
pte pointer, accessing via ptep_get() would cause pte_pfn(),
pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.
Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
Cc: stable@vger.kernel.org
Acked-by: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
mm/migrate.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index d9b23909d716c..c65f0f43df7eb 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -371,7 +371,11 @@ static bool remove_migration_pte(struct folio *folio,
continue;
}
#endif
- old_pte = ptep_get(pvmw.pte);
+ if (folio_test_hugetlb(folio))
+ old_pte = huge_ptep_get(vma->vm_mm, pvmw.address,
+ pvmw.pte);
+ else
+ old_pte = ptep_get(pvmw.pte);
if (rmap_walk_arg->map_unused_to_zeropage &&
try_to_map_unused_to_zeropage(&pvmw, folio, old_pte, idx))
continue;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] mm/rmap: use huge_ptep_get() in try_to_migrate_one()
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
try_to_migrate_one() is used by folio migration to replace a present
mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk()
returns the pte pointer to the hugetlb folio in pvmw.pte, but the code
reads the huge pte entry with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge
pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.
Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into
try_to_migrate_one.
Fixes: a98a2f0c8ce1 ("mm/rmap: split migration into its own function")
Cc: stable@vger.kernel.org
Acked-by: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
mm/rmap.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index aa8a254efaecc..abc3a44baaa3d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2505,11 +2505,16 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
/* Unexpected PMD-mapped THP? */
VM_BUG_ON_FOLIO(!pvmw.pte, folio);
- /*
- * Handle PFN swap PTEs, such as device-exclusive ones, that
- * actually map pages.
- */
- pteval = ptep_get(pvmw.pte);
+ address = pvmw.address;
+ if (folio_test_hugetlb(folio)) {
+ pteval = huge_ptep_get(mm, address, pvmw.pte);
+ } else {
+ /*
+ * Handle PFN swap PTEs, such as device-exclusive ones,
+ * that actually map pages.
+ */
+ pteval = ptep_get(pvmw.pte);
+ }
if (likely(pte_present(pteval))) {
pfn = pte_pfn(pteval);
} else {
@@ -2520,7 +2525,6 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
}
subpage = folio_page(folio, pfn - folio_pfn(folio));
- address = pvmw.address;
anon_exclusive = folio_test_anon(folio) &&
PageAnonExclusive(subpage);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
try_to_unmap_one() handles hugetlb folios when memory failure needs
to replace a poisoned hugetlb mapping with a hwpoison entry. In that
case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
in pvmw.pte, but the code reads it with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge
pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Just use huge_ptep_get() for dereferencing a huge pte pointer.
Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
Cc: stable@vger.kernel.org
Reported-by: David Hildenbrand <david@kernel.org>
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
include/linux/hugetlb.h | 3 +++
mm/rmap.c | 16 ++++++++++------
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 2abaf99321e90..fdb7bdf7645c5 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
{
}
+pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
+ pte_t *ptep);
+
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
diff --git a/mm/rmap.c b/mm/rmap.c
index 1c77d5dc06e9f..aa8a254efaecc 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
/* Unexpected PMD-mapped THP? */
VM_BUG_ON_FOLIO(!pvmw.pte, folio);
- /*
- * Handle PFN swap PTEs, such as device-exclusive ones, that
- * actually map pages.
- */
- pteval = ptep_get(pvmw.pte);
+ address = pvmw.address;
+ if (folio_test_hugetlb(folio)) {
+ pteval = huge_ptep_get(mm, address, pvmw.pte);
+ } else {
+ /*
+ * Handle PFN swap PTEs, such as device-exclusive ones,
+ * that actually map pages.
+ */
+ pteval = ptep_get(pvmw.pte);
+ }
if (likely(pte_present(pteval))) {
pfn = pte_pfn(pteval);
} else {
@@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
}
subpage = folio_page(folio, pfn - folio_pfn(folio));
- address = pvmw.address;
anon_exclusive = folio_test_anon(folio) &&
PageAnonExclusive(subpage);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/6] arm64: make huge_ptep_get handled unaligned addresses
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable
In-Reply-To: <20260702051341.126509-1-dev.jain@arm.com>
huge_ptep_get() can be handed a virtual address pointing to the middle of
a contpmd/contpte mapped hugetlb folio (examples of callers are
pagemap_hugetlb_range, page_mapped_in_vma).
The arm64 helper rewalks the pgtables in find_num_contig to answer whether
the huge pte we have maps a contpmd or a contpte hugetlb folio, and
returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the
contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS
if the addr is not aligned.
Fix this by aligning the pmdp pointer down to a contpmd base before
checking equality with the passed huge pte pointer, to correctly answer
whether the huge pte is the base of a contpmd block.
Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
Cc: stable@vger.kernel.org
Signed-off-by: Dev Jain <dev.jain@arm.com>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 30772a909aea3..8e799c1fe0aa6 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -87,7 +87,7 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr,
p4dp = p4d_offset(pgdp, addr);
pudp = pud_offset(p4dp, addr);
pmdp = pmd_offset(pudp, addr);
- if ((pte_t *)pmdp == ptep) {
+ if ((pte_t *)PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS) == ptep) {
*pgsize = PMD_SIZE;
return CONT_PMDS;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/6] Fix incorrect access of hugetlb pte entries
From: Dev Jain @ 2026-07-02 5:13 UTC (permalink / raw)
To: muchun.song, osalvador, akpm, ljs, david, liam
Cc: Dev Jain, riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang, j-nomura,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual
There are various places which use ptep_get() to get the pte entry
corresponding to a hugetlb folio. Some arches (like s390) have special
handling to compute the pteval, so they provide huge_ptep_get(). Use this
helper consistently.
Additionally, some code paths may provide huge_ptep_get with an unaligned
address. This is a problem on arm64 (I checked other arches and it looks
fine for them), which is fixed in patch 1. The fix is made to be
backport-friendly: the cleaner fix would be to perhaps pass the hstate
to huge_ptep_get() - that is wider churn and we can do that later.
---
v1->v2:
- Add patch 1
- Mention s390 in cover letter
Dev Jain (6):
arm64: make huge_ptep_get handled unaligned addresses
mm/rmap: use huge_ptep_get() in try_to_unmap_one()
mm/rmap: use huge_ptep_get() in try_to_migrate_one()
mm/migrate: use huge_ptep_get() in remove_migration_pte()
mm/page_vma_mapped: use huge_ptep_get() for hugetlb
mm/mprotect: use huge_ptep_get() for hugetlb
arch/arm64/mm/hugetlbpage.c | 2 +-
include/linux/hugetlb.h | 3 +++
mm/migrate.c | 6 +++++-
mm/mprotect.c | 8 +++++++-
mm/page_vma_mapped.c | 8 +++++++-
mm/rmap.c | 32 ++++++++++++++++++++------------
6 files changed, 43 insertions(+), 16 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v13 05/15] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait()
From: Ankur Arora @ 2026-07-02 1:33 UTC (permalink / raw)
To: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf
Cc: arnd, catalin.marinas, will, peterz, akpm, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, broonie, joao.m.martins,
boris.ostrovsky, konrad.wilk, ashok.bhat, Ankur Arora
In-Reply-To: <20260702013334.140905-1-ankur.a.arora@oracle.com>
In preparation for defining smp_cond_load_acquire_timeout(), remove
the private copy. Lacking this, the rqspinlock code falls back to using
smp_cond_load_acquire().
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: bpf@vger.kernel.org
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Haris Okanovic <harisokn@amazon.com>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Reviewed-by: Christoph Lameter (Ampere) <cl@gentwo.org>
Tested-by: Haris Okanovic <harisokn@amazon.com>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
Notes: comments about bisection hole [1][2]. Discussed and acked-by Kumar.
[1] https://lore.kernel.org/all/20260608081935.E42C61F00893@smtp.kernel.org/
[2] https://lore.kernel.org/all/04f6ed5fe4f00805ba2eeb5f5d1b6f6d731cabcd00bd74fe11c060fd828131a9@mail.kernel.org/
---
arch/arm64/include/asm/rqspinlock.h | 85 -----------------------------
1 file changed, 85 deletions(-)
diff --git a/arch/arm64/include/asm/rqspinlock.h b/arch/arm64/include/asm/rqspinlock.h
index 9ea0a74e5892..a385603436e9 100644
--- a/arch/arm64/include/asm/rqspinlock.h
+++ b/arch/arm64/include/asm/rqspinlock.h
@@ -3,91 +3,6 @@
#define _ASM_RQSPINLOCK_H
#include <asm/barrier.h>
-
-/*
- * Hardcode res_smp_cond_load_acquire implementations for arm64 to a custom
- * version based on [0]. In rqspinlock code, our conditional expression involves
- * checking the value _and_ additionally a timeout. However, on arm64, the
- * WFE-based implementation may never spin again if no stores occur to the
- * locked byte in the lock word. As such, we may be stuck forever if
- * event-stream based unblocking is not available on the platform for WFE spin
- * loops (arch_timer_evtstrm_available).
- *
- * Once support for smp_cond_load_acquire_timewait [0] lands, we can drop this
- * copy-paste.
- *
- * While we rely on the implementation to amortize the cost of sampling
- * cond_expr for us, it will not happen when event stream support is
- * unavailable, time_expr check is amortized. This is not the common case, and
- * it would be difficult to fit our logic in the time_expr_ns >= time_limit_ns
- * comparison, hence just let it be. In case of event-stream, the loop is woken
- * up at microsecond granularity.
- *
- * [0]: https://lore.kernel.org/lkml/20250203214911.898276-1-ankur.a.arora@oracle.com
- */
-
-#ifndef smp_cond_load_acquire_timewait
-
-#define smp_cond_time_check_count 200
-
-#define __smp_cond_load_relaxed_spinwait(ptr, cond_expr, time_expr_ns, \
- time_limit_ns) ({ \
- typeof(ptr) __PTR = (ptr); \
- __unqual_scalar_typeof(*ptr) VAL; \
- unsigned int __count = 0; \
- for (;;) { \
- VAL = READ_ONCE(*__PTR); \
- if (cond_expr) \
- break; \
- cpu_relax(); \
- if (__count++ < smp_cond_time_check_count) \
- continue; \
- if ((time_expr_ns) >= (time_limit_ns)) \
- break; \
- __count = 0; \
- } \
- (typeof(*ptr))VAL; \
-})
-
-#define __smp_cond_load_acquire_timewait(ptr, cond_expr, \
- time_expr_ns, time_limit_ns) \
-({ \
- typeof(ptr) __PTR = (ptr); \
- __unqual_scalar_typeof(*ptr) VAL; \
- for (;;) { \
- VAL = smp_load_acquire(__PTR); \
- if (cond_expr) \
- break; \
- __cmpwait_relaxed(__PTR, VAL); \
- if ((time_expr_ns) >= (time_limit_ns)) \
- break; \
- } \
- (typeof(*ptr))VAL; \
-})
-
-#define smp_cond_load_acquire_timewait(ptr, cond_expr, \
- time_expr_ns, time_limit_ns) \
-({ \
- __unqual_scalar_typeof(*ptr) _val; \
- int __wfe = arch_timer_evtstrm_available(); \
- \
- if (likely(__wfe)) { \
- _val = __smp_cond_load_acquire_timewait(ptr, cond_expr, \
- time_expr_ns, \
- time_limit_ns); \
- } else { \
- _val = __smp_cond_load_relaxed_spinwait(ptr, cond_expr, \
- time_expr_ns, \
- time_limit_ns); \
- smp_acquire__after_ctrl_dep(); \
- } \
- (typeof(*ptr))_val; \
-})
-
-#endif
-
-#define res_smp_cond_load_acquire(v, c) smp_cond_load_acquire_timewait(v, c, 0, 1)
-
#include <asm-generic/rqspinlock.h>
#endif /* _ASM_RQSPINLOCK_H */
--
2.43.7
^ permalink raw reply related
* Re: [PATCH] dmaengine: mediatek: mtk-uart-apdma: Return -ENOMEM on memory allocation failure
From: Frank Li @ 2026-07-02 3:50 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Vinod Koul, Frank Li, Long Cheng, dmaengine, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260701200703.117929-1-vz@kernel.org>
On Wed, Jul 01, 2026 at 11:07:03PM +0300, Vladimir Zapolskiy wrote:
>
> If dynamic memory allocation in driver's probe function execution fails, it
> should be reported to the driver's framework with -ENOMEM error code.
>
> Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support")
> Signed-off-by: Vladimir Zapolskiy <vz@kernel.org>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/dma/mediatek/mtk-uart-apdma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/mediatek/mtk-uart-apdma.c b/drivers/dma/mediatek/mtk-uart-apdma.c
> index c269d84d7bd2..f74e9a328588 100644
> --- a/drivers/dma/mediatek/mtk-uart-apdma.c
> +++ b/drivers/dma/mediatek/mtk-uart-apdma.c
> @@ -531,7 +531,7 @@ static int mtk_uart_apdma_probe(struct platform_device *pdev)
> for (i = 0; i < mtkd->dma_requests; i++) {
> c = devm_kzalloc(mtkd->ddev.dev, sizeof(*c), GFP_KERNEL);
> if (!c) {
> - rc = -ENODEV;
> + rc = -ENOMEM;
> goto err_no_dma;
> }
>
> --
> 2.51.0
>
^ permalink raw reply
* [PATCH v4 5/6] irqchip/gic-v3-its: Fix grammar and replace a bit number with its symbol
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
Fix grammatical errors in comments and replace the bit offset '62'
with GITS_BASER_INDIRECT for better readability.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 244509701070..120f6f29e978 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -163,7 +163,7 @@ struct event_lpi_map {
/*
* The ITS view of a device - belongs to an ITS, owns an interrupt
- * translation table, and a list of interrupts. If it some of its
+ * translation table, and a list of interrupts. If some of its
* LPIs are injected into a guest (GICv4), the event_map.vm field
* indicates which one.
*/
@@ -2504,7 +2504,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
if ((esz << ids) > (psz * 2)) {
/*
* Find out whether hw supports a single or two-level table by
- * table by reading bit at offset '62' after writing '1' to it.
+ * reading GITS_BASER_INDIRECT after writing '1' to it.
*/
its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
indirect = !!(baser->val & GITS_BASER_INDIRECT);
--
2.36.1
^ permalink raw reply related
* [PATCH v4 2/6] irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
Fix its node leak when its_probe_one() failed in
gic_acpi_parse_madt_its().
Fixes: 9585a495ac936 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node")
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d721b6101e0a..3e4edcb64065 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5747,9 +5747,13 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header,
its->flags |= ITS_FLAGS_FORCE_NON_SHAREABLE;
err = its_probe_one(its);
- if (!err)
- return 0;
+ if (err)
+ goto probe_err;
+
+ return 0;
+probe_err:
+ its_node_destroy(its);
node_err:
iort_deregister_domain_token(its_entry->translation_id);
dom_err:
--
2.36.1
^ permalink raw reply related
* [PATCH v4 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
Multiple ITS units may exist in a system. When an error occurs, it is
difficult to identify which ITS triggered it because most error logs
lack the ITS address. Some logs already include this information and
is useful for debugging. Add the ITS address to the remaining error
logs so that all ITS-related errors can be consistently attributed to
a specific ITS instance.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 8968bedefdba..244509701070 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1120,7 +1120,7 @@ static struct its_cmd_block *its_allocate_entry(struct its_node *its)
while (its_queue_full(its)) {
count--;
if (!count) {
- pr_err_ratelimited("ITS queue not draining\n");
+ pr_err_ratelimited("ITS@%pa queue not draining\n", &its->phys_base);
return NULL;
}
cpu_relax();
@@ -1196,8 +1196,8 @@ static int its_wait_for_range_completion(struct its_node *its,
count--;
if (!count) {
- pr_err_ratelimited("ITS queue timeout (%llu %llu)\n",
- to_idx, linear_idx);
+ pr_err_ratelimited("ITS@%pa queue timeout (%llu %llu)\n",
+ &its->phys_base, to_idx, linear_idx);
return -1;
}
prev_idx = rd_idx;
@@ -1244,7 +1244,7 @@ post: \
raw_spin_unlock_irqrestore(&its->lock, flags); \
\
if (its_wait_for_range_completion(its, rd_idx, next_cmd)) \
- pr_err_ratelimited("ITS cmd %ps failed\n", builder); \
+ pr_err_ratelimited("ITS@%pa cmd %ps failed\n", &its->phys_base, &builder); \
}
static void its_build_sync_cmd(struct its_node *its,
@@ -2411,7 +2411,8 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser,
/* 52bit PA is supported only when PageSize=64K */
if (psz != SZ_64K) {
- pr_err("ITS: no 52bit PA support when psz=%d\n", psz);
+ pr_err("ITS@%pa: no 52bit PA support when psz=%d\n",
+ &its->phys_base, psz);
its_free_pages(base, order);
return -ENXIO;
}
@@ -5183,7 +5184,7 @@ static int its_init_vpe_domain(void)
vpe_proxy.dev = its_create_device(its, devid, entries, false);
if (!vpe_proxy.dev) {
kfree(vpe_proxy.vpes);
- pr_err("ITS: Can't allocate GICv4 proxy device\n");
+ pr_err("ITS@%pa: Can't allocate GICv4 proxy device\n", &its->phys_base);
return -ENOMEM;
}
--
2.36.1
^ permalink raw reply related
* [PATCH v4 3/6] irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
When its_irq_gic_domain_alloc() fails, the following
its_vpe_irq_domain_free() skips calling its_vep_teardown() for the
corresponding irq. Call its_vpe_teardown() when its_irq_gic_domain_alloc()
is failedto avoid the leak issue.
Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown")
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3e4edcb64065..8968bedefdba 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4666,8 +4666,10 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq
break;
err = its_irq_gic_domain_alloc(domain, virq + i,
vm->vpes[i]->vpe_db_lpi);
- if (err)
+ if (err) {
+ its_vpe_teardown(vm->vpes[i]);
break;
+ }
irq_domain_set_hwirq_and_chip(domain, virq + i, i,
irqchip, vm->vpes[i]);
set_bit(i, bitmap);
--
2.36.1
^ permalink raw reply related
* [PATCH v4 6/6] irqchip/gic-v3-its: Remove redundant check in its_vpe_db_proxy_unmap_locked()
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
The high level functions already ensure that gic_rdists->has_rvpeid
is false before calling its_vpe_db_proxy_unmap_locked(), so we can
remove the redundant check in its_vpe_db_proxy_unmap_locked()
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 120f6f29e978..b0069fbe1e69 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3801,10 +3801,6 @@ static const struct irq_domain_ops its_domain_ops = {
*/
static void its_vpe_db_proxy_unmap_locked(struct its_vpe *vpe)
{
- /* GICv4.1 doesn't use a proxy, so nothing to do here */
- if (gic_rdists->has_rvpeid)
- return;
-
/* Already unmapped? */
if (vpe->vpe_proxy_event == -1)
return;
--
2.36.1
^ permalink raw reply related
* [PATCH v4 0/6] Some Minor fixes and cleanups to irqchip/gic-v3-its
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
There are some random fixes and cleanups to irqchip/gic-v3-its. More
details can be found in respective patches.
Thanks.
v1->v2:
- Drop unneeded patches and some minor improvement.
v2->v3:
- Fix an extra leak issue in its_vpe_irq_domain_alloc().
- Remove redundant check in its_vpe_db_proxy_unmap_locked()
v3->v4:
- Add missing Fixes tags
- Improve changelog description
Kemeng Shi (6):
irqchip/gic-v3-its: Fix memleak in its_probe_one()
irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
irqchip/gic-v3-its: Fix leak in its_vpe_irq_domain_alloc()
irqchip/gic-v3-its: Add ITS address info in more error logs
irqchip/gic-v3-its: Fix grammar and replace a bit number with its
symbol
irqchip/gic-v3-its: Remove redundant check in
its_vpe_db_proxy_unmap_locked()
drivers/irqchip/irq-gic-v3-its.c | 37 ++++++++++++++++++--------------
1 file changed, 21 insertions(+), 16 deletions(-)
--
2.36.1
^ permalink raw reply
* [PATCH v4 1/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-07-02 3:30 UTC (permalink / raw)
To: maz, tglx, jason, lpieralisi; +Cc: linux-arm-kernel, linux-kernel, Kemeng Shi
In-Reply-To: <20260702033050.1583-1-shikemeng@huaweicloud.com>
Fix collection leak when its_init_domain() failed in its_probe_one().
Fixes: 4c21f3c26ecc2 ("irqchip: GICv3: ITS: DT probing and initialization")
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8d..d721b6101e0a 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5326,7 +5326,7 @@ static int __init its_probe_one(struct its_node *its)
err = its_init_domain(its);
if (err)
- goto out_free_tables;
+ goto out_free_col;
raw_spin_lock(&its_lock);
list_add(&its->entry, &its_nodes);
@@ -5334,6 +5334,8 @@ static int __init its_probe_one(struct its_node *its)
return 0;
+out_free_col:
+ kfree(its->collections);
out_free_tables:
its_free_tables(its);
out_free_cmd:
--
2.36.1
^ permalink raw reply related
* [PATCH v2 net-next 14/14] net: enetc: use kzalloc_flex() for enetc_psfp_gate allocation
From: wei.fang @ 2026-07-02 2:57 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Replace the open-coded struct_size() + kzalloc() pattern with the
kzalloc_flex() helper when allocating struct enetc_psfp_gate. This
removes the intermediate entries_size local variable and makes the
allocation site more concise.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc_qos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index 7b17bca24f26..2aa0fcaafcd2 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -1135,7 +1135,6 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
struct flow_action_entry *entry;
struct action_gate_entry *e;
u8 sfi_overwrite = 0;
- int entries_size;
int i, err;
if (f->common.chain_index >= priv->psfp_cap.max_streamid) {
@@ -1242,8 +1241,7 @@ static int enetc_psfp_parse_clsflower(struct enetc_ndev_priv *priv,
goto free_filter;
}
- entries_size = struct_size(sgi, entries, entryg->gate.num_entries);
- sgi = kzalloc(entries_size, GFP_KERNEL);
+ sgi = kzalloc_flex(*sgi, entries, entryg->gate.num_entries);
if (!sgi) {
err = -ENOMEM;
goto free_filter;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 net-next 13/14] net: enetc: use alloc_etherdev_mqs() to create netdev for VF driver
From: wei.fang @ 2026-07-02 2:57 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
The VF driver uses alloc_etherdev_mq() with ENETC_MAX_NUM_TXQS as the
queue count, which forces the TX and RX queue counts to be equal and
uses a compile-time constant rather than the actual hardware capability.
After enetc_get_si_caps() is called, si->num_tx_rings and
si->num_rx_rings reflect the actual number of rings assigned to the VF
by the PF. For the ENETC VF on LS1028A and the upcoming i.MX95/94, their
SoCs have no more than 6 CPUs, and the number of TX/RX rings allocated
to the VF is less than 8.
Therefore, switch to alloc_etherdev_mqs() so that the TX and RX queue
counts are set independently based on the real hardware values, avoiding
unnecessary queue structure allocation when the VF has fewer rings than
ENETC_MAX_NUM_TXQS.
Note that if future SoCs have more than 6 CPUs and more than 6 RX rings
allocated to VFs, the size of the int_vector array in struct
enetc_ndev_priv will need to be modified. Similarly, if more than 8 TX
rings are allocated to each int_vector, ENETC_MAX_NUM_TXQS will also
need to be modified.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc_vf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
index 9cdb0a4d6baf..3df515a6e333 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
@@ -317,7 +317,8 @@ static int enetc_vf_probe(struct pci_dev *pdev,
enetc_get_si_caps(si);
- ndev = alloc_etherdev_mq(sizeof(*priv), ENETC_MAX_NUM_TXQS);
+ ndev = alloc_etherdev_mqs(sizeof(*priv), si->num_tx_rings,
+ si->num_rx_rings);
if (!ndev) {
err = -ENOMEM;
dev_err(&pdev->dev, "netdev creation failed\n");
--
2.34.1
^ permalink raw reply related
* [PATCH v2 net-next 12/14] net: enetc: remove redundant num_vsi field from enetc_port_caps
From: wei.fang @ 2026-07-02 2:57 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, wei.fang, chleroy
Cc: imx, netdev, linux-kernel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260702025714.456233-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
The num_vsi field in struct enetc_port_caps is populated by reading the
NUM_VSI field of the ECAPR1 register, which reports the number of VSIs
supported by the ENETC4 port. This value is equivalent to the total
number of VFs reported by the PCI SR-IOV capability, which is already
stored in pf->total_vfs during probe via pci_sriov_get_totalvfs().
Since pf->total_vfs carries the same information and is already
available throughout the driver, there is no need to read and cache
num_vsi separately in the port capabilities structure. Remove the
num_vsi field from enetc_port_caps and the associated ECAPR1_NUM_VSI
macro, and replace all uses of pf->caps.num_vsi with pf->total_vfs in
the ring allocation, MSI-X configuration, SI enable, and debugfs code
paths.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
.../ethernet/freescale/enetc/enetc4_debugfs.c | 13 +++----
.../net/ethernet/freescale/enetc/enetc4_hw.h | 1 -
.../net/ethernet/freescale/enetc/enetc4_pf.c | 37 +++++++++----------
.../net/ethernet/freescale/enetc/enetc_pf.h | 1 -
4 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
index be378bf8f74d..5029038bf99f 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
@@ -28,17 +28,14 @@ static void enetc_show_si_mac_hash_filter(struct seq_file *s, int i)
static int enetc_mac_filter_show(struct seq_file *s, void *data)
{
- struct enetc_si *si = s->private;
- struct enetc_hw *hw = &si->hw;
+ struct enetc_pf *pf = enetc_si_priv(s->private);
+ struct enetc_hw *hw = &pf->si->hw;
+ int num_si = pf->total_vfs + 1;
struct maft_entry_data maft;
struct ntmp_user *user;
- struct enetc_pf *pf;
u32 val, entry_id;
- int i, num_si;
int err = 0;
-
- pf = enetc_si_priv(si);
- num_si = pf->caps.num_vsi + 1;
+ int i;
val = enetc_port_rd(hw, ENETC4_PSIPMMR);
for (i = 0; i < num_si; i++) {
@@ -52,7 +49,7 @@ static int enetc_mac_filter_show(struct seq_file *s, void *data)
for (i = 0; i < num_si; i++)
enetc_show_si_mac_hash_filter(s, i);
- user = &si->ntmp_user;
+ user = &pf->si->ntmp_user;
rtnl_lock();
if (bitmap_empty(user->maft_eid_bitmap, user->maft_num_entries))
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
index 7a3ccc94b036..72b54fe02e65 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_hw.h
@@ -50,7 +50,6 @@
#define ECAPR1_NUM_MCH GENMASK(9, 8)
#define ECAPR1_NUM_UCH GENMASK(11, 10)
#define ECAPR1_NUM_MSIX GENMASK(22, 12)
-#define ECAPR1_NUM_VSI GENMASK(27, 24)
#define ECAPR1_NUM_IPV BIT(31)
#define ENETC4_ECAPR2 0x8
diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
index d919a8645fb1..c47ee2049aac 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc4_pf.c
@@ -23,7 +23,6 @@ static void enetc4_get_port_caps(struct enetc_pf *pf)
u32 val;
val = enetc_port_rd(hw, ENETC4_ECAPR1);
- pf->caps.num_vsi = (val & ECAPR1_NUM_VSI) >> 24;
pf->caps.num_msix = ((val & ECAPR1_NUM_MSIX) >> 12) + 1;
val = enetc_port_rd(hw, ENETC4_ECAPR2);
@@ -258,34 +257,35 @@ static void enetc4_default_rings_allocation(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
u32 num_rx_bdr, num_tx_bdr, val;
+ int num_vfs = pf->total_vfs;
u32 vf_tx_bdr, vf_rx_bdr;
int i, rx_rem, tx_rem;
- if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
- num_rx_bdr = pf->caps.num_rx_bdr - pf->caps.num_vsi;
+ if (pf->caps.num_rx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
+ num_rx_bdr = pf->caps.num_rx_bdr - num_vfs;
else
num_rx_bdr = ENETC_SI_MAX_RING_NUM;
- if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + pf->caps.num_vsi)
- num_tx_bdr = pf->caps.num_tx_bdr - pf->caps.num_vsi;
+ if (pf->caps.num_tx_bdr < ENETC_SI_MAX_RING_NUM + num_vfs)
+ num_tx_bdr = pf->caps.num_tx_bdr - num_vfs;
else
num_tx_bdr = ENETC_SI_MAX_RING_NUM;
val = enetc4_psicfgr0_val_construct(false, num_tx_bdr, num_rx_bdr);
enetc_port_wr(hw, ENETC4_PSICFGR0(0), val);
- if (!pf->caps.num_vsi)
+ if (!num_vfs)
return;
num_rx_bdr = pf->caps.num_rx_bdr - num_rx_bdr;
- rx_rem = num_rx_bdr % pf->caps.num_vsi;
- num_rx_bdr = num_rx_bdr / pf->caps.num_vsi;
+ rx_rem = num_rx_bdr % num_vfs;
+ num_rx_bdr = num_rx_bdr / num_vfs;
num_tx_bdr = pf->caps.num_tx_bdr - num_tx_bdr;
- tx_rem = num_tx_bdr % pf->caps.num_vsi;
- num_tx_bdr = num_tx_bdr / pf->caps.num_vsi;
+ tx_rem = num_tx_bdr % num_vfs;
+ num_tx_bdr = num_tx_bdr / num_vfs;
- for (i = 0; i < pf->caps.num_vsi; i++) {
+ for (i = 0; i < num_vfs; i++) {
vf_tx_bdr = (i < tx_rem) ? num_tx_bdr + 1 : num_tx_bdr;
vf_rx_bdr = (i < rx_rem) ? num_rx_bdr + 1 : num_rx_bdr;
val = enetc4_psicfgr0_val_construct(true, vf_tx_bdr, vf_rx_bdr);
@@ -302,26 +302,25 @@ static void enetc4_allocate_si_rings(struct enetc_pf *pf)
static void enetc4_set_si_msix_num(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
- int i, num_msix, total_si;
+ int num_si = pf->total_vfs + 1;
+ int i, num_msix;
u32 val;
- total_si = pf->caps.num_vsi + 1;
-
- num_msix = pf->caps.num_msix / total_si +
- pf->caps.num_msix % total_si - 1;
+ num_msix = pf->caps.num_msix / num_si +
+ pf->caps.num_msix % num_si - 1;
val = num_msix & PSICFGR2_NUM_MSIX;
enetc_port_wr(hw, ENETC4_PSICFGR2(0), val);
- num_msix = pf->caps.num_msix / total_si - 1;
+ num_msix = pf->caps.num_msix / num_si - 1;
val = num_msix & PSICFGR2_NUM_MSIX;
- for (i = 0; i < pf->caps.num_vsi; i++)
+ for (i = 0; i < pf->total_vfs; i++)
enetc_port_wr(hw, ENETC4_PSICFGR2(i + 1), val);
}
static void enetc4_enable_all_si(struct enetc_pf *pf)
{
struct enetc_hw *hw = &pf->si->hw;
- int num_si = pf->caps.num_vsi + 1;
+ int num_si = pf->total_vfs + 1;
u32 si_bitmap = 0;
int i;
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
index 574ab4e76d8b..9c36ba50a7f0 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
@@ -18,7 +18,6 @@ struct enetc_vf_state {
struct enetc_port_caps {
u32 half_duplex:1;
- int num_vsi;
int num_msix;
int num_rx_bdr;
int num_tx_bdr;
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox