* Re: [PATCH 14/16] powercap: intel_rapl: Use sysfs_emit() for cpumask show
From: Rafael J. Wysocki @ 2026-06-01 17:57 UTC (permalink / raw)
To: Yury Norov
Cc: Andrew Morton, Rasmus Villemoes, Russell King, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Thomas Gleixner, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Rafael J. Wysocki, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Heiko Stuebner, Lorenzo Pieralisi, Xu Yilun, Tom Rix,
Moritz Fischer, Yicong Yang, Jonathan Cameron, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Bjorn Helgaas, Shuai Xue, Will Deacon,
Jiucheng Xu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Robin Murphy, Jing Zhang, Xu Yang,
Linu Cherian, Gowthami Thiagarajan, Ji Sheng Teoh, Khuong Dinh,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Yury Norov, Kees Cook,
Thomas Weißschuh, Aboorva Devarajan, Ritesh Harjani (IBM),
Ilkka Koskinen, Besar Wicaksono, Ma Ke, Chengwen Feng,
linux-arm-kernel, imx, linux-kernel, linuxppc-dev,
linux-perf-users, linux-acpi, driver-core, linux-pm,
linux-rockchip, linux-fpga, linux-rdma, nvdimm, linux-pci,
linux-amlogic, linux-cxl, linux-arm-msm
In-Reply-To: <20260528183625.870813-15-ynorov@nvidia.com>
On Thu, May 28, 2026 at 8:37 PM Yury Norov <ynorov@nvidia.com> wrote:
>
> cpumask_show() is a sysfs show callback. Use sysfs_emit() and
> cpumask_pr_args() to emit the mask.
>
> This prepares for removing cpumap_print_to_pagebuf().
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
> ---
> drivers/powercap/intel_rapl_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c
> index a8dd02dff0a0..b38d4a7799a8 100644
> --- a/drivers/powercap/intel_rapl_common.c
> +++ b/drivers/powercap/intel_rapl_common.c
> @@ -1441,7 +1441,7 @@ static ssize_t cpumask_show(struct device *dev,
> }
> cpus_read_unlock();
>
> - ret = cpumap_print_to_pagebuf(true, buf, cpu_mask);
> + ret = sysfs_emit(buf, "%*pbl\n", cpumask_pr_args(cpu_mask));
>
> free_cpumask_var(cpu_mask);
>
> --
Applied (with adjusted subject and changelog) as 7.2 material, thanks!
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Gaurav Batra @ 2026-06-01 18:03 UTC (permalink / raw)
To: Harsh Prateek Bora, maddy, Venkat Rao Bagalkote, sbhat
Cc: linuxppc-dev, ritesh.list, vaibhav, donettom
In-Reply-To: <f7e3e2ec-5cbc-4ccc-bbc3-ec3ddd4e8b62@linux.ibm.com>
Hello Harsh,
response is inline
On 5/31/26 12:48 PM, Harsh Prateek Bora wrote:
> + Venkat
>
> Hi Gaurav,
> Would just like to confirm if it is tested with multiple iterations of
> hotplug of RAM (DLPAR) as well?
I tested the patch with both DLPAR of RAM and adapter, for 100
iterations each.
>
> Hi Venkat,
> Could you please help validate the patch for above-mentioned scenario
> as well?
>
> Hi Shivaprasad,
> Please share your review feedback or any additional testing scenarios
> needed?
>
> Thanks
> Harsh
>
> On 15/05/26 9:21 pm, Gaurav Batra wrote:
>> In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To
>> determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used.
>> This OF property dictates what is the max size of RAM an LPAR can have,
>> including DR added memory.
>>
>> In PowerPC, 16GB pages can be allocated at machine level and then
>> assigned to LPARs. These 16GB pages are added to LPAR memory at the time
>> of boot. The address range for these 16GB pages is above MAX RAM an LPAR
>> can have (ibm,lrdr-capacity). In the current implementation, these 16GB
>> pages are being excluded from pre-mapped TCEs. A driver can have DMA
>> buffers allocated from 16GB pages. This results in platform to raise an
>> EEH when DMA is attempted on buffers in 16GB memory range.
>>
>> commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly
>> adds TCEs for pmemory")
>>
>> Prior to the above patch, memblock_end_of_DRAM() was being used to
>> determine the MAX memory of an LPAR. This included 16GB pages as well.
>> The issue with using memblock_end_of_DRAM() is that when pmemory is
>> converted to RAM via daxctl command, the DDW engine will incorrectly try
>> to add TCEs for pmemory as well.
>>
>> Below is the address distribution of RAM, 16GB pages and pmemory for an
>> LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and
>> assigned pmemory of 8GB.
>>
>> RANGE SIZE STATE REMOVABLE BLOCK
>> 0x0000000000000000-0x0000000fffffffff 64G online yes 0-255
>> 0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151
>>
>> cat /sys/bus/nd/devices/region0/resource
>> 0x40100000000
>> cat /sys/bus/nd/devices/region0/size
>> 8589934592
>>
>> The approach to fix this problem is to revert back the code changes
>> introduced by the above patch and to stash away the MAX memory of an
>> LPAR, including 16GB pages, at the LPAR boot time. This value is then
>> used whenever TCEs are needed to be pre-mapped - enable_DDW() or,
>> iommu_mem_notifier()
>>
>> Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier
>> incorrectly adds TCEs for pmemory")
>> Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
>> ---
>>
>> Change log:
>>
>> V2 -> V3
>>
>> 1. Harsh: Remove R-b tags from the change log
>>
>> Response: Incorporated changes
>>
>> 2. Harsh: Change WARN_ON() to WARN_ONCE()
>>
>> Response: Incorporated changes
>>
>> 3. Harsh: Fix indendation
>>
>> Response: Incorporated changes
>>
>> 4. Harsh: Replace comment with a log if limit < arg->nr_pages ?
>>
>> Response: Doesn't seems to be needed since the WARN_ONCE() will
>> log this
>> scenario. I removed the comment instead.
>>
>> V1 -> V2
>>
>> 1. Harsh: Not only start_pfn, but end_pfn also needs to be within
>> allowed
>> range, which may require clamping arg->nr_pages if crossing the
>> limits.
>>
>> Response: Incorporated changes.
>>
>> arch/powerpc/platforms/pseries/iommu.c | 58 ++++++++++++++++++--------
>> 1 file changed, 41 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/iommu.c
>> b/arch/powerpc/platforms/pseries/iommu.c
>> index 3e1f915fe4f6..7bbe070006fa 100644
>> --- a/arch/powerpc/platforms/pseries/iommu.c
>> +++ b/arch/powerpc/platforms/pseries/iommu.c
>> @@ -69,6 +69,8 @@ static struct iommu_table
>> *iommu_pseries_alloc_table(int node)
>> return tbl;
>> }
>> +static phys_addr_t pseries_ddw_max_ram;
>> +
>> #ifdef CONFIG_IOMMU_API
>> static struct iommu_table_group_ops spapr_tce_table_group_ops;
>> #endif
>> @@ -1285,13 +1287,17 @@ static LIST_HEAD(failed_ddw_pdn_list);
>> static phys_addr_t ddw_memory_hotplug_max(void)
>> {
>> - resource_size_t max_addr;
>> + resource_size_t max_addr = memory_hotplug_max();
>> + struct device_node *memory;
>> -#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
>> - max_addr = hot_add_drconf_memory_max();
>> -#else
>> - max_addr = memblock_end_of_DRAM();
>> -#endif
>> + for_each_node_by_type(memory, "memory") {
>> + struct resource res;
>> +
>> + if (of_address_to_resource(memory, 0, &res))
>> + continue;
>> +
>> + max_addr = max_t(resource_size_t, max_addr, res.end + 1);
>> + }
>> return max_addr;
>> }
>> @@ -1446,7 +1452,7 @@ static struct property
>> *ddw_property_create(const char *propname, u32 liobn, u64
>> static bool enable_ddw(struct pci_dev *dev, struct device_node
>> *pdn, u64 dma_mask)
>> {
>> int len = 0, ret;
>> - int max_ram_len = order_base_2(ddw_memory_hotplug_max());
>> + int max_ram_len = order_base_2(pseries_ddw_max_ram);
>> struct ddw_query_response query;
>> struct ddw_create_response create;
>> int page_shift;
>> @@ -1668,7 +1674,7 @@ static bool enable_ddw(struct pci_dev *dev,
>> struct device_node *pdn, u64 dma_mas
>> if (direct_mapping) {
>> /* DDW maps the whole partition, so enable direct DMA
>> mapping */
>> - ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >>
>> PAGE_SHIFT,
>> + ret = walk_system_ram_range(0, pseries_ddw_max_ram >>
>> PAGE_SHIFT,
>> win64->value,
>> tce_setrange_multi_pSeriesLP_walk);
>> if (ret) {
>> dev_info(&dev->dev, "failed to map DMA window for %pOF:
>> %d\n",
>> @@ -2419,23 +2425,35 @@ static int iommu_mem_notifier(struct
>> notifier_block *nb, unsigned long action,
>> {
>> struct dma_win *window;
>> struct memory_notify *arg = data;
>> + unsigned long limit = arg->nr_pages;
>> + unsigned long max_ram_pages = pseries_ddw_max_ram >> PAGE_SHIFT;
>> int ret = 0;
>> /* This notifier can get called when onlining persistent
>> memory as well.
>> * TCEs are not pre-mapped for persistent memory. Persistent
>> memory will
>> - * always be above ddw_memory_hotplug_max()
>> + * always be above pseries_ddw_max_ram
>> */
>> + if (arg->start_pfn >= max_ram_pages)
>> + return NOTIFY_OK;
>> +
>> + /* RAM is being DLPAR'ed. The range should never exceed max ram.
>> + * Just in case, clamp the range and throw a warning.
>> + */
>> + if (arg->start_pfn + limit > max_ram_pages) {
>> + limit = max_ram_pages - arg->start_pfn;
>> + WARN_ONCE(1, "Limiting Page Range %lx - %lx to Max Mem
>> Pages: %lx\n",
>> + arg->start_pfn, arg->start_pfn + arg->nr_pages,
>> + max_ram_pages);
>> + }
>> switch (action) {
>> case MEM_GOING_ONLINE:
>> spin_lock(&dma_win_list_lock);
>> list_for_each_entry(window, &dma_win_list, list) {
>> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>> - ddw_memory_hotplug_max()) {
>> + if (window->direct) {
>> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
>> - arg->nr_pages, window->prop);
>> + limit, window->prop);
>> }
>> - /* XXX log error */
>> }
>> spin_unlock(&dma_win_list_lock);
>> break;
>> @@ -2443,12 +2461,10 @@ static int iommu_mem_notifier(struct
>> notifier_block *nb, unsigned long action,
>> case MEM_OFFLINE:
>> spin_lock(&dma_win_list_lock);
>> list_for_each_entry(window, &dma_win_list, list) {
>> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>> - ddw_memory_hotplug_max()) {
>> + if (window->direct) {
>> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
>> - arg->nr_pages, window->prop);
>> + limit, window->prop);
>> }
>> - /* XXX log error */
>> }
>> spin_unlock(&dma_win_list_lock);
>> break;
>> @@ -2532,6 +2548,14 @@ void __init iommu_init_early_pSeries(void)
>> register_memory_notifier(&iommu_mem_nb);
>> set_pci_dma_ops(&dma_iommu_ops);
>> +
>> + /* During init determine the max memory an LPAR can have and set
>> it. This
>> + * will be used for pre-mapping RAM in DDW.
>> memblock_end_of_DRAM() can
>> + * change during the running of LPAR - daxctl can add pmemory as
>> + * "system-ram". This memory range should not be pre-mapped in
>> DDW since
>> + * the address of pmemory can be much higher than the DDW size.
>> + */
>> + pseries_ddw_max_ram = ddw_memory_hotplug_max();
>> }
>> static int __init disable_multitce(char *str)
>>
>> base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
>
^ permalink raw reply
* Re: [PATCH 00/11] Convert moduleparams to seq_buf
From: Kees Cook @ 2026-06-01 19:59 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <88c5ca1d-eeda-4023-bc7a-397b92780db9@suse.com>
On Tue, May 26, 2026 at 08:53:06AM +0200, Petr Pavlu wrote:
> On 5/21/26 3:33 PM, Kees Cook wrote:
> > Hi,
> >
> > I tried to trim the CC list here, but it's still pretty huge...
> >
> > We've had a long-standing issue with "write to a string pointer" callbacks
> > that don't bounds check the destination (and for which the bounds is
> > also not part of the callback prototype, even if it is "known" to be
> > PAGE_SIZE, which sysfs_emit() depends on). Both moduleparams and sysfs
> > use this pattern. As a first step, and to test the migration method,
> > migrate moduleparams first.
> >
> > There are 2 "mechanical" treewide patches that are handled by Coccinelle:
> > - treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
> > - treewide: Convert custom kernel_param_ops .get callbacks to seq_buf via cocci
> >
> > The last treewide patch is manual, and may need to be broken up into
> > per-subsystem patches, though I'd prefer to avoid this, as it would
> > extend the migration from 1 relase to at least 2 releases. (1 to
> > release the migration infrastructure, then 1 release to collect all the
> > subsystem changes, and possibly 1 more release to remove the migration
> > infrastructure.)
> >
> > Thoughts, questions?
>
> This looks reasonable to me. I added a few minor comments on the patches
> but they already look solid.
Thanks for the review! I'll get a v2 prepared with your notes addressed. :)
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: Matthew Wilcox @ 2026-06-01 20:23 UTC (permalink / raw)
To: David Laight
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Jason Gunthorpe, Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521174631.71a06440@pumpkin>
On Thu, May 21, 2026 at 05:46:31PM +0100, David Laight wrote:
> On Thu, 21 May 2026 06:33:14 -0700
> Kees Cook <kees@kernel.org> wrote:
> > Collect each element into a temporary PAGE_SIZE buffer first and then
> > copy only the remaining space into the caller's page buffer.
>
> Should this be using a 4k buffer on all architectures?
> Initially perhaps just using a different name for the constant until
> all the associated PAGE_SIZE limits have been removed.
If we're acually going to think about this, even 4KiB is too big.
An 80x25 terminal is 2000 bytes (assuming no utf8), so 4KiB is two
entire screenfuls. Limiting to 2048 would seem reasonable to me.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/prom: fix /chosen properties read from wrong node
From: Rob Herring @ 2026-06-01 22:01 UTC (permalink / raw)
To: Sang-Heon Jeon
Cc: maddy, mpe, npiggin, chleroy, saravanak, linuxppc-dev, devicetree
In-Reply-To: <20260510171353.1406018-2-ekffu200098@gmail.com>
On Mon, May 11, 2026 at 02:13:52AM +0900, Sang-Heon Jeon wrote:
> Commit 60f20d84dc81 ("of/fdt: Rework early_init_dt_scan_chosen() to
> call directly") changed early_init_dt_scan_chosen() to be called
> directly instead of via of_scan_flat_dt(). After this change,
> early_init_dt_scan_chosen_ppc() does not behave as intended in either
> case below:
>
> - /chosen(or /chosen@0) exists: early_init_dt_scan_chosen() always
> succeeds, so early_init_dt_scan_chosen_ppc() then reads properties
> from the root node (first iteration) instead of chosen node.
>
> - /chosen does not exist:
> - Until commit 064e32dc5b03 ("of: fdt: Honor CONFIG_CMDLINE* even without
> /chosen node, take 2"), early_init_dt_scan_chosen() returns -ENOENT
> and early_init_dt_scan_chosen_ppc() returns 0. So of_scan_flat_dt()
> iterates over all remaining nodes. Not a bug but unnecessary.
> - After above commit, early_init_dt_scan_chosen() returns 0 and
> early_init_dt_scan_chosen_ppc() returns 1. So it reads properties
> from the root node (first iteration) instead of chosen node, same as
> the chosen node exist case above.
>
> Instead of using of_scan_flat_dt() for chosen node handling, first call
> early_init_dt_scan_chosen() directly to handle common chosen node
> properties. Then call early_init_dt_scan_chosen_ppc(), which is updated
> to handle powerpc-specific chosen node properties.
>
> Both now look up chosen node directly to avoid reading from the wrong node.
>
> Fixes: 60f20d84dc81 ("of/fdt: Rework early_init_dt_scan_chosen() to call directly")
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] of/fdt: make early_init_dt_scan_chosen() return void
From: Rob Herring @ 2026-06-01 22:03 UTC (permalink / raw)
To: Sang-Heon Jeon
Cc: maddy, mpe, npiggin, chleroy, saravanak, linuxppc-dev, devicetree
In-Reply-To: <20260510171353.1406018-3-ekffu200098@gmail.com>
On Mon, May 11, 2026 at 02:13:53AM +0900, Sang-Heon Jeon wrote:
> Since commit 064e32dc5b03 ("of: fdt: Honor CONFIG_CMDLINE* even
> without /chosen node, take 2"), early_init_dt_scan_chosen() always
> returns 0, so the return value checks at its callers have become
> dead code.
>
> Drop the return value, change the function to return void, and
> update its declaration and callers accordingly. No functional
> change.
>
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> dt-test result
>
> [ 0.684136] ### dt-test ### start of unittest - you will see error messages
> [ 0.685849] ### dt-test ### EXPECT \ : Duplicate name in testcase-data, renamed to "duplicate-name#1"
> [ 0.685870] Duplicate name in testcase-data, renamed to "duplicate-name#1"
> [ 0.689496] ### dt-test ### EXPECT / : Duplicate name in testcase-data, renamed to "duplicate-name#1"
>
> ...
>
> [ 1.693384] ### dt-test ### EXPECT / : OF: resolver: overlay phandle fixup failed: -22
> [ 1.693386] ### dt-test ### EXPECT / : OF: resolver: node label 'this_label_does_not_exist' not found in live devicetree symbols table
> [ 1.694968] ### dt-test ### end of unittest - 405 passed, 0 failed
> ---
> drivers/of/fdt.c | 10 ++--------
> include/linux/of_fdt.h | 2 +-
> 2 files changed, 3 insertions(+), 9 deletions(-)
Looks like this is dependent on patch 1, so I'm assuming the PPC folks
will take the series.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 09/23] of: platform: use platform_device_set_of_node()
From: Rob Herring (Arm) @ 2026-06-01 23:35 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Sebastian Hesselbarth, Doug Berger,
Madhavan Srinivasan, Bin Liu, Andrew Lunn,
Pengutronix Kernel Team, Thierry Reding, Nicholas Piggin,
Simona Vetter, brgl, Eric Dumazet, Fabio Estevam, David Airlie,
linux-arm-msm, Benjamin Herrenschmidt, Will Deacon, iommu,
Ulf Hansson, Matthew Brost, Florian Fainelli, Krzysztof Kozlowski,
Sascha Hauer, Thomas Hellström, Philipp Zabel,
linux-arm-kernel, David S. Miller, intel-xe, Andi Shyti,
linux-kernel, Rafael J. Wysocki, netdev, linux-sound,
Srinivas Kandagatla, linux-mips,
Broadcom internal kernel review list, driver-core,
Andy Shevchenko, Ilpo Järvinen, imx, Vinod Koul, Peter Chen,
linux-usb, Michael Ellerman, Paul Cercueil, Greg Kroah-Hartman,
Joerg Roedel, Christophe Leroy (CS GROUP), Jakub Kicinski,
Paolo Abeni, Danilo Krummrich, Mark Brown, Robin Murphy, Frank Li,
devicetree, linux-i2c, Rodrigo Vivi, linuxppc-dev,
Saravana Kannan, Maximilian Luz, linux-pm, Hans de Goede,
dri-devel, platform-driver-x86
In-Reply-To: <20260521-pdev-fwnode-ref-v1-9-88c324a1b8d2@oss.qualcomm.com>
On Thu, 21 May 2026 10:36:32 +0200, Bartosz Golaszewski wrote:
> Ahead of reworking the reference counting logic for platform devices,
> encapsulate the assignment of the OF node for dynamically allocated
> platform devices with the provided helper.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/of/platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 11/16] nvdimm: Use sysfs_emit() for cpumask show callback
From: Alison Schofield @ 2026-06-02 0:38 UTC (permalink / raw)
To: Yury Norov
Cc: Andrew Morton, Rasmus Villemoes, Russell King, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Thomas Gleixner, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Rafael J. Wysocki, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Heiko Stuebner, Lorenzo Pieralisi, Xu Yilun, Tom Rix,
Moritz Fischer, Yicong Yang, Jonathan Cameron, Dennis Dalessandro,
Jason Gunthorpe, Leon Romanovsky, Dan Williams, Vishal Verma,
Dave Jiang, Ira Weiny, Bjorn Helgaas, Shuai Xue, Will Deacon,
Jiucheng Xu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Robin Murphy, Jing Zhang, Xu Yang,
Linu Cherian, Gowthami Thiagarajan, Ji Sheng Teoh, Khuong Dinh,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Yury Norov, Kees Cook,
Thomas Weißschuh, Aboorva Devarajan, Ritesh Harjani (IBM),
Ilkka Koskinen, Besar Wicaksono, Ma Ke, Chengwen Feng,
linux-arm-kernel, imx, linux-kernel, linuxppc-dev,
linux-perf-users, linux-acpi, driver-core, linux-pm,
linux-rockchip, linux-fpga, linux-rdma, nvdimm, linux-pci,
linux-amlogic, linux-cxl, linux-arm-msm
In-Reply-To: <20260528183625.870813-12-ynorov@nvidia.com>
On Thu, May 28, 2026 at 02:36:18PM -0400, Yury Norov wrote:
> nvdimm_pmu_cpumask_show() is a sysfs show callback. Use sysfs_emit() and
> cpumask_pr_args() to emit the mask.
>
> This prepares for removing cpumap_print_to_pagebuf().
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Thanks! Reviewed and applied to nvdimm/nvdimm.git (libnvdimm-for-next)
https://git.kernel.org/nvdimm/nvdimm/c/1e7afc906f2f
>
^ permalink raw reply
* Re: [PATCH v15 00/23] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-06-02 1:43 UTC (permalink / raw)
To: Baoquan He
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
sourabhjain, thuth, ardb, masahiroy, gshan, james.morse, maz,
leitao, yeoreum.yun, coxu, suzuki.poulose, cfsworks, osandov,
jbohac, ryan.roberts, tangyouling, ritesh.list, adityag, hbathini,
bjorn, songshuaishuai, vishal.moola, junhui.liu,
djordje.todorovic, austin.kim, namcao, djbw, chao.gao, seanjc,
fuqiang.wang, liaoyuanhong, makb, graf, piliu, rafael.j.wysocki,
mario.limonciello, jbouron, chenjiahao16, guoren, bauerman, bgwin,
takahiro.akashi, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <ah2Lx7KHI60tzd0v@MiWiFi-R3L-srv>
On 6/1/2026 9:40 PM, Baoquan He wrote:
> Hi Jinjie,
>
> On 06/01/26 at 05:47pm, Jinjie Ruan wrote:
> ...snip...
>> Changes in v15:
>> - Unify the subject prefix formats as Huacai suggested.
>> - Fix powerpc pre-existing NULL pointer dereference [Sashiko [1]]
>> - Fix powerpc pre-existing __merge_memory_ranges() memory range
>> truncation [Sashiko [1]].
>> - Fix pre-existing arm64 CMA page leaks [Sashiko[2]].
>> - Fix pre-existing crash_load_dm_crypt_keys() Use-After-Free and
>> Double Free issue [Sashiko[3]].
>> - Fix vfree(headers) and uninitialized variables issue
>> and simplify the fix [Sashiko[2]].
>> - As walk_system_ram_res() and for_each_mem_range() use different
>> lock, unify and simplify the fix of TOCTOU buffer overflow via memory
>> region padding [Sashiko[4]].
>> - Fix the arm64 crash dump issues in Sashiko[5].
>> - Link to v14: https://lore.kernel.org/all/20260525084932.934910-1-ruanjinjie@huawei.com/
>
> Do these Fixes have anything with the main target of this patch series
> you mentioned in cover-letter:"arm64/riscv: Add support for crashkernel CMA"?
> The patches become more and more in each new version, I am wondering if
> it relies on these Fixes patches to implement your adding support for
> crashkernel CMA on arm64/risc-v.
>
> If not relying on them, could you split them into different patchset
> on different purpose?
Hi Baoquan,
Thank you for your valuable guidance.
You are absolutely right. Most of these fix patches are indeed not
strictly related to the core implementation of the crashkernel CMA
support. They are pre-existing bugs in the surrounding kexec/crash code
that were flagged during our review.
Previously, Andrew suggested taking a look at the code review comments
from the Sashiko AI system, which is why these fixes kept expanding. I
completely agree with your advice that there is no need to keep them
together. I will split them into two completely different patchsets
based on their purpose:
1. A cleaner version of this series, strictly focused on adding the core
crashkernel CMA support for arm64/riscv.
2. One standalone bugfix patchset dedicated entirely to fixing these
pre-existing issues.
By the way, I would also appreciate some advice on how to handle further
AI reviews. It seems that the more code we touch or refactor to fix
these pre-existing issues, the more tangential bugs the AI flags in the
newly exposed areas, making the series extremely difficult to converge.
Should I continue to address all AI-reported bugs associated with the
surrounding code in this series, or should we draw a strict line
and only focus on the core CMA logic moving forward?
I will prepare the split patchsets shortly. Thanks again for
straightening this out!
Best regards,
Jinjie Ruan
>
> Thanks
> Baoquan
>
>>
>> [1]: https://lore.kernel.org/all/20260525092207.96B9D1F000E9@smtp.kernel.org/
>> [2]: https://lore.kernel.org/all/20260525091149.1A1E01F00A3D@smtp.kernel.org/
>> [3]: https://lore.kernel.org/all/20260525105227.3C2421F000E9@smtp.kernel.org/
>> [4]: https://lore.kernel.org/all/20260525095447.944E11F000E9@smtp.kernel.org/
>> [5]: https://lore.kernel.org/all/20260525101746.9959D1F000E9@smtp.kernel.org/
>>
>> Changes in v14:
>> - Fix image->elf_headers memory leak during retry loop for arm64 as Sashiko
>> AI code review pointed out.
>> - Solve the hotplug notifier arch_crash_handle_hotplug_event() AA
>> self-deadlock problem as Sashiko AI code review pointed out.
>> - Fix the TOCTOU issue in prepare_elf_headers() by get_online_mems().
>> - -ENOMEM -> -EAGAIN as Breno suggested.
>> - Add support for arm64 crash hotplug.
>> - Link to v13: https://lore.kernel.org/all/20260511030454.1730881-1-ruanjinjie@huawei.com/
>>
[...]
>> 24 files changed, 430 insertions(+), 338 deletions(-)
>> create mode 100644 arch/arm64/kernel/crash.c
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v15 00/23] arm64/riscv: Add support for crashkernel CMA reservation
From: Baoquan He @ 2026-06-02 3:06 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
sourabhjain, thuth, ardb, masahiroy, gshan, james.morse, maz,
leitao, yeoreum.yun, coxu, suzuki.poulose, cfsworks, osandov,
jbohac, ryan.roberts, tangyouling, ritesh.list, adityag, hbathini,
bjorn, songshuaishuai, vishal.moola, junhui.liu,
djordje.todorovic, austin.kim, namcao, djbw, chao.gao, seanjc,
fuqiang.wang, liaoyuanhong, makb, graf, piliu, rafael.j.wysocki,
mario.limonciello, jbouron, chenjiahao16, guoren, bauerman, bgwin,
takahiro.akashi, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <1a459706-80db-43d8-b163-76fc09da338d@huawei.com>
On 06/02/26 at 09:43am, Jinjie Ruan wrote:
>
>
> On 6/1/2026 9:40 PM, Baoquan He wrote:
> > Hi Jinjie,
> >
> > On 06/01/26 at 05:47pm, Jinjie Ruan wrote:
> > ...snip...
> >> Changes in v15:
> >> - Unify the subject prefix formats as Huacai suggested.
> >> - Fix powerpc pre-existing NULL pointer dereference [Sashiko [1]]
> >> - Fix powerpc pre-existing __merge_memory_ranges() memory range
> >> truncation [Sashiko [1]].
> >> - Fix pre-existing arm64 CMA page leaks [Sashiko[2]].
> >> - Fix pre-existing crash_load_dm_crypt_keys() Use-After-Free and
> >> Double Free issue [Sashiko[3]].
> >> - Fix vfree(headers) and uninitialized variables issue
> >> and simplify the fix [Sashiko[2]].
> >> - As walk_system_ram_res() and for_each_mem_range() use different
> >> lock, unify and simplify the fix of TOCTOU buffer overflow via memory
> >> region padding [Sashiko[4]].
> >> - Fix the arm64 crash dump issues in Sashiko[5].
> >> - Link to v14: https://lore.kernel.org/all/20260525084932.934910-1-ruanjinjie@huawei.com/
> >
> > Do these Fixes have anything with the main target of this patch series
> > you mentioned in cover-letter:"arm64/riscv: Add support for crashkernel CMA"?
> > The patches become more and more in each new version, I am wondering if
> > it relies on these Fixes patches to implement your adding support for
> > crashkernel CMA on arm64/risc-v.
> >
> > If not relying on them, could you split them into different patchset
> > on different purpose?
>
> Hi Baoquan,
>
> Thank you for your valuable guidance.
>
> You are absolutely right. Most of these fix patches are indeed not
> strictly related to the core implementation of the crashkernel CMA
> support. They are pre-existing bugs in the surrounding kexec/crash code
> that were flagged during our review.
>
> Previously, Andrew suggested taking a look at the code review comments
> from the Sashiko AI system, which is why these fixes kept expanding. I
> completely agree with your advice that there is no need to keep them
> together. I will split them into two completely different patchsets
> based on their purpose:
>
> 1. A cleaner version of this series, strictly focused on adding the core
> crashkernel CMA support for arm64/riscv.
>
> 2. One standalone bugfix patchset dedicated entirely to fixing these
> pre-existing issues.
>
> By the way, I would also appreciate some advice on how to handle further
> AI reviews. It seems that the more code we touch or refactor to fix
> these pre-existing issues, the more tangential bugs the AI flags in the
> newly exposed areas, making the series extremely difficult to converge.
>
> Should I continue to address all AI-reported bugs associated with the
> surrounding code in this series, or should we draw a strict line
> and only focus on the core CMA logic moving forward?
Then please post patches to focus on the core implementation of the
crashkernel CMA support. If any AI reported bugs are raised but not
relatd to it, you can add note in cover-letter or explain somewhere
to tell whehter it's caused by the core code and how you want
to deal with it. Otherwise, you could go round and round of new posting
and still can't see when it ends up.
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Harsh Prateek Bora @ 2026-06-02 3:57 UTC (permalink / raw)
To: Gaurav Batra, maddy, Venkat Rao Bagalkote, sbhat
Cc: linuxppc-dev, ritesh.list, vaibhav, donettom
In-Reply-To: <2a1694c2-d3ed-475b-a4a6-2383d6229c3b@linux.ibm.com>
On 01/06/26 11:33 pm, Gaurav Batra wrote:
> Hello Harsh,
>
>
> response is inline
>
>
> On 5/31/26 12:48 PM, Harsh Prateek Bora wrote:
>> + Venkat
>>
>> Hi Gaurav,
>> Would just like to confirm if it is tested with multiple iterations of
>> hotplug of RAM (DLPAR) as well?
> I tested the patch with both DLPAR of RAM and adapter, for 100
> iterations each.
Thanks for confirming! Feel free to add:
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
>>
>> Hi Venkat,
>> Could you please help validate the patch for above-mentioned scenario
>> as well?
>>
>> Hi Shivaprasad,
>> Please share your review feedback or any additional testing scenarios
>> needed?
>>
>> Thanks
>> Harsh
>>
>> On 15/05/26 9:21 pm, Gaurav Batra wrote:
>>> In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To
>>> determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used.
>>> This OF property dictates what is the max size of RAM an LPAR can have,
>>> including DR added memory.
>>>
>>> In PowerPC, 16GB pages can be allocated at machine level and then
>>> assigned to LPARs. These 16GB pages are added to LPAR memory at the time
>>> of boot. The address range for these 16GB pages is above MAX RAM an LPAR
>>> can have (ibm,lrdr-capacity). In the current implementation, these 16GB
>>> pages are being excluded from pre-mapped TCEs. A driver can have DMA
>>> buffers allocated from 16GB pages. This results in platform to raise an
>>> EEH when DMA is attempted on buffers in 16GB memory range.
>>>
>>> commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly
>>> adds TCEs for pmemory")
>>>
>>> Prior to the above patch, memblock_end_of_DRAM() was being used to
>>> determine the MAX memory of an LPAR. This included 16GB pages as well.
>>> The issue with using memblock_end_of_DRAM() is that when pmemory is
>>> converted to RAM via daxctl command, the DDW engine will incorrectly try
>>> to add TCEs for pmemory as well.
>>>
>>> Below is the address distribution of RAM, 16GB pages and pmemory for an
>>> LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and
>>> assigned pmemory of 8GB.
>>>
>>> RANGE SIZE STATE REMOVABLE BLOCK
>>> 0x0000000000000000-0x0000000fffffffff 64G online yes 0-255
>>> 0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151
>>>
>>> cat /sys/bus/nd/devices/region0/resource
>>> 0x40100000000
>>> cat /sys/bus/nd/devices/region0/size
>>> 8589934592
>>>
>>> The approach to fix this problem is to revert back the code changes
>>> introduced by the above patch and to stash away the MAX memory of an
>>> LPAR, including 16GB pages, at the LPAR boot time. This value is then
>>> used whenever TCEs are needed to be pre-mapped - enable_DDW() or,
>>> iommu_mem_notifier()
>>>
>>> Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier
>>> incorrectly adds TCEs for pmemory")
>>> Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
>>> ---
>>>
>>> Change log:
>>>
>>> V2 -> V3
>>>
>>> 1. Harsh: Remove R-b tags from the change log
>>>
>>> Response: Incorporated changes
>>>
>>> 2. Harsh: Change WARN_ON() to WARN_ONCE()
>>>
>>> Response: Incorporated changes
>>>
>>> 3. Harsh: Fix indendation
>>>
>>> Response: Incorporated changes
>>>
>>> 4. Harsh: Replace comment with a log if limit < arg->nr_pages ?
>>>
>>> Response: Doesn't seems to be needed since the WARN_ONCE() will
>>> log this
>>> scenario. I removed the comment instead.
>>>
>>> V1 -> V2
>>>
>>> 1. Harsh: Not only start_pfn, but end_pfn also needs to be within
>>> allowed
>>> range, which may require clamping arg->nr_pages if crossing the
>>> limits.
>>>
>>> Response: Incorporated changes.
>>>
>>> arch/powerpc/platforms/pseries/iommu.c | 58 ++++++++++++++++++--------
>>> 1 file changed, 41 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/
>>> platforms/pseries/iommu.c
>>> index 3e1f915fe4f6..7bbe070006fa 100644
>>> --- a/arch/powerpc/platforms/pseries/iommu.c
>>> +++ b/arch/powerpc/platforms/pseries/iommu.c
>>> @@ -69,6 +69,8 @@ static struct iommu_table
>>> *iommu_pseries_alloc_table(int node)
>>> return tbl;
>>> }
>>> +static phys_addr_t pseries_ddw_max_ram;
>>> +
>>> #ifdef CONFIG_IOMMU_API
>>> static struct iommu_table_group_ops spapr_tce_table_group_ops;
>>> #endif
>>> @@ -1285,13 +1287,17 @@ static LIST_HEAD(failed_ddw_pdn_list);
>>> static phys_addr_t ddw_memory_hotplug_max(void)
>>> {
>>> - resource_size_t max_addr;
>>> + resource_size_t max_addr = memory_hotplug_max();
>>> + struct device_node *memory;
>>> -#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
>>> - max_addr = hot_add_drconf_memory_max();
>>> -#else
>>> - max_addr = memblock_end_of_DRAM();
>>> -#endif
>>> + for_each_node_by_type(memory, "memory") {
>>> + struct resource res;
>>> +
>>> + if (of_address_to_resource(memory, 0, &res))
>>> + continue;
>>> +
>>> + max_addr = max_t(resource_size_t, max_addr, res.end + 1);
>>> + }
>>> return max_addr;
>>> }
>>> @@ -1446,7 +1452,7 @@ static struct property
>>> *ddw_property_create(const char *propname, u32 liobn, u64
>>> static bool enable_ddw(struct pci_dev *dev, struct device_node
>>> *pdn, u64 dma_mask)
>>> {
>>> int len = 0, ret;
>>> - int max_ram_len = order_base_2(ddw_memory_hotplug_max());
>>> + int max_ram_len = order_base_2(pseries_ddw_max_ram);
>>> struct ddw_query_response query;
>>> struct ddw_create_response create;
>>> int page_shift;
>>> @@ -1668,7 +1674,7 @@ static bool enable_ddw(struct pci_dev *dev,
>>> struct device_node *pdn, u64 dma_mas
>>> if (direct_mapping) {
>>> /* DDW maps the whole partition, so enable direct DMA
>>> mapping */
>>> - ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >>
>>> PAGE_SHIFT,
>>> + ret = walk_system_ram_range(0, pseries_ddw_max_ram >>
>>> PAGE_SHIFT,
>>> win64->value,
>>> tce_setrange_multi_pSeriesLP_walk);
>>> if (ret) {
>>> dev_info(&dev->dev, "failed to map DMA window for %pOF:
>>> %d\n",
>>> @@ -2419,23 +2425,35 @@ static int iommu_mem_notifier(struct
>>> notifier_block *nb, unsigned long action,
>>> {
>>> struct dma_win *window;
>>> struct memory_notify *arg = data;
>>> + unsigned long limit = arg->nr_pages;
>>> + unsigned long max_ram_pages = pseries_ddw_max_ram >> PAGE_SHIFT;
>>> int ret = 0;
>>> /* This notifier can get called when onlining persistent
>>> memory as well.
>>> * TCEs are not pre-mapped for persistent memory. Persistent
>>> memory will
>>> - * always be above ddw_memory_hotplug_max()
>>> + * always be above pseries_ddw_max_ram
>>> */
>>> + if (arg->start_pfn >= max_ram_pages)
>>> + return NOTIFY_OK;
>>> +
>>> + /* RAM is being DLPAR'ed. The range should never exceed max ram.
>>> + * Just in case, clamp the range and throw a warning.
>>> + */
>>> + if (arg->start_pfn + limit > max_ram_pages) {
>>> + limit = max_ram_pages - arg->start_pfn;
>>> + WARN_ONCE(1, "Limiting Page Range %lx - %lx to Max Mem
>>> Pages: %lx\n",
>>> + arg->start_pfn, arg->start_pfn + arg->nr_pages,
>>> + max_ram_pages);
>>> + }
>>> switch (action) {
>>> case MEM_GOING_ONLINE:
>>> spin_lock(&dma_win_list_lock);
>>> list_for_each_entry(window, &dma_win_list, list) {
>>> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>>> - ddw_memory_hotplug_max()) {
>>> + if (window->direct) {
>>> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
>>> - arg->nr_pages, window->prop);
>>> + limit, window->prop);
>>> }
>>> - /* XXX log error */
>>> }
>>> spin_unlock(&dma_win_list_lock);
>>> break;
>>> @@ -2443,12 +2461,10 @@ static int iommu_mem_notifier(struct
>>> notifier_block *nb, unsigned long action,
>>> case MEM_OFFLINE:
>>> spin_lock(&dma_win_list_lock);
>>> list_for_each_entry(window, &dma_win_list, list) {
>>> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>>> - ddw_memory_hotplug_max()) {
>>> + if (window->direct) {
>>> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
>>> - arg->nr_pages, window->prop);
>>> + limit, window->prop);
>>> }
>>> - /* XXX log error */
>>> }
>>> spin_unlock(&dma_win_list_lock);
>>> break;
>>> @@ -2532,6 +2548,14 @@ void __init iommu_init_early_pSeries(void)
>>> register_memory_notifier(&iommu_mem_nb);
>>> set_pci_dma_ops(&dma_iommu_ops);
>>> +
>>> + /* During init determine the max memory an LPAR can have and set
>>> it. This
>>> + * will be used for pre-mapping RAM in DDW.
>>> memblock_end_of_DRAM() can
>>> + * change during the running of LPAR - daxctl can add pmemory as
>>> + * "system-ram". This memory range should not be pre-mapped in
>>> DDW since
>>> + * the address of pmemory can be much higher than the DDW size.
>>> + */
>>> + pseries_ddw_max_ram = ddw_memory_hotplug_max();
>>> }
>>> static int __init disable_multitce(char *str)
>>>
>>> base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
>>
^ permalink raw reply
* [PATCH 0/7] gpio: move ppc4xx driver to drivers/gpio and modernize
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
This series moves the ppc4xx GPIO driver from arch/powerpc to
drivers/gpio, converts it to be a proper platform driver using
generic MMIO helpers, drops architecture-specific accessors, and
prepares it for module build and COMPILE_TEST.
Patches 1-4 move the driver and convert it to standard platform
driver infrastructure. Patch 5 switches to generic MMIO helpers.
Patch 6 drops PPC-specific IO accessors and enables COMPILE_TEST.
Patch 7 adds the missing MODULE metadata so the driver can actually
be built as a module.
Rosen Penev (7):
gpio: move ppc4xx gpio driver from arch/powerpc to drivers/gpio
gpio: ppc44x: Use module platform driver helper for GPIO
gpio: ppc44x: Set GPIO chip firmware node
gpio: ppc44x: Use platform resource helper for GPIO MMIO
gpio: ppc44x: Convert GPIO to generic MMIO
gpio: ppc44x: drop PPC-specific IO helpers and rename to ppc44x
gpio: ppc44x: add MODULE info
arch/powerpc/configs/44x/warp_defconfig | 2 +-
arch/powerpc/configs/ppc44x_defconfig | 2 +-
arch/powerpc/platforms/44x/Kconfig | 7 -
arch/powerpc/platforms/44x/Makefile | 2 +-
arch/powerpc/platforms/44x/gpio.c | 210 -----------------------
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ppc44x.c | 217 ++++++++++++++++++++++++
8 files changed, 228 insertions(+), 220 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/gpio.c
create mode 100644 drivers/gpio/gpio-ppc44x.c
--
2.54.0
^ permalink raw reply
* [PATCH 1/7] gpio: move ppc4xx gpio driver from arch/powerpc to drivers/gpio
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Move the ppc4xx gpio driver out of arch/powerpc/platforms/44x/ into
drivers/gpio/gpio-ppc44x.c. The driver has no architecture-specific
dependencies and follows the same pattern as other PowerPC GPIO
drivers already in drivers/gpio/ (e.g. gpio-mpc8xxx, gpio-mpc5200).
- Renamed Kconfig symbol from PPC4xx_GPIO to GPIO_PPC44X
- Updated ppc44x_defconfig and warp_defconfig to use the new symbol
- Marked the new option as tristate (was bool) since the driver
supports module build via module_platform_driver()
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/powerpc/configs/44x/warp_defconfig | 2 +-
arch/powerpc/configs/ppc44x_defconfig | 2 +-
arch/powerpc/platforms/44x/Kconfig | 7 -------
arch/powerpc/platforms/44x/Makefile | 2 +-
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
.../platforms/44x/gpio.c => drivers/gpio/gpio-ppc44x.c | 0
7 files changed, 12 insertions(+), 10 deletions(-)
rename arch/powerpc/platforms/44x/gpio.c => drivers/gpio/gpio-ppc44x.c (100%)
diff --git a/arch/powerpc/configs/44x/warp_defconfig b/arch/powerpc/configs/44x/warp_defconfig
index 5757625469c4..d6014b9c5708 100644
--- a/arch/powerpc/configs/44x/warp_defconfig
+++ b/arch/powerpc/configs/44x/warp_defconfig
@@ -12,7 +12,7 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_EBONY is not set
CONFIG_WARP=y
-CONFIG_PPC4xx_GPIO=y
+CONFIG_GPIO_PPC44X=y
CONFIG_HZ_1000=y
CONFIG_CMDLINE="ip=on"
# CONFIG_PCI is not set
diff --git a/arch/powerpc/configs/ppc44x_defconfig b/arch/powerpc/configs/ppc44x_defconfig
index 41c930f74ed4..b0c7ad8c6d9b 100644
--- a/arch/powerpc/configs/ppc44x_defconfig
+++ b/arch/powerpc/configs/ppc44x_defconfig
@@ -22,7 +22,7 @@ CONFIG_GLACIER=y
CONFIG_REDWOOD=y
CONFIG_EIGER=y
CONFIG_YOSEMITE=y
-CONFIG_PPC4xx_GPIO=y
+CONFIG_GPIO_PPC44X=y
CONFIG_MATH_EMULATION=y
CONFIG_NET=y
CONFIG_PACKET=y
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index fc79f8466933..150813cea945 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -227,13 +227,6 @@ config PPC44x_SIMPLE
help
This option enables the simple PowerPC 44x platform support.
-config PPC4xx_GPIO
- bool "PPC4xx GPIO support"
- depends on 44x
- select GPIOLIB
- help
- Enable gpiolib support for ppc440 based boards
-
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index ca7b1bb442d9..4598d8b89bf4 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -15,4 +15,4 @@ obj-$(CONFIG_FSP2) += fsp2.o
obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_PPC4xx_HSTA_MSI) += hsta_msi.o
obj-$(CONFIG_PPC4xx_CPM) += cpm.o
-obj-$(CONFIG_PPC4xx_GPIO) += gpio.o
+
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 89c77ec6c205..77991da43ec1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -593,6 +593,14 @@ config GPIO_POLARFIRE_SOC
help
Say yes here to support the GPIO controllers on Microchip FPGAs.
+config GPIO_PPC44X
+ tristate "PPC44x GPIO support"
+ depends on 44x
+ select GPIO_GENERIC
+ select GPIOLIB
+ help
+ Enable gpiolib support for ppc440 based boards.
+
config GPIO_PXA
bool "PXA GPIO support"
depends on ARCH_PXA || ARCH_MMP || COMPILE_TEST
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8ec03c9aec20..9e8c9ca1d3fb 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_GPIO_PCIE_IDIO_24) += gpio-pcie-idio-24.o
obj-$(CONFIG_GPIO_PCI_IDIO_16) += gpio-pci-idio-16.o
obj-$(CONFIG_GPIO_PISOSR) += gpio-pisosr.o
obj-$(CONFIG_GPIO_PL061) += gpio-pl061.o
+obj-$(CONFIG_GPIO_PPC44X) += gpio-ppc44x.o
obj-$(CONFIG_GPIO_PMIC_EIC_SPRD) += gpio-pmic-eic-sprd.o
obj-$(CONFIG_GPIO_POLARFIRE_SOC) += gpio-mpfs.o
obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
diff --git a/arch/powerpc/platforms/44x/gpio.c b/drivers/gpio/gpio-ppc44x.c
similarity index 100%
rename from arch/powerpc/platforms/44x/gpio.c
rename to drivers/gpio/gpio-ppc44x.c
--
2.54.0
^ permalink raw reply related
* [PATCH 2/7] gpio: ppc44x: Use module platform driver helper for GPIO
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Replace the open-coded arch initcall registration with
module_platform_driver(). The initcall level changes from
arch_initcall to device_initcall, which is safe since the
driver no longer needs architecture-specific ordering.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-ppc44x.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index aea0d913b59d..0d2244272e32 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -203,8 +203,4 @@ static struct platform_driver ppc4xx_gpio_driver = {
},
};
-static int __init ppc4xx_gpio_init(void)
-{
- return platform_driver_register(&ppc4xx_gpio_driver);
-}
-arch_initcall(ppc4xx_gpio_init);
+module_platform_driver(ppc4xx_gpio_driver);
--
2.54.0
^ permalink raw reply related
* [PATCH 3/7] gpio: ppc44x: Set GPIO chip firmware node
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
The PPC4xx GPIO driver stopped assigning an explicit firmware node
to the gpio_chip when it moved away from of_mm_gpiochip_add_data().
Restore that association from the platform device so OF GPIO lookup
can match phandles to the registered gpiochip.
Tested on: Cisco MX60W. No more probe deferral.
Assisted-by: Codex:GPT-5.5
Fixes: 1044dbaf2a77 ("powerpc/44x: Change GPIO driver to a proper platform driver")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-ppc44x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index 0d2244272e32..07b699cc4dd9 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -169,6 +169,8 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
gc = &chip->gc;
+ gc->parent = dev;
+ gc->fwnode = dev_fwnode(dev);
gc->base = -1;
gc->ngpio = 32;
gc->direction_input = ppc4xx_gpio_dir_in;
--
2.54.0
^ permalink raw reply related
* [PATCH 4/7] gpio: ppc44x: Use platform resource helper for GPIO MMIO
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Map the PPC44x GPIO register block through the platform device
resource instead of reparsing the firmware node directly.
The GPIO node now probes as a platform device, so use the
platform helper to keep resource handling aligned with the converted
driver model and to report mapping failures with the platform device
context.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-ppc44x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index 07b699cc4dd9..b30ca357ab74 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -182,7 +182,7 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
if (!gc->label)
return -ENOMEM;
- chip->regs = devm_of_iomap(dev, np, 0, NULL);
+ chip->regs = devm_platform_ioremap_resource(ofdev, 0);
if (IS_ERR(chip->regs))
return PTR_ERR(chip->regs);
--
2.54.0
^ permalink raw reply related
* [PATCH 5/7] gpio: ppc44x: Convert GPIO to generic MMIO
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Use gpio_generic_chip_init() to set up the PPC44x GPIO chip
instead of open-coding the basic get, set, locking and state handling.
Keep the PPC44x-specific direction callbacks because they still need to
program ODR and the OSR/TSR registers around the generic data and
direction registers.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-ppc44x.c | 82 +++++++++++++++++---------------------
1 file changed, 36 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index b30ca357ab74..6b4814ed12b5 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -11,10 +11,9 @@
#include <linux/kernel.h>
#include <linux/init.h>
-#include <linux/spinlock.h>
#include <linux/io.h>
#include <linux/of.h>
-#include <linux/gpio/driver.h>
+#include <linux/gpio/generic.h>
#include <linux/types.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
@@ -45,9 +44,8 @@ struct ppc4xx_gpio {
};
struct ppc4xx_gpio_chip {
- struct gpio_chip gc;
+ struct gpio_generic_chip chip;
void __iomem *regs;
- spinlock_t lock;
};
/*
@@ -56,55 +54,35 @@ struct ppc4xx_gpio_chip {
* There are a maximum of 32 gpios in each gpio controller.
*/
-static int ppc4xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
-{
- struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
- struct ppc4xx_gpio __iomem *regs = chip->regs;
-
- return !!(in_be32(®s->ir) & GPIO_MASK(gpio));
-}
-
static inline void
__ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
- struct ppc4xx_gpio __iomem *regs = chip->regs;
+ struct gpio_generic_chip *gen_gc = &chip->chip;
if (val)
- setbits32(®s->or, GPIO_MASK(gpio));
+ gen_gc->sdata |= GPIO_MASK(gpio);
else
- clrbits32(®s->or, GPIO_MASK(gpio));
-}
+ gen_gc->sdata &= ~GPIO_MASK(gpio);
-static int ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
-{
- struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
- unsigned long flags;
-
- spin_lock_irqsave(&chip->lock, flags);
-
- __ppc4xx_gpio_set(gc, gpio, val);
-
- spin_unlock_irqrestore(&chip->lock, flags);
-
- pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
-
- return 0;
+ gpio_generic_write_reg(gen_gc, gen_gc->reg_set, gen_gc->sdata);
}
static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
+ struct gpio_generic_chip *gen_gc = &chip->chip;
struct ppc4xx_gpio __iomem *regs = chip->regs;
unsigned long flags;
- spin_lock_irqsave(&chip->lock, flags);
+ gpio_generic_chip_lock_irqsave(gen_gc, flags);
/* Disable open-drain function */
clrbits32(®s->odr, GPIO_MASK(gpio));
/* Float the pin */
clrbits32(®s->tcr, GPIO_MASK(gpio));
+ gen_gc->sdir &= ~GPIO_MASK(gpio);
/* Bits 0-15 use TSRL/OSRL, bits 16-31 use TSRH/OSRH */
if (gpio < 16) {
@@ -115,7 +93,7 @@ static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
clrbits32(®s->tsrh, GPIO_MASK2(gpio));
}
- spin_unlock_irqrestore(&chip->lock, flags);
+ gpio_generic_chip_unlock_irqrestore(gen_gc, flags);
return 0;
}
@@ -124,10 +102,11 @@ static int
ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
+ struct gpio_generic_chip *gen_gc = &chip->chip;
struct ppc4xx_gpio __iomem *regs = chip->regs;
unsigned long flags;
- spin_lock_irqsave(&chip->lock, flags);
+ gpio_generic_chip_lock_irqsave(gen_gc, flags);
/* First set initial value */
__ppc4xx_gpio_set(gc, gpio, val);
@@ -137,6 +116,7 @@ ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
/* Drive the pin */
setbits32(®s->tcr, GPIO_MASK(gpio));
+ gen_gc->sdir |= GPIO_MASK(gpio);
/* Bits 0-15 use TSRL, bits 16-31 use TSRH */
if (gpio < 16) {
@@ -147,7 +127,7 @@ ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
clrbits32(®s->tsrh, GPIO_MASK2(gpio));
}
- spin_unlock_irqrestore(&chip->lock, flags);
+ gpio_generic_chip_unlock_irqrestore(gen_gc, flags);
pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
@@ -159,33 +139,43 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
struct device *dev = &ofdev->dev;
struct device_node *np = dev->of_node;
struct ppc4xx_gpio_chip *chip;
+ struct gpio_generic_chip_config config;
struct gpio_chip *gc;
+ struct ppc4xx_gpio __iomem *regs;
+ int ret;
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
- spin_lock_init(&chip->lock);
-
- gc = &chip->gc;
+ chip->regs = devm_platform_ioremap_resource(ofdev, 0);
+ if (IS_ERR(chip->regs))
+ return PTR_ERR(chip->regs);
- gc->parent = dev;
+ regs = chip->regs;
+ config = (struct gpio_generic_chip_config) {
+ .dev = dev,
+ .sz = 4,
+ .dat = ®s->ir,
+ .set = ®s->or,
+ .dirout = ®s->tcr,
+ .flags = GPIO_GENERIC_BIG_ENDIAN |
+ GPIO_GENERIC_BIG_ENDIAN_BYTE_ORDER,
+ };
+
+ ret = gpio_generic_chip_init(&chip->chip, &config);
+ if (ret)
+ return ret;
+
+ gc = &chip->chip.gc;
gc->fwnode = dev_fwnode(dev);
- gc->base = -1;
- gc->ngpio = 32;
gc->direction_input = ppc4xx_gpio_dir_in;
gc->direction_output = ppc4xx_gpio_dir_out;
- gc->get = ppc4xx_gpio_get;
- gc->set = ppc4xx_gpio_set;
gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", np);
if (!gc->label)
return -ENOMEM;
- chip->regs = devm_platform_ioremap_resource(ofdev, 0);
- if (IS_ERR(chip->regs))
- return PTR_ERR(chip->regs);
-
return devm_gpiochip_add_data(dev, gc, chip);
}
--
2.54.0
^ permalink raw reply related
* [PATCH 6/7] gpio: ppc44x: drop PPC-specific IO helpers and rename to ppc44x
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Replace PPC-specific clrbits32()/setbits32() with local helpers using
ioread32be()/iowrite32be() which are equivalent on PPC since commit
894fa235eb4c ("powerpc: inline iomap accessors"). This allows the
driver to be compiled on any architecture with COMPILE_TEST.
- Changed Kconfig dependency to depends on 44x || COMPILE_TEST
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/Kconfig | 3 +-
drivers/gpio/gpio-ppc44x.c | 88 ++++++++++++++++++++++----------------
2 files changed, 53 insertions(+), 38 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 77991da43ec1..7374f82b7040 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -595,9 +595,8 @@ config GPIO_POLARFIRE_SOC
config GPIO_PPC44X
tristate "PPC44x GPIO support"
- depends on 44x
+ depends on 44x || COMPILE_TEST
select GPIO_GENERIC
- select GPIOLIB
help
Enable gpiolib support for ppc440 based boards.
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index 6b4814ed12b5..cc7796e0cfbd 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * PPC4xx gpio driver
+ * PPC44x gpio driver
*
* Copyright (c) 2008 Harris Corporation
* Copyright (c) 2008 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
@@ -22,7 +22,7 @@
#define GPIO_MASK2(gpio) (0xc0000000 >> ((gpio) * 2))
/* Physical GPIO register layout */
-struct ppc4xx_gpio {
+struct ppc44x_gpio {
__be32 or;
__be32 tcr;
__be32 osrl;
@@ -43,11 +43,27 @@ struct ppc4xx_gpio {
__be32 isr3h;
};
-struct ppc4xx_gpio_chip {
+struct ppc44x_gpio_chip {
struct gpio_generic_chip chip;
void __iomem *regs;
};
+static inline void ppc44x_clrbits32(void __iomem *addr, u32 mask)
+{
+ u32 val = ioread32be(addr);
+
+ val &= ~mask;
+ iowrite32be(val, addr);
+}
+
+static inline void ppc44x_setbits32(void __iomem *addr, u32 mask)
+{
+ u32 val = ioread32be(addr);
+
+ val |= mask;
+ iowrite32be(val, addr);
+}
+
/*
* GPIO LIB API implementation for GPIOs
*
@@ -55,9 +71,9 @@ struct ppc4xx_gpio_chip {
*/
static inline void
-__ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+__ppc44x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
{
- struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
+ struct ppc44x_gpio_chip *chip = gpiochip_get_data(gc);
struct gpio_generic_chip *gen_gc = &chip->chip;
if (val)
@@ -68,29 +84,29 @@ __ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
gpio_generic_write_reg(gen_gc, gen_gc->reg_set, gen_gc->sdata);
}
-static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+static int ppc44x_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
- struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
+ struct ppc44x_gpio_chip *chip = gpiochip_get_data(gc);
struct gpio_generic_chip *gen_gc = &chip->chip;
- struct ppc4xx_gpio __iomem *regs = chip->regs;
+ struct ppc44x_gpio __iomem *regs = chip->regs;
unsigned long flags;
gpio_generic_chip_lock_irqsave(gen_gc, flags);
/* Disable open-drain function */
- clrbits32(®s->odr, GPIO_MASK(gpio));
+ ppc44x_clrbits32(®s->odr, GPIO_MASK(gpio));
/* Float the pin */
- clrbits32(®s->tcr, GPIO_MASK(gpio));
+ ppc44x_clrbits32(®s->tcr, GPIO_MASK(gpio));
gen_gc->sdir &= ~GPIO_MASK(gpio);
/* Bits 0-15 use TSRL/OSRL, bits 16-31 use TSRH/OSRH */
if (gpio < 16) {
- clrbits32(®s->osrl, GPIO_MASK2(gpio));
- clrbits32(®s->tsrl, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->osrl, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->tsrl, GPIO_MASK2(gpio));
} else {
- clrbits32(®s->osrh, GPIO_MASK2(gpio));
- clrbits32(®s->tsrh, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->osrh, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->tsrh, GPIO_MASK2(gpio));
}
gpio_generic_chip_unlock_irqrestore(gen_gc, flags);
@@ -99,32 +115,32 @@ static int ppc4xx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
}
static int
-ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+ppc44x_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
{
- struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc);
+ struct ppc44x_gpio_chip *chip = gpiochip_get_data(gc);
struct gpio_generic_chip *gen_gc = &chip->chip;
- struct ppc4xx_gpio __iomem *regs = chip->regs;
+ struct ppc44x_gpio __iomem *regs = chip->regs;
unsigned long flags;
gpio_generic_chip_lock_irqsave(gen_gc, flags);
/* First set initial value */
- __ppc4xx_gpio_set(gc, gpio, val);
+ __ppc44x_gpio_set(gc, gpio, val);
/* Disable open-drain function */
- clrbits32(®s->odr, GPIO_MASK(gpio));
+ ppc44x_clrbits32(®s->odr, GPIO_MASK(gpio));
/* Drive the pin */
- setbits32(®s->tcr, GPIO_MASK(gpio));
+ ppc44x_setbits32(®s->tcr, GPIO_MASK(gpio));
gen_gc->sdir |= GPIO_MASK(gpio);
/* Bits 0-15 use TSRL, bits 16-31 use TSRH */
if (gpio < 16) {
- clrbits32(®s->osrl, GPIO_MASK2(gpio));
- clrbits32(®s->tsrl, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->osrl, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->tsrl, GPIO_MASK2(gpio));
} else {
- clrbits32(®s->osrh, GPIO_MASK2(gpio));
- clrbits32(®s->tsrh, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->osrh, GPIO_MASK2(gpio));
+ ppc44x_clrbits32(®s->tsrh, GPIO_MASK2(gpio));
}
gpio_generic_chip_unlock_irqrestore(gen_gc, flags);
@@ -134,14 +150,14 @@ ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
return 0;
}
-static int ppc4xx_gpio_probe(struct platform_device *ofdev)
+static int ppc44x_gpio_probe(struct platform_device *ofdev)
{
struct device *dev = &ofdev->dev;
struct device_node *np = dev->of_node;
- struct ppc4xx_gpio_chip *chip;
+ struct ppc44x_gpio_chip *chip;
struct gpio_generic_chip_config config;
struct gpio_chip *gc;
- struct ppc4xx_gpio __iomem *regs;
+ struct ppc44x_gpio __iomem *regs;
int ret;
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
@@ -169,8 +185,8 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
gc = &chip->chip.gc;
gc->fwnode = dev_fwnode(dev);
- gc->direction_input = ppc4xx_gpio_dir_in;
- gc->direction_output = ppc4xx_gpio_dir_out;
+ gc->direction_input = ppc44x_gpio_dir_in;
+ gc->direction_output = ppc44x_gpio_dir_out;
gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", np);
if (!gc->label)
@@ -179,20 +195,20 @@ static int ppc4xx_gpio_probe(struct platform_device *ofdev)
return devm_gpiochip_add_data(dev, gc, chip);
}
-static const struct of_device_id ppc4xx_gpio_match[] = {
+static const struct of_device_id ppc44x_gpio_match[] = {
{
.compatible = "ibm,ppc4xx-gpio",
},
{},
};
-MODULE_DEVICE_TABLE(of, ppc4xx_gpio_match);
+MODULE_DEVICE_TABLE(of, ppc44x_gpio_match);
-static struct platform_driver ppc4xx_gpio_driver = {
- .probe = ppc4xx_gpio_probe,
+static struct platform_driver ppc44x_gpio_driver = {
+ .probe = ppc44x_gpio_probe,
.driver = {
- .name = "ppc4xx-gpio",
- .of_match_table = ppc4xx_gpio_match,
+ .name = "ppc44x-gpio",
+ .of_match_table = ppc44x_gpio_match,
},
};
-module_platform_driver(ppc4xx_gpio_driver);
+module_platform_driver(ppc44x_gpio_driver);
--
2.54.0
^ permalink raw reply related
* [PATCH 7/7] gpio: ppc44x: add MODULE info
From: Rosen Penev @ 2026-06-02 5:01 UTC (permalink / raw)
To: linux-gpio
Cc: Madhavan Srinivasan, chleroy, Michael Ellerman, Nicholas Piggin,
Linus Walleij, Bartosz Golaszewski,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), open list
In-Reply-To: <20260602050131.856789-1-rosenp@gmail.com>
Fixes:
ERROR: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ppc44x.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpio/gpio-ppc44x.o
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/gpio/gpio-ppc44x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpio/gpio-ppc44x.c b/drivers/gpio/gpio-ppc44x.c
index cc7796e0cfbd..425ccbc234c8 100644
--- a/drivers/gpio/gpio-ppc44x.c
+++ b/drivers/gpio/gpio-ppc44x.c
@@ -211,4 +211,7 @@ static struct platform_driver ppc44x_gpio_driver = {
},
};
+MODULE_DESCRIPTION("PPC44x gpio driver");
+MODULE_LICENSE("GPL");
+
module_platform_driver(ppc44x_gpio_driver);
--
2.54.0
^ permalink raw reply related
* RE: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Aneesh Kumar K.V @ 2026-06-02 6:05 UTC (permalink / raw)
To: Michael Kelley, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <SN6PR02MB415754E94A9505C2B9739E4DD4092@SN6PR02MB4157.namprd02.prod.outlook.com>
Michael Kelley <mhklinux@outlook.com> writes:
> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>Sent: Thursday, May 21, 2026 9:28 PM
>>
>> Teach the atomic DMA pool code to distinguish between encrypted and
>> unencrypted pools, and make pool allocation select the matching pool based
>> on DMA attributes.
>>
>> Introduce a dma_gen_pool wrapper that records whether a pool is
>> unencrypted, initialize that state when the atomic pools are created, and
>> use it when expanding and resizing the pools. Update dma_alloc_from_pool()
>> to take attrs and skip pools whose encrypted state does not match
>> DMA_ATTR_CC_SHARED. Update dma_free_from_pool() accordingly.
>>
>> Also pass DMA_ATTR_CC_SHARED from the swiotlb atomic allocation path so
>> decrypted swiotlb allocations are taken from the correct atomic pool.
>>
>> Tested-by: Jiri Pirko <jiri@nvidia.com>
>> Reviewed-by: Mostafa Saleh <smostafa@google.com>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> drivers/iommu/dma-iommu.c | 2 +-
>> include/linux/dma-map-ops.h | 2 +-
>> kernel/dma/direct.c | 11 ++-
>> kernel/dma/pool.c | 167 +++++++++++++++++++++++-------------
>> kernel/dma/swiotlb.c | 7 +-
>> 5 files changed, 123 insertions(+), 66 deletions(-)
>>
>
> [snip]
>
>> +static __init struct dma_gen_pool *__dma_atomic_pool_init(struct dma_gen_pool *dma_pool,
>> + size_t pool_size, gfp_t gfp)
>> {
>> - struct gen_pool *pool;
>> int ret;
>>
>> - pool = gen_pool_create(PAGE_SHIFT, NUMA_NO_NODE);
>> - if (!pool)
>> + dma_pool->pool = gen_pool_create(PAGE_SHIFT, NUMA_NO_NODE);
>> + if (!dma_pool->pool)
>> return NULL;
>>
>> - gen_pool_set_algo(pool, gen_pool_first_fit_order_align, NULL);
>> + gen_pool_set_algo(dma_pool->pool, gen_pool_first_fit_order_align, NULL);
>> +
>> + /* if platform is using memory encryption atomic pools are by default decrypted. */
>> + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> + dma_pool->unencrypted = true;
>> + else
>> + dma_pool->unencrypted = false;
>
> I'm curious about the name of the "unencrypted" field in struct dma_gen_pool,
> and similarly in Patch 7 of the series for the swiotlb struct io_tlb_pool and
> struct io_tlb_mem. Up through v3 of this series, you used "decrypted", but
> starting in v4 switched to "unencrypted".
>
> To me, the above "if" statement has some cognitive dissonance in that if
> CC_ATTR_MEM_ENCRYPT is false (i.e., a normal VM), "unencrypted" is set
> to false. But I think of memory in a normal VM as "unencrypted" since it
> was never encrypted. A similar "if" statement occurs in your swiotlb changes.
>
> Two related concepts are captured by the field:
> 1) Is some action needed to put the memory into the unencrypted state,
> and to remove it from that state? This applies when assigning memory to the
> pool, or freeing the memory in the pool.
> 2) Is the memory currently in the unencrypted state? This applies when
> allocating memory from the pool to a caller.
>
> It's hard to capture all that in a short field name. But I think I prefer "decrypted"
> over "unencrypted". The former implies that some action was taken. It's a
> little easier to think of a normal VM as *not* having decrypted memory. The
> memory was never encrypted in the first place, so no decryption action was taken.
>
> Throughout the kernel, "decrypted" occurs much more frequently than
> "unencrypted". We have set_memory_encrypted() and set_memory_decrypted()
> that are "take action" names. But we also have force_dma_unencrypted(),
> phys_to_dma_unencrypted(), and dma_addr_unencrypted(). So it's a bit
> of a mess.
>
>
> But maybe there's more background here that led to the change
> between your v3 and v4.
>
> Michael
The current APIs, phys_to_dma_unencrypted() and dma_addr_unencrypted(),
are the reason I changed the pool attribute name from decrypted to
unencrypted. The rationale was that nobody actually decrypted the
memory; the memory was already in an unencrypted state.
In other words, the DMA pool did not contain encrypted content that was
later decrypted. Rather, the DMA pool itself was in an unencrypted
state.
IMHO, set_memory_decrypted()/set_memory_encrypted() is the right naming
because those APIs describe an operation that transitions memory between
states. In contrast, the pool attribute describes the state of the
memory itself, which is why I used unencrypted rather than decrypted.
-aneesh
^ permalink raw reply
* RE: [PATCH v5 10/20] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-06-02 6:10 UTC (permalink / raw)
To: Michael Kelley, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <SN6PR02MB41574064D14D4A2734222C51D40B2@SN6PR02MB4157.namprd02.prod.outlook.com>
Michael Kelley <mhklinux@outlook.com> writes:
> From: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Sent: Thursday, May 21, 2026 9:28 PM
>>
>> Teach dma_direct_map_phys() to select the DMA address encoding based on
>> DMA_ATTR_CC_SHARED.
>>
>> Use phys_to_dma_unencrypted() for decrypted mappings and
>> phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA
>> but the source physical address is still encrypted, force the mapping
>> through swiotlb so the DMA address and backing memory attributes remain
>> consistent.
>>
>> Update the arm64, x86, s390 and powerpc secure-guest setup to not use
>> swiotlb force option
>>
>> Tested-by: Jiri Pirko <jiri@nvidia.com>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
...
> With this patch removing SWIOTLB_FORCE from four places in
> kernel code, there are no remaining places where it is set.
> The test of SWIOTLB_FORCE could be removed from
> swiotlb_init_remap(), and its definition could be deleted
> from include/linux/swiotlb.h.
>
Sure, I’ll add that as a separate patch in the series.
-aneesh
^ permalink raw reply
* Re: [PATCH V16 4/7] rust/powerpc: Set min rustc version for powerpc
From: Mukesh Kumar Chaurasiya @ 2026-06-02 7:15 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, maddy, mpe, npiggin, chleroy, peterz, jpoimboe,
jbaron, aliceryhl, rostedt, ardb, ojeda, boqun, bjorn3_gh, lossin,
a.hindborg, tmgross, dakr, nathan, nick.desaulniers+lkml, morbo,
justinstitt, daniel.almeida, acourbot, fujita.tomonori, gregkh,
prafulrai522, tamird, kees, lyude, airlied, linuxppc-dev,
linux-kernel, rust-for-linux, llvm
In-Reply-To: <DITEZRMNTOX2.1DKO9U58508S8@garyguo.net>
On Wed, May 27, 2026 at 12:15:39PM +0100, Gary Guo wrote:
> On Tue May 26, 2026 at 9:52 AM BST, Mukesh Kumar Chaurasiya wrote:
> > On Mon, May 25, 2026 at 08:16:53PM +0200, Miguel Ojeda wrote:
> >> On Wed, May 20, 2026 at 8:48 AM Mukesh Kumar Chaurasiya (IBM)
> >> <mkchauras@gmail.com> wrote:
> >> >
> >> > Minimum `rustc` version required for powerpc is 1.95 as some critical
> >> > features required for compiling rust code for kernel are not there.
> >>
> >> Which critical features?
> > Hey Miguel,
> >
> > Right now i can only think of inline asm. I can rerun the whole thing
> > with 1.85 and figure out the issues with 1.85. I'll get back on this.
> >
> >>
> >> > For example Stable inline asm support which got merged in 1.95.
> >>
> >> It is not needed that the support is stable, but rather that
> >> everything you may need works.
> >>
> > I wanted inline asm be stable, I was skeptical about inline asm to be
> > unstable and potentially messing up the whole system. That's the reason
> > I waited for the stable support to get merged before sending out this
> > patch series.
>
> AFAIK inline asm is only unstable for archs for their surface syntax (i.e. name
> of register and classes). The rest is just LLVM inline asm. If there're codegen
> issues, you should gate on LLVM version instead (Rust supports multiple LLVM
> versions in a single release and distro may use different LLVM than rustup's).
>
> Best,
> Gary
Hey Gary,
Sry about delayed response.
I'll check if the codegen has any issues. If yes we'll put a guard on
that. Meanwhile i'll also test out the 1.85 for any other issues. Thanks
for the help.
Regards,
Mukesh
^ permalink raw reply
* [PATCH v2 net-next 0/9] net: dsa: netc: add bridge mode support
From: wei.fang @ 2026-06-02 7:23 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, andrew, olteanv, linux
Cc: wei.fang, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
From: Wei Fang <wei.fang@nxp.com>
This series adds bridge mode support to the NETC DSA switch driver,
covering both VLAN-aware and VLAN-unaware operation.
The NETC switch manages forwarding through a set of hardware tables
accessed via NTMP: the FDB table (FDBT), VLAN filter table (VFT), egress
treatment table (ETT), and egress count table (ECT). The series extends
the NTMP layer with the operations required for bridging, then builds the
DSA bridge callbacks on top.
Since all switch ports share the VFT, so only one VLAN-aware bridge is
supported.
FDB aging is managed in software. A periodic delayed work sweeps the
table using the hardware activity element mechanism, with a default aging
time of 300 seconds matching the IEEE 802.1Q standard. Per-port entries
are also flushed immediately on bridge leave and link-down events.
---
v2:
1. Remove ntmp_fdbt_delete_entry_by_keye()
2. Add settings for cfge.cfg and cfge_mc in
ntmp_fdbt_update_activity_element()
3. Remove the wrong comment from ntmp_fdbt_delete_aging_entries()
4. Correct the description of ntmp_fdbt_delete_port_dynamic_entries()
5. Add generic function ntmp_vft_set_entry(), which is called by
ntmp_vft_add_entry() and ntmp_vft_update_entry()
6. ntmp_ett_add_or_update_entry() is split into ntmp_ett_add_entry() and
ntmp_ett_update_entry(), and add generic function ntmp_ett_set_entry()
7. netc_add_or_update_ett_entry() is split into netc_add_ett_entry() and
netc_update_ett_entry()
8. Remove "entry->untagged_port_bitmap &= ~BIT(port)" from
netc_port_del_vlan_entry()
9. Add pvid check in netc_port_vlan_filtering()
10. Improve the comment in netc_vlan_unaware_pvid()
11. Change the error code in netc_single_vlan_aware_bridge() and
netc_port_vlan_add()
12. Add comments in netc_port_vlan_del()
13. Add ageing_time_min and ageing_time_max, and refactor
netc_set_ageing_time()
14. Remove fdbt_acteu_interval from struct netc_switch
15. Update some commit messages
v1 link: https://lore.kernel.org/netdev/20260527100217.794987-1-wei.fang@oss.nxp.com/
---
Wei Fang (9):
net: enetc: add interfaces to manage dynamic FDB entries
net: enetc: add "Update" and "Delete" operations to VLAN filter table
net: enetc: add interfaces to manage egress treatment table
net: enetc: add "Update" operation to the egress count table
net: dsa: netc: initialize the group bitmap of ETT and ECT
net: enetc: add helpers to set/clear table bitmap
net: dsa: netc: add VLAN filter table and egress treatment management
net: dsa: netc: add bridge mode support
net: dsa: netc: implement dynamic FDB entry ageing
drivers/net/dsa/netc/netc_main.c | 918 +++++++++++++++++-
drivers/net/dsa/netc/netc_switch.h | 33 +
drivers/net/dsa/netc/netc_switch_hw.h | 6 +
drivers/net/ethernet/freescale/enetc/ntmp.c | 440 ++++++++-
.../ethernet/freescale/enetc/ntmp_private.h | 18 +-
include/linux/fsl/ntmp.h | 60 ++
6 files changed, 1454 insertions(+), 21 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v2 net-next 1/9] net: enetc: add interfaces to manage dynamic FDB entries
From: wei.fang @ 2026-06-02 7:23 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, andrew, olteanv, linux
Cc: wei.fang, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20260602072313.3162120-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Add three interfaces to manage dynamic entries in the FDB table:
ntmp_fdbt_update_activity_element(): Update the activity element of all
dynamic FDB entries. For each entry, if its activity flag is not set,
which means no packet has matched this entry since the last update, the
activity counter is incremented. Otherwise, both the activity flag and
activity counter are reset. The activity counter is used to track how
long an FDB entry has been inactive, which is useful for implementing
an ageing mechanism.
ntmp_fdbt_delete_ageing_entries(): Delete all dynamic FDB entries whose
activity flag is not set and whose activity counter is greater than or
equal to the specified threshold. This is used to remove stale entries
that have been inactive for too long.
ntmp_fdbt_delete_port_dynamic_entries(): Delete all dynamic FDB entries
associated with the specified switch port. This is typically called when
a port goes down or is removed from a bridge.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/ntmp.c | 162 ++++++++++++++++++
.../ethernet/freescale/enetc/ntmp_private.h | 4 +-
include/linux/fsl/ntmp.h | 3 +
3 files changed, 167 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c b/drivers/net/ethernet/freescale/enetc/ntmp.c
index f71cad943424..cb494ad02e3e 100644
--- a/drivers/net/ethernet/freescale/enetc/ntmp.c
+++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
@@ -31,6 +31,7 @@
#define NTMP_GEN_UA_STSEU BIT(1)
/* Specific Update Actions for some tables */
+#define FDBT_UA_ACTEU BIT(1)
#define BPT_UA_BPSEU BIT(1)
/* Query Action: 0: Full query. 1: Query entry ID, the fields after entry
@@ -793,6 +794,167 @@ int ntmp_fdbt_search_port_entry(struct ntmp_user *user, int port,
}
EXPORT_SYMBOL_GPL(ntmp_fdbt_search_port_entry);
+/**
+ * ntmp_fdbt_update_activity_element - update the ageing time of all the
+ * dynamic entries in the FDB table.
+ * @user: target ntmp_user struct
+ *
+ * A single activity update management could be used to process all the
+ * dynamic entries in the FDB table. When hardware process an activity
+ * update management command for an entry in the FDB table and the entry
+ * does not have its activity flag set, the activity counter is incremented.
+ * However, if the activity flag is set, then both the activity flag and
+ * activity counter are reset. Software can issue the activity update
+ * management commands at predefined times and the value of the activity
+ * counter can then be used to estimate the period of how long an FDB
+ * entry has been inactive.
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_fdbt_update_activity_element(struct ntmp_user *user)
+{
+ struct fdbt_req_ua *req;
+ struct netc_swcbd swcbd;
+ struct netc_cbdr *cbdr;
+ union netc_cbd cbd;
+ u32 len;
+ int err;
+
+ swcbd.size = sizeof(*req);
+ err = ntmp_alloc_data_mem(user->dev, &swcbd, (void **)&req);
+ if (err)
+ return err;
+
+ /* Request data */
+ ntmp_fill_crd(&req->crd, user->tbl.fdbt_ver, 0, FDBT_UA_ACTEU);
+ req->ak.search.resume_eid = cpu_to_le32(NTMP_NULL_ENTRY_ID);
+ req->ak.search.cfge.cfg = cpu_to_le32(FDBT_DYNAMIC);
+ req->ak.search.cfge_mc = FDBT_CFGE_MC_DYNAMIC;
+
+ /* Request header */
+ len = NTMP_LEN(swcbd.size, NTMP_STATUS_RESP_LEN);
+ /* For activity update, the access method must be search */
+ ntmp_fill_request_hdr(&cbd, swcbd.dma, len, NTMP_FDBT_ID,
+ NTMP_CMD_UPDATE, NTMP_AM_SEARCH);
+
+ ntmp_select_and_lock_cbdr(user, &cbdr);
+ err = netc_xmit_ntmp_cmd(cbdr, &cbd, &swcbd);
+ if (err)
+ dev_err(user->dev,
+ "Failed to update activity of %s, err: %pe\n",
+ ntmp_table_name(NTMP_FDBT_ID), ERR_PTR(err));
+
+ ntmp_unlock_cbdr(cbdr);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(ntmp_fdbt_update_activity_element);
+
+/**
+ * ntmp_fdbt_delete_ageing_entries - delete all the ageing dynamic entries
+ * in the FDB table
+ * @user: target ntmp_user struct
+ * @act_cnt: the target value of the activity counter
+ *
+ * The matching rule is that the activity flag is not set and the activity
+ * counter is greater than or equal to act_cnt
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_fdbt_delete_ageing_entries(struct ntmp_user *user, u8 act_cnt)
+{
+ struct fdbt_req_qd *req;
+ struct netc_swcbd swcbd;
+ struct netc_cbdr *cbdr;
+ union netc_cbd cbd;
+ u32 len;
+ int err;
+
+ if (act_cnt > FDBT_ACT_CNT)
+ return -EINVAL;
+
+ swcbd.size = sizeof(*req);
+ err = ntmp_alloc_data_mem(user->dev, &swcbd, (void **)&req);
+ if (err)
+ return err;
+
+ /* Request data */
+ ntmp_fill_crd(&req->crd, user->tbl.fdbt_ver, 0, 0);
+ req->ak.search.resume_eid = cpu_to_le32(NTMP_NULL_ENTRY_ID);
+ req->ak.search.cfge.cfg = cpu_to_le32(FDBT_DYNAMIC);
+ req->ak.search.acte = act_cnt;
+ /* Exact match with ACTE_DATA[ACT_FLAG] AND
+ * match >= ACTE_DATA[ACT_CNT]
+ */
+ req->ak.search.acte_mc = FDBT_ACTE_MC;
+ req->ak.search.cfge_mc = FDBT_CFGE_MC_DYNAMIC;
+
+ /* Request header */
+ len = NTMP_LEN(swcbd.size, NTMP_STATUS_RESP_LEN);
+ ntmp_fill_request_hdr(&cbd, swcbd.dma, len, NTMP_FDBT_ID,
+ NTMP_CMD_DELETE, NTMP_AM_SEARCH);
+
+ ntmp_select_and_lock_cbdr(user, &cbdr);
+ err = netc_xmit_ntmp_cmd(cbdr, &cbd, &swcbd);
+ if (err)
+ dev_err(user->dev,
+ "Failed to delete ageing entries of %s, err: %pe\n",
+ ntmp_table_name(NTMP_FDBT_ID), ERR_PTR(err));
+
+ ntmp_unlock_cbdr(cbdr);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(ntmp_fdbt_delete_ageing_entries);
+
+/**
+ * ntmp_fdbt_delete_port_dynamic_entries - delete all dynamic FDB entries
+ * associated with the specified switch port
+ * @user: target ntmp_user struct
+ * @port: the specified switch port ID
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_fdbt_delete_port_dynamic_entries(struct ntmp_user *user, int port)
+{
+ struct fdbt_req_qd *req;
+ struct netc_swcbd swcbd;
+ struct netc_cbdr *cbdr;
+ union netc_cbd cbd;
+ u32 len;
+ int err;
+
+ swcbd.size = sizeof(*req);
+ err = ntmp_alloc_data_mem(user->dev, &swcbd, (void **)&req);
+ if (err)
+ return err;
+
+ /* Request data */
+ ntmp_fill_crd(&req->crd, user->tbl.fdbt_ver, 0, 0);
+ req->ak.search.resume_eid = cpu_to_le32(NTMP_NULL_ENTRY_ID);
+ req->ak.search.cfge.port_bitmap = cpu_to_le32(BIT(port));
+ req->ak.search.cfge.cfg = cpu_to_le32(FDBT_DYNAMIC);
+ /* Match CFGE_DATA[DYNAMIC & PORT_BITMAP] field */
+ req->ak.search.cfge_mc = FDBT_CFGE_MC_DYNAMIC_AND_PORT_BITMAP;
+
+ /* Request header */
+ len = NTMP_LEN(swcbd.size, NTMP_STATUS_RESP_LEN);
+ ntmp_fill_request_hdr(&cbd, swcbd.dma, len, NTMP_FDBT_ID,
+ NTMP_CMD_DELETE, NTMP_AM_SEARCH);
+
+ ntmp_select_and_lock_cbdr(user, &cbdr);
+ err = netc_xmit_ntmp_cmd(cbdr, &cbd, &swcbd);
+ if (err)
+ dev_err(user->dev,
+ "Failed to delete dynamic %s entries on port %d, err: %pe\n",
+ ntmp_table_name(NTMP_FDBT_ID), port, ERR_PTR(err));
+
+ ntmp_unlock_cbdr(cbdr);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(ntmp_fdbt_delete_port_dynamic_entries);
+
/**
* ntmp_vft_add_entry - add an entry into the VLAN filter table
* @user: target ntmp_user struct
diff --git a/drivers/net/ethernet/freescale/enetc/ntmp_private.h b/drivers/net/ethernet/freescale/enetc/ntmp_private.h
index 0a9b87286105..ad532b059ba8 100644
--- a/drivers/net/ethernet/freescale/enetc/ntmp_private.h
+++ b/drivers/net/ethernet/freescale/enetc/ntmp_private.h
@@ -155,8 +155,8 @@ struct fdbt_ak_search {
#define FDBT_KEYE_MAC GENMASK(1, 0)
u8 cfge_mc;
#define FDBT_CFGE_MC GENMASK(2, 0)
-#define FDBT_CFGE_MC_ANY 0
-#define FDBT_CFGE_MC_DYNAMIC 1
+#define FDBT_CFGE_MC_ANY 0
+#define FDBT_CFGE_MC_DYNAMIC 1
#define FDBT_CFGE_MC_PORT_BITMAP 2
#define FDBT_CFGE_MC_DYNAMIC_AND_PORT_BITMAP 3
u8 acte_mc;
diff --git a/include/linux/fsl/ntmp.h b/include/linux/fsl/ntmp.h
index 88166f9ad3a2..5db078e1caa0 100644
--- a/include/linux/fsl/ntmp.h
+++ b/include/linux/fsl/ntmp.h
@@ -263,6 +263,9 @@ int ntmp_fdbt_delete_entry(struct ntmp_user *user, u32 entry_id);
int ntmp_fdbt_search_port_entry(struct ntmp_user *user, int port,
u32 *resume_entry_id,
struct fdbt_entry_data *entry);
+int ntmp_fdbt_update_activity_element(struct ntmp_user *user);
+int ntmp_fdbt_delete_ageing_entries(struct ntmp_user *user, u8 act_cnt);
+int ntmp_fdbt_delete_port_dynamic_entries(struct ntmp_user *user, int port);
int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
const struct vft_cfge_data *cfge);
int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 net-next 2/9] net: enetc: add "Update" and "Delete" operations to VLAN filter table
From: wei.fang @ 2026-06-02 7:23 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, andrew, olteanv, linux
Cc: wei.fang, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20260602072313.3162120-1-wei.fang@oss.nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Add two interfaces to manage entries in the VLAN filter table:
ntmp_vft_update_entry(): Update the configuration element data of the
specified VLAN filter entry based on the given VLAN ID. It uses the
exact key access method to locate the entry.
ntmp_vft_delete_entry(): Delete the VLAN filter entry corresponding to
the specified VLAN ID. It also uses the exact key access method to
identify the target entry.
In addition, introduce struct vft_req_qd to describe the request data
buffer format for Query and Delete actions of the VLAN filter table,
which contains a common request data header and a VLAN access key.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/ntmp.c | 103 ++++++++++++++++--
.../ethernet/freescale/enetc/ntmp_private.h | 6 +
include/linux/fsl/ntmp.h | 3 +
3 files changed, 105 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/ntmp.c b/drivers/net/ethernet/freescale/enetc/ntmp.c
index cb494ad02e3e..bcbbb012aec6 100644
--- a/drivers/net/ethernet/freescale/enetc/ntmp.c
+++ b/drivers/net/ethernet/freescale/enetc/ntmp.c
@@ -956,15 +956,17 @@ int ntmp_fdbt_delete_port_dynamic_entries(struct ntmp_user *user, int port)
EXPORT_SYMBOL_GPL(ntmp_fdbt_delete_port_dynamic_entries);
/**
- * ntmp_vft_add_entry - add an entry into the VLAN filter table
+ * ntmp_vft_set_entry - add an entry into the VLAN filter table or update
+ * the configuration element data of the specified VLAN filter entry
* @user: target ntmp_user struct
* @vid: VLAN ID
+ * @cmd: command type, NTMP_CMD_ADD or NTMP_CMD_UPDATE
* @cfge: configuration element data
*
* Return: 0 on success, otherwise a negative error code
*/
-int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
- const struct vft_cfge_data *cfge)
+static int ntmp_vft_set_entry(struct ntmp_user *user, u16 vid, int cmd,
+ const struct vft_cfge_data *cfge)
{
struct netc_swcbd swcbd;
struct vft_req_ua *req;
@@ -973,34 +975,121 @@ int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
u32 len;
int err;
+ if (cmd != NTMP_CMD_ADD && cmd != NTMP_CMD_UPDATE)
+ return -EINVAL;
+
swcbd.size = sizeof(*req);
err = ntmp_alloc_data_mem(user->dev, &swcbd, (void **)&req);
if (err)
return err;
/* Request data */
- ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0,
- NTMP_GEN_UA_CFGEU);
+ ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0, NTMP_GEN_UA_CFGEU);
req->ak.exact.vid = cpu_to_le16(vid);
req->cfge = *cfge;
/* Request header */
len = NTMP_LEN(swcbd.size, NTMP_STATUS_RESP_LEN);
ntmp_fill_request_hdr(&cbd, swcbd.dma, len, NTMP_VFT_ID,
- NTMP_CMD_ADD, NTMP_AM_EXACT_KEY);
+ cmd, NTMP_AM_EXACT_KEY);
ntmp_select_and_lock_cbdr(user, &cbdr);
err = netc_xmit_ntmp_cmd(cbdr, &cbd, &swcbd);
+ ntmp_unlock_cbdr(cbdr);
+
+ return err;
+}
+
+/**
+ * ntmp_vft_add_entry - add an entry into the VLAN filter table
+ * @user: target ntmp_user struct
+ * @vid: VLAN ID
+ * @cfge: configuration element data
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
+ const struct vft_cfge_data *cfge)
+{
+ int err;
+
+ err = ntmp_vft_set_entry(user, vid, NTMP_CMD_ADD, cfge);
if (err)
dev_err(user->dev,
"Failed to add %s entry, vid: %u, err: %pe\n",
ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
+ return err;
+}
+EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
+
+/**
+ * ntmp_vft_update_entry - update the configuration element data of the
+ * specified VLAN filter entry
+ * @user: target ntmp_user struct
+ * @vid: VLAN ID
+ * @cfge: configuration element data
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_vft_update_entry(struct ntmp_user *user, u16 vid,
+ const struct vft_cfge_data *cfge)
+{
+ int err;
+
+ err = ntmp_vft_set_entry(user, vid, NTMP_CMD_UPDATE, cfge);
+ if (err)
+ dev_err(user->dev,
+ "Failed to update %s entry, vid: %u, err: %pe\n",
+ ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(ntmp_vft_update_entry);
+
+/**
+ * ntmp_vft_delete_entry - delete the VLAN filter entry based on the
+ * specified VLAN ID
+ * @user: target ntmp_user struct
+ * @vid: VLAN ID
+ *
+ * Return: 0 on success, otherwise a negative error code
+ */
+int ntmp_vft_delete_entry(struct ntmp_user *user, u16 vid)
+{
+ struct netc_swcbd swcbd;
+ struct vft_req_qd *req;
+ struct netc_cbdr *cbdr;
+ union netc_cbd cbd;
+ u32 len;
+ int err;
+
+ swcbd.size = sizeof(*req);
+ err = ntmp_alloc_data_mem(user->dev, &swcbd, (void **)&req);
+ if (err)
+ return err;
+
+ /* Request data */
+ ntmp_fill_crd(&req->crd, user->tbl.vft_ver, 0, 0);
+ req->ak.exact.vid = cpu_to_le16(vid);
+
+ /* Request header */
+ len = NTMP_LEN(swcbd.size, NTMP_STATUS_RESP_LEN);
+ ntmp_fill_request_hdr(&cbd, swcbd.dma, len, NTMP_VFT_ID,
+ NTMP_CMD_DELETE, NTMP_AM_EXACT_KEY);
+
+ ntmp_select_and_lock_cbdr(user, &cbdr);
+ err = netc_xmit_ntmp_cmd(cbdr, &cbd, &swcbd);
+ if (err)
+ dev_err(user->dev,
+ "Failed to delete %s entry, vid: %u, err: %pe\n",
+ ntmp_table_name(NTMP_VFT_ID), vid, ERR_PTR(err));
+
ntmp_unlock_cbdr(cbdr);
return err;
}
-EXPORT_SYMBOL_GPL(ntmp_vft_add_entry);
+EXPORT_SYMBOL_GPL(ntmp_vft_delete_entry);
int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
const struct bpt_cfge_data *cfge)
diff --git a/drivers/net/ethernet/freescale/enetc/ntmp_private.h b/drivers/net/ethernet/freescale/enetc/ntmp_private.h
index ad532b059ba8..9d30f128849a 100644
--- a/drivers/net/ethernet/freescale/enetc/ntmp_private.h
+++ b/drivers/net/ethernet/freescale/enetc/ntmp_private.h
@@ -211,6 +211,12 @@ struct vft_req_ua {
struct vft_cfge_data cfge;
};
+/* VLAN Filter Table Request Data Buffer Format of Query and Delete actions */
+struct vft_req_qd {
+ struct ntmp_cmn_req_data crd;
+ union vft_access_key ak;
+};
+
/* Buffer Pool Table Request Data Buffer Format of Update action */
struct bpt_req_update {
struct ntmp_req_by_eid rbe;
diff --git a/include/linux/fsl/ntmp.h b/include/linux/fsl/ntmp.h
index 5db078e1caa0..36a9089526ad 100644
--- a/include/linux/fsl/ntmp.h
+++ b/include/linux/fsl/ntmp.h
@@ -268,6 +268,9 @@ int ntmp_fdbt_delete_ageing_entries(struct ntmp_user *user, u8 act_cnt);
int ntmp_fdbt_delete_port_dynamic_entries(struct ntmp_user *user, int port);
int ntmp_vft_add_entry(struct ntmp_user *user, u16 vid,
const struct vft_cfge_data *cfge);
+int ntmp_vft_update_entry(struct ntmp_user *user, u16 vid,
+ const struct vft_cfge_data *cfge);
+int ntmp_vft_delete_entry(struct ntmp_user *user, u16 vid);
int ntmp_bpt_update_entry(struct ntmp_user *user, u32 entry_id,
const struct bpt_cfge_data *cfge);
#else
--
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