summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-02-19io_uring/rw: don't directly use ki_completePavel Begunkov
We want to avoid checking ->ki_complete directly in the io_uring completion path. Fortunately we have only two callback the selection of which depend on the ring constant flags, i.e. IOPOLL, so use that to infer the function. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/4eb4bdab8cbcf5bc87083f7047edc81e920ab83c.1739919038.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-19io_uring/rw: forbid multishot async readsPavel Begunkov
At the moment we can't sanely handle queuing an async request from a multishot context, so disable them. It shouldn't matter as pollable files / socekts don't normally do async. Patching it in __io_read() is not the cleanest way, but it's simpler than other options, so let's fix it there and clean up on top. Cc: stable@vger.kernel.org Reported-by: chase xd <sl1589472800@gmail.com> Fixes: fc68fcda04910 ("io_uring/rw: add support for IORING_OP_READ_MULTISHOT") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/7d51732c125159d17db4fe16f51ec41b936973f8.1739919038.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-19Merge branch 'bpf-support-setting-max-rto-for-bpf_setsockopt'Martin KaFai Lau
Jason Xing says: ==================== Support max RTO set by BPF program calling bpf_setsockopt(). Add corresponding selftests. ==================== Link: https://patch.msgid.link/20250219081333.56378-1-kerneljasonxing@gmail.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2025-02-19selftests/bpf: Add rto max for bpf_setsockopt testJason Xing
Test the TCP_RTO_MAX_MS optname in the existing setget_sockopt test. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20250219081333.56378-3-kerneljasonxing@gmail.com
2025-02-19bpf: Support TCP_RTO_MAX_MS for bpf_setsockoptJason Xing
Some applications don't want to wait for too long because the time of retransmission increases exponentially and can reach more than 10 seconds, for example. Eric implements the core logic on supporting rto max feature in the stack previously. Based on that, we can support it for BPF use. This patch reuses the same logic of TCP_RTO_MAX_MS in do_tcp_setsockopt() and do_tcp_getsockopt(). BPF program can call bpf_{set/get}sockopt() to set/get the maximum value of RTO. Signed-off-by: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250219081333.56378-2-kerneljasonxing@gmail.com
2025-02-19drm/i915/dp: Fix disabling the transcoder function in 128b/132b modeImre Deak
During disabling the transcoder in DP 128b/132b mode (both in case of an MST master transcoder and in case of SST) the transcoder function must be first disabled without changing any other field in the register (in particular leaving the DDI port and mode select fields unchanged) and clearing the DDI port and mode select fields separately, later during the disabling sequences. Fix the sequence accordingly. Bspec: 54128, 65448, 68849 Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 79a6734cd56e ("drm/i915/ddi: disable trancoder port select for 128b/132b SST") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217223828.1166093-3-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 2ed653c7b843db0670136330480842d76cb65cd8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-19drm/i915/dp: Fix error handling during 128b/132b link trainingImre Deak
At the end of a 128b/132b link training sequence, the HW expects the transcoder training pattern to be set to TPS2 and from that to normal mode (disabling the training pattern). Transitioning from TPS1 directly to normal mode leaves the transcoder in a stuck state, resulting in page-flip timeouts later in the modeset sequence. Atm, in case of a failure during link training, the transcoder may be still set to output the TPS1 pattern. Later the transcoder is then set from TPS1 directly to normal mode in intel_dp_stop_link_train(), leading to modeset failures later as described above. Fix this by setting the training patter to TPS2, if the link training failed at any point. The clue in the specification about the above HW behavior is the explicit mention that TPS2 must be set after the link training sequence (and there isn't a similar requirement specified for the 8b/10b link training), see the Bspec links below. v2: Add bspec aspect/link to the commit log. (Jani) Bspec: 54128, 65448, 68849 Cc: stable@vger.kernel.org # v5.18+ Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250217223828.1166093-2-imre.deak@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 8b4bbaf8ddc1f68f3ee96a706f65fdb1bcd9d355) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-19bcachefs: Fix fsck directory i_size checkingKent Overstreet
Error handling was wrong, causing unhandled transaction restart errors. check_directory_size() was also inefficient, since keys in multiple snapshots would be iterated over once for every snapshot. Convert it to the same scheme used for i_sectors and subdir count checking. Cc: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-02-19accel/amdxdna: Add missing include linux/slab.hSu Hui
When compiling without CONFIG_IA32_EMULATION, there can be some errors: drivers/accel/amdxdna/amdxdna_mailbox.c: In function ‘mailbox_release_msg’: drivers/accel/amdxdna/amdxdna_mailbox.c:197:2: error: implicit declaration of function ‘kfree’. 197 | kfree(mb_msg); | ^~~~~ drivers/accel/amdxdna/amdxdna_mailbox.c: In function ‘xdna_mailbox_send_msg’: drivers/accel/amdxdna/amdxdna_mailbox.c:418:11: error:implicit declaration of function ‘kzalloc’. 418 | mb_msg = kzalloc(sizeof(*mb_msg) + pkg_size, GFP_KERNEL); | ^~~~~~~ Add the missing include. Fixes: b87f920b9344 ("accel/amdxdna: Support hardware mailbox") Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211015354.3388171-1-suhui@nfschina.com
2025-02-19ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_upVasiliy Kovalev
The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK> Fixes: b07d5cc93e1b ("ovl: update of dentry revalidate flags after copy up") Reported-by: syzbot+316db8a1191938280eb6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=316db8a1191938280eb6 Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Link: https://lore.kernel.org/r/20250214215148.761147-1-kovalev@altlinux.org Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-02-19cifs: Treat unhandled directory name surrogate reparse points as mount ↵Pali Rohár
directory nodes If the reparse point was not handled (indicated by the -EOPNOTSUPP from ops->parse_reparse_point() call) but reparse tag is of type name surrogate directory type, then treat is as a new mount point. Name surrogate reparse point represents another named entity in the system. From SMB client point of view, this another entity is resolved on the SMB server, and server serves its content automatically. Therefore from Linux client point of view, this name surrogate reparse point of directory type crosses mount point. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-02-19cifs: Throw -EOPNOTSUPP error on unsupported reparse point type from ↵Pali Rohár
parse_reparse_point() This would help to track and detect by caller if the reparse point type was processed or not. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-02-19smb311: failure to open files of length 1040 when mounting with SMB3.1.1 ↵Steve French
POSIX extensions If a file size has bits 0x410 = ATTR_DIRECTORY | ATTR_REPARSE set then during queryinfo (stat) the file is regarded as a directory and subsequent opens can fail. A simple test example is trying to open any file 1040 bytes long when mounting with "posix" (SMB3.1.1 POSIX/Linux Extensions). The cause of this bug is that Attributes field in smb2_file_all_info struct occupies the same place that EndOfFile field in smb311_posix_qinfo, and sometimes the latter struct is incorrectly processed as if it was the first one. Reported-by: Oleh Nykyforchyn <oleh.nyk@gmail.com> Tested-by: Oleh Nykyforchyn <oleh.nyk@gmail.com> Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.com> Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2025-02-19smb: client, common: Avoid multiple -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with flexible-array members in the middle of other structs, we use the `__struct_group()` helper to separate the flexible arrays from the rest of the members in the flexible structures. We then use the newly created tagged `struct smb2_file_link_info_hdr` and `struct smb2_file_rename_info_hdr` to replace the type of the objects causing trouble: `rename_info` and `link_info` in `struct smb2_compound_vars`. We also want to ensure that when new members need to be added to the flexible structures, they are always included within the newly created tagged structs. For this, we use `static_assert()`. This ensures that the memory layout for both the flexible structure and the new tagged struct is the same after any changes. So, with these changes, fix 86 of the following warnings: fs/smb/client/cifsglob.h:2335:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] fs/smb/client/cifsglob.h:2334:38: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2025-02-19io_uring/rsrc: remove unused constantsCaleb Sander Mateos
IO_NODE_ALLOC_CACHE_MAX has been unused since commit fbbb8e991d86 ("io_uring/rsrc: get rid of io_rsrc_node allocation cache") removed the rsrc_node_cache. IO_RSRC_TAG_TABLE_SHIFT and IO_RSRC_TAG_TABLE_MASK have been unused since commit 7029acd8a950 ("io_uring/rsrc: get rid of per-ring io_rsrc_node list") removed the separate tag table for registered nodes. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20250219033444.2020136-1-csander@purestorage.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-02-19Merge tag 'spi-nor/fixes-for-6.14-rc4' of ↵Miquel Raynal
https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/fixes Fix writes on SST flashes Commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`") introduced a bug where only one byte of data is written, regardless of the number of bytes requested. This causes the driver to use the incorrect write size for flashes using the SST byte programming, and to spit out a warning. # -----BEGIN PGP SIGNATURE----- # # iIoEABYIADIWIQQTlUWNzXGEo3bFmyIR4drqP028CQUCZ7NEiBQccHJhdHl1c2hA # a2VybmVsLm9yZwAKCRAR4drqP028CTVnAP9krBOLfmlYO94PntaDscgjcehnxbuF # PEQby8/KlEnX0gEA5K73/0oQIZUnHQ98E6ntAtKoYD5zGNAJaYDpw+66CAU= # =5xea # -----END PGP SIGNATURE----- # gpg: Signature made Mon 17 Feb 2025 03:15:36 PM CET # gpg: using EDDSA key 1395458DCD7184A376C59B2211E1DAEA3F4DBC09 # gpg: issuer "pratyush@kernel.org" # gpg: Good signature from "Pratyush Yadav <p.yadav@ti.com>" [expired] # gpg: aka "Pratyush Yadav <me@yadavpratyush.com>" [expired] # gpg: issuer "pratyush@kernel.org" does not match any User ID # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 805C 3923 2FBE 108C 49E1 663C F650 3556 C11B 1CCD # Subkey fingerprint: 1395 458D CD71 84A3 76C5 9B22 11E1 DAEA 3F4D BC09
2025-02-19mtd: rawnand: cadence: fix unchecked dereferenceNiravkumar L Rabara
Add NULL check before variable dereference to fix static checker warning. Fixes: d76d22b5096c ("mtd: rawnand: cadence: use dma_map_resource for sdma address") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/e448a22c-bada-448d-9167-7af71305130d@stanley.mountain/ Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-02-19MAINTAINERS: Remove myselfKarol Herbst
I was pondering with myself for a while if I should just make it official that I'm not really involved in the kernel community anymore, neither as a reviewer, nor as a maintainer. Most of the time I simply excused myself with "if something urgent comes up, I can chime in and help out". Lyude and Danilo are doing a wonderful job and I've put all my trust into them. However, there is one thing I can't stand and it's hurting me the most. I'm convinced, no, my core believe is, that inclusivity and respect, working with others as equals, no power plays involved, is how we should work together within the Free and Open Source community. I can understand maintainers needing to learn, being concerned on technical points. Everybody deserves the time to understand and learn. It is my true belief that most people are capable of change eventually. I truly believe this community can change from within, however this doesn't mean it's going to be a smooth process. The moment I made up my mind about this was reading the following words written by a maintainer within the kernel community: "we are the thin blue line" This isn't okay. This isn't creating an inclusive environment. This isn't okay with the current political situation especially in the US. A maintainer speaking those words can't be kept. No matter how important or critical or relevant they are. They need to be removed until they learn. Learn what those words mean for a lot of marginalized people. Learn about what horrors it evokes in their minds. I can't in good faith remain to be part of a project and its community where those words are tolerated. Those words are not technical, they are a political statement. Even if unintentionally, such words carry power, they carry meanings one needs to be aware of. They do cause an immense amount of harm. I wish the best of luck for everybody to continue to try to work from within. You got my full support and I won't hold it against anybody trying to improve the community, it's a thankless job, it's a lot of work. People will continue to burn out. I got burned out enough by myself caring about the bits I maintained, but eventually I had to realize my limits. The obligation I felt was eating me from inside. It stopped being fun at some point and I reached a point where I simply couldn't continue the work I was so motivated doing as I've did in the early days. Please respect my wishes and put this statement as is into the tree. Leaving anything out destroys its entire meaning. Respectfully Karol Signed-off-by: Karol Herbst <kherbst@redhat.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250215073753.1217002-2-kherbst@redhat.com
2025-02-19drm/nouveau/pmu: Fix gp10b firmware guardAaron Kling
Most kernel configs enable multiple Tegra SoC generations, causing this typo to go unnoticed. But in the case where a kernel config is strictly for Tegra186, this is a problem. Fixes: 989863d7cbe5 ("drm/nouveau/pmu: select implementation based on available firmware") Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250218-nouveau-gm10b-guard-v2-1-a4de71500d48@gmail.com
2025-02-19Merge branch 'am65-cpsw-cleanup'David S. Miller
Roger Quadros says: ==================== net: ethernet: ti: am65-cpsw: drop multiple functions and code cleanup We have 2 tx completion functions to handle single-port vs multi-port variants. Merge them into one function to make maintenance easier. We also have 2 functions to handle TX completion for SKB vs XDP. Get rid of them too. Also do some minor cleanups. ==================== Signed-off-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: ethernet: ti am65_cpsw: Drop separate TX completion functionsRoger Quadros
Drop separate TX completion functions for SKB and XDP. To do that use the SW_DATA mechanism to store ndev and skb/xdpf for TX packets. Use BUILD_BUG_ON_MSG() to fail build if SW_DATA size exceeds whats available. i.e. AM65_CPSW_NAV_SW_DATA_SIZE. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: ethernet: ti: am65_cpsw: move am65_cpsw_put_page() out of ↵Roger Quadros
am65_cpsw_run_xdp() This allows us to re-use am65_cpsw_run_xdp() for zero copy case. Add AM65_CPSW_XDP_TX case for successful XDP_TX so we don't free the page while in flight. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: ethernet: ti: am65-cpsw: use return instead of goto in am65_cpsw_run_xdp()Roger Quadros
In am65_cpsw_run_xdp() instead of goto followed by return, simply return. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: ethernet: ti: am65_cpsw: remove cpu argument am65_cpsw_run_xdpRoger Quadros
am65_cpsw_run_xdp() can figure out the cpu id itself. No need to pass it around 2 functions so drop it. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: ethernet: ti: am65-cpsw: remove am65_cpsw_nuss_tx_compl_packets_2g()Roger Quadros
The only difference between am65_cpsw_nuss_tx_compl_packets_2g() and am65_cpsw_nuss_tx_compl_packets() is the usage of spin_lock() and netdev_tx_completed_queue() + am65_cpsw_nuss_tx_wake at every packet in the latter. Insted of having 2 separate functions for TX completion, merge them into one. This will reduce code duplication and make maintenance easier. Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19can: rockchip_canfd: rkcanfd_chip_fifo_setup(): remove duplicated setup of ↵Robin van der Gracht
RX FIFO The rockchip_canfd driver doesn't make use of the TXE FIFO. Although the comment states that the TXE FIFO is setup, it's actually a setup of the RX FIFO. The regular setup of the RX FIFO follows. Remove the duplicated setup of the RX FIFO. Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Signed-off-by: Robin van der Gracht <robin@protonic.nl> Link: https://patch.msgid.link/20250219-rk3568-canfd-v1-1-453869358c72@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: gs_usb: add VID/PID for the CANnectivity firmwareHenrik Brix Andersen
Add USB VID/PID for the CANnectivity USB to CAN adapter firmware. Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk> Tested-by: Sean Nyekjaer <sean@geanix.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250120133827.668977-1-henrik@brixandersen.dk Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: canxl: support Remote Request Substitution bit accessOliver Hartkopp
The Remote Request Substitution bit is a dominant bit ("0") in the CAN XL frame. As some CAN XL controllers support to access this bit a new CANXL_RRS value has been defined for the canxl_frame.flags element. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20250124142347.7444-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: j1939: Extend stack documentation with buffer size behaviorOleksij Rempel
Extend the J1939 stack documentation to include information about how buffer sizes influence stack behavior, detailing handling of simple sessions, TP, and ETP transfers. Additionally, describe various setsockopt(2) options, including their usage and potential error values that can be returned by the stack. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20241013181715.3488980-1-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19dt-binding: can: mcp251xfd: remove duplicate wordRuffalo Lavoisier
Remove duplicate word 'to' from microchip,rx-int-gpios description. Signed-off-by: Ruffalo Lavoisier <ruffalolavoisier@gmail.com> Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20241120044014.92375-1-RuffaloLavoisier@gmail.com [mkl: rephrase subject and patch description] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19Merge patch series "add FlexCAN support for S32G2/S32G3 SoCs"Marc Kleine-Budde
Ciprian Costea <ciprianmarian.costea@oss.nxp.com> says: S32G2 and S32G3 SoCs share the FlexCAN module with i.MX SoCs, with some hardware integration particularities. Main difference covered by this patch-set relates to interrupt management. On S32G2/S32G3 SoC, there are separate interrupts for state change, bus errors, MBs 0-7 and MBs 8-127 respectively. Changes in V4: - Updated IRQ description in bindings documentation - Fixed some small issues with the proposed changes in the flexcan binding documentation Changes in V3: - Added Vincent Mailhol's Reviewed-by tag on the second patch - Changed to 'platform_get_irq_byname' for second range of mailboxes - Made several rephasing in bindings doc - Removed Frank Li's Reviewed-by tags since changes were made afterwards. Changes in V2: - Separated 'FLEXCAN_QUIRK_NR_IRQ_3' quirk addition from S32G SoC Flexcan support. - Provided more information in dt-bindings documentation with respect to FlexCAN module integration on S32G SoCs. - Fixed and IRQ resource freeing management issue. Link: https://patch.msgid.link/20250113120704.522307-1-ciprianmarian.costea@oss.nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: flexcan: add NXP S32G2/S32G3 SoC supportCiprian Marian Costea
Add device type data for S32G2/S32G3 SoC. FlexCAN module from S32G2/S32G3 is similar with i.MX SoCs, but interrupt management is different. On S32G2/S32G3 SoC, there are separate interrupts for state change, bus errors, Mailboxes 0-7 and Mailboxes 8-127 respectively. In order to handle this FlexCAN hardware particularity, first reuse the 'FLEXCAN_QUIRK_NR_IRQ_3' quirk provided by mcf5441x's irq handling support. Secondly, use the newly introduced 'FLEXCAN_QUIRK_SECONDARY_MB_IRQ' quirk which handles the case where two separate mailbox ranges are controlled by independent hardware interrupt lines. Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Link: https://patch.msgid.link/20250113120704.522307-4-ciprianmarian.costea@oss.nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: flexcan: Add quirk to handle separate interrupt lines for mailboxesCiprian Marian Costea
Introduce 'FLEXCAN_QUIRK_SECONDARY_MB_IRQ' quirk to handle a FlexCAN hardware module integration particularity where two ranges of mailboxes are controlled by separate hardware interrupt lines. The same 'flexcan_irq' handler is used for both separate mailbox interrupt lines, with no other changes. Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250113120704.522307-3-ciprianmarian.costea@oss.nxp.com [mkl: flexcan_open(): change order and free irq_secondary_mb first] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19dt-bindings: can: fsl,flexcan: add S32G2/S32G3 SoC supportCiprian Marian Costea
Add S32G2/S32G3 SoCs compatible strings. A particularity for these SoCs is the presence of separate interrupts for state change, bus errors, MBs 0-7 and MBs 8-127 respectively. Increase maxItems of 'interrupts' to 4 for S32G based SoCs and keep the same restriction for other SoCs. Also, as part of this commit, move the 'allOf' after the required properties to make the documentation easier to read. Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250113120704.522307-2-ciprianmarian.costea@oss.nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19Merge patch series "can: c_can: Simplify few things"Marc Kleine-Budde
This series by Krzysztof Kozlowski simplifies the c_can_plat_probe() function. Changes in v2: - None, just rebase and drop applied fix. - Link to v1: https://lore.kernel.org/r/20250112-syscon-phandle-args-can-v1-0-314d9549906f@linaro.org Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-0-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: c_can: Use syscon_regmap_lookup_by_phandle_argsKrzysztof Kozlowski
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over syscon_regmap_lookup_by_phandle() combined with getting the syscon argument. Except simpler code this annotates within one line that given phandle has arguments, so grepping for code would be easier. There is also no real benefit in printing errors on missing syscon argument, because this is done just too late: runtime check on static/build-time data. Dtschema and Devicetree bindings offer the static/build-time check for this already. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-4-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: c_can: Use of_property_present() to test existence of DT propertyKrzysztof Kozlowski
of_property_read_bool() should be used only on boolean properties. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-3-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: c_can: Simplify handling syscon error pathKrzysztof Kozlowski
Use error handling block instead of open-coding it in one of probe failure cases. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-2-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19can: c_can: Drop useless final probe failure messageKrzysztof Kozlowski
Generic probe failure message is useless: does not give information what failed and it duplicates messages provided by the core, e.g. from memory allocation or platform_get_irq(). It also floods dmesg in case of deferred probe, e.g. resulting from devm_clk_get(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250212-syscon-phandle-args-can-v2-1-ac9a1253396b@linaro.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-02-19Merge branch 'net-mana-big-tcp'David S. Miller
Shradha Gupta says: ==================== net: Enable Big TCP for MANA devices Allow the max gso/gro aggregated pkt size to go up to GSO_MAX_SIZE for MANA NIC. On Azure, this not possible without allowing the same for netvsc NIC (as the NICs are bonded together). Therefore, we use netif_set_tso_max_size() to set max aggregated pkt size to VF's tso_max_size for netvsc too, when the data path is switched over to the VF The first patch allows MANA to configure aggregated pkt size of up-to GSO_MAX_SIZE The second patch enables the same on the netvsc NIC, if the data path for the bonded NIC is switched to the VF --- Changes in v3 * Add ipv6_hopopt_jumbo_remove() while sending Big TCP packets --- Changes in v2 * Instead of using 'tcp segment' throughout the patch used the words 'aggregated pkt size' ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19hv_netvsc: Use VF's tso_max_size value when data path is VFShradha Gupta
On Azure, increasing VF's gso/gro packet size to up-to GSO_MAX_SIZE is not possible without allowing the same for netvsc NIC (as the NICs are bonded together). For bonded NICs, the min of the max aggregated pkt size of the members is propagated in the stack. Therefore, we use netif_set_tso_max_size() to set max aggregated pkt size to VF's packet size for netvsc too, when the data path is switched over to the VF Tested on azure env with Accelerated Networking enabled and disabled. Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19net: mana: Allow tso_max_size to go up-to GSO_MAX_SIZEShradha Gupta
Allow the max aggregated pkt size to go up-to GSO_MAX_SIZE for MANA NIC. This patch only increases the max allowable gso/gro pkt size for MANA devices and does not change the defaults. Following are the perf benefits by increasing the pkt aggregate size from legacy gso_max_size value(64K) to newer one(up-to 511K IPv4 tests for i in {1..10}; do netperf -t TCP_RR -H 10.0.0.5 -p50000 -- -r80000,80000 -O MIN_LATENCY,P90_LATENCY,P99_LATENCY,THROUGHPUT|tail -1; done min p90 p99 Throughput gso_max_size 93 171 194 6594.25 97 154 180 7183.74 95 165 189 6927.86 96 165 188 6976.04 93 154 185 7338.05 64K 93 168 189 6938.03 94 169 189 6784.93 92 166 189 7117.56 94 179 191 6678.44 95 157 183 7277.81 min p90 p99 Throughput 93 134 146 8448.75 95 134 140 8396.54 94 137 148 8204.12 94 137 148 8244.41 94 128 139 8666.52 80K 94 141 153 8116.86 94 138 149 8163.92 92 135 142 8362.72 92 134 142 8497.57 93 136 148 8393.23 IPv6 Tests for i in {1..10}; do netperf -t TCP_RR -H fd00:9013:cadd::4 -p50000 -- -r80000,80000 -O MIN_LATENCY,P90_LATENCY,P99_LATENCY,THROUGHPUT|tail -1; done min p90 p99 Throughput gso_max_size 108 165 170 6673.2 101 169 189 6451.69 101 165 169 6737.65 102 167 175 6614.64 101 178 189 6247.13 64K 107 163 169 6678.63 106 176 187 6350.86 100 164 169 6617.36 102 163 170 6849.21 102 168 175 6605.7 min p90 p99 Throughput 108 155 166 7183 110 154 163 7268.87 109 152 159 7434.35 107 145 157 7569.15 107 149 164 7496.17 80K 110 154 159 7245.85 108 156 162 7266.24 109 145 158 7526.66 106 145 151 7785.75 111 148 157 7246.65 Tested on azure env with Accelerated Networking enabled and disabled. Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-02-19HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()Zhang Lixu
The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed. Fixes: 0b28cb4bcb17 ("HID: intel-ish-hid: ISH HID client driver") Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-02-19HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove()Zhang Lixu
During the `rmmod` operation for the `intel_ishtp_hid` driver, a use-after-free issue can occur in the hid_ishtp_cl_remove() function. The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(), which can lead to accessing freed memory or resources during the removal process. Call Trace: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? hid_output_report+0xe3/0x150 [hid] hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid] ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid] hid_hw_request+0x1f/0x40 [hid] sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub] _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger] hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger] sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub] hid_device_remove+0x49/0xb0 [hid] hid_destroy_device+0x6f/0x90 [hid] ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid] hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Additionally, ishtp_hid_remove() is a HID level power off, which should occur before the ISHTP level disconnect. This patch resolves the issue by reordering the calls in hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now called before hid_ishtp_cl_deinit(). Fixes: f645a90e8ff7 ("HID: intel-ish-hid: ishtp-hid-client: use helper functions for connection") Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-02-19HID: google: fix unused variable warning under !CONFIG_ACPIYu-Chun Lin
As reported by the kernel test robot, the following warning occurs: >> drivers/hid/hid-google-hammer.c:261:36: warning: 'cbas_ec_acpi_ids' defined but not used [-Wunused-const-variable=] 261 | static const struct acpi_device_id cbas_ec_acpi_ids[] = { | ^~~~~~~~~~~~~~~~ The 'cbas_ec_acpi_ids' array is only used when CONFIG_ACPI is enabled. Wrapping its definition and 'MODULE_DEVICE_TABLE' in '#ifdef CONFIG_ACPI' prevents a compiler warning when ACPI is disabled. Fixes: eb1aac4c8744f75 ("HID: google: add support tablet mode switch for Whiskers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501201141.jctFH5eB-lkp@intel.com/ Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-02-19HID: nintendo: fix gencon button events mapRyan McClelland
This fixes the button event map to match the 3-button recommendation as well as the redundant 'z' in the button map events for the Sega MD/Gen 6 Button. Signed-off-by: Ryan McClelland <rymcclel@gmail.com> Reviewed-by: Daniel J. Ogorchock <djogorchock@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-02-19cgroup/dmem: Don't open-code css_for_each_descendant_preFriedrich Vock
The current implementation has a bug: If the current css doesn't contain any pool that is a descendant of the "pool" (i.e. when found_descendant == false), then "pool" will point to some unrelated pool. If the current css has a child, we'll overwrite parent_pool with this unrelated pool on the next iteration. Since we can just check whether a pool refers to the same region to determine whether or not it's related, all the additional pool tracking is unnecessary, so just switch to using css_for_each_descendant_pre for traversal. Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup") Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250127152754.21325-1-friedrich.vock@gmx.de Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-02-19cxl: Fix cross-reference in documentation and add deprecation warningAndrew Donnellan
commit 5731d41af924 ("cxl: Deprecate driver") labelled the cxl driver as deprecated and moved the ABI documentation to the obsolete/ subdirectory, but didn't update cxl.rst, causing a warning once ff7ff6eb4f809 ("docs: media: Allow creating cross-references for RC ABI") was merged. Fix the cross-reference, and also add a deprecation warning. Fixes: 5731d41af924 ("cxl: Deprecate driver") Reported-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Acked-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250219064807.175107-1-ajd@linux.ibm.com
2025-02-18Merge branch 'net-fix-race-of-rtnl_net_lock-dev_net-dev'Jakub Kicinski
Kuniyuki Iwashima says: ==================== net: Fix race of rtnl_net_lock(dev_net(dev)). Yael Chemla reported that commit 7fb1073300a2 ("net: Hold rtnl_net_lock() in (un)?register_netdevice_notifier_dev_net().") started to trigger KASAN's use-after-free splat. The problem is that dev_net(dev) fetched before rtnl_net_lock() might be different after rtnl_net_lock(). The patch 2 fixes the issue by checking dev_net(dev) after rtnl_net_lock(), and the patch 3 fixes the same potential issue that would emerge once RTNL is removed. v4: https://lore.kernel.org/20250212064206.18159-1-kuniyu@amazon.com v3: https://lore.kernel.org/20250211051217.12613-1-kuniyu@amazon.com v2: https://lore.kernel.org/20250207044251.65421-1-kuniyu@amazon.com v1: https://lore.kernel.org/20250130232435.43622-1-kuniyu@amazon.com ==================== Link: https://patch.msgid.link/20250217191129.19967-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-18dev: Use rtnl_net_dev_lock() in unregister_netdev().Kuniyuki Iwashima
The following sequence is basically illegal when dev was fetched without lookup because dev_net(dev) might be different after holding rtnl_net_lock(): net = dev_net(dev); rtnl_net_lock(net); Let's use rtnl_net_dev_lock() in unregister_netdev(). Note that there is no real bug in unregister_netdev() for now because RTNL protects the scope even if dev_net(dev) is changed before/after RTNL. Fixes: 00fb9823939e ("dev: Hold per-netns RTNL in (un)?register_netdev().") Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250217191129.19967-4-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-15 07:42:52 +0000