* [PATCH 05/11] resource: Make resource_alignment() input const resource
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
resource_alignment() does not need to change resource so it can be
made const.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
include/linux/ioport.h | 2 +-
kernel/resource.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 3c73c9c0d4f7..f7930b3dfd0a 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -261,7 +261,7 @@ extern int allocate_resource(struct resource *root, struct resource *new,
struct resource *lookup_resource(struct resource *root, resource_size_t start);
int adjust_resource(struct resource *res, resource_size_t start,
resource_size_t size);
-resource_size_t resource_alignment(struct resource *res);
+resource_size_t resource_alignment(const struct resource *res);
/**
* resource_set_size - Calculate resource end address from size and start
diff --git a/kernel/resource.c b/kernel/resource.c
index d02a53fb95d8..3d17e3196a3e 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1238,7 +1238,7 @@ reserve_region_with_split(struct resource *root, resource_size_t start,
*
* Returns alignment on success, 0 (invalid alignment) on failure.
*/
-resource_size_t resource_alignment(struct resource *res)
+resource_size_t resource_alignment(const struct resource *res)
{
switch (res->flags & (IORESOURCE_SIZEALIGN | IORESOURCE_STARTALIGN)) {
case IORESOURCE_SIZEALIGN:
--
2.39.5
^ permalink raw reply related
* [PATCH 06/11] powerpc/pseries: Make pseries_get_iov_fw_value() & pnv_iov_get() pci_dev const
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
Convert input pci_dev for pseries_get_iov_fw_value() and pnv_iov_get()
to const to be able to convert pcibios_iov_resource_alignment() as well
in an upcoming change.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/powerpc/platforms/powernv/pci.h | 2 +-
arch/powerpc/platforms/pseries/setup.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 42075501663b..032b2081aedb 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -251,7 +251,7 @@ struct pnv_iov_data {
struct resource holes[PCI_SRIOV_NUM_BARS];
};
-static inline struct pnv_iov_data *pnv_iov_get(struct pci_dev *pdev)
+static inline struct pnv_iov_data *pnv_iov_get(const struct pci_dev *pdev)
{
return pdev->dev.archdata.iov_data;
}
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 50b26ed8432d..b670c6fdfcea 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -658,7 +658,8 @@ enum get_iov_fw_value_index {
WDW_SIZE = 3 /* Get Window Size */
};
-static resource_size_t pseries_get_iov_fw_value(struct pci_dev *dev, int resno,
+static resource_size_t pseries_get_iov_fw_value(const struct pci_dev *dev,
+ int resno,
enum get_iov_fw_value_index value)
{
const int *indexes;
--
2.39.5
^ permalink raw reply related
* [PATCH 07/11] PCI: Make pci_sriov_resource_alignment() pci_dev const
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
pci_sriov_resource_alignment() inputs struct pci_dev which it should not
need to alter to calculate alignment.
Make pci_dev pci_sriov_resource_alignment() inputs const. It requires
making pci_iov_resource_size() input const as well.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/powerpc/include/asm/machdep.h | 2 +-
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/platforms/powernv/pci-sriov.c | 4 ++--
arch/powerpc/platforms/powernv/pci.h | 3 ++-
arch/powerpc/platforms/pseries/setup.c | 2 +-
drivers/pci/iov.c | 7 ++++---
drivers/pci/pci.h | 5 +++--
include/linux/pci.h | 8 +++++---
8 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 3298eec123a3..256f9309bf4f 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -169,7 +169,7 @@ struct machdep_calls {
#ifdef CONFIG_PCI_IOV
void (*pcibios_fixup_sriov)(struct pci_dev *pdev);
- resource_size_t (*pcibios_iov_resource_alignment)(struct pci_dev *, int resno);
+ resource_size_t (*pcibios_iov_resource_alignment)(const struct pci_dev *, int resno);
int (*pcibios_sriov_enable)(struct pci_dev *pdev, u16 num_vfs);
int (*pcibios_sriov_disable)(struct pci_dev *pdev);
#endif /* CONFIG_PCI_IOV */
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8efe95a0c4ff..3c4ca90e2ab7 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -254,7 +254,7 @@ resource_size_t pcibios_default_alignment(void)
}
#ifdef CONFIG_PCI_IOV
-resource_size_t pcibios_iov_resource_alignment(struct pci_dev *pdev, int resno)
+resource_size_t pcibios_iov_resource_alignment(const struct pci_dev *pdev, int resno)
{
if (ppc_md.pcibios_iov_resource_alignment)
return ppc_md.pcibios_iov_resource_alignment(pdev, resno);
diff --git a/arch/powerpc/platforms/powernv/pci-sriov.c b/arch/powerpc/platforms/powernv/pci-sriov.c
index 7105a573aec4..8652078801f2 100644
--- a/arch/powerpc/platforms/powernv/pci-sriov.c
+++ b/arch/powerpc/platforms/powernv/pci-sriov.c
@@ -244,8 +244,8 @@ void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev)
}
}
-resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
- int resno)
+resource_size_t pnv_pci_iov_resource_alignment(const struct pci_dev *pdev,
+ int resno)
{
resource_size_t align = pci_iov_resource_size(pdev, resno);
struct pnv_phb *phb = pci_bus_to_pnvhb(pdev->bus);
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 032b2081aedb..3ac718d471c2 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -257,7 +257,8 @@ static inline struct pnv_iov_data *pnv_iov_get(const struct pci_dev *pdev)
}
void pnv_pci_ioda_fixup_iov(struct pci_dev *pdev);
-resource_size_t pnv_pci_iov_resource_alignment(struct pci_dev *pdev, int resno);
+resource_size_t pnv_pci_iov_resource_alignment(const struct pci_dev *pdev,
+ int resno);
int pnv_pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs);
int pnv_pcibios_sriov_disable(struct pci_dev *pdev);
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index b670c6fdfcea..1223dc961242 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -789,7 +789,7 @@ static void pseries_pci_fixup_iov_resources(struct pci_dev *pdev)
pseries_disable_sriov_resources(pdev);
}
-static resource_size_t pseries_pci_iov_resource_alignment(struct pci_dev *pdev,
+static resource_size_t pseries_pci_iov_resource_alignment(const struct pci_dev *pdev,
int resno)
{
const __be32 *reg;
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 91ac4e37ecb9..c86409835f73 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -150,7 +150,7 @@ static void virtfn_remove_bus(struct pci_bus *physbus, struct pci_bus *virtbus)
pci_remove_bus(virtbus);
}
-resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno)
+resource_size_t pci_iov_resource_size(const struct pci_dev *dev, int resno)
{
if (!dev->is_physfn)
return 0;
@@ -1084,7 +1084,7 @@ void pci_iov_update_resource(struct pci_dev *dev, int resno)
}
}
-resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev,
+resource_size_t __weak pcibios_iov_resource_alignment(const struct pci_dev *dev,
int resno)
{
return pci_iov_resource_size(dev, resno);
@@ -1100,7 +1100,8 @@ resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev,
* the VF BAR size multiplied by the number of VFs. The alignment
* is just the VF BAR size.
*/
-resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno)
+resource_size_t pci_sriov_resource_alignment(const struct pci_dev *dev,
+ int resno)
{
return pcibios_iov_resource_alignment(dev, resno);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4fcf5a25ad9e..710803be3a79 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -947,7 +947,8 @@ int pci_iov_init(struct pci_dev *dev);
void pci_iov_release(struct pci_dev *dev);
void pci_iov_remove(struct pci_dev *dev);
void pci_iov_update_resource(struct pci_dev *dev, int resno);
-resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev, int resno);
+resource_size_t pci_sriov_resource_alignment(const struct pci_dev *dev,
+ int resno);
void pci_restore_iov_state(struct pci_dev *dev);
int pci_iov_bus_range(struct pci_bus *bus);
void pci_iov_resource_set_size(struct pci_dev *dev, int resno, int size);
@@ -981,7 +982,7 @@ static inline int pci_iov_init(struct pci_dev *dev)
static inline void pci_iov_release(struct pci_dev *dev) { }
static inline void pci_iov_remove(struct pci_dev *dev) { }
static inline void pci_iov_update_resource(struct pci_dev *dev, int resno) { }
-static inline resource_size_t pci_sriov_resource_alignment(struct pci_dev *dev,
+static inline resource_size_t pci_sriov_resource_alignment(const struct pci_dev *dev,
int resno)
{
return 0;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..0ced3bbd08c0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2540,7 +2540,7 @@ int pci_vfs_assigned(struct pci_dev *dev);
int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
int pci_sriov_get_totalvfs(struct pci_dev *dev);
int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn);
-resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno);
+resource_size_t pci_iov_resource_size(const struct pci_dev *dev, int resno);
int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size);
u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, int num_vfs);
void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe);
@@ -2548,7 +2548,8 @@ void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe);
/* Arch may override these (weak) */
int pcibios_sriov_enable(struct pci_dev *pdev, u16 num_vfs);
int pcibios_sriov_disable(struct pci_dev *pdev);
-resource_size_t pcibios_iov_resource_alignment(struct pci_dev *dev, int resno);
+resource_size_t pcibios_iov_resource_alignment(const struct pci_dev *dev,
+ int resno);
#else
static inline int pci_iov_virtfn_bus(struct pci_dev *dev, int id)
{
@@ -2593,7 +2594,8 @@ static inline int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs)
static inline int pci_sriov_get_totalvfs(struct pci_dev *dev)
{ return 0; }
#define pci_sriov_configure_simple NULL
-static inline resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno)
+static inline resource_size_t pci_iov_resource_size(const struct pci_dev *dev,
+ int resno)
{ return 0; }
static inline int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size)
{ return -ENODEV; }
--
2.39.5
^ permalink raw reply related
* [PATCH 08/11] PCI: Convert pci_resource_alignment() input parameters to const
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
pci_resource_alignment() calculates resource alignment and should not
alter its input structs. Make its input parameters const.
It requires making also pci_cardbus_resource_alignment() input const.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/pci.h | 8 ++++----
drivers/pci/setup-cardbus.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 710803be3a79..e0fcc33dfef6 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -419,7 +419,7 @@ static inline bool pci_is_cardbus_bridge(struct pci_dev *dev)
return dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
}
#ifdef CONFIG_CARDBUS
-unsigned long pci_cardbus_resource_alignment(struct resource *res);
+unsigned long pci_cardbus_resource_alignment(const struct resource *res);
int pci_bus_size_cardbus_bridge(struct pci_bus *bus,
struct list_head *realloc_head);
int pci_cardbus_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
@@ -428,7 +428,7 @@ int pci_cardbus_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
int pci_setup_cardbus(char *str);
#else
-static inline unsigned long pci_cardbus_resource_alignment(struct resource *res)
+static inline unsigned long pci_cardbus_resource_alignment(const struct resource *res)
{
return 0;
}
@@ -1044,8 +1044,8 @@ static inline void pci_suspend_ptm(struct pci_dev *dev) { }
static inline void pci_resume_ptm(struct pci_dev *dev) { }
#endif
-static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
- struct resource *res)
+static inline resource_size_t pci_resource_alignment(const struct pci_dev *dev,
+ const struct resource *res)
{
int resno = pci_resource_num(dev, res);
diff --git a/drivers/pci/setup-cardbus.c b/drivers/pci/setup-cardbus.c
index 1ebd13a1f730..0cba404080ad 100644
--- a/drivers/pci/setup-cardbus.c
+++ b/drivers/pci/setup-cardbus.c
@@ -22,7 +22,7 @@
static unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
static unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
-unsigned long pci_cardbus_resource_alignment(struct resource *res)
+unsigned long pci_cardbus_resource_alignment(const struct resource *res)
{
if (res->flags & IORESOURCE_IO)
return pci_cardbus_io_size;
--
2.39.5
^ permalink raw reply related
* [PATCH 09/11] PCI: Move pci_resource_alignment() to setup-res.c file
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
pci_resource_alignment() is a bit one the complex side to have in a
header so put it into setup-res.c.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/pci.h | 13 ++-----------
drivers/pci/setup-res.c | 12 ++++++++++++
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index e0fcc33dfef6..472b6c2f7c4d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1044,17 +1044,8 @@ static inline void pci_suspend_ptm(struct pci_dev *dev) { }
static inline void pci_resume_ptm(struct pci_dev *dev) { }
#endif
-static inline resource_size_t pci_resource_alignment(const struct pci_dev *dev,
- const struct resource *res)
-{
- int resno = pci_resource_num(dev, res);
-
- if (pci_resource_is_iov(resno))
- return pci_sriov_resource_alignment(dev, resno);
- if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS)
- return pci_cardbus_resource_alignment(res);
- return resource_alignment(res);
-}
+resource_size_t pci_resource_alignment(const struct pci_dev *dev,
+ const struct resource *res);
resource_size_t pci_min_window_alignment(struct pci_bus *bus,
unsigned long type);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 0d203325562b..18e8775ea848 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -246,6 +246,18 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
return 0;
}
+resource_size_t pci_resource_alignment(const struct pci_dev *dev,
+ const struct resource *res)
+{
+ int resno = pci_resource_num(dev, res);
+
+ if (pci_resource_is_iov(resno))
+ return pci_sriov_resource_alignment(dev, resno);
+ if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS)
+ return pci_cardbus_resource_alignment(res);
+ return resource_alignment(res);
+}
+
/*
* For mem bridge windows, try to relocate tail remainder space to space
* before res->start if there's enough free space there. This enables
--
2.39.5
^ permalink raw reply related
* [PATCH 10/11] PCI: Lower bound bridge window alignment
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
pci_resource_alignment() does not consider bridge windows special,
yet their alignment is subject to different requirements from BAR
alignment.
Add lower bound to bridge window alignment to help callers out to
always have large enough alignment.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/setup-res.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 18e8775ea848..c15bce20815d 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -19,7 +19,10 @@
#include <linux/errno.h>
#include <linux/ioport.h>
#include <linux/cache.h>
+#include <linux/minmax.h>
#include <linux/slab.h>
+#include <linux/types.h>
+
#include "pci.h"
static void pci_std_update_resource(struct pci_dev *dev, int resno)
@@ -250,12 +253,19 @@ resource_size_t pci_resource_alignment(const struct pci_dev *dev,
const struct resource *res)
{
int resno = pci_resource_num(dev, res);
+ resource_size_t min_align = 0;
if (pci_resource_is_iov(resno))
return pci_sriov_resource_alignment(dev, resno);
+
if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS)
return pci_cardbus_resource_alignment(res);
- return resource_alignment(res);
+
+ if (pci_resource_is_bridge_win(resno) &&
+ (res->flags & (IORESOURCE_IO|IORESOURCE_MEM)))
+ min_align = pci_min_window_alignment(dev->bus, res->flags);
+
+ return max(resource_alignment(res), min_align);
}
/*
--
2.39.5
^ permalink raw reply related
* [PATCH 11/11] PCI: Return valid alignment for assigned resources
From: Ilpo Järvinen @ 2026-04-29 12:26 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Shawn Jin, linuxppc-dev,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260429122617.7324-1-ilpo.jarvinen@linux.intel.com>
When a resource is assigned, IORESOURCE_STARTALIGN flag is cleared,
resulting in pci_resource_alignment() returning 0 in some situations
(at least for bridge windows).
Add heuristic to pci_resource_alignment() which mimics start and size
alignment by taking minimum of those for an assigned resource. It may
overestimate alignment when start has large alignment but the exact
alignment information is not available and regenerating it by sizing
the bridge again is costly.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/setup-res.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index c15bce20815d..03098f159ec9 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -13,6 +13,7 @@
* Resource sorting
*/
+#include <linux/bitops.h>
#include <linux/kernel.h>
#include <linux/export.h>
#include <linux/pci.h>
@@ -265,6 +266,18 @@ resource_size_t pci_resource_alignment(const struct pci_dev *dev,
(res->flags & (IORESOURCE_IO|IORESOURCE_MEM)))
min_align = pci_min_window_alignment(dev->bus, res->flags);
+ if (resource_assigned(res)) {
+ resource_size_t start_align = 1, size_align;
+
+ size_align = roundup_pow_of_two(resource_size(res));
+ if (res->start)
+ start_align <<= __ffs(res->start);
+ else
+ start_align = size_align;
+
+ return max(min(start_align, size_align), min_align);
+ }
+
return max(resource_alignment(res), min_align);
}
--
2.39.5
^ permalink raw reply related
* Re: [PATCH V15 6/7] rust: Add PowerPC support
From: Miguel Ojeda @ 2026-04-29 12:51 UTC (permalink / raw)
To: Mukesh Kumar Chaurasiya
Cc: maddy, mpe, npiggin, chleroy, peterz, jpoimboe, jbaron, aliceryhl,
rostedt, ardb, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, nathan, nick.desaulniers+lkml, morbo, justinstitt,
daniel.almeida, fujita.tomonori, viresh.kumar, prafulrai522,
gregkh, arnd, tamird, mark.rutland, lyude, lina+kernel,
linuxppc-dev, linux-kernel, rust-for-linux, llvm, Link Mauve
In-Reply-To: <afGUgjRQJgu34Dfh@li-1a3e774c-28e4-11b2-a85c-acc9f2883e29.ibm.com>
On Wed, Apr 29, 2026 at 7:19 AM Mukesh Kumar Chaurasiya
<mkchauras@gmail.com> wrote:
>
> Upstream Issue for powerpc target.
> Link: https://github.com/rust-lang/compiler-team/issues/986
Great, thanks -- linked from the PowerPC issue:
https://github.com/Rust-for-Linux/linux/issues/105.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH V15 7/7] powerpc: Enable Rust for ppc64le
From: Miguel Ojeda @ 2026-04-29 12:52 UTC (permalink / raw)
To: Mukesh Kumar Chaurasiya
Cc: maddy, mpe, npiggin, chleroy, peterz, jpoimboe, jbaron, aliceryhl,
rostedt, ardb, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
tmgross, dakr, nathan, nick.desaulniers+lkml, morbo, justinstitt,
daniel.almeida, fujita.tomonori, viresh.kumar, prafulrai522,
gregkh, arnd, tamird, mark.rutland, lyude, lina+kernel,
linuxppc-dev, linux-kernel, rust-for-linux, llvm, Link Mauve,
Venkat Rao Bagalkote
In-Reply-To: <afGT_RB1-PZVKzE3@li-1a3e774c-28e4-11b2-a85c-acc9f2883e29.ibm.com>
On Wed, Apr 29, 2026 at 7:17 AM Mukesh Kumar Chaurasiya
<mkchauras@gmail.com> wrote:
>
> Upstream issue for powerpc64 and powerpc64le target.
> Link: https://github.com/rust-lang/compiler-team/issues/987
> Link: https://github.com/rust-lang/compiler-team/issues/988
Great, thanks -- linked from the PowerPC issue:
https://github.com/Rust-for-Linux/linux/issues/105.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH V3] tools/perf/tests: Update test_adding_kernel.sh to handle proper debuginfo check
From: Venkat @ 2026-04-29 13:31 UTC (permalink / raw)
To: Athira Rajeev
Cc: acme, jolsa, adrian.hunter, mpetlan, tmricht, maddy, irogers,
namhyung, linux-perf-users, linuxppc-dev, hbathini, Tejas.Manhas1,
Tanushree.Shah, Shivani.Nittor
In-Reply-To: <20260424172435.91725-1-atrajeev@linux.ibm.com>
> On 24 Apr 2026, at 10:54 PM, Athira Rajeev <atrajeev@linux.ibm.com> wrote:
>
> Perf test perftool-testsuite_probe fails as below:
>
> Regexp not found: "\s*probe:inode_permission(?:_\d+)?\s+\(on inode_permission(?:[:\+][0-9A-Fa-f]+)?@.+\)"
> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: listing added probe :: perf probe -l (output regexp parsing)
> -- [ PASS ] -- perf_probe :: test_adding_kernel :: removing multiple probes
> Regexp not found: "probe:vfs_mknod"
> Regexp not found: "probe:vfs_create"
> Regexp not found: "probe:vfs_rmdir"
> Regexp not found: "probe:vfs_link"
> Regexp not found: "probe:vfs_write"
> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: wildcard adding support (command exitcode + output regexp parsing)
> Regexp not found: "somenonexistingrandomstuffwhichisalsoprettylongorevenlongertoexceed64"
> Regexp not found: "in this function|at this address"
> -- [ FAIL ] -- perf_probe :: test_adding_kernel :: non-existing variable (output regexp parsing)
> ## [ FAIL ] ## perf_probe :: test_adding_kernel SUMMARY :: 3 failures found
>
> Further analysing, the failed testcase is for "test_adding_kernel".
> If the kernel debuginfo is missing, perf probe fails as below:
>
> perf probe -nf --max-probes=512 -a 'vfs_* $params'
> Failed to find the path for the kernel: No such file or directory
> Error: Failed to add events.
>
> skip_if_no_debuginfo has check to handle whether debuginfo is present
> and the testcase checks for debuginfo since this :
> commit 90d32e92011e ("tools/perf: Handle perftool-testsuite_probe
> testcases fail when kernel debuginfo is not present")
>
> Recently a change got added in "tests/shell/lib/probe_vfs_getname.sh"
> via this another fix:
> commit 92b664dcefab ("perf test probe_vfs_getname: Skip if no suitable
> line detected")
> Since this commit, first add_probe_vfs_getname is used to prevent false
> failures. And based on return code of add_probe_vfs_getname, skip_if_no_debuginfo
> is used to skip testcase if debuginfo is present. And this modified other
> testcases to call add_probe_vfs_getname first and invoke
> skip_if_no_debuginfo based on return value.
>
> The tests in test_adding_kernel.sh which depends on presence of
> debuginfo are:
> 1. probe add for inode_permission
> 2. probe max-probes option using 'vfs_* $params'
> 3. non-existing variable probing
>
> For these tests, probe check for specific line is not required.
> So call skip_if_no_debuginfo with argument to say if line check is
> needed. This is to convey to skip_if_no_debuginfo() function
> that test only needs to check for debuginfo, and not specifically
> line number. Update skip_if_no_debuginfo to use simple "perf probe"
> check if test only needs to check for debuginfo. And for other
> tests which rely on line number, use add_probe_vfs_getname()
> Update other places which uses skip_if_no_debuginfo to use argument
> as zero.
>
> With the change, verified that only three which required debuginfo only
> is skipped and others ran successfully. Also tested with debuginfo
> to make sure tests are not skipped.
>
> Reported-by: Tejas Manhas <Tejas.Manhas1@ibm.com>
> Reviewed-by: Ian Rogers <irogers@google.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
> ---
Tested this patch, by applying on top of mainline, and it fixes the reported issue.
Without this patch:
# ./perf test -v perftool-testsuite_probe
--- start ---
test child forked, pid 15772
Probing start_text
-- [ PASS ] -- perf_probe :: test_adding_blacklisted :: adding blacklisted function start_text
-- [ PASS ] -- perf_probe :: test_adding_blacklisted :: listing blacklisted probe (should NOT be listed)
## [ PASS ] ## perf_probe :: test_adding_blacklisted SUMMARY
-- [ PASS ] -- perf_probe :: test_adding_kernel :: adding probe inode_permission ::
-- [ PASS ] -- perf_probe :: test_adding_kernel :: adding probe inode_permission :: -a
-- [ PASS ] -- perf_probe :: test_adding_kernel :: adding probe inode_permission :: --add
-- [ PASS ] -- perf_probe :: test_adding_kernel :: listing added probe :: perf list
Regexp not found: "\s*probe:inode_permission(?:_\d+)?\s+\(on inode_permission(?:[:\+][0-9A-Fa-f]+)?@.+\)"
-- [ FAIL ] -- perf_probe :: test_adding_kernel :: listing added probe :: perf probe -l (output regexp parsing)
-- [ PASS ] -- perf_probe :: test_adding_kernel :: using added probe
-- [ PASS ] -- perf_probe :: test_adding_kernel :: deleting added probe
-- [ PASS ] -- perf_probe :: test_adding_kernel :: listing removed probe (should NOT be listed)
-- [ PASS ] -- perf_probe :: test_adding_kernel :: dry run :: adding probe
-- [ PASS ] -- perf_probe :: test_adding_kernel :: force-adding probes :: first probe adding
-- [ PASS ] -- perf_probe :: test_adding_kernel :: force-adding probes :: second probe adding (without force)
-- [ PASS ] -- perf_probe :: test_adding_kernel :: force-adding probes :: second probe adding (with force)
-- [ PASS ] -- perf_probe :: test_adding_kernel :: using doubled probe
-- [ PASS ] -- perf_probe :: test_adding_kernel :: removing multiple probes
Regexp not found: "probe:vfs_mknod"
Regexp not found: "probe:vfs_create"
Regexp not found: "probe:vfs_rmdir"
Regexp not found: "probe:vfs_link"
Regexp not found: "probe:vfs_write"
-- [ FAIL ] -- perf_probe :: test_adding_kernel :: wildcard adding support (command exitcode + output regexp parsing)
Regexp not found: "Failed to find"
Regexp not found: "somenonexistingrandomstuffwhichisalsoprettylongorevenlongertoexceed64"
Regexp not found: "in this function|at this address"
Line did not match any pattern: "The /lib/modules/7.1.0-rc1+/build/vmlinux file has no debug information."
Line did not match any pattern: "Rebuild with CONFIG_DEBUG_INFO=y, or install an appropriate debuginfo package."
-- [ FAIL ] -- perf_probe :: test_adding_kernel :: non-existing variable (output regexp parsing)
-- [ PASS ] -- perf_probe :: test_adding_kernel :: function with retval :: add
-- [ PASS ] -- perf_probe :: test_adding_kernel :: function with retval :: record
-- [ PASS ] -- perf_probe :: test_adding_kernel :: function argument probing :: script
## [ FAIL ] ## perf_probe :: test_adding_kernel SUMMARY :: 3 failures found
-- [ SKIP ] -- perf_probe :: test_basic :: help message :: testcase skipped
-- [ PASS ] -- perf_probe :: test_basic :: usage message
-- [ PASS ] -- perf_probe :: test_basic :: quiet switch
## [ PASS ] ## perf_probe :: test_basic SUMMARY
-- [ PASS ] -- perf_probe :: test_invalid_options :: missing argument for -a
-- [ PASS ] -- perf_probe :: test_invalid_options :: missing argument for -d
-- [ PASS ] -- perf_probe :: test_invalid_options :: missing argument for -L
-- [ PASS ] -- perf_probe :: test_invalid_options :: missing argument for -V
-- [ PASS ] -- perf_probe :: test_invalid_options :: unnecessary argument for -F
-- [ PASS ] -- perf_probe :: test_invalid_options :: unnecessary argument for -l
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -a xxx -d xxx
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -a xxx -L foo
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -a xxx -V foo
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -a xxx -l
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -a xxx -F
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -d xxx -L foo
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -d xxx -V foo
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -d xxx -l
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -d xxx -F
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -L foo -V bar
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -L foo -l
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -L foo -F
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -V foo -l
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -V foo -F
-- [ PASS ] -- perf_probe :: test_invalid_options :: mutually exclusive options :: -l -F
## [ PASS ] ## perf_probe :: test_invalid_options SUMMARY
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func:10
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func:0-10
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func:2+10
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func@source.c
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: func@source.c:1
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: source.c:1
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: source.c:1+1
-- [ PASS ] -- perf_probe :: test_line_semantics :: acceptable descriptions :: source.c:1-10
-- [ PASS ] -- perf_probe :: test_line_semantics :: unacceptable descriptions :: func:foo
-- [ PASS ] -- perf_probe :: test_line_semantics :: unacceptable descriptions :: func:1-foo
-- [ PASS ] -- perf_probe :: test_line_semantics :: unacceptable descriptions :: func:1+foo
-- [ PASS ] -- perf_probe :: test_line_semantics :: unacceptable descriptions :: func;lazy\*pattern
## [ PASS ] ## perf_probe :: test_line_semantics SUMMARY
---- end(-1) ----
137: perftool-testsuite_probe : FAILED!
With This patch:
# ./perf test -v perftool-testsuite_probe
137: perftool-testsuite_probe : Ok
Please add below tag.
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Regards,
Venkat.
> Changelog:
> v2 -> v3:
> - Update other callsites to use "skip_if_no_debuginfo 0"
> - Use "perf probe -vn --add inode_permission $params"
>
> v1 -> v2:
> - First version used "perf probe -v -L getname_flags" for debuginfo
> check. This will not catch fail string "Debuginfo-analysis is not
> supported" which is used in cases when perf is built without dwarf.
> So use "perf probe -vn add inode_permission" to capture cases when
> tools built with NO_LIBDWARF=1. This will capture debuginfo missing as
> well as tool built without dwarf case.
>
> .../tests/shell/base_probe/test_adding_kernel.sh | 15 ++++++++++++++-
> tools/perf/tests/shell/lib/probe_vfs_getname.sh | 13 ++++++++++++-
> tools/perf/tests/shell/probe_vfs_getname.sh | 7 ++++++-
> .../shell/record+script_probe_vfs_getname.sh | 7 ++++++-
> tools/perf/tests/shell/trace+probe_vfs_getname.sh | 7 ++++++-
> 5 files changed, 44 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/tests/shell/base_probe/test_adding_kernel.sh b/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
> index 555a825d55f2..f3db125c8669 100755
> --- a/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
> +++ b/tools/perf/tests/shell/base_probe/test_adding_kernel.sh
> @@ -23,10 +23,23 @@ TEST_RESULT=0
> . "$DIR_PATH/../lib/probe_vfs_getname.sh"
>
> TEST_PROBE=${TEST_PROBE:-"inode_permission"}
> +PROBE_NO_LINE_CHECK=1
>
> # set NO_DEBUGINFO to skip testcase if debuginfo is not present
> # skip_if_no_debuginfo returns 2 if debuginfo is not present
> -skip_if_no_debuginfo
> +#
> +# The perf probe checks which depends on presence of debuginfo and
> +# used in this testcase are:
> +# 1. probe add for inode_permission
> +# 2. probe max-probes option using 'vfs_* $params'
> +# 3. non-existing variable probing
> +#
> +# For these tests, probe check for specific line is not
> +# required ( add_probe_vfs_getname does that ). So call
> +# skip_if_no_debuginfo with argument as 1. This is to convey
> +# that test only needs to check for debuginfo, and not specifically
> +# line number
> +skip_if_no_debuginfo $PROBE_NO_LINE_CHECK
> if [ $? -eq 2 ]; then
> NO_DEBUGINFO=1
> fi
> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> index 88cd0e26d5f6..2c5252a38ea1 100644
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> @@ -39,7 +39,18 @@ add_probe_vfs_getname() {
> }
>
> skip_if_no_debuginfo() {
> - add_probe_vfs_getname -v 2>&1 | grep -E -q "^(Failed to find the path for the kernel|Debuginfo-analysis is not supported)|(file has no debug information)" && return 2
> + no_line_check=$1
> + debug_str="^(Failed to find the path for the kernel|Debuginfo-analysis is not supported)|(file has no debug information)"
> +
> + # search for debug_str using simple perf probe if the
> + # test only needs to check for debuginfo, and not specifically
> + # line number.
> + if [ $no_line_check -eq 1 ]; then
> + perf probe -vn --add 'inode_permission $params' 2>&1 | grep -E -q "$debug_str" && return 2
> + else
> + add_probe_vfs_getname -v 2>&1 | grep -E -q "$debug_str" && return 2
> + fi
> +
> return 1
> }
>
> diff --git a/tools/perf/tests/shell/probe_vfs_getname.sh b/tools/perf/tests/shell/probe_vfs_getname.sh
> index 5fe5682c28ce..b0878f571449 100755
> --- a/tools/perf/tests/shell/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/probe_vfs_getname.sh
> @@ -16,8 +16,13 @@ skip_if_no_perf_probe || exit 2
> add_probe_vfs_getname
> err=$?
>
> +# Invoke skip_if_no_debuginfo with argument as 0,
> +# since the test needs suitable line number for getname
> +# along with debuginfo check.
> +# Argument "1" is used when to convey that test only needs to
> +# check for debuginfo, and not specifically line number.
> if [ $err -eq 1 ] ; then
> - skip_if_no_debuginfo
> + skip_if_no_debuginfo 0
> err=$?
> fi
>
> diff --git a/tools/perf/tests/shell/record+script_probe_vfs_getname.sh b/tools/perf/tests/shell/record+script_probe_vfs_getname.sh
> index 002f7037f182..48063fc2b221 100755
> --- a/tools/perf/tests/shell/record+script_probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/record+script_probe_vfs_getname.sh
> @@ -38,8 +38,13 @@ perf_script_filenames() {
> add_probe_vfs_getname
> err=$?
>
> +# Invoke skip_if_no_debuginfo with argument as 0,
> +# since the test needs suitable line number for getname
> +# along with debuginfo check.
> +# Argument "1" is used when to convey that test only needs to
> +# check for debuginfo, and not specifically line number.
> if [ $err -eq 1 ] ; then
> - skip_if_no_debuginfo
> + skip_if_no_debuginfo 0
> err=$?
> fi
>
> diff --git a/tools/perf/tests/shell/trace+probe_vfs_getname.sh b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
> index 7a0b1145d0cd..6833fba12086 100755
> --- a/tools/perf/tests/shell/trace+probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/trace+probe_vfs_getname.sh
> @@ -28,8 +28,13 @@ trace_open_vfs_getname() {
> add_probe_vfs_getname
> err=$?
>
> +# Invoke skip_if_no_debuginfo with argument as 0,
> +# since the test needs suitable line number for getname
> +# along with debuginfo check.
> +# Argument "1" is used when to convey that test only needs to
> +# check for debuginfo, and not specifically line number.
> if [ $err -eq 1 ] ; then
> - skip_if_no_debuginfo
> + skip_if_no_debuginfo 0
> err=$?
> fi
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH 04/14] powerpc/time: Prepare to stop elapsing in dynticks-idle
From: Frederic Weisbecker @ 2026-04-29 13:42 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: LKML, Rafael J. Wysocki, Alexander Gordeev, Anna-Maria Behnsen,
Ben Segall, Boqun Feng, Christian Borntraeger, Dietmar Eggemann,
Heiko Carstens, Ingo Molnar, Jan Kiszka, Joel Fernandes,
Juri Lelli, Kieran Bingham, Madhavan Srinivasan, Mel Gorman,
Michael Ellerman, Neeraj Upadhyay, Nicholas Piggin,
Paul E . McKenney, Peter Zijlstra, Shrikanth Hegde,
Steven Rostedt, Sven Schnelle, Thomas Gleixner, Uladzislau Rezki,
Valentin Schneider, Vasily Gorbik, Vincent Guittot, Viresh Kumar,
Xin Zhao, linux-pm, linux-s390, linuxppc-dev
In-Reply-To: <2dab11d1-18ca-4da4-a33e-3f2c3c4b6320@kernel.org>
Le Mon, Apr 13, 2026 at 01:00:07PM +0200, Christophe Leroy (CS GROUP) a écrit :
> > @@ -37,11 +37,17 @@ extern void vtime_account_irq(struct task_struct *tsk, unsigned int offset);
> > extern void vtime_account_softirq(struct task_struct *tsk);
> > extern void vtime_account_hardirq(struct task_struct *tsk);
> > extern void vtime_flush(struct task_struct *tsk);
> > +extern void vtime_reset(void);
> > +extern void vtime_dyntick_start(void);
> > +extern void vtime_dyntick_stop(void);
> > #else /* !CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
> > static inline void vtime_account_irq(struct task_struct *tsk, unsigned int offset) { }
> > static inline void vtime_account_softirq(struct task_struct *tsk) { }
> > static inline void vtime_account_hardirq(struct task_struct *tsk) { }
> > static inline void vtime_flush(struct task_struct *tsk) { }
> > +static inline void vtime_reset(void) { }
> > +static inline void vtime_dyntick_start(void) { }
> > +extern inline void vtime_dyntick_stop(void) { }
>
> You mean 'static' inline, not 'extern' ?
I might have been too creative here, yes.
Thanks.
>
> Christophe
>
> > #endif
> > /*
>
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: fortify_test_known_sizes: EXPECTATION FAILED at lib/tests/fortify_kunit.c:90 (v7.0.2, ppc)
From: Christophe Leroy (CS GROUP) @ 2026-04-29 14:27 UTC (permalink / raw)
To: Erhard Furtner, linux-hardening, Kees Cook; +Cc: linuxppc-dev
In-Reply-To: <f45fd960-335c-4761-9590-ff8eccb62e9a@mailbox.org>
Le 29/04/2026 à 12:17, Erhard Furtner a écrit :
> Greetings!
>
> Getting this on my G4 DP on kernel v7.0.2 and v7.1-rc1 at running
> fortify_kunit test:
>
> [...]
> KTAP version 1
> 1..1
> KTAP version 1
> # Subtest: fortify
> # module: fortify_kunit
> 1..26
> # fortify_test_known_sizes: EXPECTATION FAILED at lib/tests/
> fortify_kunit.c:90
> Expected ({ char *__p = (char *)(stack); size_t __ret =
> (~(size_t)0); const size_t __p_size =
> __builtin_dynamic_object_size(stack, 1); if (__p_size != (~(size_t)0) &&
> __builtin_constant_p(*__p)) { size_t __p_len = __p_size - 1; if
> (__builtin_constant_p(__p[__p_len]) && __p[__p_len] == '\0') __ret =
> __builtin_strlen(__p); } __ret; }) == 5, but
> ({ char *__p = (char *)(stack); size_t __ret = (~(size_t)0);
> const size_t __p_size = __builtin_dynamic_object_size(stack, 1); if
> (__p_size != (~(size_t)0) && __builtin_constant_p(*__p)) { size_t
> __p_len = __p_size - 1; if (__builtin_constant_p(__p[__p_len]) &&
> __p[__p_len] == '\0') __ret = __builtin_strlen(__p); } __ret; }) ==
> 4294967295 (0xffffffff)
> not ok 1 fortify_test_known_sizes
I have the same on QEMU with pmac32_defconfig + FORTITY + KUNIT ...
Apparently it is due to __builtin_constant_p(*__p) returning FALSE, if I
understand correctly it is expected that it returns TRUE.
This is with GCC 15.2
Christophe
> ok 2 fortify_test_control_flow_split
> ok 3 fortify_test_alloc_size_kmalloc_const
> ok 4 fortify_test_alloc_size_kmalloc_dynamic
> ok 5 fortify_test_alloc_size_vmalloc_const
> ok 6 fortify_test_alloc_size_vmalloc_dynamic
> ok 7 fortify_test_alloc_size_kvmalloc_const
> ok 8 fortify_test_alloc_size_kvmalloc_dynamic
> ok 9 fortify_test_alloc_size_devm_kmalloc_const
> ok 10 fortify_test_alloc_size_devm_kmalloc_dynamic
> ok 11 fortify_test_realloc_size
> ok 12 fortify_test_strlen
> ok 13 fortify_test_strnlen
> ok 14 fortify_test_strcpy
> ok 15 fortify_test_strncpy
> ok 16 fortify_test_strscpy
> ok 17 fortify_test_strcat
> ok 18 fortify_test_strncat
> ok 19 fortify_test_strlcat
> ok 20 fortify_test_memcpy
> ok 21 fortify_test_memmove
> ok 22 fortify_test_memscan
> ok 23 fortify_test_memchr
> ok 24 fortify_test_memchr_inv
> ok 25 fortify_test_memcmp
> ok 26 fortify_test_kmemdup
> # fortify: pass:25 fail:1 skip:0 total:26
> # Totals: pass:25 fail:1 skip:0 total:26
>
>
> Suppose this may be a ppc/BE specific test failure as I don't get it on
> my Thinkpad T60 (x86).
>
> Full dmesg and kernel .config available on request.
>
> Greetings,
> Erhard
>
^ permalink raw reply
* Re: iov_kunit_copy_to_kvec: ASSERTION FAILED at lib/tests/kunit_iov_iter.c:63, Expected got == npages, but, got == 1 (0x1), npages == 256 (0x100) (v7.0.2, ppc)
From: LEROY Christophe @ 2026-04-29 14:55 UTC (permalink / raw)
To: Erhard Furtner, linux-hardening@vger.kernel.org, Kees Cook,
David Howells
Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2708666d-68f8-4cd3-9b25-f14ceeba3a1f@mailbox.org>
Le 29/04/2026 à 13:45, Erhard Furtner a écrit :
> Greetings!
>
> Getting this on my G4 DP on kernel v7.0.2 and v7.1-rc1 via 'modprobe -v
> kunit_iov_iter':
>
> [...]
> KTAP version 1
> 1..1
> KTAP version 1
> # Subtest: iov_iter
> # module: kunit_iov_iter
> 1..12
> # iov_kunit_copy_to_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 1 iov_kunit_copy_to_kvec
This happens in alloc_pages_bulk_noprof(), due to
pcp = pcp_spin_trylock(zone->per_cpu_pageset);
if (!pcp)
goto failed;
Because:
#ifdef CONFIG_SMP
[...]
/*
* On CONFIG_SMP=n the UP implementation of spin_trylock() never fails
and thus
* is not compatible with our locking scheme. However we do not need
pcp for
* scalability in the first place, so just make all the trylocks fail
and take
* the slow path unconditionally.
*/
#else
#define pcp_spin_trylock(ptr) \
NULL
So apparently it is expected that alloc_pages_bulk() returns 1 on non-SMP.
Christophe
> # iov_kunit_copy_from_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 2 iov_kunit_copy_from_kvec
> # iov_kunit_copy_to_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 3 iov_kunit_copy_to_bvec
> # iov_kunit_copy_from_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 4 iov_kunit_copy_from_bvec
> # iov_kunit_copy_to_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 5 iov_kunit_copy_to_folioq
> # iov_kunit_copy_from_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 6 iov_kunit_copy_from_folioq
> # iov_kunit_copy_to_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 7 iov_kunit_copy_to_xarray
> # iov_kunit_copy_from_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 8 iov_kunit_copy_from_xarray
> # iov_kunit_extract_pages_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 9 iov_kunit_extract_pages_kvec
> # iov_kunit_extract_pages_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 10 iov_kunit_extract_pages_bvec
> # iov_kunit_extract_pages_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 11 iov_kunit_extract_pages_folioq
> # iov_kunit_extract_pages_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 12 iov_kunit_extract_pages_xarray
> # iov_iter: pass:0 fail:12 skip:0 total:12
> # Totals: pass:0 fail:12 skip:0 total:12
> not ok 1 iov_iter
>
>
> Suppose this may be a ppc/BE specific test failure as I don't get it on
> my Thinkpad T60 (x86).
>
> Full dmesg and kernel .config available on request.
>
> Greetings,
> Erhard
>
^ permalink raw reply
* Re: iov_kunit_copy_to_kvec: ASSERTION FAILED at lib/tests/kunit_iov_iter.c:63, Expected got == npages, but, got == 1 (0x1), npages == 256 (0x100) (v7.0.2, ppc)
From: Christophe Leroy (CS GROUP) @ 2026-04-29 14:56 UTC (permalink / raw)
To: Erhard Furtner, linux-hardening, Kees Cook, David Howells; +Cc: linuxppc-dev
In-Reply-To: <2708666d-68f8-4cd3-9b25-f14ceeba3a1f@mailbox.org>
Le 29/04/2026 à 13:45, Erhard Furtner a écrit :
> Greetings!
>
> Getting this on my G4 DP on kernel v7.0.2 and v7.1-rc1 via 'modprobe -v
> kunit_iov_iter':
>
> [...]
> KTAP version 1
> 1..1
> KTAP version 1
> # Subtest: iov_iter
> # module: kunit_iov_iter
> 1..12
> # iov_kunit_copy_to_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 1 iov_kunit_copy_to_kvec
This happens in alloc_pages_bulk_noprof(), due to
pcp = pcp_spin_trylock(zone->per_cpu_pageset);
if (!pcp)
goto failed;
Because:
#ifdef CONFIG_SMP
[...]
/*
* On CONFIG_SMP=n the UP implementation of spin_trylock() never fails
and thus
* is not compatible with our locking scheme. However we do not need
pcp for
* scalability in the first place, so just make all the trylocks fail
and take
* the slow path unconditionally.
*/
#else
#define pcp_spin_trylock(ptr) \
NULL
So apparently it is expected that alloc_pages_bulk() returns 1 on non-SMP.
Christophe
> # iov_kunit_copy_from_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 2 iov_kunit_copy_from_kvec
> # iov_kunit_copy_to_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 3 iov_kunit_copy_to_bvec
> # iov_kunit_copy_from_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 4 iov_kunit_copy_from_bvec
> # iov_kunit_copy_to_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 5 iov_kunit_copy_to_folioq
> # iov_kunit_copy_from_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 6 iov_kunit_copy_from_folioq
> # iov_kunit_copy_to_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 7 iov_kunit_copy_to_xarray
> # iov_kunit_copy_from_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 8 iov_kunit_copy_from_xarray
> # iov_kunit_extract_pages_kvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 9 iov_kunit_extract_pages_kvec
> # iov_kunit_extract_pages_bvec: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 10 iov_kunit_extract_pages_bvec
> # iov_kunit_extract_pages_folioq: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 11 iov_kunit_extract_pages_folioq
> # iov_kunit_extract_pages_xarray: ASSERTION FAILED at lib/tests/
> kunit_iov_iter.c:63
> Expected got == npages, but
> got == 1 (0x1)
> npages == 256 (0x100)
> not ok 12 iov_kunit_extract_pages_xarray
> # iov_iter: pass:0 fail:12 skip:0 total:12
> # Totals: pass:0 fail:12 skip:0 total:12
> not ok 1 iov_iter
>
>
> Suppose this may be a ppc/BE specific test failure as I don't get it on
> my Thinkpad T60 (x86).
>
> Full dmesg and kernel .config available on request.
>
> Greetings,
> Erhard
>
^ permalink raw reply
* Re: iov_kunit_copy_to_kvec: ASSERTION FAILED at lib/tests/kunit_iov_iter.c:63, Expected got == npages, but, got == 1 (0x1), npages == 256 (0x100) (v7.0.2, ppc)
From: Erhard Furtner @ 2026-04-29 16:05 UTC (permalink / raw)
To: LEROY Christophe, linux-hardening@vger.kernel.org, Kees Cook,
David Howells
Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <d8cbbe3b-7eb0-43c4-ada7-0730f7c05f69@cs-soprasteria.com>
> This happens in alloc_pages_bulk_noprof(), due to
>
> pcp = pcp_spin_trylock(zone->per_cpu_pageset);
> if (!pcp)
> goto failed;
>
> Because:
>
> #ifdef CONFIG_SMP
> [...]
> /*
> * On CONFIG_SMP=n the UP implementation of spin_trylock() never fails
> and thus
> * is not compatible with our locking scheme. However we do not need
> pcp for
> * scalability in the first place, so just make all the trylocks fail
> and take
> * the slow path unconditionally.
> */
> #else
> #define pcp_spin_trylock(ptr) \
> NULL
>
>
> So apparently it is expected that alloc_pages_bulk() returns 1 on non-SMP.
>
> Christophe
I got SMP set as my G4 DP got 2 x 7450 cpus.
I can attach full kernel .config when I return on Saturday.
Regards,
Erhard
^ permalink raw reply
* Re: [mainline][BUG] Observed Workqueue lockups on offline CPUs.
From: Shrikanth Hegde @ 2026-04-29 17:51 UTC (permalink / raw)
To: Samir M, Paul E . McKenney, Tejun Heo
Cc: Boqun Feng, LKML, RCU, linuxppc-dev, Boqun Feng
In-Reply-To: <1b89c25b-7c1d-4ed8-adf3-ac504b6f086a@linux.ibm.com>
Hi Samir.
On 4/29/26 3:46 PM, Samir M wrote:
>
> Hi Boqun,
>
> Thank you for pointing me to the existing patches. I have tested both
> Paul's patch [1] and TJ's workqueue patch [2] on my PowerPC system (80
> CPUs), and can confirm that the workqueue lockup issue is not observed.
>
Can you try only paul's patch and confirm if the issue is fixed?
> Test Environment:
> - System: PowerPC with 80 CPUs ( e.g. PowerPC LPARs with 80 online and
> 384 possible CPUs)
> - Kernel version: Latest upstream (7.1-rc1)
>
> Regression Testing Results:
> All tests completed successfully with no issues observed:
> - Hackbench
> - Kernel selftests
> - LTP scheduler tests
>
> The workqueue lockup that was previously occurring is no longer present
> with the patches applied.
>
> References:
> [1]: https://lore.kernel.org/rcu/ed1fa6cd-7343-4ca3-8b9d-
> d699ca496f83@paulmck-laptop/
> [2]: https://lore.kernel.org/rcu/adlHKowvhn8AGXCc@slm.duckdns.org/
>
> Best regards,
> Samir
^ permalink raw reply
* Re: [PATCH v6 04/24] PCI/sysfs: Use BAR length in pci_llseek_resource() when attr->size is zero
From: Bjorn Helgaas @ 2026-04-29 19:50 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260422161407.118748-5-kwilczynski@kernel.org>
On Wed, Apr 22, 2026 at 04:13:47PM +0000, Krzysztof Wilczyński wrote:
> Both legacy and resource attributes set .f_mapping = iomem_get_mapping,
> so the default generic_file_llseek() would consult iomem_inode for the
> file size, which knows nothing about the attribute. That is why this
> custom llseek callback exists.
>
> Currently, the legacy and resource attributes have .size set at creation
> time, as such, using the attr->size is sufficient. However, the upcoming
> static resource attributes will have .size == 0 set, since they are const,
> and the .bin_size callback will be used to provide the real size to kernfs
> instead.
>
> Thus, update pci_llseek_resource() to derive the file size from the
> BAR using pci_resource_len() instead of reading the attr->size directly.
>
> The custom pci_llseek_resource() helper has been added in commit
> 24de09c16f97 ("PCI: Implement custom llseek for sysfs resource
> entries").
>
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
> ---
> drivers/pci/pci-sysfs.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 6783c6168445..73a9ae9d289b 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -909,11 +909,21 @@ static const struct attribute_group pci_dev_config_attr_group = {
> */
> static __maybe_unused loff_t
> pci_llseek_resource(struct file *filep,
> - struct kobject *kobj __always_unused,
> + struct kobject *kobj,
> const struct bin_attribute *attr,
> loff_t offset, int whence)
> {
> - return fixed_size_llseek(filep, offset, whence, attr->size);
> + struct pci_dev *pdev;
> + int bar;
> +
> + if (attr->size)
> + return fixed_size_llseek(filep, offset, whence, attr->size);
> +
> + pdev = to_pci_dev(kobj_to_dev(kobj));
> + bar = (unsigned long)attr->private;
> +
> + return fixed_size_llseek(filep, offset, whence,
> + pci_resource_len(pdev, bar));
Is there a case where using "attr->size" is better than using
"pci_resource_len(pdev, bar)"?
In other words, would the following be equivalent?
pci_llseek_resource(...)
{
...
pdev = to_pci_dev(kobj_to_dev(kobj));
bar = (unsigned long)attr->private;
return fixed_size_llseek(filep, offset, whence,
pci_resource_len(pdev, bar));
}
^ permalink raw reply
* Re: [PATCH v6 00/24] PCI: Convert all dynamic sysfs attributes to static
From: Bjorn Helgaas @ 2026-04-29 20:04 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev, moubingquan, Ian, Koba Ko, Koen Vandeputte,
Pali Rohár, Artem Savkov, Korneliusz Osmenda,
Alexander Stein
In-Reply-To: <20260422161407.118748-1-kwilczynski@kernel.org>
[+cc moubingquan, Ian, Koba, Krzysztof H, Koen, Pali, Artem,
Korneliusz, Alexander
+bcc vsd
in case any of you can verify that this fixes the issue you reported]
On Wed, Apr 22, 2026 at 04:13:43PM +0000, Krzysztof Wilczyński wrote:
> Hello,
>
> This series converts every dynamically allocated PCI sysfs attribute to
> a static const definition. After the full series, pci_sysfs_init() and
> sysfs_initialized are gone, and every sysfs file is created by the
> driver model at device_add() time.
>
> Currently, the PCI resource files (resourceN, resourceN_wc) and the
> legacy bus files (legacy_io, legacy_mem) are created dynamically
> from two unsynchronised paths:
>
> Path A: late_initcall
>
> pci_sysfs_init (late_initcall)
> sysfs_initialized = 1
> for_each_pci_dev
> pci_create_sysfs_dev_files
> sysfs_create_bin_file (resourceN, resourceN_wc)
> pci_find_next_bus
> pci_create_legacy_files
> sysfs_create_bin_file (legacy_io, legacy_mem)
>
> Path B: device registration / hotplug
>
> pci_bus_add_devices
> pci_bus_add_device
> pci_create_sysfs_dev_files
> if (!sysfs_initialized) return <- only guard
> sysfs_create_bin_file (resourceN, resourceN_wc)
>
> On most ACPI systems this does not race because PCI enumeration
> completes at subsys_initcall time, before pci_sysfs_init() runs:
>
> subsys_initcall (level 4):
> acpi_pci_root_add
> pci_bus_add_device
> pci_create_sysfs_dev_files
> if (!sysfs_initialized) <- not yet set
> return -EACCES
>
> late_initcall (level 7):
> pci_sysfs_init
> sysfs_initialized = 1
> for_each_pci_dev
> pci_create_sysfs_dev_files <- creates the files, no race
>
> On Devicetree platforms the host controller is a platform driver that
> probes via the driver model, often on a workqueue, and overlaps with the
> late_initcall:
>
> CPU 0 (late_initcall) CPU 1 (driver probe)
> --------------------------- ----------------------------
> pci_sysfs_init()
> sysfs_initialized = 1
> for_each_pci_dev(pdev) pci_bus_add_device(pdev)
> pci_create_sysfs_dev_files() pci_create_sysfs_dev_files()
> sysfs_create_bin_file() sysfs_create_bin_file()
> -> "duplicate filename"
>
> The same happens on ACPI when probing is asynchronous (hv_pci on
> Azure, RISC-V with ACPI).
>
> The duplicate causes sysfs_create_bin_file() to fail with -EEXIST.
> pci_create_resource_files() then calls pci_remove_resource_files() in
> its error unwind, tearing down files the other thread created and
> still references through pdev->res_attr[]. This has caused kernel
> panics on i.MX6 and boot failures on other platforms.
>
> Several different fixes have been proposed over the years: reordering
> the sysfs_initialized assignment, adding locks, checking
> pci_dev_is_added(), setting pdev->res_attr[] to NULL after kfree
> (which only prevents a double-free on the teardown path, not the
> error unwind removing the other thread's files). None would address the
> root cause.
>
> This has been reported a few times:
>
> - https://lore.kernel.org/linux-pci/20250702155112.40124-1-heshuan@bytedance.com/
> - https://lore.kernel.org/linux-pci/b51519d6-ce45-4b6d-8135-c70169bd110e@h-partners.com/
> - https://lore.kernel.org/linux-pci/1702093576-30405-1-git-send-email-ssengar@linux.microsoft.com/
> - https://lore.kernel.org/linux-pci/SY0P300MB04687548090B73E40AF97D8897B82@SY0P300MB0468.AUSP300.PROD.OUTLOOK.COM/
> - https://lore.kernel.org/linux-pci/20230105174736.GA1154719@bhelgaas/
> - https://lore.kernel.org/linux-pci/m3eebg9puj.fsf@t19.piap.pl/
> - https://lore.kernel.org/linux-pci/20200716110423.xtfyb3n6tn5ixedh@pali/
> - https://lore.kernel.org/linux-pci/1366196798-15929-1-git-send-email-artem.savkov@gmail.com/
> - https://bugzilla.kernel.org/show_bug.cgi?id=215515
> - https://bugzilla.kernel.org/show_bug.cgi?id=216888
Seems like some or all of these should be mentioned in the relevant
patch as "Closes:" tags?
> With static attributes the driver model creates sysfs entries once per
> device at device_add() time, under the device lock, eliminating the
> late_initcall iteration and the race along with it.
^ permalink raw reply
* Re: [PATCH v6 24/24] PCI/sysfs: Limit BAR resize attribute scope to platforms with PCI mmap
From: Bjorn Helgaas @ 2026-04-29 20:49 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260422161407.118748-25-kwilczynski@kernel.org>
On Wed, Apr 22, 2026 at 04:14:07PM +0000, Krzysztof Wilczyński wrote:
> The resourceN_resize sysfs attributes allow users to resize
> Resizable BARs (ReBAR). After a successful resize, the resource
> attribute groups are removed and recreated so that the updated
> BAR sizes are reflected in the sysfs files.
Out of curiosity, where does this removal/recreation happen? I don't
see it in pci_resize_resource() or
pci_do_resource_release_and_resize().
> Resizable BARs are a PCI Express extended capability
> (PCI_EXT_CAP_ID_REBAR), which requires PCIe extended config
> space.
It sounds like the fact that ReBAR requires extended config space is
important somehow (beyond just the fact that we can't discover ReBAR
without it)? Is there some connection between extended config space
and mmap?
> Every PCIe-capable architecture defines either HAVE_PCI_MMAP or
> ARCH_GENERIC_PCI_MMAP_RESOURCE (via the relevant arch headers
> or the generic asm-generic/pci.h fallback). On platforms that
> define neither, the resource files are not created and the sysfs
> group remove and create calls in __resource_resize_store() are
> no-ops.
What's the connection between ReBAR and mmap?
> Thus, move the resize show and store helpers, the per-BAR attribute
> definitions, and the attribute group behind the existing #ifdef
> HAVE_PCI_MMAP || ARCH_GENERIC_PCI_MMAP_RESOURCE guard, and fold
> the group reference in pci_dev_groups[] into the existing #if block.
>
> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
> ---
> drivers/pci/pci-sysfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index b167e32d55ac..37c1990124d0 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -1690,6 +1690,7 @@ static const struct attribute_group pci_dev_reset_method_attr_group = {
> .is_visible = pci_dev_reset_attr_is_visible,
> };
>
> +#if defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)
> static ssize_t __resource_resize_show(struct device *dev, int n, char *buf)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> @@ -1804,6 +1805,7 @@ static const struct attribute_group pci_dev_resource_resize_attr_group = {
> .attrs = resource_resize_attrs,
> .is_visible = resource_resize_attr_is_visible,
> };
> +#endif
>
> static struct attribute *pci_dev_dev_attrs[] = {
> &dev_attr_boot_vga.attr,
> @@ -1878,8 +1880,8 @@ const struct attribute_group *pci_dev_groups[] = {
> &pci_dev_resource_io_attr_group,
> &pci_dev_resource_uc_attr_group,
> &pci_dev_resource_wc_attr_group,
> -#endif
> &pci_dev_resource_resize_attr_group,
> +#endif
> &pci_dev_config_attr_group,
> &pci_dev_rom_attr_group,
> &pci_dev_reset_attr_group,
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v6 04/24] PCI/sysfs: Use BAR length in pci_llseek_resource() when attr->size is zero
From: Krzysztof Wilczyński @ 2026-04-29 20:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260429195055.GA312811@bhelgaas>
Hello,
> > @@ -909,11 +909,21 @@ static const struct attribute_group pci_dev_config_attr_group = {
> > */
> > static __maybe_unused loff_t
> > pci_llseek_resource(struct file *filep,
> > - struct kobject *kobj __always_unused,
> > + struct kobject *kobj,
> > const struct bin_attribute *attr,
> > loff_t offset, int whence)
> > {
> > - return fixed_size_llseek(filep, offset, whence, attr->size);
> > + struct pci_dev *pdev;
> > + int bar;
> > +
> > + if (attr->size)
> > + return fixed_size_llseek(filep, offset, whence, attr->size);
> > +
> > + pdev = to_pci_dev(kobj_to_dev(kobj));
> > + bar = (unsigned long)attr->private;
> > +
> > + return fixed_size_llseek(filep, offset, whence,
> > + pci_resource_len(pdev, bar));
>
> Is there a case where using "attr->size" is better than using
> "pci_resource_len(pdev, bar)"?
>
> In other words, would the following be equivalent?
>
> pci_llseek_resource(...)
> {
> ...
> pdev = to_pci_dev(kobj_to_dev(kobj));
> bar = (unsigned long)attr->private;
>
> return fixed_size_llseek(filep, offset, whence,
> pci_resource_len(pdev, bar));
> }
Sadly, the simplified version would break legacy attributes.
pci_llseek_resource() is shared between device-level resource
attributes and bus-level legacy attributes, both have different
semantics:
- Resource attributes (resource0, resource0_wc, ...) are per-device,
carry a BAR index in attr->private, and will have .size == 0 with
the static conversion.
- Legacy attributes (legacy_io, legacy_mem, ...) are per-bus, have
no BAR index in attr->private, and carry a fixed .size
(PCI_LEGACY_IO_SIZE, PCI_LEGACY_MEM_SIZE, etc.).
The if (attr->size) check distinguishes the two cases, where legacy
attributes have size set at compile time (no BAR index), and the
resource attributes derive it from the BAR at runtime.
For legacy attributes, the kobj belongs to a struct pci_bus, not a
struct pci_dev, so to_pci_dev(kobj_to_dev(kobj)) would be a wrong
type for container_of(). Also, the pci_resource_len() helper would
not work there either.
Thus, dropping the attr->size check and always using pci_resource_len()
would break the legacy attributes case.
The alternative would be separate llseek callbacks for both the legacy
and resource attributes, which we can add if this would be the preference
here.
I hope this clears this up a little bit.
Thank you!
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 24/24] PCI/sysfs: Limit BAR resize attribute scope to platforms with PCI mmap
From: Krzysztof Wilczyński @ 2026-04-29 21:53 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260429204932.GA318462@bhelgaas>
Hello,
> > The resourceN_resize sysfs attributes allow users to resize
> > Resizable BARs (ReBAR). After a successful resize, the resource
> > attribute groups are removed and recreated so that the updated
> > BAR sizes are reflected in the sysfs files.
>
> Out of curiosity, where does this removal/recreation happen? I don't
> see it in pci_resize_resource() or
> pci_do_resource_release_and_resize().
The __resource_resize_store() helper carries the relevant code, per:
sysfs_remove_groups(&pdev->dev.kobj, pci_dev_resource_attr_groups);
ret = pci_resize_resource(pdev, n, size, 0);
if (ret)
pci_warn(pdev, "Failed to resize BAR %d: %pe\n",
n, ERR_PTR(ret));
pci_assign_unassigned_bus_resources(bus);
if (sysfs_create_groups(&pdev->dev.kobj, pci_dev_resource_attr_groups))
pci_warn(pdev, "Failed to recreate resource groups after BAR resizing\n");
pci_write_config_word(pdev, PCI_COMMAND, cmd);
This takes place under the device_lock() with a given device woken up using
pci_config_pm_runtime_get().
See for reference:
https://elixir.bootlin.com/linux/v7.0.1/source/drivers/pci/pci-sysfs.c#L1596
> > Resizable BARs are a PCI Express extended capability
> > (PCI_EXT_CAP_ID_REBAR), which requires PCIe extended config
> > space.
>
> It sounds like the fact that ReBAR requires extended config space is
> important somehow (beyond just the fact that we can't discover ReBAR
> without it)? Is there some connection between extended config space
> and mmap?
No, there is no connection between extended configuration space and mmap.
I was trying to establish two separate facts:
- ReBAR requires PCI Express (for the extended configuration
space support).
- Every PCI Express-capable architecture defines either
HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE.
The commit message should have captured the reasoning better.
> > Every PCIe-capable architecture defines either HAVE_PCI_MMAP or
> > ARCH_GENERIC_PCI_MMAP_RESOURCE (via the relevant arch headers
> > or the generic asm-generic/pci.h fallback). On platforms that
> > define neither, the resource files are not created and the sysfs
> > group remove and create calls in __resource_resize_store() are
> > no-ops.
>
> What's the connection between ReBAR and mmap?
The connection is somewhat indirect, through the sysfs resource files.
The resourceN_resize attribute exists so userspace can resize a BAR and
then access it through the resourceN sysfs files. Those resource files
only exist on platforms that define HAVE_PCI_MMAP or
ARCH_GENERIC_PCI_MMAP_RESOURCE.
On architectures without either of these defines, pci_dev_resource_attr_groups
array will be NULL and the sysfs_remove_groups() and sysfs_create_groups()
calls in __resource_resize_store() are no-ops. And there will be no
resource files to tear down or recreate.
To add, there are some kernel drivers that need ReBAR call pci_resize_resource()
directly (e.g., amdgpu, xe, i915), not through the sysfs attribute.
The only platform without these aforementioned defines is Alpha, which is
conventional PCI only and cannot have ReBAR. So this guard removes dead
sysfs code on platforms where it can never be executed.
Hope this helps.
Thank you!
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 00/24] PCI: Convert all dynamic sysfs attributes to static
From: Krzysztof Wilczyński @ 2026-04-30 1:31 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev, moubingquan, Ian, Koba Ko, Koen Vandeputte,
Pali Rohár, Artem Savkov, Korneliusz Osmenda,
Alexander Stein
In-Reply-To: <20260429200439.GA313340@bhelgaas>
Hello,
> > This has been reported a few times:
> >
> > - https://lore.kernel.org/linux-pci/20250702155112.40124-1-heshuan@bytedance.com/
> > - https://lore.kernel.org/linux-pci/b51519d6-ce45-4b6d-8135-c70169bd110e@h-partners.com/
> > - https://lore.kernel.org/linux-pci/1702093576-30405-1-git-send-email-ssengar@linux.microsoft.com/
> > - https://lore.kernel.org/linux-pci/SY0P300MB04687548090B73E40AF97D8897B82@SY0P300MB0468.AUSP300.PROD.OUTLOOK.COM/
> > - https://lore.kernel.org/linux-pci/20230105174736.GA1154719@bhelgaas/
> > - https://lore.kernel.org/linux-pci/m3eebg9puj.fsf@t19.piap.pl/
> > - https://lore.kernel.org/linux-pci/20200716110423.xtfyb3n6tn5ixedh@pali/
> > - https://lore.kernel.org/linux-pci/1366196798-15929-1-git-send-email-artem.savkov@gmail.com/
> > - https://bugzilla.kernel.org/show_bug.cgi?id=215515
> > - https://bugzilla.kernel.org/show_bug.cgi?id=216888
>
> Seems like some or all of these should be mentioned in the relevant
> patch as "Closes:" tags?
Bugzilla would makes sense. As for the lore.kernel.org links, then if you
find these useful when included, then add these too. Surprisingly, not as
popular to do so, as I thought, per:
$ git log | grep -E 'Closes: (http?://)?lore' | wc -l
43
Having said that, the following bug looks like it might be out of scope
for us, for this series aims to fix, after having a second look at it:
https://bugzilla.kernel.org/show_bug.cgi?id=216888
Thank you!
Krzysztof
^ permalink raw reply
* [PATCH v5 net-next 00/15] Add preliminary NETC switch support for i.MX94
From: Wei Fang @ 2026-04-30 2:49 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
i.MX94 NETC (v4.3) integrates 802.1Q Ethernet switch functionality, the
switch provides advanced QoS with 8 traffic classes and a full range of
TSN standards capabilities. It has 3 user ports and 1 CPU port, and the
CPU port is connected to an internal ENETC through the pseduo link, so
instead of a back-to-back MAC, the lightweight "pseudo MAC" is used at
both ends of the pseudo link to transfer Ethernet frames. The pseudo
link provides a zero-copy interface (no serialization delay) and lower
power (less logic and memory).
Like most Ethernet switches, the NETC switch also supports a proprietary
switch tag, is used to carry in-band metadata information about frames.
This in-band metadata information can include the source port from which
the frame was received, what was the reason why this frame got forwarded
to the entity, and for the entity to indicate the precise destination
port of a frame. The NETC switch tag is added to frames after the source
MAC address. There are three types of switch tags, and each type has 1
to 4 subtypes, more details are as follows.
Forward switch tag (Type = 0): Represents forwarded frames.
- SubType = 0 - Normal frame processing.
To_Port switch tag (Type = 1): Represents frames that are to be sent to
a specific switch port.
- SubType = 0. No request to perform timestamping.
- SubType = 1. Request to perform one-step timestamping.
- SubType = 2. Request to perform two-step timestamping.
- SubType = 3. Request to perform both one-step timestamping and
two-step timestamping.
To_Host switch tag (Type = 2): Represents frames redirected or copied to
the switch management port.
- SubType = 0. Received frames redirected or copied to the switch
management port.
- SubType = 1. Received frames redirected or copied to the switch
management port with captured timestamp at the switch port where
the frame was received.
- SubType = 2. Transmit timestamp response (two-step timestamping).
Currently, this patch set supports Forward tag, SubType 0 of To_Port tag
and SubType 0 of To_Host tag. More tags will be supported in the future.
In addition, the switch supports NETC Table Management Protocol (NTMP),
some switch functionality is controlled using control messages sent to
the hardware using BD ring interface with 32B descriptors similar to the
packet Transmit BD ring used on ENETC. This interface is referred to as
the command BD ring. This is used to configure functionality where the
underlying resources may be shared between different entities or being
too large to configure using direct registers.
For this patch set, we have supported the following tables through the
command BD ring interface.
FDB Table: It contains forwarding and/or filtering information about MAC
addresses. The FDB table is used for MAC learning lookups and MAC
forwarding lookups.
VLAN Filter Table: It contains configuration and control information for
each VLAN configured on the switch.
Buffer Pool Table: It contains buffer pool configuration and operational
information. Each entry corresponds to a buffer pool. Currently, we use
this table to implement flow control feature on each port.
Ingress Port Filter Table: It contains a set of filters each capable of
classifying incoming traffic using a mix of L2, L3, and L4 parsed and
arbitrary field data. We use this table to implement host flood support
to the switch port.
The switch also supports other tables, and we will add more advanced
features through them in the future.
---
v5:
1. Move '$ref: dsa.yaml#' under the 'allOf'
2. Change '^(ethernet-)?ports$' to 'ethernet-ports'
3. Change '^(ethernet-)?port@[0-9a-f]$' to '^ethernet-port@[0-9a-f]'
4. Update node names in the DT example
5. Change port_id type from int to u32
6. Remove netc_get_switch_ports()
7. Remove unused inline functions from ntmp.h
8. Refactor the implemention of new tables due to ntmp.c is updated
8. Correct the definition of IPFT_DSCP_MASK
9. Check the return value of netdev_txq_to_tc()
10. Use pcim_* functions for automatic resource cleanup and remove
netc_switch_pci_destroy()
11. Simplify error handling paths in probe function
12. Remove PHY_INTERFACE_MODE_1000BASEX from the driver
13. Add vid check to netc_port_fdb_add/del()
14. Move netc_mac_port_rmw from patch 10 to patch 11
15. Delete the old host flood entry after adding a new one to avoid
losing the configuration if the new rule fails
16. Add netc_get_switch_capabilities() to get the FDB table capability
17. Add a maximum query count check to netc_port_fdb_dump() to prevent
infinite loops caused by hardware malfunctions.
18. Remove netc_get_buffer_pool_num(), the logic is moved to
netc_get_switch_capabilities()
19. Remove enum netc_port_mac
20. Move some register definitions from patch 14 to patch 15, as they
are not used in patch 14.
21. Patch 15 is a new patch
22. Update commit message, correct typos and add some comments
v4 link: https://lore.kernel.org/imx/20260331113025.1566878-1-wei.fang@nxp.com/
v3 link: https://lore.kernel.org/imx/20260326062917.3552334-1-wei.fang@nxp.com/
v2 link: https://lore.kernel.org/imx/20260323060752.1157031-1-wei.fang@nxp.com/
v1 link: https://lore.kernel.org/imx/20260316094152.1558671-1-wei.fang@nxp.com/
---
Wei Fang (15):
dt-bindings: net: dsa: update the description of 'dsa,member' property
dt-bindings: net: dsa: add NETC switch
net: enetc: add pre-boot initialization for i.MX94 switch
net: enetc: add basic operations to the FDB table
net: enetc: add support for the "Add" operation to VLAN filter table
net: enetc: add support for the "Update" operation to buffer pool
table
net: enetc: add support for "Add" and "Delete" operations to IPFT
net: enetc: add multiple command BD rings support
net: dsa: add NETC switch tag support
net: dsa: netc: introduce NXP NETC switch driver for i.MX94
net: dsa: netc: add phylink MAC operations
net: dsa: netc: add FDB, STP, MTU, port setup and host flooding
support
net: dsa: netc: initialize buffer pool table and implement
flow-control
net: dsa: netc: add support for the standardized counters
net: dsa: netc: add support for ethtool private statistics
.../devicetree/bindings/net/dsa/dsa.yaml | 6 +-
.../bindings/net/dsa/nxp,netc-switch.yaml | 127 ++
MAINTAINERS | 11 +
drivers/net/dsa/Kconfig | 2 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/netc/Kconfig | 14 +
drivers/net/dsa/netc/Makefile | 3 +
drivers/net/dsa/netc/netc_ethtool.c | 297 ++++
drivers/net/dsa/netc/netc_main.c | 1566 +++++++++++++++++
drivers/net/dsa/netc/netc_platform.c | 87 +
drivers/net/dsa/netc/netc_switch.h | 172 ++
drivers/net/dsa/netc/netc_switch_hw.h | 361 ++++
.../ethernet/freescale/enetc/netc_blk_ctrl.c | 185 +-
drivers/net/ethernet/freescale/enetc/ntmp.c | 381 +++-
.../ethernet/freescale/enetc/ntmp_private.h | 122 +-
include/linux/dsa/tag_netc.h | 14 +
include/linux/fsl/netc_global.h | 6 +
include/linux/fsl/ntmp.h | 187 +-
include/net/dsa.h | 2 +
include/uapi/linux/if_ether.h | 1 +
net/dsa/Kconfig | 10 +
net/dsa/Makefile | 1 +
net/dsa/tag_netc.c | 193 ++
23 files changed, 3719 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
create mode 100644 drivers/net/dsa/netc/Kconfig
create mode 100644 drivers/net/dsa/netc/Makefile
create mode 100644 drivers/net/dsa/netc/netc_ethtool.c
create mode 100644 drivers/net/dsa/netc/netc_main.c
create mode 100644 drivers/net/dsa/netc/netc_platform.c
create mode 100644 drivers/net/dsa/netc/netc_switch.h
create mode 100644 drivers/net/dsa/netc/netc_switch_hw.h
create mode 100644 include/linux/dsa/tag_netc.h
create mode 100644 net/dsa/tag_netc.c
--
2.34.1
^ permalink raw reply
* [PATCH v5 net-next 01/15] dt-bindings: net: dsa: update the description of 'dsa,member' property
From: Wei Fang @ 2026-04-30 2:49 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
In-Reply-To: <20260430024945.3413973-1-wei.fang@nxp.com>
The current description indicates that the 'dsa,member' property cannot
be set for a switch that is not part of any cluster. Vladimir thinks
that this is a case where the actual technical limitation was poorly
transposed into words when this restriction was first documented, in
commit 8c5ad1d6179d ("net: dsa: Document new binding").
The true technical limitation is that many DSA tagging protocols are
topology-unaware, and always call dsa_conduit_find_user() with a
switch_id of 0. Specifying a custom "dsa,member" property with a
non-zero switch_id would break them.
Therefore, for topology-aware switches, it is fine to specify this
property for them, even if they are not part of any cluster. Our NETC
switch is a good example which is topology-aware, the switch_id is
carried in the switch tag, but the switch_id 0 is reserved for VEPA
switch and cannot be used, so we need to use this property to assign
a non-zero switch_id for it.
Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
index 2abd036578d1..801e1411e5c2 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml
@@ -28,7 +28,11 @@ properties:
A two element list indicates which DSA cluster, and position within the
cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0,
switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster
- (single device hanging off a CPU port) must not specify this property
+ (single device hanging off a CPU port) does not usually need to specify
+ this property, and then it becomes cluster 0, switch 0. For a topology
+ aware switch, its switch index can be specified through this property,
+ even if it is not part of any cluster. Also, topology-unaware switches
+ must always be defined as index 0 of their cluster.
$ref: /schemas/types.yaml#/definitions/uint32-array
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH v5 net-next 02/15] dt-bindings: net: dsa: add NETC switch
From: Wei Fang @ 2026-04-30 2:49 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
In-Reply-To: <20260430024945.3413973-1-wei.fang@nxp.com>
Add bindings for NETC switch. This switch is a PCIe function of NETC IP,
it supports advanced QoS with 8 traffic classes and 4 drop resilience
levels, and a full range of TSN standards capabilities. The switch CPU
port connects to an internal ENETC port, which is also a PCIe function
of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
of a back-to-back MAC, because the "pseudo MAC" provides the delineation
between switch and ENETC, this translates to lower power (less logic and
memory) and lower delay (as there is no serialization delay across this
link).
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
.../bindings/net/dsa/nxp,netc-switch.yaml | 127 ++++++++++++++++++
1 file changed, 127 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
new file mode 100644
index 000000000000..988688bf4467
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NETC Switch family
+
+description: >
+ The NETC presents itself as a multi-function PCIe Root Complex Integrated
+ Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
+ advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
+ full range of TSN standards capabilities.
+
+ The CPU port of the switch connects to an internal ENETC. The switch and
+ the internal ENETC are fully integrated into the NETC IP, a back-to-back
+ MAC is not required. Instead, a light-weight "pseudo MAC" provides the
+ delineation between the switch and ENETC. This translates to lower power
+ (less logic and memory) and lower delay (as there is no serialization
+ delay across this link).
+
+maintainers:
+ - Wei Fang <wei.fang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - pci1131,eef2
+
+ reg:
+ maxItems: 1
+
+ dsa,member:
+ description: >
+ The property indicates DSA cluster and switch index. For NETC switch,
+ the valid range of the switch index is 1 ~ 7, the index is reflected
+ in the switch tag as an indication of the switch ID where the frame
+ originated. The value 0 is reserved for ENETC VEPA switch, whose ID
+ is hardwired to zero.
+
+ ethernet-ports:
+ type: object
+ patternProperties:
+ "^ethernet-port@[0-9a-f]$":
+ type: object
+ $ref: dsa-port.yaml#
+
+ properties:
+ clocks:
+ items:
+ - description: MAC transmit/receive reference clock.
+
+ clock-names:
+ items:
+ - const: ref
+
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
+ unevaluatedProperties: false
+ description:
+ Optional child node for switch port, otherwise use NETC EMDIO.
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - dsa,member
+ - ethernet-ports
+
+allOf:
+ - $ref: /schemas/pci/pci-device.yaml
+ - $ref: dsa.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pcie {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ethernet-switch@0,2 {
+ compatible = "pci1131,eef2";
+ reg = <0x200 0 0 0 0>;
+ dsa,member = <0 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_switch>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <ðphy0>;
+ phy-mode = "mii";
+ };
+
+ ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <ðphy1>;
+ phy-mode = "mii";
+ };
+
+ ethernet-port@2 {
+ reg = <2>;
+ clocks = <&scmi_clk 103>;
+ clock-names = "ref";
+ phy-handle = <ðphy2>;
+ phy-mode = "rgmii-id";
+ };
+
+ ethernet-port@3 {
+ reg = <3>;
+ ethernet = <&enetc3>;
+ phy-mode = "internal";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
--
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