summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-08-10iio: imu: adis16475: drop ifdef around CONFIG_DEBUG_FSNuno Sa
Use IS_ENABLED(CONFIG_DEBUG_FS) to return early in case debugfs is not present. Since this is known at compile time, it allows the compiler to drop any unused code. Therefore no need to wrap the code with #ifdef. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240809-dev-adis-debugfs-improv-v1-1-d3adb6996518@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: adc: pac1921: add missing error return in probe()Dan Carpenter
This error path was intended to return, and not just print an error. The current code will lead to an error pointer dereference. Fixes: 371f778b83cd ("iio: adc: add support for pac1921") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Matteo Martelli <matteomartelli3@gmail.com> Link: https://patch.msgid.link/1fa4ab12-0939-477d-bc92-306fd32e4fd9@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: Fix spelling mistake "avaialable" -> "available"Colin Ian King
There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20240807094745.4174785-1-colin.i.king@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: dac: ltc2664: Fix off by one in ltc2664_channel_config()Dan Carpenter
This comparison should be >= ARRAY_SIZE() instead of >. The "mspan" variable is later used as an array index into ltc2664_mspan_lut[] so this is an off by one bug. Fixes: 4cc2fc445d2e ("iio: dac: ltc2664: Add driver for LTC2664 and LTC2672") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/5727ab54-6280-466e-b107-1b6006e5ab29@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: bmi323: suspend and resume triggering on relevant pm operationsDenis Benato
Prevent triggers from stop working after the device has entered sleep: use iio_device_suspend_triggering and iio_device_resume_triggering helpers. Signed-off-by: Denis Benato <benato.denis96@gmail.com> Link: https://patch.msgid.link/20240807185619.7261-3-benato.denis96@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: trigger: allow devices to suspend/resume theirs associated triggerDenis Benato
When a machine enters a sleep state while a trigger is associated to an iio device that trigger is not resumed after exiting the sleep state: provide iio device drivers a way to suspend and resume the associated trigger to solve the aforementioned bug. Each iio driver supporting external triggers is expected to call iio_device_suspend_triggering before suspending, and iio_device_resume_triggering upon resuming. Signed-off-by: Denis Benato <benato.denis96@gmail.com> Link: https://patch.msgid.link/20240807185619.7261-2-benato.denis96@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: adc: Add rockchip,rk3576-saradc stringDetlev Casanova
Add rockchip,rk3576-saradc compatible string. The saradc on RK3576 is compatible with the one on RK3588, so they are used together in an arm of the oneOf. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20240802214612.434179-5-detlev.casanova@collabora.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: ad4695: fix common-mode-channelDavid Lechner
The common-mode-channel property is a scalar, not an array, so we should not be using items: in the schema when specifying allowable values. Reported-by: Rob Herring <robh@kernel.org> Closes: https://lore.kernel.org/linux-iio/CAL_JsqKaddw8FnPfdnhKhHUb8AcTxFadc_eZmxjX0QxFR80=mw@mail.gmail.com/ Fixes: b40cafc11436 ("dt-bindings: iio: adc: add AD4695 and similar ADCs") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240808-iio-adc-ad4695-fix-dt-bindings-v1-1-5cf37b9547b0@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: light: apds9960: Add proximity and gesture offset calibrationAbhash Jha
Proximity and gesture offset registers perform offset correction to improve cross-talk performance. Added `calibbias` to the proximity and gesture channels. Provided facility to set calibbias based on the channel number. Signed-off-by: Abhash Jha <abhashkumarjha123@gmail.com> Link: https://patch.msgid.link/20240804134212.51682-2-abhashkumarjha123@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: adc: stm32-dfsdm: add scaling support to dfsdmOlivier Moysan
Add scaling support to STM32 DFSDM. When used in an analog context, a DFSDM filter typically converts the data from a sigma delta modulator. The IIO device associated to the DFSDM filter provides these data as raw data. The IIO device can provide scaling information (voltage and offset) to allow conversion of raw data into physical values. With the new binding based on IIO backend framework, the sigma delta modulators are defined as backends providing scaling information. The scaling is not supported with legacy binding. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Acked-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240730084640.1307938-10-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: add iio backend support to sd modulatorOlivier Moysan
The legacy sd modulator driver registers the sigma delta modulator as an IIO channel provider. This implementation is not convenient when the SD modulator has to be cascaded with another IIO device. The scaling information is distributed across devices, which makes it difficult to report consistent scaling data on IIO devices. The solution is to expose these cascaded IIO devices as an aggregate device, which report global scaling information. Add IIO backend support to SD modulator to allow scaling information management. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20240730084640.1307938-9-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: adc: stm32-dfsdm: adopt generic channels bindingsOlivier Moysan
Move to generic channels binding to ease new backend framework adoption and prepare the convergence with MDF IP support on STM32MP2 SoC family. Legacy binding: DFSDM is an IIO channel consumer. SD modulator is an IIO channels provider. The channel phandles are provided in DT through io-channels property and channel indexes through st,adc-channels property. New binding: DFSDM is an IIO channel provider. The channel indexes are given by reg property in channel child node. This new binding is intended to be used with SD modulator IIO backends. It does not support SD modulator legacy IIO devices. The st,adc-channels property presence is used to discriminate between legacy and backend bindings. The support of the DFSDM legacy channels and SD modulator IIO devices is kept for backward compatibility. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20240730084640.1307938-8-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: add vref support to sd modulatorOlivier Moysan
Allow to specify the reference voltage used by the SD modulator. When the SD modulator is defined as an IIO backend, the reference voltage can be used to evaluate scaling information of the IIO device. The reference voltage is not used otherwise. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240730084640.1307938-7-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: add backend support to sd modulatorOlivier Moysan
The legacy sd modulator driver registers the sigma delta modulator as an IIO channel provider. This implementation is not convenient when the SD modulator has to be cascaded with another IIO device. The scaling information is distributed across devices, which makes it difficult to report consistent scaling data on IIO devices. The solution is to expose these cascaded IIO devices as an aggregate device, which report global scaling information. Add IIO backend support to SD modulator to allow scaling information management. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240730084640.1307938-6-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: dfsdm: move to backend frameworkOlivier Moysan
Change the DFSDM binding to use the new IIO backend framework, along with the adoption of IIO generic channels. This binding change allows to add scaling support to the DFSDM. Keep the legacy binding as deprecated for backward compatibility. The io-backends property is supported only in generic IIO channel binding. - Channel description with the generic binding (Audio and Analog): Properties superseded by generic properties: st,adc-channels: becomes "reg" property in channel node st,adc-channel-names: becomes "label" property in channel node Properties moved to channel child node: st,adc-channel-types: becomes st,adc-channel-type st,adc-channel-clk-src, st,adc-alt-channel - Analog binding: DFSDM filter channel is configured as an IIO backend consumer. Add io-backends property in channel child nodes. DFSDM is no more configured as a channel consumer from SD modulator. Use of io-channels in DFSDM node is deprecated. - Audio binding: DFSDM audio DAI is configured as a channel consumer from DFSDM filter. No change compare to legacy. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20240730084640.1307938-5-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: add child nodes support in iio backend frameworkOlivier Moysan
Add an API to support IIO generic channels binding: http://devicetree.org/schemas/iio/adc/adc.yaml# This new API is needed, as generic channel DT node isn't populated as a device. Add devm_iio_backend_fwnode_get() to allow an IIO device backend consumer to reference backend phandles in its child nodes. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240730084640.1307938-4-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: add enable and disable services to iio backend frameworkOlivier Moysan
Add iio_backend_disable() and iio_backend_enable() APIs to allow IIO backend consumer to request backend disabling and enabling. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240730084640.1307938-3-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: add read scale and offset services to iio backend frameworkOlivier Moysan
Add iio_backend_read_scale() and iio_backend_read_offset() services to read channel scale and offset from an IIO backbend device. Also add a read_raw callback which replicates the read_raw callback of the IIO framework, and is intended to request miscellaneous channel attributes from the backend device. Both scale and offset helpers use this callback. Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240730084640.1307938-2-olivier.moysan@foss.st.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatibleKrzysztof Kozlowski
All compatibles in this binding without prefixes were deprecated, so adding a new deprecated one after some time is not allowed, because it defies the core logic of deprecating things. Drop the AK09916 vendorless compatible. Fixes: 76e28aa97fa0 ("iio: magnetometer: ak8975: add AK09116 support") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20240806053016.6401-2-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: magnetometer: ak8975: drop incorrect AK09116 compatibleKrzysztof Kozlowski
All compatibles in this binding without prefixes were deprecated, so adding a new deprecated one after some time is not allowed, because it defies the core logic of deprecating things. Drop the AK09916 vendorless compatible. Fixes: 76e28aa97fa0 ("iio: magnetometer: ak8975: add AK09116 support") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240806053016.6401-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10ABI: debugfs-iio-ad9467: document the debugfs interfaceNuno Sa
Document the debugfs interface for the IIO ad9467 high speed ADC. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240806-dev-ad-debugfs-doc-v1-2-153b882a3f01@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10MAINTAINERS: add entry for ad9467Nuno Sa
Document the maintainers for the IIO ad9467 high speed ADC. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240806-dev-ad-debugfs-doc-v1-1-153b882a3f01@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: dac: ad9739a: add backend debugfs interfaceNuno Sa
Call iio_backend_debugfs_add() to add (if available) the backend debug interface. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240806-dev-backend-dac-direct-reg-access-v1-2-b84a6e8ee8a0@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: dac: adi-axi-dac: support debugfs direct_reg_accessNuno Sa
Make it possible to read/write registers on the backend using the debugfs interface for it. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20240806-dev-backend-dac-direct-reg-access-v1-1-b84a6e8ee8a0@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10iio: remove unneeded assignment in __iio_format_valueMatteo Martelli
Trivial cleanup in __iio_format_value() for the IIO_VAL_FRACTIONAL case where tmp1 = vals[1] assignment is unneeded and irrelevant since tmp1 is immediately overwritten by the subsequent div_s64_rem() call. Signed-off-by: Matteo Martelli <matteomartelli3@gmail.com> Link: https://patch.msgid.link/20240730-iio-clean-fmt-value-v1-1-3e1c3deafc33@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-08-10wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletionJanne Grunau
wpa_supplicant 2.11 sends since 1efdba5fdc2c ("Handle PMKSA flush in the driver for SAE/OWE offload cases") SSID based PMKSA del commands. brcmfmac is not prepared and tries to dereference the NULL bssid and pmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based updates so copy the SSID. Fixes: a96202acaea4 ("wifi: brcmfmac: cfg80211: Add support for PMKID_V3 operations") Cc: stable@vger.kernel.org # 6.4.x Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Neal Gompa <neal@gompa.dev> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240803-brcmfmac_pmksa_del_ssid-v1-1-4e85f19135e1@jannau.net
2024-08-10ALSA: timer: Relax start tick time check for slave timer elementsTakashi Iwai
The recent addition of a sanity check for a too low start tick time seems breaking some applications that uses aloop with a certain slave timer setup. They may have the initial resolution 0, hence it's treated as if it were a too low value. Relax and skip the check for the slave timer instance for addressing the regression. Fixes: 4a63bd179fa8 ("ALSA: timer: Set lower bound of start tick time") Cc: <stable@vger.kernel.org> Link: https://github.com/raspberrypi/linux/issues/6294 Link: https://patch.msgid.link/20240810084833.10939-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-08-10irqchip/riscv-aplic: Retrigger MSI interrupt on source configurationYong-Xuan Wang
The section 4.5.2 of the RISC-V AIA specification says that "any write to a sourcecfg register of an APLIC might (or might not) cause the corresponding interrupt-pending bit to be set to one if the rectified input value is high (= 1) under the new source mode." When the interrupt type is changed in the sourcecfg register, the APLIC device might not set the corresponding pending bit, so the interrupt might never become pending. To handle sourcecfg register changes for level-triggered interrupts in MSI mode, manually set the pending bit for retriggering interrupt so it gets retriggered if it was already asserted. Fixes: ca8df97fe679 ("irqchip/riscv-aplic: Add support for MSI-mode") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20240809071049.2454-1-yongxuan.wang@sifive.com
2024-08-10irqchip/xilinx: Fix shift out of boundsRadhey Shyam Pandey
The device tree property 'xlnx,kind-of-intr' is sanity checked that the bitmask contains only set bits which are in the range of the number of interrupts supported by the controller. The check is done by shifting the mask right by the number of supported interrupts and checking the result for zero. The data type of the mask is u32 and the number of supported interrupts is up to 32. In case of 32 interrupts the shift is out of bounds, resulting in a mismatch warning. The out of bounds condition is also reported by UBSAN: UBSAN: shift-out-of-bounds in irq-xilinx-intc.c:332:22 shift exponent 32 is too large for 32-bit type 'unsigned int' Fix it by promoting the mask to u64 for the test. Fixes: d50466c90724 ("microblaze: intc: Refactor DT sanity check") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/1723186944-3571957-1-git-send-email-radhey.shyam.pandey@amd.com
2024-08-09Merge branch 'mlx5-misc-fixes-2024-08-08'Jakub Kicinski
Tariq Toukan says: ==================== mlx5 misc fixes 2024-08-08 This patchset provides misc bug fixes from the team to the mlx5 core and Eth drivers. ==================== Link: https://patch.msgid.link/20240808144107.2095424-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net/mlx5e: Fix queue stats access to non-existing channels splatGal Pressman
The queue stats API queries the queues according to the real_num_[tr]x_queues, in case the device is down and channels were not yet created, don't try to query their statistics. To trigger the panic, run this command before the interface is brought up: ./cli.py --spec ../../../Documentation/netlink/specs/netdev.yaml --dump qstats-get --json '{"ifindex": 4}' BUG: kernel NULL pointer dereference, address: 0000000000000c00 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 3 UID: 0 PID: 977 Comm: python3 Not tainted 6.10.0+ #40 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_get_queue_stats_rx+0x3c/0xb0 [mlx5_core] Code: fc 55 48 63 ee 53 48 89 d3 e8 40 3d 70 e1 85 c0 74 58 4c 89 ef e8 d4 07 04 00 84 c0 75 41 49 8b 84 24 f8 39 00 00 48 8b 04 e8 <48> 8b 90 00 0c 00 00 48 03 90 40 0a 00 00 48 89 53 08 48 8b 90 08 RSP: 0018:ffff888116be37d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888116be3868 RCX: 0000000000000004 RDX: ffff88810ada4000 RSI: 0000000000000000 RDI: ffff888109df09c0 RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000004 R10: ffff88813461901c R11: ffffffffffffffff R12: ffff888109df0000 R13: ffff888109df09c0 R14: ffff888116be38d0 R15: 0000000000000000 FS: 00007f4375d5c740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c00 CR3: 0000000106ada006 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x14e/0x3d0 ? exc_page_fault+0x73/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5e_get_queue_stats_rx+0x3c/0xb0 [mlx5_core] netdev_nl_stats_by_netdev+0x2a6/0x4c0 ? __rmqueue_pcplist+0x351/0x6f0 netdev_nl_qstats_get_dumpit+0xc4/0x1b0 genl_dumpit+0x2d/0x80 netlink_dump+0x199/0x410 __netlink_dump_start+0x1aa/0x2c0 genl_family_rcv_msg_dumpit+0x94/0xf0 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 genl_rcv_msg+0x116/0x2b0 ? __pfx_netdev_nl_qstats_get_dumpit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x21a/0x340 netlink_sendmsg+0x1f4/0x440 __sys_sendto+0x1b6/0x1c0 ? do_sock_setsockopt+0xc3/0x180 ? __sys_setsockopt+0x60/0xb0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f43757132b0 Code: c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 1d 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 68 c3 0f 1f 80 00 00 00 00 41 54 48 83 ec 20 RSP: 002b:00007ffd258da048 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007ffd258da0f8 RCX: 00007f43757132b0 RDX: 000000000000001c RSI: 00007f437464b850 RDI: 0000000000000003 RBP: 00007f4375085de0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: ffffffffc4653600 R14: 0000000000000001 R15: 00007f43751a6147 </TASK> Modules linked in: netconsole xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core zram zsmalloc mlx5_core fuse [last unloaded: netconsole] CR2: 0000000000000c00 ---[ end trace 0000000000000000 ]--- RIP: 0010:mlx5e_get_queue_stats_rx+0x3c/0xb0 [mlx5_core] Code: fc 55 48 63 ee 53 48 89 d3 e8 40 3d 70 e1 85 c0 74 58 4c 89 ef e8 d4 07 04 00 84 c0 75 41 49 8b 84 24 f8 39 00 00 48 8b 04 e8 <48> 8b 90 00 0c 00 00 48 03 90 40 0a 00 00 48 89 53 08 48 8b 90 08 RSP: 0018:ffff888116be37d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888116be3868 RCX: 0000000000000004 RDX: ffff88810ada4000 RSI: 0000000000000000 RDI: ffff888109df09c0 RBP: 0000000000000000 R08: 0000000000000004 R09: 0000000000000004 R10: ffff88813461901c R11: ffffffffffffffff R12: ffff888109df0000 R13: ffff888109df09c0 R14: ffff888116be38d0 R15: 0000000000000000 FS: 00007f4375d5c740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c00 CR3: 0000000106ada006 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fixes: 7b66ae536a78 ("net/mlx5e: Add per queue netdev-genl stats") Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20240808144107.2095424-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net/mlx5e: Correctly report errors for ethtool rx flowsCosmin Ratiu
Previously, an ethtool rx flow with no attrs would not be added to the NIC as it has no rules to configure the hw with, but it would be reported as successful to the caller (return code 0). This is confusing for the user as ethtool then reports "Added rule $num", but no rule was actually added. This change corrects that by instead reporting these wrong rules as -EINVAL. Fixes: b29c61dac3a2 ("net/mlx5e: Ethtool steering flow validation refactoring") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20240808144107.2095424-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net/mlx5e: Take state lock during tx timeout reporterDragos Tatulea
mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag. Fixes: eab0da38912e ("net/mlx5e: Fix possible deadlock on mlx5e_tx_timeout_work") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Link: https://lore.kernel.org/all/ZplpKq8FKi3vwfxv@gmail.com/T/ Reviewed-by: Breno Leitao <leitao@debian.org> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20240808144107.2095424-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net/mlx5e: SHAMPO, Increase timeout to improve latencyDragos Tatulea
During latency tests (netperf TCP_RR) a 30% degradation of HW GRO vs SW GRO was observed. This is due to SHAMPO triggering timeout filler CQEs instead of delivering the CQE for the packet. Having a short timeout for SHAMPO doesn't bring any benefits as it is the driver that does the merging, not the hardware. On the contrary, it can have a negative impact: additional filler CQEs are generated due to the timeout. As there is no way to disable this timeout, this change sets it to the maximum value. Instead of using the packet_merge.timeout parameter which is also used for LRO, set the value directly when filling in the rest of the SHAMPO parameters in mlx5e_build_rq_param(). Fixes: 99be56171fa9 ("net/mlx5e: SHAMPO, Re-enable HW-GRO") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20240808144107.2095424-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net/mlx5: SD, Do not query MPIR register if no sd_groupTariq Toukan
Unconditionally calling the MPIR query on BF separate mode yields the FW syndrome below [1]. Do not call it unless admin clearly specified the SD group, i.e. expressing the intention of using the multi-PF netdev feature. This fix covers cases not covered in commit fca3b4791850 ("net/mlx5: Do not query MPIR on embedded CPU function"). [1] mlx5_cmd_out_err:808:(pid 8267): ACCESS_REG(0x805) op_mod(0x1) failed, status bad system state(0x4), syndrome (0x685f19), err(-5) Fixes: 678eb448055a ("net/mlx5: SD, Implement basic query and instantiation") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20240808144107.2095424-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09Merge branch ↵Jakub Kicinski
'don-t-take-hw-uso-path-when-packets-can-t-be-checksummed-by-device' Jakub Sitnicki says: ==================== Don't take HW USO path when packets can't be checksummed by device This series addresses a recent regression report from syzbot [1]. After enabling UDP_SEGMENT for egress devices which don't support checksum offload [2], we need to tighten down the checks which let packets take the HW USO path. The fix consists of two parts: 1. don't let devices offer USO without checksum offload, and 2. force software USO fallback in presence of IPv6 extension headers. [1] https://lore.kernel.org/all/000000000000e1609a061d5330ce@google.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10154dbded6d6a2fecaebdfda206609de0f121a9 v3: https://lore.kernel.org/r/20240807-udp-gso-egress-from-tunnel-v3-0-8828d93c5b45@cloudflare.com v2: https://lore.kernel.org/r/20240801-udp-gso-egress-from-tunnel-v2-0-9a2af2f15d8d@cloudflare.com v1: https://lore.kernel.org/r/20240725-udp-gso-egress-from-tunnel-v1-0-5e5530ead524@cloudflare.com ==================== Link: https://patch.msgid.link/20240808-udp-gso-egress-from-tunnel-v4-0-f5c5b4149ab9@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09selftests/net: Add coverage for UDP GSO with IPv6 extension headersJakub Sitnicki
After enabling UDP GSO for devices not offering checksum offload, we have hit a regression where a bad offload warning can be triggered when sending a datagram with IPv6 extension headers. Extend the UDP GSO IPv6 tests to cover this scenario. Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Link: https://patch.msgid.link/20240808-udp-gso-egress-from-tunnel-v4-3-f5c5b4149ab9@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09udp: Fall back to software USO if IPv6 extension headers are presentJakub Sitnicki
In commit 10154dbded6d ("udp: Allow GSO transmit from devices with no checksum offload") we have intentionally allowed UDP GSO packets marked CHECKSUM_NONE to pass to the GSO stack, so that they can be segmented and checksummed by a software fallback when the egress device lacks these features. What was not taken into consideration is that a CHECKSUM_NONE skb can be handed over to the GSO stack also when the egress device advertises the tx-udp-segmentation / NETIF_F_GSO_UDP_L4 feature. This will happen when there are IPv6 extension headers present, which we check for in __ip6_append_data(). Syzbot has discovered this scenario, producing a warning as below: ip6tnl0: caps=(0x00000006401d7869, 0x00000006401d7869) WARNING: CPU: 0 PID: 5112 at net/core/dev.c:3293 skb_warn_bad_offload+0x166/0x1a0 net/core/dev.c:3291 Modules linked in: CPU: 0 PID: 5112 Comm: syz-executor391 Not tainted 6.10.0-rc7-syzkaller-01603-g80ab5445da62 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:skb_warn_bad_offload+0x166/0x1a0 net/core/dev.c:3291 [...] Call Trace: <TASK> __skb_gso_segment+0x3be/0x4c0 net/core/gso.c:127 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x585/0x1120 net/core/dev.c:3661 __dev_queue_xmit+0x17a4/0x3e90 net/core/dev.c:4415 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0xffa/0x1680 net/ipv6/ip6_output.c:137 ip6_finish_output+0x41e/0x810 net/ipv6/ip6_output.c:222 ip6_send_skb+0x112/0x230 net/ipv6/ip6_output.c:1958 udp_v6_send_skb+0xbf5/0x1870 net/ipv6/udp.c:1292 udpv6_sendmsg+0x23b3/0x3270 net/ipv6/udp.c:1588 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xef/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2585 ___sys_sendmsg net/socket.c:2639 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2725 __do_sys_sendmmsg net/socket.c:2754 [inline] __se_sys_sendmmsg net/socket.c:2751 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2751 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] </TASK> We are hitting the bad offload warning because when an egress device is capable of handling segmentation offload requested by skb_shinfo(skb)->gso_type, the chain of gso_segment callbacks won't produce any segment skbs and return NULL. See the skb_gso_ok() branch in {__udp,tcp,sctp}_gso_segment helpers. To fix it, force a fallback to software USO when processing a packet with IPv6 extension headers, since we don't know if these can checksummed by all devices which offer USO. Fixes: 10154dbded6d ("udp: Allow GSO transmit from devices with no checksum offload") Reported-by: syzbot+e15b7e15b8a751a91d9a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000e1609a061d5330ce@google.com/ Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Link: https://patch.msgid.link/20240808-udp-gso-egress-from-tunnel-v4-2-f5c5b4149ab9@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09net: Make USO depend on CSUM offloadJakub Sitnicki
UDP segmentation offload inherently depends on checksum offload. It should not be possible to disable checksum offload while leaving USO enabled. Enforce this dependency in code. There is a single tx-udp-segmentation feature flag to indicate support for both IPv4/6, hence the devices wishing to support USO must offer checksum offload for both IP versions. Fixes: 10154dbded6d ("udp: Allow GSO transmit from devices with no checksum offload") Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240808-udp-gso-egress-from-tunnel-v4-1-f5c5b4149ab9@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09gtp: pull network headers in gtp_dev_xmit()Eric Dumazet
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1] We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them. Use pskb_inet_may_pull() to fix this issue. [1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Fixes: 999cb275c807 ("gtp: add IPv6 support") Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Harald Welte <laforge@gnumonks.org> Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org> Link: https://patch.msgid.link/20240808132455.3413916-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-09Merge tag '6.11-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fixes from Steve French: - DFS fix - fix for security flags for requiring encryption - minor cleanup * tag '6.11-rc2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: cifs_inval_name_dfs_link_error: correct the check for fullpath Fix spelling errors in Server Message Block smb3: fix setting SecurityFlags when encryption is required
2024-08-09Merge tag 'spi-fix-v6.11-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few SPI fixes: clock rate calculation fixes for the Kunpeng and lpsi drivers and a missing registration of a device ID for spidev (which had only been updated for DT cases, causing warnings)" * tag 'spi-fix-v6.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-fsl-lpspi: Fix scldiv calculation spi: spidev: Add missing spi_device_id for bh2228fv spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware spi: hisi-kunpeng: Add validation for the minimum value of speed_hz
2024-08-09binfmt_flat: Fix corruption when not offsetting data startKees Cook
Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") Co-developed-by: Stefan O'Rear <sorear@fastmail.com> Signed-off-by: Stefan O'Rear <sorear@fastmail.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/r/20240807195119.it.782-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2024-08-09perf daemon: Fix the build on 32-bit architecturesArnaldo Carvalho de Melo
Noticed with: 1 6.22 debian:experimental-x-mipsel : FAIL gcc version 13.2.0 (Debian 13.2.0-25) builtin-daemon.c: In function 'cmd_session_list': builtin-daemon.c:691:35: error: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'time_t' {aka 'long long int'} [-Werror=format=] Use inttypes.h's PRIu64 to deal with that. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Link: https://lore.kernel.org/r/ZplvH21aQ8pzmza_@x1 Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2024-08-09bcachefs: bcachefs_metadata_version_disk_accounting_v3Kent Overstreet
bcachefs_metadata_version_disk_accounting_v2 erroneously had padding bytes in disk_accounting_key, which is a problem because we have to guarantee that all unused bytes in disk_accounting_key are zeroed. Fortunately 6.11 isn't out yet, so it's cheap to fix this by spinning a new version. Reported-by: Gabriel de Perthuis <g2p.code@gmail.com> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2024-08-10rust: x86: remove `-3dnow{,a}` from target featuresMiguel Ojeda
LLVM 19 is dropping support for 3DNow! in commit f0eb5587ceeb ("Remove support for 3DNow!, both intrinsics and builtins. (#96246)"): Remove support for 3DNow!, both intrinsics and builtins. (#96246) This set of instructions was only supported by AMD chips starting in the K6-2 (introduced 1998), and before the "Bulldozer" family (2011). They were never much used, as they were effectively superseded by the more-widely-implemented SSE (first implemented on the AMD side in Athlon XP in 2001). This is being done as a predecessor towards general removal of MMX register usage. Since there is almost no usage of the 3DNow! intrinsics, and no modern hardware even implements them, simple removal seems like the best option. Thus we should avoid passing these to the backend, since otherwise we get a diagnostic about it: '-3dnow' is not a recognized feature for this target (ignoring feature) '-3dnowa' is not a recognized feature for this target (ignoring feature) We could try to disable them only up to LLVM 19 (not the C side one, but the one used by `rustc`, which may be built with a range of LLVMs). However, to avoid more complexity, we can likely just remove them altogether. According to Nikita [2]: > I don't think it's needed because LLVM should not generate 3dnow > instructions unless specifically asked to, using intrinsics that > Rust does not provide in the first place. Thus do so, like Rust did for one of their builtin targets [3]. For those curious: Clang will warn only about trying to enable them (`-m3dnow{,a}`), but not about disabling them (`-mno-3dnow{,a}`), so there is no change needed there. Cc: Nikita Popov <github@npopov.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: x86@kernel.org Link: https://github.com/llvm/llvm-project/commit/f0eb5587ceeb641445b64cb264c822b4751de04a [1] Link: https://github.com/rust-lang/rust/pull/127864#issuecomment-2235898760 [2] Link: https://github.com/rust-lang/rust/pull/127864 [3] Closes: https://github.com/Rust-for-Linux/linux/issues/1094 Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240806144558.114461-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-10kbuild: rust-analyzer: mark `rust_is_available.sh` invocation as recursiveMiguel Ojeda
When calling the `rust_is_available.sh` script, we need to make the jobserver available to it, as commit ecab4115c44c ("kbuild: mark `rustc` (and others) invocations as recursive") explains and did for the others. Otherwise, we get a warning from `rustc` when calling `make rust-analyzer` with parallel jobs, e.g. `-j8`. Using several jobs for that target does not really matter, but developers may call `make` with jobs enabled in all cases. Thus fix it. Fixes: 6dc9d9ca9a72 ("kbuild: rust-analyzer: better error handling") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240806233559.246705-1-ojeda@kernel.org [ Reworded to add a couple more details mentioned in the list. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-10rust: add intrinsics to fix `-Os` buildsMiguel Ojeda
Alice reported [1] that an arm64 build failed with: ld.lld: error: undefined symbol: __extendsfdf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a ld.lld: error: undefined symbol: __truncdfsf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a Rust 1.80.0 or later together with `CONFIG_CC_OPTIMIZE_FOR_SIZE=y` is what triggers it. In addition, x86_64 builds also fail the same way. Similarly, compiling with Rust 1.82.0 (currently in nightly) makes another one appear, possibly due to the LLVM 19 upgrade there: ld.lld: error: undefined symbol: __eqdf2 >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_up) in archive vmlinux.a >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_down) in archive vmlinux.a Gary adds [1]: > Usually the fix on rustc side is to mark those functions as `#[inline]` > > All of {midpoint,next_up,next_down} are indeed unstable functions not > marked as inline... Fix all those by adding those intrinsics to our usual workaround. [ Trevor quickly submitted a fix to upstream Rust [2] that has already been merged, to be released in Rust 1.82.0 (2024-10-17). - Miguel ] Cc: Gary Guo <gary@garyguo.net> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/455637364 [1] Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://github.com/rust-lang/rust/pull/128749 [2] Link: https://lore.kernel.org/r/20240806150619.192882-1-ojeda@kernel.org [ Shortened Zulip link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-10kbuild: rust: skip -fmin-function-alignment in bindgen flagsZehui Xu
GCC 14 recently added -fmin-function-alignment option and the root Makefile uses it to replace -falign-functions when available. However, this flag can cause issues when passed to the Rust Makefile and affect the bindgen process. Bindgen relies on libclang to parse C code, and currently does not support the -fmin-function-alignment flag, leading to compilation failures when GCC 14 is used. This patch addresses the issue by adding -fmin-function-alignment to the bindgen_skip_c_flags in rust/Makefile. This prevents the flag from causing compilation issues. [ Matthew and Gary confirm function alignment should not change the ABI in a way that bindgen would care about, thus we did not need the extra logic for bindgen from v2. - Miguel ] Link: https://lore.kernel.org/linux-kbuild/20240222133500.16991-1-petr.pavlu@suse.com/ Signed-off-by: Zehui Xu <zehuixu@whu.edu.cn> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240731134346.10630-1-zehuixu@whu.edu.cn [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-09Merge tag 'drm-fixes-2024-08-10' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly regular fixes, mostly amdgpu with i915/xe having a few each, and then some misc bits across the board, seems about right for rc3 time. client: - fix null ptr deref bridge: - connector: fix double free atomic: - fix async flip update panel: - document panel omap: - add config dependency tests: - fix gem shmem test drm buddy: - Add start address to trim function amdgpu: - DMCUB fix - Fix DET programming on some DCNs - DCC fixes - DCN 4.0.1 fixes - SMU 14.0.x update - MMHUB fix - DCN 3.1.4 fix - GC 12.0 fixes - Fix soft recovery error propogation - SDMA 7.0 fixes - DSC fix xe: - Fix off-by-one when processing RTP rules - Use dma_fence_chain_free in chain fence unused as a sync - Fix PL1 disable flow in xe_hwmon_power_max_write - Take ref to VM in delayed dump snapshot i915: - correct dual pps handling for MTL_PCH+ [display] - Adjust vma offset for framebuffer mmap offset [gem] - Fix Virtual Memory mapping boundaries calculation [gem] - Allow evicting to use the requested placement - Attempt to get pages without eviction first" * tag 'drm-fixes-2024-08-10' of https://gitlab.freedesktop.org/drm/kernel: (31 commits) drm/xe: Take ref to VM in delayed snapshot drm/xe/hwmon: Fix PL1 disable flow in xe_hwmon_power_max_write drm/xe: Use dma_fence_chain_free in chain fence unused as a sync drm/xe/rtp: Fix off-by-one when processing rules drm/amdgpu: Add DCC GFX12 flag to enable address alignment drm/amdgpu: correct sdma7 max dw drm/amdgpu: Add address alignment support to DCC buffers drm/amd/display: Skip Recompute DSC Params if no Stream on Link drm/amdgpu: change non-dcc buffer copy configuration drm/amdgpu: Forward soft recovery errors to userspace drm/amdgpu: add golden setting for gc v12 drm/buddy: Add start address support to trim function drm/amd/display: Add missing program DET segment call to pipe init drm/amd/display: Add missing DCN314 to the DML Makefile drm/amdgpu: force to use legacy inv in mmhub drm/amd/pm: update powerplay structure on smu v14.0.2/3 drm/amd/display: Add missing mcache registers drm/amd/display: Add dcc propagation value drm/amd/display: Add missing DET segments programming drm/amd/display: Replace dm_execute_dmub_cmd with dc_wake_and_execute_dmub_cmd ...
generated by cgit (git 2.34.1) at 2025-09-12 11:53:15 +0000