user/sven/linux.git/drivers/net/fjes, branch master

net: fjes: Drop fjes_acpi_driver and rework initialization

2026-03-20T00:20:55Z

The ACPI driver interface used by the Fujitsu Extended Socket (fjes) Network Device driver is redundant because its only role is to create a platform device the fjes platform driver can bind to, which can be done already at the module initialization time. Namely, acpi_find_extended_socket_device() looks for the requisite ACPI device object anyway and it may as well check its resources, and the platform device can be created when the ACPI object in question has been found (and it can be freed when the module is unloaded). Moreover, as a rule, it is better to avoid binding drivers directly to ACPI device objects [1]. Accordingly, drop fjes_acpi_driver, adjust the module initialization and exit code as per the above and set the fwnode for the fjes platform device to point to the corresponding ACPI device object as its ACPI companion. While this is not expected to alter functionality, it changes sysfs layout and so it will be visible to user space. Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1] Signed-off-by: Rafael J. Wysocki Reviewed-by: Simon Horman Link: https://patch.msgid.link/12857407.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Jakub Kicinski

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

fjes: Add missing iounmap in fjes_hw_init()

2025-12-22T11:11:32Z

In error paths, add fjes_hw_iounmap() to release the resource acquired by fjes_hw_iomap(). Add a goto label to do so. Fixes: 8cdc3f6c5d22 ("fjes: Hardware initialization routine") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Signed-off-by: Simon Horman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251211073756.101824-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Paolo Abeni

net: WQ_PERCPU added to alloc_workqueue users

2025-09-23T00:40:30Z

Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This change adds a new WQ_PERCPU flag at the network subsystem, to explicitly request the use of the per-CPU behavior. Both flags coexist for one release cycle to allow callers to transition their calls. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. All existing users have been updated accordingly. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Link: https://patch.msgid.link/20250918142427.309519-4-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski

net: fjes: use ethtool string helpers

2024-11-01T02:36:59Z

The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Signed-off-by: Rosen Penev Reviewed-by: Simon Horman Link: https://patch.msgid.link/20241029232721.8442-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski

net: Switch back to struct platform_driver::remove()

2024-10-04T23:39:57Z

After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/net after the previous conversion commits apart from the wireless drivers to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König Reviewed-by: Andrew Lunn Reviewed-by: Sergey Ryazanov Acked-by: Stefan Schmidt Signed-off-by: Jakub Kicinski

minmax: make generic MIN() and MAX() macros available everywhere

2024-07-28T22:49:18Z

This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight Cc: Lorenzo Stoakes Signed-off-by: Linus Torvalds

net: fjes: correct TRACE_INCLUDE_PATH

2024-05-31T01:28:31Z

A comment in define_trace.h clearly states: TRACE_INCLUDE_PATH if the path is something other than core kernel vvvvvvvvvvvvvv include/trace then this macro can define the path to use. Note, the path is relative to define_trace.h, not the file including it. Full path names ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for out of tree modules must be used. fjes uses path relative to itself. Which (somehow) works most of the time. Except when the kernel tree is "nested" in another kernel tree, and ../drivers/net/fjes actually exists. In which case build will use the header file from the wrong directory. I've been trying to figure out why net NIPA builder is constantly failing for the last 5 days, with: include/trace/../../../drivers/net/fjes/fjes_trace.h:88:17: error: ‘__assign_str’ undeclared (first use in this function) 88 | __assign_str(err, err); | ^~~~~~~~~~~~ when the line in the tree clearly has only one "err". NIPA does indeed have "nested" trees, because it uses git work-trees and the tree on the "outside" is not very up to date. Link: https://lore.kernel.org/r/20240529023322.3467755-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

tracing/treewide: Remove second parameter of __assign_str()

2024-05-23T00:14:47Z

With the rework of how the __string() handles dynamic strings where it saves off the source string in field in the helper structure[1], the assignment of that value to the trace event field is stored in the helper value and does not need to be passed in again. This means that with: __string(field, mystring) Which use to be assigned with __assign_str(field, mystring), no longer needs the second parameter and it is unused. With this, __assign_str() will now only get a single parameter. There's over 700 users of __assign_str() and because coccinelle does not handle the TRACE_EVENT() macro I ended up using the following sed script: git grep -l __assign_str | while read a ; do sed -e 's/$__assign_str([^,]*[^ ,]$ *,[^;]*/\1)/' $a > /tmp/test-file; mv /tmp/test-file $a; done I then searched for __assign_str() that did not end with ';' as those were multi line assignments that the sed script above would fail to catch. Note, the same updates will need to be done for: __assign_str_len() __assign_rel_str() __assign_rel_str_len() I tested this with both an allmodconfig and an allyesconfig (build only for both). [1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/ Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Linus Torvalds Cc: Julia Lawall Signed-off-by: Steven Rostedt (Google) Acked-by: Jani Nikula Acked-by: Christian König for the amdgpu parts. Acked-by: Thomas Hellström #for Acked-by: Rafael J. Wysocki # for thermal Acked-by: Takashi Iwai Acked-by: Darrick J. Wong # xfs Tested-by: Guenter Roeck