aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-05-20block: t10-pi: add MODULE_DESCRIPTION()Jeff Johnson1-1/+1
Fix the allmodconfig 'make W=1' issue: WARNING: modpost: missing MODULE_DESCRIPTION() in block/t10-pi.o Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-20nfc: nci: Fix uninit-value in nci_rx_workRyosuke Yasuoka1-1/+14
syzbot reported the following uninit-value access issue [1] nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded. Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet") Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d7b4dc6cd50410152534 [1] Signed-off-by: Ryosuke Yasuoka <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-20selftests: net: kill smcrouted in the cleanup logic in amt.shTaehee Yoo1-1/+7
The amt.sh requires smcrouted for multicasting routing. So, it starts smcrouted before forwarding tests. It must be stopped after all tests, but it isn't. To fix this issue, it kills smcrouted in the cleanup logic. Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Signed-off-by: Taehee Yoo <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-20ipv6: sr: fix missing sk_buff release in seg6_input_coreAndrea Mayer1-5/+6
The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails. Fixes: af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") Signed-off-by: Andrea Mayer <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-20net: Always descend into dsa/ folder with CONFIG_NET_DSA enabledFlorian Fainelli1-1/+3
Stephen reported that he was unable to get the dsa_loop driver to get probed, and the reason ended up being because he had CONFIG_FIXED_PHY=y in his kernel configuration. As Masahiro explained it: "obj-m += dsa/" means everything under dsa/ must be modular. If there is a built-in object under dsa/ with CONFIG_NET_DSA=m, you cannot do "obj-$(CONFIG_NET_DSA) += dsa/". You need to change it back to "obj-y += dsa/". This was the case here whereby CONFIG_NET_DSA=m, and so the obj-$(CONFIG_FIXED_PHY) += dsa_loop_bdinfo.o rule is not executed and the DSA loop mdio_board info structure is not registered with the kernel, and eventually the device is simply not found. To preserve the intention of the original commit of limiting the amount of folder descending, conditionally descend into drivers/net/dsa when CONFIG_NET_DSA is enabled. Fixes: 227d72063fcc ("dsa: simplify Kconfig symbols and dependencies") Reported-by: Stephen Langstaff <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Alexander Lobakin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-05-19dt-bindings: mailbox: qcom-ipcc: Document the SDX75 IPCCRohit Agarwal1-0/+1
Document the Inter-Processor Communication Controller on the SDX75 Platform. Signed-off-by: Rohit Agarwal <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19dt-bindings: mailbox: qcom: Add MSM8974 APCS compatibleLuca Weiss1-0/+1
Add compatible for the Qualcomm MSM8974 APCS block. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: Convert from tasklet to BH workqueueAllen Pais2-18/+19
The only generic interface to execute asynchronously in the BH context is tasklet; however, it's marked deprecated and has some design flaws. To replace tasklets, BH workqueue support was recently added. A BH workqueue behaves similarly to regular workqueues except that the queued work items are executed in the BH context. Based on the work done by Tejun Heo <[email protected]> Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10 Signed-off-by: Allen Pais <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdownJason-JH.Lin1-1/+1
The return value of pm_runtime_get_sync() in cmdq_mbox_shutdown() will return 1 when pm runtime state is active, and we don't want to get the warning message in this case. So we change the return value < 0 for WARN_ON(). Fixes: 8afe816b0c99 ("mailbox: mtk-cmdq-mailbox: Implement Runtime PM with autosuspend") Signed-off-by: Jason-JH.Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: mtk-cmdq-mailbox: fix module autoloadingKrzysztof Kozlowski1-0/+1
Add MODULE_DEVICE_TABLE(), so this module could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: zynqmp: handle SGI for shared IPITanmay Shah1-7/+152
At least one IPI is used in TF-A for communication with PMC firmware. If this IPI needs to be used by other agents such as RPU then, IPI system interrupt can't be generated in mailbox driver. In such case TF-A generates SGI to mailbox driver for IPI notification. Signed-off-by: Tanmay Shah <[email protected]> Signed-off-by: Saeed Nowshadi <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: arm_mhuv3: Add driverCristian Marussi4-0/+1126
Add support for ARM MHUv3 mailbox controller. Support is limited to the MHUv3 Doorbell extension using only the PBX/MBX combined interrupts. Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19dt-bindings: mailbox: arm,mhuv3: Add bindingsCristian Marussi2-0/+237
Add bindings for the ARM MHUv3 Mailbox controller. Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove kernel FIFO message queuingAndrew Davis2-111/+5
The kernel FIFO queue has a couple issues. The biggest issue is that it causes extra latency in a path that can be used in real-time tasks, such as communication with real-time remote processors. The whole FIFO idea itself looks to be a leftover from before the unified mailbox framework. The current mailbox framework expects mbox_chan_received_data() to be called with data immediately as it arrives. Remove the FIFO and pass the messages to the mailbox framework directly as part of a threaded IRQ handler. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Reverse FIFO busy check logicAndrew Davis1-17/+16
It is much more clear to check if the hardware FIFO is full and return EBUSY if true. This allows us to also remove one level of indention from the core of this function. It also makes the similarities between omap_mbox_chan_send_noirq() and omap_mbox_chan_send() more obvious. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove mbox_chan_to_omap_mbox()Andrew Davis1-11/+3
This function only checks if mbox_chan *chan is not NULL, but that cannot be the case and if it was returning NULL which is not later checked doesn't save us from this. The second check for chan->con_priv is completely redundant as if it was NULL we would return NULL just the same. Simply dereference con_priv directly and remove this function. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Use mbox_controller channel list directlyAndrew Davis1-31/+11
The driver stores a list of omap_mbox structs so it can later use it to lookup the mailbox names in of_xlate. This same information is already available in the mbox_controller passed into of_xlate. Simply use that data and remove the extra allocation and storage of the omap_mbox list. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Use function local struct mbox_controllerAndrew Davis1-9/+12
The mbox_controller struct is only needed in the probe function. Make it a local variable instead of storing a copy in omap_mbox_device to simplify that struct. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Merge mailbox child node setup loopsAndrew Davis1-73/+46
Currently the driver loops through all mailbox child nodes twice, once to read in data from each node, and again to make use of this data. Instead read the data and make use of it in one pass. This removes the need for several temporary data structures and reduces the complexity of this main loop in probe. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Use devm_pm_runtime_enable() helperAndrew Davis1-15/+3
Use device life-cycle managed runtime enable function to simplify probe and exit paths. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove device classAndrew Davis1-87/+2
The driver currently creates a new device class "mbox". Then for each mailbox adds a device to that class. This class provides no file operations provided for any userspace users of this device class. It may have been extended to be functional in our vendor tree at some point, but that is not the case anymore, nor does it matter for the upstream tree. Remove this device class and related functions and variables. This also allows us to switch to module_platform_driver() as there is nothing left to do in module_init(). Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove unneeded header omap-mailbox.hAndrew Davis1-5/+2
The type of message sent using omap-mailbox is always u32. The definition of mbox_msg_t is uintptr_t which is wrong as that type changes based on the architecture (32bit vs 64bit). This type should have been defined as u32. Instead of making that change here, simply remove the header usage and fix the last couple users of the same in this driver. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Move fifo size check to point of useAndrew Davis1-5/+5
The mbox_kfifo_size can be changed at runtime, the sanity check on it's value should be done when it is used, not only once at init time. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Move omap_mbox_irq_t into driverAndrew Davis2-4/+5
This is only used internal to the driver, move it out of the public header and into the driver file. While we are here, this is not used as a bitwise, so drop that and make it a simple enum type. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove unused omap_mbox_request_channel() functionAndrew Davis2-42/+0
This function is not used, remove this function. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19mailbox: omap: Remove unused omap_mbox_{enable,disable}_irq() functionsAndrew Davis2-35/+10
These function are not used, remove these here. While here, remove the leading _ from the driver internal functions that do the same thing as the functions removed. Signed-off-by: Andrew Davis <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2024-05-19usercopy: Don't use "proxy" headersAndy Shevchenko1-2/+6
Update header inclusions to follow IWYU (Include What You Use) principle. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Yury Norov <[email protected]>
2024-05-19bitops: Move aligned_byte_mask() to wordpart.hAndy Shevchenko3-7/+8
The bitops.h is for bit related operations. The aligned_byte_mask() is about byte (or part of the machine word) operations, for which we have a separate header, move the mentioned macro to wordpart.h to consolidate similar operations. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Yury Norov <[email protected]>
2024-05-19MAINTAINERS: add BITOPS API recordYury Norov1-0/+14
Bitops API is the very basic, and it's widely used by the kernel. But corresponding files are not maintained. Bitmaps actively use bit operations, and big share of bitops material already moves through the bitmap branch. I would like to take a closer look to bitops. This patch creates a BITOPS API record in the MAINTAINERS, and adds Rasmus as a reviewer, and myself as a maintainer of those files. CC: Rasmus Villemoes <[email protected]> Signed-off-by: Yury Norov <[email protected]>
2024-05-19mm/page-owner: use gfp_nested_mask() instead of open coded maskingDave Chinner1-6/+1
The page-owner tracking code records stack traces during page allocation. To do this, it must do a memory allocation for the stack information from inside an existing memory allocation context. This internal allocation must obey the high level caller allocation constraints to avoid generating false positive warnings that have nothing to do with the code they are instrumenting/tracking (e.g. through lockdep reclaim state tracking) We also don't want recording stack traces to deplete emergency memory reserves - debug code is useless if it creates new issues that can't be replicated when the debug code is disabled. Switch the stack tracking allocation masking to use gfp_nested_mask() to address these issues. gfp_nested_mask() naturally strips GFP_ZONEMASK, too, which greatly simplifies this code. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Marco Elver <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19stackdepot: use gfp_nested_mask() instead of open coded maskingDave Chinner1-9/+2
The stackdepot code is used by KASAN and lockdep for recoding stack traces. Both of these track allocation context information, and so their internal allocations must obey the caller allocation contexts to avoid generating their own false positive warnings that have nothing to do with the code they are instrumenting/tracking. We also don't want recording stack traces to deplete emergency memory reserves - debug code is useless if it creates new issues that can't be replicated when the debug code is disabled. Switch the stackdepot allocation masking to use gfp_nested_mask() to address these issues. gfp_nested_mask() also strips GFP_ZONEMASK naturally, so that greatly simplifies this code. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Marco Elver <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: Andrey Konovalov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19mm: lift gfp_kmemleak_mask() to gfp.hDave Chinner2-8/+29
Patch series "mm: fix nested allocation context filtering". This patchset is the followup to the comment I made earlier today: https://lore.kernel.org/linux-xfs/[email protected]/ Tl;dr: Memory allocations that are done inside the public memory allocation API need to obey the reclaim recursion constraints placed on the allocation by the original caller, including the "don't track recursion for this allocation" case defined by __GFP_NOLOCKDEP. These nested allocations are generally in debug code that is tracking something about the allocation (kmemleak, KASAN, etc) and so are allocating private kernel objects that only that debug system will use. Neither the page-owner code nor the stack depot code get this right. They also also clear GFP_ZONEMASK as a separate operation, which is completely redundant because the constraint filter applied immediately after guarantees that GFP_ZONEMASK bits are cleared. kmemleak gets this filtering right. It preserves the allocation constraints for deadlock prevention and clears all other context flags whilst also ensuring that the nested allocation will fail quickly, silently and without depleting emergency kernel reserves if there is no memory available. This can be made much more robust, immune to whack-a-mole games and the code greatly simplified by lifting gfp_kmemleak_mask() to include/linux/gfp.h and using that everywhere. Also document it so that there is no excuse for not knowing about it when writing new debug code that nests allocations. Tested with lockdep, KASAN + page_owner=on and kmemleak=on over multiple fstests runs with XFS. This patch (of 3): Any "internal" nested allocation done from within an allocation context needs to obey the high level allocation gfp_mask constraints. This is necessary for debug code like KASAN, kmemleak, lockdep, etc that allocate memory for saving stack traces and other information during memory allocation. If they don't obey things like __GFP_NOLOCKDEP or __GFP_NOWARN, they produce false positive failure detections. kmemleak gets this right by using gfp_kmemleak_mask() to pass through the relevant context flags to the nested allocation to ensure that the allocation follows the constraints of the caller context. KASAN recently was foudn to be missing __GFP_NOLOCKDEP due to stack depot allocations, and even more recently the page owner tracking code was also found to be missing __GFP_NOLOCKDEP support. We also don't wan't want KASAN or lockdep to drive the system into OOM kill territory by exhausting emergency reserves. This is something that kmemleak also gets right by adding (__GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN) to the allocation mask. Hence it is clear that we need to define a common nested allocation filter mask for these sorts of third party nested allocations used in debug code. So to start this process, lift gfp_kmemleak_mask() to gfp.h and rename it to gfp_nested_mask(), and convert the kmemleak callers to use it. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Marco Elver <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Reviewed-by: Oscar Salvador <[email protected]> Cc: Andrey Konovalov <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19nilfs2: make block erasure safe in nilfs_finish_roll_forward()Ryusuke Konishi1-0/+4
The implementation of writing a zero-fill block in nilfs_finish_roll_forward() is not safe. The buffer is being cleared without acquiring a lock or setting the uptodate flag, so theoretically, between the time the buffer's data is cleared and the time it is written back to the block device using sync_dirty_buffer(), that zero data can be undone by concurrent block device reads. Since this buffer points to a location that has been read from disk once, the uptodate flag will most likely remain, but since it was obtained with __getblk(), that is not guaranteed. In other words, this is exceptional, and this function itself is not normally called (only once when mounting after a specific pattern of unclean shutdown), so it is highly unlikely that this will actually cause a problem. Anyway, eliminate this potential race issue by protecting the clearing of buffer data with a buffer lock and setting the buffer's uptodate flag within the protected section. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19selftests/harness: use 1024 in place of LINE_MAXTao Su1-2/+1
Android was seeing a compilation error because its C library does not define LINE_MAX. Since LINE_MAX is only used to determine the size of test_name[] and 1024 should be enough for the test name, use 1024 instead of LINE_MAX. Link: https://lkml.kernel.org/r/[email protected] Fixes: 38c957f07038 ("selftests: kselftest_harness: generate test name once") Signed-off-by: Tao Su <[email protected]> Reviewed-by: Simon Horman <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Bongsu Jeon <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David S. Miller <[email protected]> Cc: Edward Liaw <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Ivan Orlov <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Mark Brown <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Takashi Iwai <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19Revert "selftests/harness: remove use of LINE_MAX"Tao Su2-9/+4
Patch series "Selftests: Fix compilation warnings due to missing _GNU_SOURCE definition", v2. Since kselftest_harness.h introduces asprintf()[1], many selftests have compilation warnings or errors due to missing _GNU_SOURCE definitions. The issue stems from a lack of a LINE_MAX definition in Android (see commit 38c957f07038), which is the reason why asprintf() was introduced. We tried adding _GNU_SOURCE definitions to more selftests to fix, but asprintf() may continue to cause problems, and since it is quite late in the 6.9 cycle, we would like to revert 809216233555 first to provide testing for forks[2]. [1] https://lore.kernel.org/all/[email protected] [2] https://lore.kernel.org/linux-kselftest/[email protected] This patch (of 2): This reverts commit 8092162335554c8ef5e7f50eff68aa9cfbdbf865. asprintf() is declared in stdio.h when defining _GNU_SOURCE, but stdio.h is so common that many files don't define _GNU_SOURCE before including stdio.h, and defining _GNU_SOURCE after including stdio.h will no longer take effect, which causes warnings or even errors during compilation in many selftests. Revert 'commit 809216233555 ("selftests/harness: remove use of LINE_MAX")' as that came in quite late in the 6.9 cycle. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/linux-kselftest/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX") Signed-off-by: Tao Su <[email protected]> Reviewed-by: Simon Horman <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Bongsu Jeon <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David S. Miller <[email protected]> Cc: Edward Liaw <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Ivan Orlov <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Mark Brown <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Takashi Iwai <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19selftests/fpu: allow building on other architecturesSamuel Holland3-25/+7
Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile and run floating-point code, this test is no longer x86-specific. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19selftests/fpu: move FP code to a separate translation unitSamuel Holland4-32/+48
This ensures no compiler-generated floating-point code can appear outside kernel_fpu_{begin,end}() sections, and some architectures enforce this separation. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19drm/amd/display: use ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland4-94/+7
Now that all previously-supported architectures select ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead of the existing list of architectures. It can also take advantage of the common kernel-mode FPU API and method of adjusting CFLAGS. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19drm/amd/display: only use hard-float, not altivec on powerpcMichael Ellerman3-12/+4
The compiler flags enable altivec, but that is not required; hard-float is sufficient for the code to build and function. Drop altivec from the compiler flags and adjust the enable/disable code to only enable FPU use. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Christian König <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19riscv: add support for kernel-mode FPUSamuel Holland5-0/+49
This is motivated by the amdgpu DRM driver, which needs floating-point code to support recent hardware. That code is not performance-critical, so only provide a minimal non-preemptible implementation for now. Support is limited to riscv64 because riscv32 requires runtime (libgcc) assistance to convert between doubles and 64-bit integers. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> Reviewed-by: Palmer Dabbelt <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19x86: implement ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland3-0/+34
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a different header. Add a wrapper header, and export the CFLAGS adjustments as found in lib/Makefile. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19powerpc: implement ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland3-1/+33
PowerPC provides an equivalent to the common kernel-mode FPU API, but in a different header and using different function names. The PowerPC API also requires a non-preemptible context. Add a wrapper header, and export the CFLAGS adjustments. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Acked-by: Michael Ellerman <[email protected]> (powerpc) Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19LoongArch: implement ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland3-1/+6
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in asm/fpu.h, so it only needs to add kernel_fpu_available() and export the CFLAGS adjustments. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Acked-by: WANG Xuerui <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19lib/raid6: use CC_FLAGS_FPU for NEON CFLAGSSamuel Holland1-23/+10
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source tree, use it instead of duplicating the flags here. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19arm64: crypto: use CC_FLAGS_FPU for NEON CFLAGSSamuel Holland1-4/+2
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source tree, use it instead of duplicating the flags here. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19arm64: implement ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland3-1/+24
arm64 provides an equivalent to the common kernel-mode FPU API, but in a different header and using different function names. Add a wrapper header, and export CFLAGS adjustments as found in lib/raid6/Makefile. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19ARM: crypto: use CC_FLAGS_FPU for NEON CFLAGSSamuel Holland1-2/+1
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source tree, use it instead of duplicating the flags here. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19ARM: implement ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland2-0/+22
ARM provides an equivalent to the common kernel-mode FPU API, but in a different header and using different function names. Add a wrapper header, and export CFLAGS adjustments as found in lib/raid6/Makefile. [[email protected]: ARM: do not select ARCH_HAS_KERNEL_FPU_SUPPORT] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Cc: Thiago Jung Bauermann <[email protected]> Cc: Ard Biesheuvel <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19arch: add ARCH_HAS_KERNEL_FPU_SUPPORTSamuel Holland5-0/+102
Several architectures provide an API to enable the FPU and run floating-point SIMD code in kernel space. However, the function names, header locations, and semantics are inconsistent across architectures, and FPU support may be gated behind other Kconfig options. provide a standard way for architectures to declare that kernel space FPU support is available. Architectures selecting this option must implement what is currently the most common API (kernel_fpu_begin() and kernel_fpu_end(), plus a new function kernel_fpu_available()) and provide the appropriate CFLAGS for compiling floating-point C code. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Acked-by: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: WANG Xuerui <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2024-05-19x86/fpu: fix asm/fpu/types.h include guardSamuel Holland1-3/+3
Patch series "Unified cross-architecture kernel-mode FPU API", v4. This series unifies the kernel-mode FPU API across several architectures by wrapping the existing functions (where needed) in consistently-named functions placed in a consistent header location, with mostly the same semantics: they can be called from preemptible or non-preemptible task context, and are not assumed to be reentrant. Architectures are also expected to provide CFLAGS adjustments for compiling FPU-dependent code. For the moment, SIMD/vector units are out of scope for this common API. This allows us to remove the ifdeffery and duplicated Makefile logic at each FPU user. It then implements the common API on RISC-V, and converts a couple of users to the new API: the AMDGPU DRM driver, and the FPU self test. The underlying goal of this series is to allow using newer AMD GPUs (e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode FPU support. This patch (of 15): The include guard should match the filename, or it will conflict with the newly-added asm/fpu.h. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Samuel Holland <[email protected]> Acked-by: Dave Hansen <[email protected]> Acked-by: Christian König <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Huacai Chen <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: Russell King <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: WANG Xuerui <[email protected]> Signed-off-by: Andrew Morton <[email protected]>