Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11 2025-09-19T09:48:14+00:00 2025-09-19T09:48:14+00:00 pengdonglin pengdonglin@xiaomi.com 2025-09-16T04:47:31+00:00 urn:sha1:872e397d62a67843ea09cf6641819cb1a7e5ee98 Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function definitions") there is no difference between rcu_read_lock(), rcu_read_lock_bh() and rcu_read_lock_sched() in terms of RCU read section and the relevant grace period. That means that spin_lock(), which implies rcu_read_lock_sched(), also implies rcu_read_lock(). There is no need no explicitly start a RCU read section if one has already been started implicitly by spin_lock(). Simplify the code and remove the inner rcu_read_lock() invocation. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: pengdonglin <pengdonglin@xiaomi.com> Signed-off-by: pengdonglin <dolinux.peng@gmail.com> Link: https://patch.msgid.link/20250916044735.2316171-11-dolinux.peng@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2025-07-18T12:14:44+00:00 Lachlan Hodges lachlan.hodges@morsemicro.com 2025-07-17T07:42:04+00:00 urn:sha1:2758b703a9b389158964b3ae6ca171b66bfc883c Introduce the sb_count variable which tracks the number of beacon intervals until the next long beacon. To initialise this value, we find the current short beacon index into this period which represents the number of short beacons left to send before the next long beacon. We use the same TSF value used to initialise the DTIM count to ensure the short beacon count and DTIM count are in sync as its common for the long beacon period and DTIM period to be equivalent. Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250717074205.312577-4-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2025-01-28T20:25:12+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-01-28T20:25:12+00:00 urn:sha1:2ab002c755bfa88777e3f2db884d531f3010736c Pull driver core and debugfs updates from Greg KH: "Here is the big set of driver core and debugfs updates for 6.14-rc1. Included in here is a bunch of driver core, PCI, OF, and platform rust bindings (all acked by the different subsystem maintainers), hence the merge conflict with the rust tree, and some driver core api updates to mark things as const, which will also require some fixups due to new stuff coming in through other trees in this merge window. There are also a bunch of debugfs updates from Al, and there is at least one user that does have a regression with these, but Al is working on tracking down the fix for it. In my use (and everyone else's linux-next use), it does not seem like a big issue at the moment. Here's a short list of the things in here: - driver core rust bindings for PCI, platform, OF, and some i/o functions. We are almost at the "write a real driver in rust" stage now, depending on what you want to do. - misc device rust bindings and a sample driver to show how to use them - debugfs cleanups in the fs as well as the users of the fs api for places where drivers got it wrong or were unnecessarily doing things in complex ways. - driver core const work, making more of the api take const * for different parameters to make the rust bindings easier overall. - other small fixes and updates All of these have been in linux-next with all of the aforementioned merge conflicts, and the one debugfs issue, which looks to be resolved "soon"" * tag 'driver-core-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (95 commits) rust: device: Use as_char_ptr() to avoid explicit cast rust: device: Replace CString with CStr in property_present() devcoredump: Constify 'struct bin_attribute' devcoredump: Define 'struct bin_attribute' through macro rust: device: Add property_present() saner replacement for debugfs_rename() orangefs-debugfs: don't mess with ->d_name octeontx2: don't mess with ->d_parent or ->d_parent->d_name arm_scmi: don't mess with ->d_parent->d_name slub: don't mess with ->d_name sof-client-ipc-flood-test: don't mess with ->d_name qat: don't mess with ->d_name xhci: don't mess with ->d_iname mtu3: don't mess wiht ->d_iname greybus/camera - stop messing with ->d_iname mediatek: stop messing with ->d_iname netdevsim: don't embed file_operations into your structs b43legacy: make use of debugfs_get_aux() b43: stop embedding struct file_operations into their objects carl9170: stop embedding file_operations into their objects ... 2025-01-15T12:14:37+00:00 Al Viro viro@zeniv.linux.org.uk 2025-01-12T08:07:05+00:00 urn:sha1:f7862dfef6612b87b2ad8352c4d73886f09456d6 Existing primitive has several problems: 1) calling conventions are clumsy - it returns a dentry reference that is either identical to its second argument or is an ERR_PTR(-E...); in both cases no refcount changes happen. Inconvenient for users and bug-prone; it would be better to have it return 0 on success and -E... on failure. 2) it allows cross-directory moves; however, no such caller have ever materialized and considering the way debugfs is used, it's unlikely to happen in the future. What's more, any such caller would have fun issues to deal with wrt interplay with recursive removal. It also makes the calling conventions clumsier... 3) tautological rename fails; the callers have no race-free way to deal with that. 4) new name must have been formed by the caller; quite a few callers have it done by sprintf/kasprintf/etc., ending up with considerable boilerplate. Proposed replacement: int debugfs_change_name(dentry, fmt, ...). All callers convert to that easily, and it's simpler internally. IMO debugfs_rename() should go; if we ever get a real-world use case for cross-directory moves in debugfs, we can always look into the right way to handle that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/r/20250112080705.141166-21-viro@zeniv.linux.org.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2025-01-13T14:34:05+00:00 Johannes Berg johannes.berg@intel.com 2024-12-30T08:14:07+00:00 urn:sha1:7553477cbfd784b128297f9ed43751688415bbaa In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly. Reported-by: syzbot+0c5d8e65f23569a8ffec@syzkaller.appspotmail.com Fixes: 3d9011029227 ("wifi: mac80211: implement link switching") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20241230091408.505bd125c35a.Ic3c1f9572b980a952a444cad62b09b9c6721732b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2024-10-23T14:47:07+00:00 Johannes Berg johannes.berg@intel.com 2024-10-22T13:18:35+00:00 urn:sha1:31cb94f71c1ba126b9c684c5882cbf5032d0d1bc Given the large size of the regular struct file_operations, save a lot of space with the newly added short fops for debugfs. Link: https://patch.msgid.link/20241022151838.2f6de3ea3ecc.I45657e6a8415d796ec95c95becc9efb377ee3be6@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2024-02-02T12:09:55+00:00 Johannes Berg johannes.berg@intel.com 2024-01-29T14:54:02+00:00 urn:sha1:733c498a80853acbafe284a40468b91f4d41f0b4 If a driver implements the change_interface() method, we switch interface type without taking the interface down, but still will recreate the debugfs for it since it's a new type. As such, we should use the ieee80211_debugfs_recreate_netdev() function here to also recreate the driver's files, if it is indeed from a type change while up. Link: https://msgid.link/20240129155402.7311a36ffeeb.I18df02bbeb685d4250911de5ffbaf090f60c3803@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2023-12-19T12:08:00+00:00 Benjamin Berg benjamin.berg@intel.com 2023-12-20T02:38:01+00:00 urn:sha1:0a3d898ee9a8303d5b3982b97ef0703919c3ea76 When an interface is removed, we should also be deleting the driver debugfs entries (as it might still exist in DOWN state in mac80211). At the same time, when adding an interface, we can check the IEEE80211_SDATA_IN_DRIVER flag to know whether the interface was previously known to the driver and is simply being reconfigured. Fixes: a1f5dcb1c0c1 ("wifi: mac80211: add a driver callback to add vif debugfs") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20231220043149.a9f64c359424.I7076526b5297ae8f832228079c999f7b8e147a4c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2023-11-27T10:25:09+00:00 Johannes Berg johannes.berg@intel.com 2023-11-24T16:25:29+00:00 urn:sha1:4ded3bfe1db655367642aadba91aee770cbab317 The debugfs files for netdevs (sdata) and links are removed with the wiphy mutex held, which may deadlock. Use the new wiphy locked debugfs to avoid that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2023-10-23T09:43:27+00:00 Ilan Peer ilan.peer@intel.com 2023-09-28T14:35:27+00:00 urn:sha1:00f823b68ecee865bb2e4e6d5b7f4359eef0b3e3 EMLSR operation and SMPS operation cannot coexist. Thus, when EMLSR is enabled, all SMPS signaling towards the AP should be stopped (it is expected that the AP will consider SMPS to be off). Rename IEEE80211_VIF_DISABLE_SMPS_OVERRIDE to IEEE80211_VIF_EML_ACTIVE and use the flag as an indication from the driver that EMLSR is enabled. When EMLSR is enabled SMPS flows towards the AP MLD should be stopped. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230928172905.fb2c2f9a0645.If6df5357568abd623a081f0f33b07e63fb8bba99@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>