* [PATCH v1 0/6] perf vendor events intel: update
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
Sync with the latest perfmon events from:
https://github.com/intel/perfmon
by running the script:
https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py
and copying the resulting json and mapfile.csv changes into the perf
tree.
Chun-Tse Shao (6):
perf vendor events intel: Update arrowlake events from 1.17 to 1.19
perf vendor events intel: Update emeraldrapids events from 1.23 to
1.24
perf vendor events intel: Update graniterapids events from 1.18 to
1.19
perf vendor events intel: Update lunarlake events from 1.22 to 1.25
perf vendor events intel: Update pantherlake events from 1.05 to 1.06
perf vendor events intel: Update tigerlake events from 1.18 to 1.19
.../pmu-events/arch/x86/arrowlake/cache.json | 30 ++-
.../arch/x86/arrowlake/floating-point.json | 45 ++++
.../pmu-events/arch/x86/arrowlake/memory.json | 18 ++
.../arch/x86/arrowlake/pipeline.json | 129 +++++++++-
.../arch/x86/emeraldrapids/cache.json | 9 +
.../graniterapids/uncore-interconnect.json | 10 +
.../arch/x86/graniterapids/uncore-memory.json | 2 +-
.../pmu-events/arch/x86/lunarlake/cache.json | 2 +-
.../arch/x86/lunarlake/pipeline.json | 27 ++-
.../arch/x86/lunarlake/uncore-memory.json | 208 ++++++++++++++++-
tools/perf/pmu-events/arch/x86/mapfile.csv | 12 +-
.../arch/x86/pantherlake/counter.json | 5 +
.../arch/x86/pantherlake/pipeline.json | 29 ++-
.../x86/pantherlake/uncore-interconnect.json | 10 +
.../arch/x86/pantherlake/uncore-memory.json | 221 +++++++++++++++++-
15 files changed, 728 insertions(+), 29 deletions(-)
create mode 100644 tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply
* [v8 PATCH] arm64: mm: show direct mapping use in /proc/meminfo
From: Yang Shi @ 2026-06-09 21:42 UTC (permalink / raw)
To: catalin.marinas, will, ryan.roberts, cl
Cc: yang, linux-arm-kernel, linux-kernel
Since commit a166563e7ec3 ("arm64: mm: support large block mapping when
rodata=full"), the direct mapping may be split on some machines instead
keeping static since boot. It makes more sense to show the direct mapping
use in /proc/meminfo than before.
This patch will make /proc/meminfo show the direct mapping use like the
below (4K base page size):
DirectMap4K: 94792 kB
DirectMap64K: 134208 kB
DirectMap2M: 1173504 kB
DirectMap32M: 5636096 kB
DirectMap1G: 529530880 kB
Although just the machines which support BBML2_NOABORT can split the
direct mapping, show it on all machines regardless of BBML2_NOABORT so
that the users have consistent view in order to avoid confusion.
Although ptdump also can tell the direct map use, but it needs to dump
the whole kernel page table. It is costly and overkilling. It is also
in debugfs which may not be enabled by all distros. So showing direct
map use in /proc/meminfo seems more convenient and has less overhead.
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
---
arch/arm64/mm/mmu.c | 200 +++++++++++++++++++++++++++++++++++++++-----
1 file changed, 179 insertions(+), 21 deletions(-)
v8: * Fixed the double accounting per Sashiko
* Responded the review comments from Sashiko
v7: * Rebased to v7.1-rc4
* Changed "dm" to "lm" to follow ARM convention per Will
* Used __is_lm_alias() instead of reinventing a new helper per Will
v6: * Rebased to v7.0-rc3
* Rebased on top of Anshuman's v5 "arm64/mm: Enable batched TLB flush
in unmap_hotplug_range()"
* Used const for direct map type array per Will
* Defined PUD size for 16K/64K even though it is not used per Will
* Removed the misleading comment in init_pmd() per Will
v5: * Rebased to v6.19-rc4
* Fixed the build error for !CONFIG_PROC_FS
v4: * Used PAGE_END instead of _PAGE_END(VA_BITS_MIN) per Ryan
* Used shorter name for the helpers and variables per Ryan
* Fixed accounting for memory hotunplug
v3: * Fixed the over-accounting problems per Ryan
* Introduced helpers for add/sub direct map use and #ifdef them with
CONFIG_PROC_FS per Ryan
* v3 is a fix patch on top of v2
v2: * Counted in size instead of the number of entries per Ryan
* Removed shift array per Ryan
* Use lower case "k" per Ryan
* Fixed a couple of build warnings reported by kernel test robot
* Fixed a couple of poential miscounts
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dd85e093ffdb..783a473c71ed 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -29,6 +29,7 @@
#include <linux/mm_inline.h>
#include <linux/pagewalk.h>
#include <linux/stop_machine.h>
+#include <linux/proc_fs.h>
#include <asm/barrier.h>
#include <asm/cputype.h>
@@ -164,6 +165,82 @@ static void init_clear_pgtable(void *table)
dsb(ishst);
}
+enum lm_type {
+ PTE,
+ CONT_PTE,
+ PMD,
+ CONT_PMD,
+ PUD,
+ NR_LM_TYPE,
+};
+
+#ifdef CONFIG_PROC_FS
+static unsigned long lm_meminfo[NR_LM_TYPE];
+
+void arch_report_meminfo(struct seq_file *m)
+{
+ const char *size[NR_LM_TYPE];
+
+#if defined(CONFIG_ARM64_4K_PAGES)
+ size[PTE] = "4k";
+ size[CONT_PTE] = "64k";
+ size[PMD] = "2M";
+ size[CONT_PMD] = "32M";
+ size[PUD] = "1G";
+#elif defined(CONFIG_ARM64_16K_PAGES)
+ size[PTE] = "16k";
+ size[CONT_PTE] = "2M";
+ size[PMD] = "32M";
+ size[CONT_PMD] = "1G";
+ size[PUD] = "64G";
+#elif defined(CONFIG_ARM64_64K_PAGES)
+ size[PTE] = "64k";
+ size[CONT_PTE] = "2M";
+ size[PMD] = "512M";
+ size[CONT_PMD] = "16G";
+ size[PUD] = "4T";
+#endif
+
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PTE], lm_meminfo[PTE] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[CONT_PTE],
+ lm_meminfo[CONT_PTE] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PMD], lm_meminfo[PMD] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[CONT_PMD],
+ lm_meminfo[CONT_PMD] >> 10);
+ if (pud_sect_supported())
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PUD], lm_meminfo[PUD] >> 10);
+}
+
+static inline void lm_meminfo_add(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+ if (__is_lm_address(addr))
+ lm_meminfo[type] += size;
+}
+
+static inline void lm_meminfo_sub(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+ if (__is_lm_address(addr))
+ lm_meminfo[type] -= size;
+}
+#else
+static inline void lm_meminfo_add(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+}
+
+static inline void lm_meminfo_sub(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+}
+#endif
+
static void init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot)
{
@@ -219,6 +296,7 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
do {
pgprot_t __prot = prot;
+ bool count_lm = pte_none(__ptep_get(ptep));
next = pte_cont_addr_end(addr, end);
@@ -229,6 +307,13 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
init_pte(ptep, addr, next, phys, __prot);
+ if (count_lm) {
+ if (pgprot_val(__prot) & PTE_CONT)
+ lm_meminfo_add(addr, (next - addr), CONT_PTE);
+ else
+ lm_meminfo_add(addr, (next - addr), PTE);
+ }
+
ptep += pte_index(next) - pte_index(addr);
phys += next - addr;
} while (addr = next, addr != end);
@@ -251,6 +336,7 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
do {
pmd_t old_pmd = READ_ONCE(*pmdp);
+ bool count_lm = pmd_none(old_pmd);
next = pmd_addr_end(addr, end);
@@ -259,6 +345,12 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
(flags & NO_BLOCK_MAPPINGS) == 0) {
pmd_set_huge(pmdp, phys, prot);
+ if (count_lm) {
+ if (pgprot_val(prot) & PTE_CONT)
+ lm_meminfo_add(addr, (next - addr), CONT_PMD);
+ else
+ lm_meminfo_add(addr, (next - addr), PMD);
+ }
/*
* After the PMD entry has been populated once, we
* only allow updates to the permission attributes.
@@ -371,6 +463,7 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
do {
pud_t old_pud = READ_ONCE(*pudp);
+ bool count_lm = pud_none(old_pud);
next = pud_addr_end(addr, end);
@@ -382,6 +475,8 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
(flags & NO_BLOCK_MAPPINGS) == 0) {
pud_set_huge(pudp, phys, prot);
+ if (count_lm)
+ lm_meminfo_add(addr, (next - addr), PUD);
/*
* After the PUD entry has been populated once, we
* only allow updates to the permission attributes.
@@ -571,16 +666,21 @@ pgd_pgtable_alloc_special_mm(enum pgtable_level pgtable_level)
return __pgd_pgtable_alloc(NULL, GFP_PGTABLE_KERNEL, pgtable_level);
}
-static void split_contpte(pte_t *ptep)
+static void split_contpte(unsigned long addr, pte_t *ptep)
{
int i;
+ lm_meminfo_sub(addr, CONT_PTE_SIZE, CONT_PTE);
+
ptep = PTR_ALIGN_DOWN(ptep, sizeof(*ptep) * CONT_PTES);
for (i = 0; i < CONT_PTES; i++, ptep++)
__set_pte(ptep, pte_mknoncont(__ptep_get(ptep)));
+
+ lm_meminfo_add(addr, CONT_PTE_SIZE, PTE);
}
-static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
+static int split_pmd(unsigned long addr, pmd_t *pmdp, pmd_t pmd, gfp_t gfp,
+ bool to_cont)
{
pmdval_t tableprot = PMD_TYPE_TABLE | PMD_TABLE_UXN | PMD_TABLE_AF;
unsigned long pfn = pmd_pfn(pmd);
@@ -604,8 +704,13 @@ static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
if (to_cont)
prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+ lm_meminfo_sub(addr, PMD_SIZE, PMD);
for (i = 0; i < PTRS_PER_PTE; i++, ptep++, pfn++)
__set_pte(ptep, pfn_pte(pfn, prot));
+ if (to_cont)
+ lm_meminfo_add(addr, PMD_SIZE, CONT_PTE);
+ else
+ lm_meminfo_add(addr, PMD_SIZE, PTE);
/*
* Ensure the pte entries are visible to the table walker by the time
@@ -617,16 +722,21 @@ static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
return 0;
}
-static void split_contpmd(pmd_t *pmdp)
+static void split_contpmd(unsigned long addr, pmd_t *pmdp)
{
int i;
+ lm_meminfo_sub(addr, CONT_PMD_SIZE, CONT_PMD);
+
pmdp = PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS);
for (i = 0; i < CONT_PMDS; i++, pmdp++)
set_pmd(pmdp, pmd_mknoncont(pmdp_get(pmdp)));
+
+ lm_meminfo_add(addr, CONT_PMD_SIZE, PMD);
}
-static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
+static int split_pud(unsigned long addr, pud_t *pudp, pud_t pud, gfp_t gfp,
+ bool to_cont)
{
pudval_t tableprot = PUD_TYPE_TABLE | PUD_TABLE_UXN | PUD_TABLE_AF;
unsigned int step = PMD_SIZE >> PAGE_SHIFT;
@@ -651,8 +761,13 @@ static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
if (to_cont)
prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+ lm_meminfo_sub(addr, PUD_SIZE, PUD);
for (i = 0; i < PTRS_PER_PMD; i++, pmdp++, pfn += step)
set_pmd(pmdp, pfn_pmd(pfn, prot));
+ if (to_cont)
+ lm_meminfo_add(addr, PUD_SIZE, CONT_PMD);
+ else
+ lm_meminfo_add(addr, PUD_SIZE, PMD);
/*
* Ensure the pmd entries are visible to the table walker by the time
@@ -707,7 +822,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
if (!pud_present(pud))
goto out;
if (pud_leaf(pud)) {
- ret = split_pud(pudp, pud, GFP_PGTABLE_KERNEL, true);
+ ret = split_pud(addr, pudp, pud, GFP_PGTABLE_KERNEL, true);
if (ret)
goto out;
}
@@ -725,14 +840,14 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
goto out;
if (pmd_leaf(pmd)) {
if (pmd_cont(pmd))
- split_contpmd(pmdp);
+ split_contpmd(addr, pmdp);
/*
* PMD: If addr is PMD aligned then addr already describes a
* leaf boundary. Otherwise, split to contpte.
*/
if (ALIGN_DOWN(addr, PMD_SIZE) == addr)
goto out;
- ret = split_pmd(pmdp, pmd, GFP_PGTABLE_KERNEL, true);
+ ret = split_pmd(addr, pmdp, pmd, GFP_PGTABLE_KERNEL, true);
if (ret)
goto out;
}
@@ -749,7 +864,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
if (!pte_present(pte))
goto out;
if (pte_cont(pte))
- split_contpte(ptep);
+ split_contpte(addr, ptep);
out:
return ret;
@@ -856,7 +971,7 @@ static int split_to_ptes_pud_entry(pud_t *pudp, unsigned long addr,
int ret = 0;
if (pud_leaf(pud))
- ret = split_pud(pudp, pud, gfp, false);
+ ret = split_pud(addr, pudp, pud, gfp, false);
return ret;
}
@@ -870,8 +985,8 @@ static int split_to_ptes_pmd_entry(pmd_t *pmdp, unsigned long addr,
if (pmd_leaf(pmd)) {
if (pmd_cont(pmd))
- split_contpmd(pmdp);
- ret = split_pmd(pmdp, pmd, gfp, false);
+ split_contpmd(addr, pmdp);
+ ret = split_pmd(addr, pmdp, pmd, gfp, false);
/*
* We have split the pmd directly to ptes so there is no need to
@@ -889,7 +1004,7 @@ static int split_to_ptes_pte_entry(pte_t *ptep, unsigned long addr,
pte_t pte = __ptep_get(ptep);
if (pte_cont(pte))
- split_contpte(ptep);
+ split_contpte(addr, ptep);
return 0;
}
@@ -1463,20 +1578,20 @@ static bool pgtable_range_aligned(unsigned long start, unsigned long end,
return true;
}
-static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
+static void unmap_hotplug_pte_range(pte_t *ptep, unsigned long addr,
unsigned long end, bool free_mapped,
struct vmem_altmap *altmap)
{
- pte_t *ptep, pte;
+ pte_t pte;
do {
- ptep = pte_offset_kernel(pmdp, addr);
pte = __ptep_get(ptep);
if (pte_none(pte))
continue;
WARN_ON(!pte_present(pte));
__pte_clear(&init_mm, addr, ptep);
+ lm_meminfo_sub(addr, PAGE_SIZE, PTE);
if (free_mapped) {
/* CONT blocks are not supported in the vmemmap */
WARN_ON(pte_cont(pte));
@@ -1485,19 +1600,39 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
PAGE_SIZE, altmap);
}
/* unmap_hotplug_range() flushes TLB for !free_mapped */
- } while (addr += PAGE_SIZE, addr < end);
+ } while (ptep++, addr += PAGE_SIZE, addr < end);
+}
+
+static void unmap_hotplug_cont_pte_range(pmd_t *pmdp, unsigned long addr,
+ unsigned long end, bool free_mapped,
+ struct vmem_altmap *altmap)
+{
+ unsigned long next;
+ pte_t *ptep, pte;
+
+ do {
+ next = pte_cont_addr_end(addr, end);
+ ptep = pte_offset_kernel(pmdp, addr);
+ pte = __ptep_get(ptep);
+
+ if (pte_present(pte) && pte_cont(pte)) {
+ lm_meminfo_sub(addr, CONT_PTE_SIZE, CONT_PTE);
+ lm_meminfo_add(addr, CONT_PTE_SIZE, PTE);
+ }
+
+ unmap_hotplug_pte_range(ptep, addr, next, free_mapped, altmap);
+ } while (addr = next, addr < end);
}
-static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
+static void unmap_hotplug_pmd_range(pmd_t *pmdp, unsigned long addr,
unsigned long end, bool free_mapped,
struct vmem_altmap *altmap)
{
unsigned long next;
- pmd_t *pmdp, pmd;
+ pmd_t pmd;
do {
next = pmd_addr_end(addr, end);
- pmdp = pmd_offset(pudp, addr);
pmd = READ_ONCE(*pmdp);
if (pmd_none(pmd))
continue;
@@ -1505,6 +1640,7 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
WARN_ON(!pmd_present(pmd));
if (pmd_leaf(pmd)) {
pmd_clear(pmdp);
+ lm_meminfo_sub(addr, PMD_SIZE, PMD);
if (free_mapped) {
/* CONT blocks are not supported in the vmemmap */
WARN_ON(pmd_cont(pmd));
@@ -1516,7 +1652,28 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
continue;
}
WARN_ON(!pmd_table(pmd));
- unmap_hotplug_pte_range(pmdp, addr, next, free_mapped, altmap);
+ unmap_hotplug_cont_pte_range(pmdp, addr, next, free_mapped, altmap);
+ } while (pmdp++, addr = next, addr < end);
+}
+
+static void unmap_hotplug_cont_pmd_range(pud_t *pudp, unsigned long addr,
+ unsigned long end, bool free_mapped,
+ struct vmem_altmap *altmap)
+{
+ unsigned long next;
+ pmd_t *pmdp, pmd;
+
+ do {
+ next = pmd_cont_addr_end(addr, end);
+ pmdp = pmd_offset(pudp, addr);
+ pmd = READ_ONCE(*pmdp);
+
+ if (pmd_leaf(pmd) && pmd_cont(pmd)) {
+ lm_meminfo_sub(addr, CONT_PMD_SIZE, CONT_PMD);
+ lm_meminfo_add(addr, CONT_PMD_SIZE, PMD);
+ }
+
+ unmap_hotplug_pmd_range(pmdp, addr, next, free_mapped, altmap);
} while (addr = next, addr < end);
}
@@ -1537,6 +1694,7 @@ static void unmap_hotplug_pud_range(p4d_t *p4dp, unsigned long addr,
WARN_ON(!pud_present(pud));
if (pud_leaf(pud)) {
pud_clear(pudp);
+ lm_meminfo_sub(addr, PUD_SIZE, PUD);
if (free_mapped) {
flush_tlb_kernel_range(addr, addr + PUD_SIZE);
free_hotplug_page_range(pud_page(pud),
@@ -1546,7 +1704,7 @@ static void unmap_hotplug_pud_range(p4d_t *p4dp, unsigned long addr,
continue;
}
WARN_ON(!pud_table(pud));
- unmap_hotplug_pmd_range(pudp, addr, next, free_mapped, altmap);
+ unmap_hotplug_cont_pmd_range(pudp, addr, next, free_mapped, altmap);
} while (addr = next, addr < end);
}
--
2.47.0
^ permalink raw reply related
* arm64: tlbflush: Reset active_cpu on ASID rollover
From: sk @ 2026-06-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Andrew Morton, David Hildenbrand, Anshuman Khandual,
Mike Rapoport, Dev Jain, Kevin Brodsky, Marc Zyngier,
Oliver Upton, cl
Hi all,
This series is based on arm64: tlbflush: Don't broadcast if mm was only active on local cpu, specifically
on commit(s) starting from https://lore.kernel.org/linux-arm-kernel/20260523134710.3827956-1-linu.cherian@arm.com/.
Changes since the previous posting:
* Reset active_cpu to ACTIVE_CPU_NONE when a new ASID is assigned after rollover, so we don’t remain stuck in ACTIVE_CPU_MULTIPLE when the workload later settles back to one CPU.
* Rely on the fact that flush_context() already issues a global TLB flush at ASID assignment after rollover, ensuring there are no stale TLB entries on any CPU.
* This restores a fresh chance for processes to take the local-only flush fast path after each ASID generation rollover.
Series overview:
* Patch 1/2: arm64: tlbflush: Reset active_cpu on ASID rollover
* Patch 2/2: arm64: tlbflush: Don't broadcast if mm was only active on local cpu
Thanks,
Sayali Kulkarni
sskulkarni@amperecomputing.com (Ampere)
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-06-09 21:31 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, krzk+dt, conor+dt, linusw,
brgl, arnd, gregkh, Daniel Thompson, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605144758.GB3659201-robh@kernel.org>
On 6/5/26 9:47 AM, Rob Herring wrote:
> On Thu, Jun 04, 2026 at 08:00:20PM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
>> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
>> that can be accessed, along with several other peripherals, via two
>> PCIe endpoint functions. There is a main driver for the endpoint that
>> decomposes things and creates auxiliary bus devices to model the SoC.
>>
>> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
>> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
>> MSIs.
>>
>> Add a driver for the eMAC/MSIGEN combination.
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>
> The order is wrong here unless you worked on it and then Daniel took
> over. Tags should be chronological order.
I think this was a dumb reorder I did to address a complaint
from checkpatch, but in any case I'll fix this. Yes, my
signoff should "wrap" the others.
>> ---
>> MAINTAINERS | 2 +
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 14 +
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +
>> .../ethernet/stmicro/stmmac/dwmac-tc956x.c | 818 ++++++++++++++++++
>> 4 files changed, 836 insertions(+)
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0439607d1155f..418537cbefbbb 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -27059,6 +27059,8 @@ S: Maintained
>> F: Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
>> F: drivers/gpio/gpio-tc956x.c
>> F: drivers/misc/tc956x_pci.c
>> +F: drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> +F: include/soc/toshiba/tc956x-dwmac.h
>>
>> TOSHIBA WMI HOTKEYS DRIVER
>> M: Azael Avalos <coproscefalo@gmail.com>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> index e3dd5adda5aca..8d247e033e356 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> @@ -404,6 +404,20 @@ config DWMAC_MOTORCOMM
>> This enables glue driver for Motorcomm DWMAC-based PCI Ethernet
>> controllers. Currently only YT6801 is supported.
>>
>> +config DWMAC_TC956X
>> + tristate "Toshiba TC956X DWMAC support"
>> + depends on PCI
>> + depends on COMMON_CLK
>> + depends on TOSHIBA_TC956X_PCI
>> + default TOSHIBA_TC956X_PCI
>> + select GENERIC_IRQ_CHIP
>> + help
>> + This selects the Toshiba TC956X (and Qualcomm QPS615) support in the
>> + stmmac driver.
>> +
>> + This provides support for the ethernet controllers found on these
>> + devices.
>> +
>> config STMMAC_PCI
>> tristate "STMMAC PCI bus support"
>> depends on PCI
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index a1cea2f57252e..e8e7f95dbe3e8 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -51,4 +51,6 @@ obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
>> obj-$(CONFIG_DWMAC_INTEL) += dwmac-intel.o
>> obj-$(CONFIG_DWMAC_LOONGSON) += dwmac-loongson.o
>> obj-$(CONFIG_DWMAC_MOTORCOMM) += dwmac-motorcomm.o
>> +obj-$(CONFIG_TC956X_PCI) += tc956x-pci.o
>> +obj-$(CONFIG_DWMAC_TC956X) += dwmac-tc956x.o
>> stmmac-pci-objs:= stmmac_pci.o
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> new file mode 100644
>> index 0000000000000..c77585e4a50e6
>> --- /dev/null
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> @@ -0,0 +1,818 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/*
>> + * Copyright (C) 2026 by RISCstar Solutions Corporation. All rights reserved.
>> + *
>> + * Derived from code having the following copyrights:
>> + * Copyright (C) 2011-2012 Vayavya Labs Pvt Ltd
>> + * Copyright (C) 2025 Toshiba Electronic Devices & Storage Corporation
>> + */
>> +
>> +#include <linux/auxiliary_bus.h>
>
> Based on the block diagram, these are PCI devices. Auxiliary bus is the
> wrong thing to use here.
As I said in the other message, I'm going to rearrange this
to use pci-ep-bus and platform drivers. Most of the core
code should be stay the same but the overall structure will
change.
Thanks for your suggestions.
-Alex
>
> Rob
^ permalink raw reply
* Re: [PATCH net-next v2 10/14] dt-bindings: net: toshiba,tc9654-dwmac: add TC9564 Ethernet bridge
From: Alex Elder @ 2026-06-09 21:31 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, krzk+dt, conor+dt, linusw,
brgl, arnd, gregkh, Daniel Thompson, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605144032.GA3659201-robh@kernel.org>
On 6/5/26 9:40 AM, Rob Herring wrote:
> On Thu, Jun 04, 2026 at 08:00:17PM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Add devicetree bindings for the Toshiba TC956x family of Ethernet-AVB/TSN
>> bridges.
>>
>> The TC9564 contains a PCIe switch with one upstream and three downstream
>> PCIe ports. The third PCIe downstream port has an attached embedded PCIe
>> endpoint, and that endpoint implements two PCIe functions. Each internal
>> PCIe function has a Synopsys XGMAC Ethernet interface capable of 10 Gbps
>> operation.
>>
>> The TC9564 also implements an embedded GPIO controller, which exposes
>> 10 lines externally. Some platforms use these GPIO lines, so this
>> GPIO controller is managed by a separate driver. Other embedded
>> peripherals (like a microcontroller, SRAM, and UART) are currently
>> unused.
>>
>> The GPIO controller is managed by registers accessed via MMIO on an
>> internal PCIe function's registers.
>>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> ---
>> .../bindings/net/toshiba,tc9564-dwmac.yaml | 120 ++++++++++++++++++
>> MAINTAINERS | 6 +
>> 2 files changed, 126 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>> new file mode 100644
>> index 0000000000000..6e7a63dfcf86a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>> @@ -0,0 +1,120 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/toshiba,tc9564-dwmac.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toshiba TC956x Ethernet-AVB/TSN Controller
>> +
>> +maintainers:
>> + - Alex Elder <elder@riscstar.com>
>> + - Daniel Thompson <daniel@riscstar.com>
>> +
>> +description: |
>> + The Toshiba TC9564 (and more generally, TC956x) incorporates a PCIe
>> + gen 3 switch with one upstream and three downstream ports. The first
>> + two downstream ports are exposed externally, while the third is used
>> + by an internal PCIe endpoint. The PCIe endpoint implements two PCIe
>> + functions, and attached to each of these is a 10 Gbps capable Synopsys
>> + Ethernet controller.
>> +
>> + The TC956x additionally implements other internal IP blocks, and in
>> + particular it implements a GPIO controller. Ten of the 35 GPIO lines
>> + implemented are exposed externally and are usable by the platform.
>> + It is platform-dependent whether the GPIO function must be exposed,
>> + and if it is, PCIe function 0 supplies it.
>> +
>> + ----------------------------------
>> + | Host |
>> + ------+...+----------+........+---
>> + |i2c| | PCIe |
>> + ----------------+...+----------+........+------
>> + | TC956x |I2C| |upstream| |
>> + | ----- --+--------+--- |
>> + | ----- ------ ------- | PCIe switch | |
>> + | |SPI| |GPIO| |reset| | | |
>> + | ----- ------ |clock| | DS3 DS2 DS1 | |
>> + | ------- ---++--++--++-- |
>> + | ----- ------ downstream// \\ \\ | downstream
>> + | |MCU| |SRAM| /==========/ \\ \===== PCIe port 1
>> + | ----- ------ //PCIe port 3 \\ |
>> + | || \======= downstream
>> + | ----+-----------++-----------+---- | PCIe port 2
>> + | | M | internal PCIe endpoint | M | |
>> + | | S |------------------------| S | ------ |
>> + | | I | PCIe | | PCIe | I | |UART| |
>> + | | G |function 0| |function 1| G | ------ |
>
> I don't see nodes for these PCI functions. Boot this platform with
> CONFIG_PCI_DYNAMIC_OF_NODES enabled and use the resulting DT node
> structure. Anything else is wrong. This will give you the DTS:
>
> dtc -O dts /proc/device-tree
>
> The ethernet nodes should be just these PCI function nodes. You need to
> make the DWMAC PCI driver (stmmac_pci.c) bind to those 2 PCI devices.
> And really, a DT node for them should be completely optional (unless
> there's some power on ctrl needed).
>
> Everything else like SPI, GPIO, UART, etc. should be under the PCIe
> switch upstream node in a pci-ep-bus.
I unfortunately hadn't looked closely enough at pci-ep-bus
before. It really looks like what we should use. It's a
simple bus, and we'll use platform drivers and compatible
strings to match the devices on the bus.
I'll work toward converting things over to use this model.
>
>
>> + | | E |----++----| |----++----| E | |
>> + | | N | eMAC 0 | | eMAC 1 | N | |
>> + --------+.......+------+.....+-----------------
>> + |USXGMII| |SGMII|
>> + --+.......+-- --+.....+--
>> + | ARQ113C | | QEP8121 |
>> + | PHY | | PHY |
>> + ------------- -----------
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - pci1179,0220 # Toshiba TC9564 (a.k.a. Qualcomm QPS615)
>> +
>> + gpio:
>> + type: object
>> + description: Embedded GPIO controller
>> + $ref: /schemas/gpio/gpio.yaml#
>
> gpio.yaml alone does not define a GPIO controller. How many #gpio-cells
> needs to be defined.
>
> Is there no address associated with the controller?
>
>> +
>> + ethernet:
>> + type: object
>> + description: XGMAC Ethernet controller
>> + $ref: /schemas/net/ethernet-controller.yaml#
>> + properties:
>> + mdio:
>> + $ref: snps,dwmac.yaml#/properties/mdio
>
> Either all of snps,dwmac.yaml should apply or none of it. Generally, we
> only reference whole schema files (OF graph being a notable exception).
OK.
>
>> + required:
>> + - mdio
>> +
>> +required:
>> + - compatible
>> +
>> +allOf:
>> + - $ref: /schemas/pci/pci-device.yaml#
>> + - $ref: /schemas/pci/pci-bus-common.yaml#
>
> These 2 are just pci-pci-bridge.yaml.
OK.
-Alex
>
> Rob
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
From: Congkai Tan @ 2026-06-09 20:56 UTC (permalink / raw)
To: oupton
Cc: blakgeof, catalin.marinas, congkai, harisokn, joey.gouly, kvmarm,
linux-arm-kernel, linux-kernel, mark.rutland, maz, suzuki.poulose,
will, yuzenghui
In-Reply-To: <aieclTmL1op0AYfS@kernel.org>
On Mon, Jun 08, 2026 at 09:54:45PM -0700, Oliver Upton wrote:
> > - set_pmmir() writes pmmir_slots to 0 if the user input is 0;
> > otherwise it no-ops or rejects.
>
> Reject is always better heh :)
For sure. Just to see what happens when migrating a guest onto a PMU
with different SLOTS - after pmmir_slots is set to the new value, the VMM
tries to restore the original non-zero SLOTS via SET_ONE_REG and gets the
error. I think it's a good design to force VMMs to be aware of SLOTS
changes?
> So I was previously under the impression that we already expose PMMIR_EL1
> to userspace but we actually don't. Grr.
>
> The UAPI around PMUv3 is crappy enough that we should just add a new
> vCPU feature flag. When that flag is set:
>
> - KVM will not create a 'default' PMU, userspace must select a PMU
> implementation to init the vCPU
>
> - PMMIR_EL1 becomes a user-visible register with the behavior that you
> outline above
>
> - No PMCEID masking for STALL_SLOT* events
>
> There's a couple larger PMU features underway (e.g. Colton's partitioned
> PMU, Akihiko's fixed counters PMU) that we can also condition on the new
> feature flag.
It makes sense to guard everything behind a flag. Just to confirm my
understanding, by "a new vCPU feature flag" are you referring to
extending the features set through KVM_ARM_VCPU_INIT? If so,
since the flag may guard more PMU features later, do you have a preferred
name in mind that best reflects its planned usage?
For v2 I'll work on 3 patches:
- Patch 1 adds the flag, skips the default PMU selection behind it, and
checks for/rejects absent PMU
- Patch 2 implements the new PMMIR_EL1 behavior
- Patch 3 implements the new PMCEID1 behavior
Thanks,
Congkai
^ permalink raw reply
* Re: [PATCH v2] gpiolib: handle gpio-hogs only once
From: Daniel Drake @ 2026-06-09 20:48 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-gpio, linux-arm-kernel, linusw
In-Reply-To: <CAMRc=MfUd3nwpjgz-87hrpQ9AV6T8_1zwCm+tfYFurkYHKoKTw@mail.gmail.com>
On 09/06/2026 13:39, Bartosz Golaszewski wrote:
> On Mon, 8 Jun 2026 23:01:08 +0200, Daniel Drake <dan@reactivated.net> said:
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index 1e6dce430dca..b02d711289d0 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -1031,9 +1031,17 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
>> if (!fwnode_property_present(fwnode, "gpio-hog"))
>> continue;
>>
>> + /* The hog may have been handled by another gpio_chip on the same fwnode */
>> + if (is_of_node(fwnode) &&
>> + of_node_check_flag(to_of_node(fwnode), OF_POPULATED))
>> + continue;
>> +
>> ret = gpiochip_add_hog(gc, fwnode);
>> if (ret)
>> return ret;
>> +
>> + if (is_of_node(fwnode))
>> + of_node_set_flag(to_of_node(fwnode), OF_POPULATED);
>
> Sashiko correctly points out that on errors, the state will be corrupted. We
> could maybe move the clearing of the flag to gpiochip_free_hogs() and track its
> state when processing fwnodes in order not to clear it incorrectly?
I guess you are referring to:
> Does setting OF_POPULATED here cause state corruption if a secondary chip on a
> shared node fails to probe?
> When multiple gpio_chip instances share a device node, the first chip processes
> its hogs and sets OF_POPULATED. If a subsequent chip fails probe (for example,
> returning -EPROBE_DEFER), its cleanup path calls of_gpiochip_remove() which
> clears the flag for all hogs.
> If the flag is unconditionally cleared, will the deferred chip attempt to
> process the first chip's hogs on retry, fail due to a mismatch, and
> permanently abort probe?
I don't think this is actually an issue. If we have two gpio_chips
sharing a device node, a first one with a hog that probes fine and a
subsequent one that fails during probe, both of the gpio_chips will
brought down and the flag is cleared. If it was a EPROBE_DEFER case
which is then retried later, the first chip's hogs will be set up a 2nd
time when the probe is retried.
It is true that the teardown of the 2nd gpio_chip would erase the
OF_POPULATED flag of a gpio-hog node that it does not "own", but the
first gpio_chip would also be torn down at the same time (and
OF_POPULATED unset a 2nd time). This is not ideal, but harmless as far
as I can see.
I don't quite follow the suggestion for doing the clearing better in
gpiochip_free_hogs(). It would be neat if we could go from a hogged
gpio_desc back to the fwnode, so that we could only unset OF_POPULATED
on the fwnode at the point when we are really removing the hog, but I
don't see a way to derive the gpio-hog fwnode from gpio_desc. Also, this
would be complicated because one gpio-hog node can hog multiple gpios.
Let me know if I'm missing anything or if you have any preference to
handle this differently!
Thanks
Daniel
^ permalink raw reply
* Re: [EXT] Re: [PATCH] arm64: dts: imx93-11x11-frdm: enable additional devices
From: Francesco Valla @ 2026-06-09 20:39 UTC (permalink / raw)
To: Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, devicetree, imx, linux-arm-kernel, linux-kernel,
steven.yang
In-Reply-To: <db95fec5-d8ac-4d52-ad2a-75e5593f99ef@nxp.com>
Hi Joseph,
On lunedì 8 giugno 2026 07:14:24 Ora legale dell’Europa centrale Joseph Guo
wrote:
> On 6/5/2026 7:36 PM, Francesco Valla wrote:
> > Caution: This is an external email. Please take care when clicking links
> > or opening attachments. When in doubt, report the message using the
> > 'Report this email' button
> >
> >
> > Hi Joseph,
> >
> > On venerdì 5 giugno 2026 10:59:08 Ora legale dell’Europa centrale Joseph
> > Guo>
> > wrote:
> >> On Thu, Jan 15, 2026 at 06:11:34PM +0100, Francesco Valla wrote:
> >>> Enable additional devices on the i.MX93 FRDM board:
> >>> - CAN port and associated transceiver
> >>> - Bluetooth portion of the IW612 chipset
> >>> - WiFi SDIO port
> >>> - user buttons
> >>>
> >>> The WiFi portion of the on-board IW612 chipset is still not supported
> >>> upstream, but since SDIO is a discoverable bus it will be probed once it
> >>> is.
> >>>
> >>> Signed-off-by: Francesco Valla <francesco@valla.it>
> >>> ---
> >
> > [...]
> >
> >> Hi Francesco,
> >>
> >> Do you ever tried bluetooth feature? The bluetooth failed to scan with
> >> 'device-wakeup-gpios' property.
> >>
> >> Regards,
> >> Joseph
> >
> > Yes, Bluetooth was tested using bluetoothctl, I just briefly re-tested it
> > with latest master branch (7.1.0-rc6).
> >
> > Can you clarify what you mean with "The bluetooth failed to scan
> > with 'device-wakeup-gpios' property."?
>
> Hi Francesco,
>
> If 'device-wakeup-gpios' property is set. The bluetoothctl can work, but
> errors will show up if try to scan the bluetooth devices.
>
> [bluetoothctl]> scan on
> SetDiscoveryFilter success
> Failed to start discovery: org.bluez.Error.InProgress
> hci0 class of device changed: 0x000000
> hci0 new_settings: bondable ssp br/edr le secure-conn cis-central
> cis-peripheral iso-broadcaster sync-receiver ll-privacy past-sender
> past-receiver [CHG] Controller 20:BA:36:5C:B0:D8 Class: 0x00000000 (0)
> [CHG] Controller 20:BA:36:5C:B0:D8 Powered: no
> [CHG] Controller 20:BA:36:5C:B0:D8 Discovering: no
> [CHG] Controller 20:BA:36:5C:B0:D8 PowerState: on
> [bluetoothctl]> discoverable on
> Failed to set discoverable on: org.bluez.Error.Failed
>
> After remove the 'device-wakeup-gpios' node. The bluetooth can work
> normally.
This is not my experience:
[bluetoothctl]> scan on
SetDiscoveryFilter success
hci0 type 7 discovering on
Discovery started
[CHG] Controller B8:F4:4F:AA:9D:1C Discovering: yes
[NEW] Device C4:DE:E2:52:B9:96 BWT Perla BLue 16L 0025-003A
[bluetoothctl]> discoverable on
hci0 new_settings: powered connectable bondable ssp br/edr le secure-conn cis-
central cis-peripheral iso-broadcaster sync-receiver ll-privacy past-sender
past-receiver
[CHG] Controller B8:F4:4F:AA:9D:1C Connectable: yes
hci0 new_settings: powered connectable discoverable bondable ssp br/edr le
secure-conn cis-central cis-peripheral iso-broadcaster sync-receiver ll-
privacy past-sender past-receiver
Changing discoverable on succeeded
[CHG] Controller B8:F4:4F:AA:9D:1C Discoverable: yes
I also enabled the driver debug prints (through #define DEBUG) and can confirm
that the GPIO is being driven:
root@imx93-11x11-frdm:~# dmesg|grep h2c
[ 13.524321] hci0: Set Wakeup Method response: status=0, h2c_wakeupmode=4
[ 15.586748] hci0: Set h2c_ps_gpio: high
[ 28.459963] hci0: Set h2c_ps_gpio: low
[ 32.034623] hci0: Set h2c_ps_gpio: high
Maybe we have a different board revision? Do you know if there is a way I can
read mine?
Regards,
Francesco
^ permalink raw reply
* Re: [PATCH v17 00/28] Add new general DRM property "color format"
From: Daniel Stone @ 2026-06-09 20:11 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel, Werner Sembach,
Andri Yngvason, Cristian Ciocaltea, Marius Vlad, Dmitry Baryshkov,
Andy Yan
In-Reply-To: <20260609-color-format-v17-0-35739b5782cc@collabora.com>
Hi Nicolas,
On Tue, 9 Jun 2026 at 13:44, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
> this is a follow-up to
> https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
> which in of itself is a follow-up to
> https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
> a new DRM connector property has been added allowing users to
> force a particular color format.
>
> That in turn was actually also a follow-up from Werner Sembach's posted at
> https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
>
> As the number of cooks have reached critical mass, I'm hoping I'll be
> the last person to touch this particular series.
Thanks for seeing this through!
I've pushed this now, minus the Intel patches which they can merge
through their own tree. The AMD tree required a pretty trivial
conflict resolution which seems to work OK here.
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-09 20:11 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rAGLH7si2S4aYhSUWyL-zZL7B_uo+WLE4zKY9SqKVi8zQ@mail.gmail.com>
On Tue, Jun 09, 2026 at 11:34:42AM -0700, Daniel Mentz wrote:
> On Tue, Jun 9, 2026 at 3:34 AM Pranjal Shrivastava <praan@google.com> wrote:
> > > I'm not sure if I have a good suggestion here. Have you considered the
> > > following: Do not call arm_smmu_handle_gerror() from
> > > arm_smmu_runtime_suspend(). Instead, call disable_irq() at the end of
> > > the suspend handler (and enable_irq() at the beginning of the resume
> > > handler)?
> >
> > I thought about using disable_irq(), but I think doing it at the
> > hardware level (IRQ_CTRL) is better.
> >
> > By disabling in IRQ_CTRL and keeping the manual arm_smmu_handle_gerror()
> > call at the end of suspend, we ensure that we don't lose any gerror info
> > We catch and handle any errors that occurred during the drain/quiesce
> > phase right before the power-down.
>
> I think the beauty of disable_irq() is that it synchronizes any
> potentially running hard IRQ handler, which helps avoid races.
Alright, I guess we could:
1. SMMUEN=0
2. IRQ_CTRL.gerror=0
3. disable_irq();
4. handle_gerror(); at the end of suspend
Thanks,
Praan
^ permalink raw reply
* [PATCH] ARM/PCI: remove stale CONFIG_PCI_HOST_ITE8152 reference
From: Ethan Nelson-Moore @ 2026-06-09 20:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Ethan Nelson-Moore, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
The IT8152 driver was removed in commit 6da5238fa384 ("ARM: 8993/1:
remove it8152 PCI controller driver"), but a reference to its config
symbol remained in arch/arm/kernel/bios32.c. Remove it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/kernel/bios32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index ac0e890510da..eff8d9e3c14c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -528,12 +528,10 @@ void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
}
}
-#ifndef CONFIG_PCI_HOST_ITE8152
void pcibios_set_master(struct pci_dev *dev)
{
/* No special bus mastering setup handling */
}
-#endif
char * __init pcibios_setup(char *str)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v6 02/11] arm64: dts: ti: k3-am62d2-evm: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62A defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 364 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B5B000
which results in an end at 0x9e600000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e600000 - 0x9c900000 = 0x1d00000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 1544bca2f188 ("arm64: dts: ti: Add support for AM62D2-EVM")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62d2-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
index f5ceb6a1b5debabf1ead67eea634b48db1540186..463a3f6130b8f2927a032137e87c01df446cffda 100644
--- a/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62d2-evm.dts
@@ -67,7 +67,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0xf00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d00000>;
no-map;
bootph-pre-ram;
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 6/8] can: flexcan: add NXP S32N79 SoC support
From: Vincent Mailhol @ 2026-06-09 19:52 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Andra-Teodora Ilie,
Larisa Grigore, Haibo Chen
In-Reply-To: <20260609142954.1807421-7-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> Add device data and compatible string for NXP S32N79 SoC.
>
> FlexCAN IP integration on S32N79 SoC uses two interrupts:
> - one for mailboxes 0-127
> - one for signaling bus errors and device state changes
>
> Co-developed-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
> Signed-off-by: Andra-Teodora Ilie <andra.ilie@nxp.com>
> Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Diederik de Haas @ 2026-06-09 19:51 UTC (permalink / raw)
To: Jonas Karlman, Diederik de Haas
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <9e8f806d-72ec-4eb4-8967-3f82eb0e7dd4@kwiboo.se>
Hi Jonas,
On Tue Jun 9, 2026 at 8:06 PM CEST, Jonas Karlman wrote:
> Hi Diederik,
>
> On 6/9/2026 6:32 PM, Diederik de Haas wrote:
>> Hi Jonas,
>>
>> On Tue Jun 9, 2026 at 5:41 PM CEST, Jonas Karlman wrote:
>>> The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
>>> being enabled, or the system may freeze when registers are accessed.
>>>
>>> Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
>>> constraint as RK3588.
>>>
>>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>>> ---
>>> Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
>>> next patch make use of these new compatibles and adds the missing
>>> clk_usbphy1_480m clock references.
>>> ---
>>> .../devicetree/bindings/usb/generic-ehci.yaml | 10 ++++++++++
>>> .../devicetree/bindings/usb/generic-ohci.yaml | 5 ++++-
>>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> index 55a5aa7d7a54..c49a1bbc8cfd 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>> @@ -52,6 +52,7 @@ properties:
>>> - ibm,476gtr-ehci
>>> - nxp,lpc1850-ehci
>>> - qca,ar7100-ehci
>>> + - rockchip,rk3568-ehci
>>> - rockchip,rk3588-ehci
>>> - snps,hsdk-v1.0-ehci
>>> - socionext,uniphier-ehci
>>> @@ -186,6 +187,15 @@ allOf:
>>> required:
>>> - clocks
>>> - clock-names
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: rockchip,rk3568-ehci
>>> + then:
>>> + properties:
>>> + clocks:
>>> + minItems: 4
>>
>> I think that the constraint for rk3588 is this:
>> - minItems: 1
>> - maxItems: 4
>>
>> Like ~ every other compatible; there's no 'branch' for rk3588-ehci.
>>
>> That's different from what you add for rk3568. Is that deliberate?
>> Because from the commit message I assumed they should be the same.
>
> It was deliberate, the intention is to use min/maxItems: 4 for rk3568
Thanks :-)
> for both EHCI and OHCI. I left out anything related to k3588 to keep
> existing behavior and avoid any possible breakage, and why I used
> 'similar' and not 'same' in the commit message ;-)
>
> Did a check and the rk3588 variant also uses 4 clocks so I will add same
> constraint for the rk3588 variant and address Sashiko's concern in v2.
FWIW: I would be absolutely fine if you restrict this patch set to just RK3568.
For the same reason you mentioned. All I wanted to know if it was deliberate
and you confirmed that :-)
Cheers,
Diederik
> Regards,
> Jonas
>
>>
>>> unevaluatedProperties: false
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> index d42f448fa204..5f1b4d2bff89 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
>>> @@ -47,6 +47,7 @@ properties:
>>> - hpe,gxp-ohci
>>> - ibm,476gtr-ohci
>>> - ingenic,jz4740-ohci
>>> + - rockchip,rk3568-ohci
>>> - rockchip,rk3588-ohci
>>> - snps,hsdk-v1.0-ohci
>>> - const: generic-ohci
>>> @@ -198,7 +199,9 @@ allOf:
>>> properties:
>>> compatible:
>>> contains:
>>> - const: rockchip,rk3588-ohci
>>> + enum:
>>> + - rockchip,rk3568-ohci
>>> + - rockchip,rk3588-ohci
>>
>> Here they clearly do have the same constraint.
>>
>> Cheers,
>> Diederik
>>
>>> then:
>>> properties:
>>> clocks:
>>
^ permalink raw reply
* Re: [PATCH v5 5/8] can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
From: Vincent Mailhol @ 2026-06-09 19:51 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Larisa Grigore,
Haibo Chen
In-Reply-To: <20260609142954.1807421-6-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> Introduce FLEXCAN_QUIRK_IRQ_BERR quirk to handle hardware integration
> where the FlexCAN module has a dedicated interrupt line for signaling
> bus errors and device state changes.
>
> This adds the flexcan_irq_esr() handler which composes
> flexcan_do_state() and flexcan_do_berr() to handle platforms where
> these events share a single IRQ line.
>
> Also extend flexcan_chip_interrupts_enable() to disable/enable the
> new IRQ line during IMASK register writes.
>
> This is required for NXP S32N79 SoC support.
>
> Co-developed-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> drivers/net/can/flexcan/flexcan-core.c | 54 +++++++++++++++++++++-----
> drivers/net/can/flexcan/flexcan.h | 2 +
> 2 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 0ed838f0719a..adf3af57fb0a 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -1300,6 +1300,22 @@ static irqreturn_t flexcan_irq_boff(int irq, void *dev_id)
> return handled;
> }
>
> +/* Combined bus error and state change IRQ handler */
> +static irqreturn_t flexcan_irq_esr(int irq, void *dev_id)
> +{
> + struct net_device *dev = dev_id;
> + struct flexcan_priv *priv = netdev_priv(dev);
> + irqreturn_t handled;
> +
> + handled = flexcan_do_state(dev);
> + handled |= flexcan_do_berr(dev);
> +
> + if (handled)
> + can_rx_offload_irq_finish(&priv->offload);
> +
> + return handled;
> +}
> +
> static void flexcan_set_bittiming_ctrl(const struct net_device *dev)
> {
> const struct flexcan_priv *priv = netdev_priv(dev);
> @@ -1540,10 +1556,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
> u64 reg_imask;
>
> disable_irq(dev->irq);
> - if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> + if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> disable_irq(priv->irq_boff);
> + if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> disable_irq(priv->irq_err);
> - }
> if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> disable_irq(priv->irq_secondary_mb);
>
> @@ -1554,10 +1570,10 @@ static void flexcan_chip_interrupts_enable(const struct net_device *dev)
> enable_irq(dev->irq);
> if (quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> enable_irq(priv->irq_secondary_mb);
> - if (quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> - enable_irq(priv->irq_boff);
> + if (quirks & (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> enable_irq(priv->irq_err);
> - }
> + if (quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + enable_irq(priv->irq_boff);
> }
>
> static void flexcan_chip_interrupts_disable(const struct net_device *dev)
> @@ -1881,7 +1897,8 @@ static int flexcan_open(struct net_device *dev)
>
> can_rx_offload_enable(&priv->offload);
>
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_NR_IRQ_3 | FLEXCAN_QUIRK_IRQ_BERR))
> err = request_irq(dev->irq, flexcan_irq_mb,
> IRQF_SHARED, dev->name, dev);
> else
> @@ -1902,6 +1919,13 @@ static int flexcan_open(struct net_device *dev)
> goto out_free_irq_boff;
> }
>
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
> + err = request_irq(priv->irq_err,
> + flexcan_irq_esr, IRQF_SHARED, dev->name, dev);
> + if (err)
> + goto out_free_irq_boff;
> + }
> +
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ) {
> err = request_irq(priv->irq_secondary_mb,
> flexcan_irq_mb, IRQF_SHARED, dev->name, dev);
> @@ -1916,7 +1940,8 @@ static int flexcan_open(struct net_device *dev)
> return 0;
>
> out_free_irq_err:
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
> free_irq(priv->irq_err, dev);
> out_free_irq_boff:
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> @@ -1948,10 +1973,12 @@ static int flexcan_close(struct net_device *dev)
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> free_irq(priv->irq_secondary_mb, dev);
>
> - if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> + if (priv->devtype_data.quirks &
> + (FLEXCAN_QUIRK_IRQ_BERR | FLEXCAN_QUIRK_NR_IRQ_3))
> free_irq(priv->irq_err, dev);
> +
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3)
> free_irq(priv->irq_boff, dev);
> - }
>
> free_irq(dev->irq, dev);
> can_rx_offload_disable(&priv->offload);
> @@ -2338,12 +2365,21 @@ static int flexcan_probe(struct platform_device *pdev)
> if (transceiver)
> priv->can.bitrate_max = transceiver->attrs.max_link_rate;
>
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_IRQ_BERR) {
> + priv->irq_err = platform_get_irq_byname(pdev, "berr");
> + if (priv->irq_err < 0) {
> + err = priv->irq_err;
> + goto failed_platform_get_irq;
> + }
> + }
> +
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> priv->irq_boff = platform_get_irq(pdev, 1);
> if (priv->irq_boff < 0) {
> err = priv->irq_boff;
> goto failed_platform_get_irq;
> }
> +
Nitpick: you shouldn't have unrelated changes, like this newline
addition, in you patches.
@Marc, do you mind removing this while applying?
> priv->irq_err = platform_get_irq(pdev, 2);
> if (priv->irq_err < 0) {
> err = priv->irq_err;
> diff --git a/drivers/net/can/flexcan/flexcan.h b/drivers/net/can/flexcan/flexcan.h
> index 16692a2502eb..bbb1a8dd4777 100644
> --- a/drivers/net/can/flexcan/flexcan.h
> +++ b/drivers/net/can/flexcan/flexcan.h
> @@ -74,6 +74,8 @@
> * both need to have an interrupt handler registered.
> */
> #define FLEXCAN_QUIRK_SECONDARY_MB_IRQ BIT(18)
> +/* Setup dedicated bus error and state change IRQ */
> +#define FLEXCAN_QUIRK_IRQ_BERR BIT(19)
>
> struct flexcan_devtype_data {
> u32 quirks; /* quirks needed for different IP cores */
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Andrew Morton @ 2026-06-09 19:45 UTC (permalink / raw)
To: Xueyuan Chen
Cc: linux-mm, linux-kernel, linux-arm-kernel, x86, catalin.marinas,
will, tglx, mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs,
liam, vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh,
Dave Hansen
In-Reply-To: <20260609143801.7917-2-xueyuan.chen21@gmail.com>
On Tue, 9 Jun 2026 22:37:59 +0800 Xueyuan Chen <xueyuan.chen21@gmail.com> wrote:
> The huge zero folio is shared globally, and its contents should never
> change after initialization. As Jann Horn pointed out[1], the kernel has
> had bugs, including security bugs, where read-only pages were later written
> to. If the persistent huge zero folio is read-only in the direct map, such
> writes fault instead of silently corrupting the shared zero contents.
>
> Add arch_make_pages_readonly() so mm code can request read-only direct-map
> protection for a page range. Direct-map protection is
> architecture-specific, so the generic weak implementation does nothing.
>
> This was inspired by Jann Horn's read-only zero page work[1] and follow-up
> discussion[2] with Yang Shi.
>
> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
> [2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
>
> ...
>
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -308,6 +308,11 @@ static unsigned long shrink_huge_zero_folio_scan(struct shrinker *shrink,
> return 0;
> }
>
> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
> +{
> + return false;
> +}
> +
> static struct shrinker *huge_zero_folio_shrinker;
>
> #ifdef CONFIG_SYSFS
> @@ -982,8 +987,14 @@ static int __init thp_shrinker_init(void)
> * that get_huge_zero_folio() will most likely not fail as
> * thp_shrinker_init() is invoked early on during boot.
> */
> - if (!get_huge_zero_folio())
> + if (!get_huge_zero_folio()) {
> pr_warn("Allocating persistent huge zero folio failed\n");
> + return 0;
> + }
> +
> + arch_make_pages_readonly(folio_page(huge_zero_folio, 0),
> + HPAGE_PMD_NR);
Can it simply pass the folio?
^ permalink raw reply
* [PATCH v6 04/11] arm64: dts: ti: k3-am62p-verdin: Fix wkup R5F memory region size
From: Markus Schneider-Pargmann (TI) @ 2026-06-09 18:56 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Judith Mendez,
Daniel Schultz, Andrew Davis, Siddharth Vadapalli, Paresh Bhagat,
Bryan Brattlof, Jai Luthra, Devarsh Thakkar, Beleswar Padhi,
Francesco Dolcini, Stefano Radaelli
Cc: Vishal Mahaveer, Kevin Hilman, Sebin Francis, Kendall Willis,
Akashdeep Kaur, linux-arm-kernel, devicetree, linux-kernel, llvm,
Hari Nagalla, Markus Schneider-Pargmann (TI)
In-Reply-To: <20260609-topic-am62a-ioddr-dt-v6-19-v6-0-16afba97fbe0@baylibre.com>
The wkup_r5fss0_core0_memory_region was reserved with only
0x0f00000 but the MCU SDK linker for the wkup R5F firmware on
AM62P defines the DM code/data DDR footprint differently:
/* DDR for DM R5F code/data [ size 27 MiB + 396 KB ] */
DDR : ORIGIN = 0x9CAA5000 LENGTH = 0x1B63000
which results in an end at 0x9e608000. For this memory region which
starts at 0x9c900000 this means a length of:
0x9e608000 - 0x9c900000 = 0x1d08000
Link: https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62px-sk/wkup-r5fss0-0_freertos/ti-arm-clang/linker.cmd
Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P")
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
---
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 7ee894d59113aa727d41b7ecd6b2bc7e12760823..8a5ff5c457579c7b1be7157d235fd4b4e5c6af11 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -170,7 +170,7 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
wkup_r5fss0_core0_memory_region: memory@9c900000 {
compatible = "shared-dma-pool";
- reg = <0x00 0x9c900000 0x00 0x01e00000>;
+ reg = <0x00 0x9c900000 0x00 0x01d08000>;
no-map;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 3/8] can: flexcan: split rx/tx masks per mailbox IRQ line
From: Vincent Mailhol @ 2026-06-09 19:42 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-4-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> On S32G2, which has two mailbox IRQ lines (mb-0 for MBs 0-7, mb-1
> for MBs 8-63), both handlers currently process the full rx_mask/tx_mask
> range.
>
> Introduce FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK and
> FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK to describe the split, and pass
> the selected mask to flexcan_do_mb() via a new mb_mask parameter.
>
> In flexcan_irq_mb(), the irq argument selects the correct mask: the
> primary MB IRQ uses MB0_MASK and the secondary uses MB1_MASK.
>
> For single-IRQ platforms, mb_mask is ~0ULL with no functional change.
>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Looks better than v5!
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> drivers/net/can/flexcan/flexcan-core.c | 39 ++++++++++++++++++--------
> 1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index 7dde2e623def..0ed838f0719a 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -182,6 +182,12 @@
> #define FLEXCAN_IFLAG_RX_FIFO_WARN BIT(6)
> #define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(5)
>
> +/* On platforms with FLEXCAN_QUIRK_SECONDARY_MB_IRQ, the MB IRQ lines are
> + * split.
> + */
> +#define FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK GENMASK_ULL(7, 0)
> +#define FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK GENMASK_ULL(63, 8)
Nitpick: priv->rx_mask, priv->tx_mask and your mb_mask variable all have
type u64 so you could have used GENMASK_U64() to stay coherent with the
type. But you don't have to send a v6 just for this.
> /* FLEXCAN message buffers */
> #define FLEXCAN_MB_CODE_MASK (0xf << 24)
> #define FLEXCAN_MB_CODE_RX_BUSY_BIT (0x1 << 24)
> @@ -957,14 +963,16 @@ static inline void flexcan_write64(struct flexcan_priv *priv, u64 val, void __io
> priv->write(lower_32_bits(val), addr);
> }
>
> -static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_rx(struct flexcan_priv *priv,
> + u64 rx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->rx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, rx_mask);
> }
>
> -static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv)
> +static inline u64 flexcan_read_reg_iflag_tx(struct flexcan_priv *priv,
> + u64 tx_mask)
> {
> - return flexcan_read64_mask(priv, &priv->regs->iflag1, priv->tx_mask);
> + return flexcan_read64_mask(priv, &priv->regs->iflag1, tx_mask);
> }
>
> static inline struct flexcan_priv *rx_offload_to_priv(struct can_rx_offload *offload)
> @@ -1071,12 +1079,14 @@ static struct sk_buff *flexcan_mailbox_read(struct can_rx_offload *offload,
> }
>
> /* Process mailbox (RX + TX) events */
> -static irqreturn_t flexcan_do_mb(struct net_device *dev)
> +static irqreturn_t flexcan_do_mb(struct net_device *dev, u64 mb_mask)
> {
> struct net_device_stats *stats = &dev->stats;
> struct flexcan_priv *priv = netdev_priv(dev);
> struct flexcan_regs __iomem *regs = priv->regs;
> irqreturn_t handled = IRQ_NONE;
> + u64 rx_mask = priv->rx_mask & mb_mask;
> + u64 tx_mask = priv->tx_mask & mb_mask;
> u64 reg_iflag_tx;
>
> /* reception interrupt */
> @@ -1084,7 +1094,8 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> u64 reg_iflag_rx;
> int ret;
>
> - while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv))) {
> + while ((reg_iflag_rx = flexcan_read_reg_iflag_rx(priv,
> + rx_mask))) {
> handled = IRQ_HANDLED;
> ret = can_rx_offload_irq_offload_timestamp(&priv->offload,
> reg_iflag_rx);
> @@ -1110,10 +1121,10 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> }
> }
>
> - reg_iflag_tx = flexcan_read_reg_iflag_tx(priv);
> + reg_iflag_tx = flexcan_read_reg_iflag_tx(priv, tx_mask);
>
> /* transmission complete interrupt */
> - if (reg_iflag_tx & priv->tx_mask) {
> + if (reg_iflag_tx & tx_mask) {
> u32 reg_ctrl = priv->read(&priv->tx_mb->can_ctrl);
>
> handled = IRQ_HANDLED;
> @@ -1125,7 +1136,7 @@ static irqreturn_t flexcan_do_mb(struct net_device *dev)
> /* after sending a RTR frame MB is in RX mode */
> priv->write(FLEXCAN_MB_CODE_TX_INACTIVE,
> &priv->tx_mb->can_ctrl);
> - flexcan_write64(priv, priv->tx_mask, ®s->iflag1);
> + flexcan_write64(priv, tx_mask, ®s->iflag1);
> netif_wake_queue(dev);
> }
>
> @@ -1228,7 +1239,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
> struct flexcan_priv *priv = netdev_priv(dev);
> irqreturn_t handled;
>
> - handled = flexcan_do_mb(dev);
> + handled = flexcan_do_mb(dev, ~0ULL);
> handled |= flexcan_do_state(dev);
> handled |= flexcan_do_berr(dev);
>
> @@ -1244,8 +1255,14 @@ static irqreturn_t flexcan_irq_mb(int irq, void *dev_id)
> struct net_device *dev = dev_id;
> struct flexcan_priv *priv = netdev_priv(dev);
> irqreturn_t handled;
> + u64 mb_mask = ~0ULL;
> +
> + if (priv->devtype_data.quirks & FLEXCAN_QUIRK_SECONDARY_MB_IRQ)
> + mb_mask = (irq == priv->irq_secondary_mb) ?
> + FLEXCAN_SECONDARY_MB_IRQ_MB1_MASK :
> + FLEXCAN_SECONDARY_MB_IRQ_MB0_MASK;
>
> - handled = flexcan_do_mb(dev);
> + handled = flexcan_do_mb(dev, mb_mask);
>
> if (handled)
> can_rx_offload_irq_finish(&priv->offload);
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH] media: bcm2835-unicam: Fix asc leaked in error/remove path
From: Laurent Pinchart @ 2026-06-09 19:39 UTC (permalink / raw)
To: Eugen Hristev
Cc: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Hans Verkuil, Naushir Patuck, Sakari Ailus,
Dave Stevenson, Jean-Michel Hautbois, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260609-bcmpiclean-v1-1-23bdeb19caf6@kernel.org>
On Tue, Jun 09, 2026 at 08:05:23PM +0300, Eugen Hristev wrote:
> v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when
> v4l2_async_nf_cleanup() is called.
>
> Call v4l2_async_nf_cleanup() properly in the driver paths.
>
> Discovered with kmemleak after rmmod:
>
> unreferenced object 0xffff000084526b80 (size 64):
> comm "modprobe", pid 185, jiffies 4295013512
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................
> 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`.......
> backtrace (crc ac584083):
> [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44
> [<00000000d2fd9301>] __kmalloc+0x1b0/0x250
> [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c
> [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64
>
> Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
> Signed-off-by: Eugen Hristev <ehristev@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/broadcom/bcm2835-unicam.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
> index 8d28ba0b59a3..1508843ae58c 100644
> --- a/drivers/media/platform/broadcom/bcm2835-unicam.c
> +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
> @@ -2613,6 +2613,7 @@ static int unicam_async_nf_init(struct unicam_device *unicam)
> return 0;
>
> error:
> + v4l2_async_nf_cleanup(&unicam->notifier);
> fwnode_handle_put(ep_handle);
> return ret;
> }
> @@ -2745,6 +2746,7 @@ static void unicam_remove(struct platform_device *pdev)
> v4l2_device_unregister(&unicam->v4l2_dev);
> media_device_unregister(&unicam->mdev);
> v4l2_async_nf_unregister(&unicam->notifier);
> + v4l2_async_nf_cleanup(&unicam->notifier);
>
> unicam_subdev_cleanup(unicam);
>
>
> ---
> base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
> change-id: 20260609-bcmpiclean-69a8ee3192b0
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 2/8] can: flexcan: disable all IRQ lines in flexcan_chip_interrupts_enable()
From: Vincent Mailhol @ 2026-06-09 19:38 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-3-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> flexcan_chip_interrupts_enable() disables only the primary IRQ line while
> writing to the IMASK and CTRL registers.
>
> On multi-IRQ platforms (S32G2, MCF5441X), the additional IRQ lines (boff,
> err, secondary-mb) remain active so their handlers can fire while
> registers are inconsistent.
>
> Disable all registered IRQ lines around the IMASK/CTRL writes. This
> also fixes the resume path, which calls this function.
>
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: Dave Hansen @ 2026-06-09 19:33 UTC (permalink / raw)
To: Xueyuan Chen, akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, david, ljs, liam,
vbabka, rppt, surenb, mhocko, ziy, baolin.wang, npache,
ryan.roberts, dev.jain, baohua, lance.yang, yang, jannh
In-Reply-To: <20260609143801.7917-2-xueyuan.chen21@gmail.com>
On 6/9/26 07:37, Xueyuan Chen wrote:
> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
> +{
> + return false;
> +}
This is a rather wonky function. It's going to cause all kinds of fun if
it is used like this:
arch_make_pages_readonly(syscall_table, 1);
It's also kinda weird to have it return a bool, and not check that bool
at the single call site. Some things come to mind:
1. This function needs commenting. It needs to say what it does, when
architectures should override it and what their implementations
should look like. It needs to be clear that this can't be used for
anything really important. What should architectures do with alias
mappings? Are they allowed to touch non-direct map aliases? Are they
required to?
2. The return type needs to be reconsidered. Is 'bool' even acceptable?
Should it just be 'void' if callers can't do anything when it fails?
3. What should the naming be? "readonly" vs "ro". Should it have a
"maybe" since it's kinda optional?
4. Should this new API be folio or page-based in the first place?
5. Is mm/huge_memory.c the right place to define a generic mm function,
even a stub?
^ permalink raw reply
* Re: [PATCH v5 1/8] can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
From: Vincent Mailhol @ 2026-06-09 19:35 UTC (permalink / raw)
To: Ciprian Costea, Marc Kleine-Budde, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Haibo Chen
In-Reply-To: <20260609142954.1807421-2-ciprianmarian.costea@oss.nxp.com>
On 09/06/2026 at 16:29, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
> On platforms with multiple IRQ lines (S32G2, MCF5441X), all lines are
> registered to the same flexcan_irq() handler. Since these are distinct IRQ
> numbers, they can be dispatched concurrently on different CPUs. Both
> instances then read the same iflag and ESR registers unconditionally,
> leading to duplicate frame processing.
>
> Fix this by splitting the monolithic handler into focused parts:
> - flexcan_do_mb(): processes mailbox events
> - flexcan_do_state(): processes device state change events
> - flexcan_do_berr(): processes bus error events
>
> Introduce dedicated IRQ handlers for multi-IRQ platforms:
> - flexcan_irq_mb(): mailbox-only, used for mb-0, mb-1 IRQ lines
> - flexcan_irq_boff(): state-change-only, used for boff/state IRQ line
> - flexcan_irq_berr(): bus-error-only, used for berr IRQ line
>
> The combined flexcan_irq() handler is preserved for single-IRQ
> platforms with no functional change.
>
> Fixes: d9cead75b1c6 ("can: flexcan: add mcf5441x support")
> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
> Reviewed-and-tested-by: Haibo Chen <haibo.chen@nxp.com>
> Tested-by: Enric Balletbo i Serra <eballetb@redhat.com>
Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
Yours sincerely,
Vincent Mailhol
^ permalink raw reply
* Re: [PATCH v2 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Andy Shevchenko @ 2026-06-09 19:33 UTC (permalink / raw)
To: Roman Vivchar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <hacDZbv1Whk_g8AMSfJqKHrgXfyVKt2o3_UGK-1k9jNRJyMxEFPztGhytHvHbc1x9j-F84I_ZuprmXWf2Azbtdqj2vnVal4PO1gG_DijYyA=@protonmail.com>
On Tue, Jun 09, 2026 at 07:15:42PM +0000, Roman Vivchar wrote:
> On Tuesday, June 9th, 2026 at 9:30 PM, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Jun 09, 2026 at 04:31:59PM +0300, Roman Vivchar via B4 Relay wrote:
...
> > > + case IIO_CHAN_INFO_RAW:
> > > + scoped_guard(mutex, &auxadc->lock) {
> >
> > I'm wondering why we haven't moved to guard()() here
>
> The compiler would complain about 'cannot jump from switch statement'
> due to default case.
I am not sure I follow. See the examples in the existing drivers. They are
warning clean in that sense.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-06-09 19:32 UTC (permalink / raw)
To: Maxime Chevallier, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <c60d1819-18d7-4d4c-a997-586599323d7e@bootlin.com>
On 6/5/26 11:05 AM, Maxime Chevallier wrote:
> Hi Alex,
>
> On 6/5/26 03:00, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
>> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
>> that can be accessed, along with several other peripherals, via two
>> PCIe endpoint functions. There is a main driver for the endpoint that
>> decomposes things and creates auxiliary bus devices to model the SoC.
>>
>> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
>> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
>> MSIs.
>>
>> Add a driver for the eMAC/MSIGEN combination.
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> ---
> [...]
>
>> +static int tc956x_lookup_max_speed(phy_interface_t phy_interface)
>> +{
>> + switch (phy_interface) {
>> + case PHY_INTERFACE_MODE_SGMII:
>
> The SGMII definition we use in the kernel is the Cisco SGMII de-facto
> standard that only supports 10/100/1000M. Some vendors use flavours with
> names such as HS-SGMII and such, that's basically SGMII clocked at 2.5G
> with aneg disabled. It kinda becomes 2500BaseX then.
So for SGMII then, the max speed returned/used should be
SPEED_1000, correct? And for 2500BASEX it's SPEED_2500.
(I'll fix this.)
For USXGMII I presume we'd use SPEED_10000 as the max_speed.
Can someone explain when the plat_stmmacenet_data->max_speed value
must be set? It seems like plat_stmmacenet_data->phy_interface
should normally imply the right maximum speed. It looks like
phylink_interface_max_speed() has a big switch statement related
to this.
Thanks.
-Alex
> So all in all, we don't support 2500M on SGMII.
>
>> + case PHY_INTERFACE_MODE_2500BASEX:
>> + return SPEED_2500;
>> +
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>
> Maxime
^ permalink raw reply
* Re: [PATCH net-next v2 03/14] net: pcs: pcs-xpcs-regmap: support XPCS memory-mapped MDIO bus via regmap
From: Alex Elder @ 2026-06-09 19:31 UTC (permalink / raw)
To: Maxime Chevallier, andrew+netdev, davem, edumazet, kuba, pabeni,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh
Cc: Daniel Thompson, mohd.anwar, a0987203069, alexandre.torgue, ast,
boon.khai.ng, chenchuangyu, chenhuacai, daniel, hawk, hkallweit1,
inochiama, john.fastabend, julianbraha, livelycarpet87,
mcoquelin.stm32, me, prabhakar.mahadev-lad.rj, richardcochran,
rohan.g.thomas, sdf, siyanteng, weishangjuan, wens, netdev, bpf,
linux-arm-msm, devicetree, linux-gpio, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <566af63b-05a9-43f8-94e9-19af737c848a@bootlin.com>
On 6/5/26 10:35 AM, Maxime Chevallier wrote:
>> + const struct xpcs_regmap_config *config)
>> +{
>> + static atomic_t id = ATOMIC_INIT(-1);
>> + struct dw_xpcs_regmap *pxpcs;
>> + struct dw_xpcs *xpcs;
>> + int ret;
>> +
>> + pxpcs = devm_kzalloc(dev, sizeof(*pxpcs), GFP_KERNEL);
>> + if (!pxpcs)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + pxpcs->dev = dev;
>> + pxpcs->regmap = config->regmap;
>> + pxpcs->reg_indir = config->reg_indir;
> Looking at the overall series, is there any reason for this flag ?
>
> Looks like the reg_indir=false path isn't used at all in this series.
>
> Maybe just drop it and let anyone add it back should the need arise ?
You're right that it's always true (in this one case it's used).
I think it's fine to get rid of the reg_indir flag, and that
will simplify a lot of things. It eliminates the need for the
xpcs_regmap_config structure (just register with regmap pointer
instead).
The "pcs-xpcs-regmap.h" header could be removed too if we declared
devm_xpcs_regmap_register() in "drivers/net/pcs/pcs-xpcs.h". (I
won't do this unless you or someone else suggests it though.)
I will rearrange the code to support only the indirect access
method for this code.
-Alex
^ 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