summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-09Merge branch 'enic-set-link-speed-only-after-link-up'Jakub Kicinski
John Daley says: ==================== enic: Set link speed only after link up ==================== Link: https://patch.msgid.link/20250107214159.18807-1-johndale@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09enic: Fix typo in comment in table indexed by link speedJohn Daley
The RX adaptive interrupt moderation table is indexed by link speed range, where the last row of the table is the catch-all for all link speeds greater than 10Gbps. The comment said 10 - 40Gbps, but since there are now adapters with link speeds than 40Gbps, the comment is now wrong and should indicate it applies to all speeds greater than 10Gbps. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://patch.msgid.link/20250107214159.18807-4-johndale@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09enic: Obtain the Link speed only after the link comes upJohn Daley
The link speed is obtained in the RX adaptive coalescing function. It was being called at probe time when the link may not be up. Change the call to run after the Link comes up. The impact of not getting the correct link speed was that the low end of the adaptive interrupt range was always being set to 0 which could have caused a slight increase in the number of RX interrupts. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://patch.msgid.link/20250107214159.18807-3-johndale@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09enic: Move RX coalescing set functionJohn Daley
Move the function used for setting the RX coalescing range to before the function that checks the link status. It needs to be called from there instead of from the probe function. There is no functional change. Co-developed-by: Nelson Escobar <neescoba@cisco.com> Signed-off-by: Nelson Escobar <neescoba@cisco.com> Co-developed-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: John Daley <johndale@cisco.com> Link: https://patch.msgid.link/20250107214159.18807-2-johndale@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09dt-bindings: net: qcom,ipa: Use recommended MBN firmware format in DTS exampleKrzysztof Kozlowski
All Qualcomm firmwares uploaded to linux-firmware are in MBN format, instead of split MDT. No functional changes, just correct the DTS example so people will not rely on unaccepted files. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Alex Elder <elder@kernel.org> Link: https://patch.msgid.link/20250108120242.156201-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09spi: spi-mem: Create macros for DTR operationMiquel Raynal
We do have macros for defining command, address, dummy and data cycles. We also have a .dtr flag that implies sampling the bus on both edges, but there are currently no macros enabling it. We might make use of such macros, so let's create: - SPI_MEM_DTR_OP_CMD - SPI_MEM_DTR_OP_ADDR - SPI_MEM_DTR_OP_DUMMY - SPI_MEM_DTR_OP_DATA_OUT - SPI_MEM_DTR_OP_DATA_OUT Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-19-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: spi-mem: Reorder spi-mem macro assignmentsMiquel Raynal
Follow the order in which all the `struct spi_mem_op` members are defined. This is purely aesthetics, there is no functional change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-18-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: zynqmp-gqspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Michal Simek <michal.simek@amd.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-17-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: zynq-qspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-16-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: spi-ti-qspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-15-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: spi-sn-f-ospi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-14-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: rockchip-sfc: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Han Xu <han.xu@nxp.com> Cc: Haibo Chen <haibo.chen@nxp.com> Cc: Yogesh Gaur <yogeshgaur.83@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-13-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: nxp-fspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-12-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: mxic: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-11-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: mt65xx: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-10-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: microchip-core-qspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. This controller however performed a frequency check, which is also observed during the ->check_op() phase. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Conor Dooley <conor.dooley@microchip.com> Cc: Daire McNamara <daire.mcnamara@microchip.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-9-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: fsl-qspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Han Xu <han.xu@nxp.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-8-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: dw: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-7-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: cadence-qspi: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-6-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: amlogic-spifc-a1: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. The per-operation frequency capability is thus advertised to the spi-mem core. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-5-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: amd: Drop redundant checkMiquel Raynal
Both spi and spi-mem cores already take care of checking the minimum and maximum speed for transfers depending on the controller capabilities. There is no reason to repeat this check in controller drivers. Once this possible error condition removed from the function, it makes no longer sense to return an int. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-4-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: amd: Support per spi-mem operation frequency switchesMiquel Raynal
Every ->exec_op() call correctly configures the spi bus speed to the maximum allowed frequency for the memory using the constant spi default parameter. Since we can now have per-operation constraints, let's use the value that comes from the spi-mem operation structure instead. In case there is no specific limitation for this operation, the default spi device value will be given anyway. This controller however performed a frequency check, which is also observed during the ->check_op() phase. The per-operation frequency capability is thus advertised to the spi-mem core. Cc: Sanjay R Mehta <sanju.mehta@amd.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-3-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: spi-mem: Add a new controller capabilityMiquel Raynal
There are spi devices with multiple frequency limitations depending on the invoked command. We probably do not want to afford running at the lowest supported frequency all the time, so if we want to get the most of our hardware, we need to allow per-operation frequency limitations. Among all the SPI memory controllers, I believe all are capable of changing the spi frequency on the fly. Some of the drivers do not make any frequency setup though. And some others will derive a per chip prescaler value which will be used forever. Actually changing the frequency on the fly is something new in Linux, so we need to carefully flag the drivers which do and do not support it. A controller capability is created for that, and the presence for this capability will always be checked before accepting such pattern. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-2-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09spi: spi-mem: Extend spi-mem operations with a per-operation maximum frequencyMiquel Raynal
In the spi subsystem, the bus frequency is derived as follows: - the controller may expose a minimum and maximum operating frequency - the hardware description, through the spi peripheral properties, advise what is the maximum acceptable frequency from a device/wiring point of view. Transfers must be observed at a frequency which fits both (so in practice, the lowest maximum). Actually, this second point mixes two information and already takes the lowest frequency among: - what the spi device is capable of (what is written in the component datasheet) - what the wiring allows (electromagnetic sensibility, crossovers, terminations, antenna effect, etc). This logic works until spi devices are no longer capable of sustaining their highest frequency regardless of the operation. Spi memories are typically subject to such variation. Some devices are capable of spitting their internally stored data (essentially in read mode) at a very fast rate, typically up to 166MHz on Winbond SPI-NAND chips, using "fast" commands. However, some of the low-end operations, such as regular page read-from-cache commands, are more limited and can only be executed at 54MHz at most. This is currently a problem in the SPI-NAND subsystem. Another situation, even if not yet supported, will be with DTR commands, when the data is latched on both edges of the clock. The same chips as mentioned previously are in this case limited to 80MHz. Yet another example might be continuous reads, which, under certain circumstances, can also run at most at 104 or 120MHz. As a matter of fact, the "one frequency per chip" policy is outdated and more fine grain configuration is needed: we need to allow per-operation frequency limitations. So far, all datasheets I encountered advertise a maximum default frequency, which need to be lowered for certain specific operations. So based on the current infrastructure, we can still expect firmware (device trees in general) to continued advertising the same maximum speed which is a mix between the PCB limitations and the chip maximum capability, and expect per-operation lower frequencies when this is relevant. Add a `struct spi_mem_op` member to carry this information. Not providing this field explicitly from upper layers means that there is no further constraint and the default spi device maximum speed will be carried instead. The SPI_MEM_OP() macro is also expanded with an optional frequency argument, because virtually all operations can be subject to such a limitation, and this will allow for a smooth and discrete transition. For controller drivers which do not implement the spi-mem interface, the per-transfer speed is also set acordingly to a lower (than the maximum default) speed when relevant. Acked-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20241224-winbond-6-11-rc1-quad-support-v2-1-ad218dbc406f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09doc: module: DEFAULT_SYMBOL_NAMESPACE must be defined before #includesUwe Kleine-König
The definition of EXPORT_SYMBOL et al depends on DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be available when <linux/export.h> is parsed. Also when defined that early there is no need for an #undef, so drop that from the usage example. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/linux-i2c/Z09bp9uMzwXRLXuF@smile.fi.intel.com/ Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/3dd7ff6fa0a636de86e091286016be8c90e03631.1733305665.git.ukleinek@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241230142357.3203913-6-u.kleine-koenig@baylibre.com
2025-01-09doc: module: Fix documented type of namespaceUwe Kleine-König
Since commit cdd30ebb1b9f ("module: Convert symbol namespace to string literal") the namespace has to be a string. Fix accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6fe15069c01b31aaa68c6224bec2df9f4a449858.1733305665.git.ukleinek@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241230142357.3203913-5-u.kleine-koenig@baylibre.com
2025-01-09Documentation/kernel-parameters: Fix a reference to vga-softcursor.rstLubomir Rintel
A very minor oversight that dates all the way back to rst migration in commit 9d85025b0418 ("docs-rst: create an user's manual book"). Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241231190240.417446-1-lkundrak@v3.sk
2025-01-09docs/zh_CN: Add landlock index Chinese translationYuxian Mao
Translate lwn/Documentation/security/landlock.rst into Chinese. Update the translation through commit dad2f2071516 ("landlock: Fix grammar issues in documentation") Signed-off-by: Yuxian Mao <maoyuxian@cqsoftware.com.cn> Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20250102104406.17600-1-maoyuxian@cqsoftware.com.cn
2025-01-09Documentation: Fix typo localmodonfig -> localmodconfigLi Zhijian
It's noticed when I myself made the same spelling mistake while searching for localmodconfig Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20250103004358.1310121-1-lizhijian@fujitsu.com
2025-01-09overlayfs.rst: Fix and improve grammarGeert Uytterhoeven
- Correct "in a way the" to "in a way that", - Add a comma to improve readability. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/cf07f705d63f04ebf7ba4ecafdc9ab6f63960e3d.1736239148.git.geert+renesas@glider.be
2025-01-09ASoC: Use of_property_present() for non-boolean propertiesRob Herring (Arm)
The use of of_property_read_bool() for non-boolean properties is deprecated in favor of of_property_present() when testing for property presence. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250109182303.3973082-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09drm/xe/guc: Adding steering info support for GuC register listsJesus Narvaez
The guc_mmio_reg interface supports steering, but it is currently not implemented. This will allow the GuC to control steering of MMIO registers after save-restore and avoid reading from fused off MCR register instances. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241212190100.3768068-1-jesus.narvaez@intel.com
2025-01-09docs/zh_CN: Add siphash index Chinese translationzhangwei
Translate lwn/Documentation/security/siphash.rst into Chinese Update the translation through commit 12fe434314c8 ("Documentation: siphash: Fix typo in the name of offsetofend macro") Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: zhangwei <zhangwei@cqsoftware.com.cn> Reviewed-by: Yanteng Si <siyanteng@linux.dev> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/0af3d9b8be0e5166f74bd36fd6b040767f767fce.1736315479.git.zhangwei@cqsoftware.com.cn
2025-01-09docs/zh_CN: Add security IMA-templates Chinese translationShuo Zhao
Translate .../security/IMA-templates.rst into Chinese. Update the translation through commit 398c42e2c46c ("ima: support fs-verity file digest based version 3 signatures"). Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Shuo Zhao <zhaoshuo@cqsoftware.com.cn> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20250108075740.19342-1-zhaoshuo@cqsoftware.com.cn
2025-01-09docs/zh_CN: Add security digsig Chinese translationShuo Zhao
Translate .../security/digsig.rst into Chinese. Update the translation through commit d56b699d76d1 ("Documentation: Fix typos") Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Shuo Zhao <zhaoshuo@cqsoftware.com.cn> Reviewed-by: Yanteng Si <siyanteng@linux.dev> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20250108080136.19398-1-zhaoshuo@cqsoftware.com.cn
2025-01-09Merge tag 'for-6.13-rc6-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "A few more fixes. Besides the one-liners in Btrfs there's fix to the io_uring and encoded read integration (added in this development cycle). The update to io_uring provides more space for the ongoing command that is then used in Btrfs to handle some cases. - io_uring and encoded read: - provide stable storage for io_uring command data - make a copy of encoded read ioctl call, reuse that in case the call would block and will be called again - properly initialize zlib context for hardware compression on s390 - fix max extent size calculation on filesystems with non-zoned devices - fix crash in scrub on crafted image due to invalid extent tree" * tag 'for-6.13-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path btrfs: zoned: calculate max_extent_size properly on non-zoned setup btrfs: avoid NULL pointer dereference if no valid extent tree btrfs: don't read from userspace twice in btrfs_uring_encoded_read() io_uring: add io_uring_cmd_get_async_data helper io_uring/cmd: add per-op data to struct io_uring_cmd_data io_uring/cmd: rename struct uring_cache to io_uring_cmd_data
2025-01-09Merge patch series "SBI PMU event related fixes"Palmer Dabbelt
Atish Patra <atishp@rivosinc.com> says: Here are two minor improvement/fixes in the PMU event path. The first patch was part of the series[1]. The 2nd patch was suggested during the series review. While the series can only be merged once SBI v3.0 is frozen, these two patches can be independent of SBI v3.0 and can be merged sooner. Hence, these two patches are sent as a separate series. * b4-shazam-merge: drivers/perf: riscv: Do not allow invalid raw event config drivers/perf: riscv: Return error for default case drivers/perf: riscv: Fix Platform firmware event data Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-0-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Do not allow invalid raw event configAtish Patra
The SBI specification allows only lower 48bits of hpmeventX to be configured via SBI PMU. Currently, the driver masks of the higher bits but doesn't return an error. This will lead to an additional SBI call for config matching which should return for an invalid event error in most of the cases. However, if a platform(i.e Rocket and sifive cores) implements a bitmap of all bits in the event encoding this will lead to an incorrect event being programmed leading to user confusion. Report the error to the user if higher bits are set during the event mapping itself to avoid the confusion and save an additional SBI call. Suggested-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-3-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Return error for default caseAtish Patra
If the upper two bits has an invalid valid (0x1), the event mapping is not reliable as it returns an uninitialized variable. Return appropriate value for the default case. Fixes: f0c9363db2dd ("perf/riscv-sbi: Add platform specific firmware event handling") Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-2-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Fix Platform firmware event dataAtish Patra
Platform firmware event data field is allowed to be 62 bits for Linux as uppper most two bits are reserved to indicate SBI fw or platform specific firmware events. However, the event data field is masked as per the hardware raw event mask which is not correct. Fix the platform firmware event data field with proper mask. Fixes: f0c9363db2dd ("perf/riscv-sbi: Add platform specific firmware event handling") Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-1-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09Merge patch series "selftest: fix riscv/vector tests"Palmer Dabbelt
This contains a pair of fixes for the vector self tests, which avoids some warnings and provides proper status messages. * b4-shazam-merge: tools: selftests: riscv: Add test count for vstate_prctl tools: selftests: riscv: Add pass message for v_initval_nolibc Link: https://lore.kernel.org/r/20241220091730.28006-1-yongxuan.wang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09tools: selftests: riscv: Add test count for vstate_prctlYong-Xuan Wang
Add the test count to drop the warning message. "Planned tests != run tests (0 != 1)" Fixes: 7cf6198ce22d ("selftests: Test RISC-V Vector prctl interface") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Andy Chiu <AndybnAC@gmail.com> Link: https://lore.kernel.org/r/20241220091730.28006-3-yongxuan.wang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09tools: selftests: riscv: Add pass message for v_initval_nolibcYong-Xuan Wang
Add the pass message after we successfully complete the test. Fixes: 5c93c4c72fbc ("selftests: Test RISC-V Vector's first-use handler") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Andy Chiu <AndybnAC@gmail.com> Link: https://lore.kernel.org/r/20241220091730.28006-2-yongxuan.wang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09ASoC: amd: Add ACPI dependency to fix build errorYu-Chun Lin
As reported by the kernel test robot, the following error occurs: sound/soc/amd/yc/acp6x-mach.c: In function 'acp6x_probe': >> sound/soc/amd/yc/acp6x-mach.c:573:15: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'? [-Werror=implicit-function-declaration] 573 | ret = acpi_evaluate_integer(handle, "_WOV", NULL, &dmic_status); | ^~~~~~~~~~~~~~~~~~~~~ | acpi_evaluate_object cc1: some warnings being treated as errors The function 'acpi_evaluate_integer' and its prototype in 'acpi_bus.h' are only available when 'CONFIG_ACPI' is enabled. Add a 'depends on ACPI' directive in Kconfig to ensure proper compilation. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501090345.pBIDRTym-lkp@intel.com/ Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Link: https://patch.msgid.link/20250109171547.362412-1-eleanor15x@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-01-09drm/xe: Fix all typos in xeNitin Gote
Fix all typos in files of xe, reported by codespell tool. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250106102646.1400146-2-nitin.r.gote@intel.com Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
2025-01-09Merge tag 'nf-25-01-09' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Fix imbalance between flowtable BIND and UNBIND calls to configure hardware offload, this fixes a possible kmemleak. 2) Clamp maximum conntrack hashtable size to INT_MAX to fix a possible WARN_ON_ONCE splat coming from kvmalloc_array(), only possible from init_netns. * tag 'nf-25-01-09' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: conntrack: clamp maximum hashtable size to INT_MAX netfilter: nf_tables: imbalance in flowtable binding ==================== Link: https://patch.msgid.link/20250109123532.41768-1-pablo@netfilter.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09Merge branch 'net-sysctl-avoid-using-current-nsproxy'Jakub Kicinski
Matthieu Baerts says: ==================== net: sysctl: avoid using current->nsproxy As pointed out by Al Viro and Eric Dumazet in [1], using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns as it is usually done. This could cause unexpected issues when other operations are done on the wrong netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' or 'pernet' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly in more places, but that would increase the size of this fix to replace all accesses via 'net'. Probably best to avoid that for fixes. Patches 2-9 remove access of net via current->nsproxy in sysfs handlers in MPTCP, SCTP and RDS. There are multiple patches doing almost the same thing, but the reason is to ease the backports. Patch 1 is not directly linked to this, but it is a small fix for MPTCP available_schedulers sysctl knob to explicitly mark it as read-only. Please note that this series does not address Al's comment [2]. In SCTP, some sysctl knobs set other sysfs-exposed variables for the min/max: two processes could then write two linked values at the same time, resulting in new values being outside the new boundaries. It would be great if SCTP developers can look at this problem. Link: https://lore.kernel.org/67769ecb.050a0220.3a8527.003f.GAE@google.com [1] Link: https://lore.kernel.org/20250105211158.GL1977892@ZenIV [2] ==================== Link: https://patch.msgid.link/20250108-net-sysctl-current-nsproxy-v1-0-5df34b2083e8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyMatthieu Baerts (NGI0)
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The per-netns structure can be obtained from the table->data using container_of(), then the 'net' one can be retrieved from the listen socket (if available). Fixes: c6a58ffed536 ("RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/67769ecb.050a0220.3a8527.003f.GAE@google.com [1] Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250108-net-sysctl-current-nsproxy-v1-9-5df34b2083e8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyMatthieu Baerts (NGI0)
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.probe_interval' is used. Fixes: d1e462a7a5f3 ("sctp: add probe_interval in sysctl and sock/asoc/transport") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/67769ecb.050a0220.3a8527.003f.GAE@google.com [1] Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250108-net-sysctl-current-nsproxy-v1-8-5df34b2083e8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-09sctp: sysctl: udp_port: avoid using current->nsproxyMatthieu Baerts (NGI0)
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/67769ecb.050a0220.3a8527.003f.GAE@google.com [1] Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250108-net-sysctl-current-nsproxy-v1-7-5df34b2083e8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>