summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-07-13iio: imu: adis16400: Use separate structures rather than an array for chip infoDavid Lechner1-161/+153
Change the adis16400 driver to use individual chip info structures instead of an array. This reduces the verbosity of the code. Also, the data is now const as it should have been in the first place. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-17-v1-1-a215ebb653ec@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: adc: ad7768-1: add low pass -3dB cutoff attributeJonathan Santos1-1/+17
Ad7768-1 has a different -3db frequency multiplier depending on the filter type configured. The cutoff frequency also varies according to the current ODR. Add a readonly low pass -3dB frequency cutoff attribute to clarify to the user which bandwidth is being allowed depending on the filter configurations. Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> Link: https://patch.msgid.link/804d66f1858014d7278aec3344d81c223661e878.1749569957.git.Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: adc: ad7124: Use separate structures rather than array for chip infoDavid Lechner1-22/+14
Change the ad7124 driver to use individual chip info structures instead of an array. This reduces the verbosity of the code. Also, the data is now const as it should have been in the first place. Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-5-v1-1-9e56c2f77979@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: proximity: vcnl3020: make vcnl3020_property constDavid Lechner1-2/+2
Add const qualifier to struct vcnl3020_property vcnl3020_led_current_property. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-25-v1-2-5d99cf17790e@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: proximity: vcnl3020: pass struct vcnl3020_property by pointerDavid Lechner1-7/+7
Pass struct vcnl3020_property by pointer instead of by value to avoid copying the entire struct. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-25-v1-1-5d99cf17790e@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: pressure: abp060mg: make abp_config constDavid Lechner1-2/+2
Add const qualifier to struct abp_config abp_config[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-23-v1-1-542cfadce9d0@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: light: zopt2201: make zopt2201_scale constDavid Lechner1-3/+3
Add const qualifier to struct zopt2201_scale zopt2201_scale_*[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-22-v1-1-fc9ebdc5f5c3@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13iio: light: isl76682: make isl76682_range_table constDavid Lechner1-1/+1
Add const qualifier to struct isl76682_range isl76682_range_table[]. This is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250628-iio-const-data-21-v1-1-2597d8eda30f@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-13gpio: virtio: use new GPIO line value setter callbacksBartosz Golaszewski1-3/+4
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-12-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: viperboard: use new GPIO line value setter callbacksBartosz Golaszewski1-58/+68
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-11-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: uniphier: use new GPIO line value setter callbacksBartosz Golaszewski1-6/+10
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-10-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: twl6040: set line value in .direction_out()Bartosz Golaszewski1-7/+7
It's ok for a GPIO controller to be output-only but the .direction_out() callback must also set the requested line value. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-9-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: twl6040: use new GPIO line value setter callbacksBartosz Golaszewski1-4/+5
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-8-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: twl4030: use new GPIO line value setter callbacksBartosz Golaszewski1-11/+12
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-7-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: ts4900: use new GPIO line value setter callbacksBartosz Golaszewski1-7/+7
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-6-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: tqmx86: use new GPIO line value setter callbacksBartosz Golaszewski1-3/+5
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Acked-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-5-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: tps68470: use new GPIO line value setter callbacksBartosz Golaszewski1-5/+9
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-4-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: tps65912: use new GPIO line value setter callbacksBartosz Golaszewski1-5/+5
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-3-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: tps65912: check the return value of regmap_update_bits()Bartosz Golaszewski1-2/+5
regmap_update_bits() can fail, check its return value like we do elsewhere in the driver. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-2-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpio: tps65910: use new GPIO line value setter callbacksBartosz Golaszewski1-9/+12
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250707-gpiochip-set-rv-gpio-round4-v1-1-35668aaaf6d2@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13gpiolib: don't use GPIO global numbers in debugfs outputBartosz Golaszewski1-3/+2
One of the users of global GPIO numbers in the kernel are the debugfs callbacks in GPIO drivers. Before converting any custom .dbg_show() callbacks in individual modules, let's first make GPIO core stop using GPIO base in debugfs output. Use hardware offsets instead. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250707141313.73169-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-13RDMA/mana_ib: add additional port countersZhiyue Qiu3-0/+34
Add packet and request port counters to mana_ib. Signed-off-by: Zhiyue Qiu <zhiyueqiu@microsoft.com> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/1752143395-5324-1-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13RDMA/mana_ib: Fix DSCP value in modify QPShiraz Saleem1-1/+1
Convert the traffic_class in GRH to a DSCP value as required by the HW. Fixes: e095405b45bb ("RDMA/mana_ib: Modify QP state") Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/1752143085-4169-1-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13RDMA/efa: Add CQ with external memory supportMichael Margolin3-14/+51
Add an option to create CQ using external memory instead of allocating in the driver. The memory can be passed from userspace by dmabuf fd and an offset or a VA. One of the possible usages is creating CQs that reside in accelerator memory, allowing low latency asynchronous direct polling from the accelerator device. Add a capability bit to reflect on the feature support. Reviewed-by: Daniel Kranzdorf <dkkranzd@amazon.com> Reviewed-by: Yonatan Nachum <ynachum@amazon.com> Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20250708202308.24783-4-mrgolin@amazon.com Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13RDMA/uverbs: Add a common way to create CQ with umemMichael Margolin2-6/+82
Add ioctl command attributes and a common handling for the option to create CQs with memory buffers passed from userspace. When required attributes are supplied, create umem and provide it for driver's use. The extension enables creation of CQs on top of preallocated CPU virtual or device memory buffers, by supplying VA or dmabuf fd, in a common way. Drivers can support this flow by initializing a new create_cq_umem fp field in their ops struct, with a function that can handle the new parameter. Signed-off-by: Michael Margolin <mrgolin@amazon.com> Link: https://patch.msgid.link/20250708202308.24783-2-mrgolin@amazon.com Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13HID: core: do not bypass hid_hw_raw_requestBenjamin Tissoires1-2/+1
hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used. Reported-by: Alan Stern <stern@rowland.harvard.edu> Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250710-report-size-null-v2-3-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-13HID: core: ensure __hid_request reserves the report ID as the first byteBenjamin Tissoires1-2/+9
The low level transport driver expects the first byte to be the report ID, even when the report ID is not use (in which case they just shift the buffer). However, __hid_request() whas not offsetting the buffer it used by one in this case, meaning that the raw_request() callback emitted by the transport driver would be stripped of the first byte. Note: this changes the API for uhid devices when a request is made through hid_hw_request. However, several considerations makes me think this is fine: - every request to a HID device made through hid_hw_request() would see that change, but every request made through hid_hw_raw_request() already has the new behaviour. So that means that the users are already facing situations where they might have or not the first byte being the null report ID when it is 0. We are making things more straightforward in the end. - uhid is mainly used for BLE devices - uhid is also used for testing, but I don't see that change a big issue - for BLE devices, we can check which kernel module is calling hid_hw_request() - and in those modules, we can check which are using a Bluetooth device - and then we can check if the command is used with a report ID or not. - surprise: none of the kernel module are using a report ID 0 - and finally, bluez, in its function set_report()[0], does the same shift if the report ID is 0 and the given buffer has a size > 0. [0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879 Reported-by: Alan Stern <stern@rowland.harvard.edu> Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43 Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-13HID: core: ensure the allocated report buffer can contain the reserved report IDBenjamin Tissoires1-1/+4
When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7. Reported-by: Alan Stern <stern@rowland.harvard.edu> Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/ Cc: stable@vger.kernel.org Suggested-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20250710-report-size-null-v2-1-ccf922b7c4e5@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-13RDMA/mlx5: Optimize DMABUF mkey page sizeEdward Srouji4-43/+327
The current implementation of DMABUF memory registration uses a fixed page size for the memory key (mkey), which can lead to suboptimal performance when the underlying memory layout may offer better page size. The optimization improves performance by reducing the number of page table entries required for the mkey, leading to less MTT/KSM descriptors that the HCA must go through to find translations, fewer cache-lines, and shorter UMR work requests on mkey updates such as when re-registering or reusing a cacheable mkey. To ensure safe page size updates, the implementation uses a 5-step process: 1. Make the first X entries non-present, while X is calculated to be minimal according to a large page shift that can be used to cover the MR length. 2. Update the page size to the large supported page size 3. Load the remaining N-X entries according to the (optimized) page shift 4. Update the page size according to the (optimized) page shift 5. Load the first X entries with the correct translations This ensures that at no point is the MR accessible with a partially updated translation table, maintaining correctness and preventing access to stale or inconsistent mappings, such as having an mkey advertising the new page size while some of the underlying page table entries still contain the old page size translations. Signed-off-by: Edward Srouji <edwards@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Link: https://patch.msgid.link/bc05a6b2142c02f96a90635f9a4458ee4bbbf39f.1751979184.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13RDMA/mlx5: Align mkc page size capability check to PRMMichael Guralnik2-9/+52
Align the capabilities checked when using the log_page_size 6th bit in the mkey context to the PRM definition. The upper and lower bounds are set by max/min caps, and modification of the 6th bit by UMR is allowed only when a specific UMR cap is set. Current implementation falsely assumes all page sizes up-to 2^63 are supported when the UMR cap is set. In case the upper bound cap is lower than 63, this might result a FW syndrome on mkey creation, e.g: mlx5_core 0000:c1:00.0: mlx5_cmd_out_err:832:(pid 0): CREATE_MKEY(0×200) op_mod(0×0) failed, status bad parameter(0×3), syndrome (0×38a711), err(-22) Previous cap enforcement is still correct for all current HW, FW and driver combinations. However, this patch aligns the code to be PRM compliant in the general case. Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Link: https://patch.msgid.link/eab4eeb4785105a4bb5eb362dc0b3662cd840412.1751979184.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13Optimize DMABUF mkey page size in mlx5Leon Romanovsky1-2/+4
From Edward: This patch series enables the mlx5 driver to dynamically choose the optimal page size for a DMABUF-based memory key (mkey), rather than always registering with a fixed page size. Previously, DMABUF memory registration used a fixed 4K page size for mkeys which could lead to suboptimal performance when the underlying memory layout may offer better page sizes. This approach did not take advantage of larger page size capabilities advertised by the HCA, and the driver was not setting the proper page size mask in the mkey mask when performing page size changes, potentially leading to invalid registrations when updating to a very large pages. This series improves DMABUF performance by dynamically selecting the best page size for a given memory region (MR) both at creation time and on page fault occurrences, based on the underlying layout and fixing related gaps and bugs. By doing so, we reduce the number of page table entries (and thus MTT/ KSM descriptors) that the HCA must traverse, which in turn reduces cache-line fetches. Thanks * mlx5-next: RDMA/mlx5: Fix UMR modifying of mkey page size net/mlx5: Expose HCA capability bits for mkey max page size Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-13RDMA/mlx5: Fix UMR modifying of mkey page sizeEdward Srouji1-2/+4
When changing the page size on an mkey, the driver needs to set the appropriate bits in the mkey mask to indicate which fields are being modified. The 6th bit of a page size in mlx5 driver is considered an extension, and this bit has a dedicated capability and mask bits. Previously, the driver was not setting this mask in the mkey mask when performing page size changes, regardless of its hardware support, potentially leading to an incorrect page size updates. This fixes the issue by setting the relevant bit in the mkey mask when performing page size changes on an mkey and the 6th bit of this field is supported by the hardware. Fixes: cef7dde8836a ("net/mlx5: Expand mkey page size to support 6 bits") Signed-off-by: Edward Srouji <edwards@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Link: https://patch.msgid.link/9f43a9c73bf2db6085a99dc836f7137e76579f09.1751979184.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-12power: supply: core: fix static checker warningSebastian Reichel1-1/+1
static checker complains, that the block already breaks if IS_ERR(np) and thus the extra !IS_ERR(np) check in the while condition is superfluous. Avoid the extra check by using while(true) instead. This should not change the runtime behavior at all and I expect the binary to be more or less the same for an optimizing compiler. Fixes: f368f87b22da ("power: supply: core: convert to fwnnode") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-pm/285c9c39-482c-480c-8b0b-07111e39fdfe@sabinyo.mountain/ Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250707-fix-psy-static-checker-warning-v1-1-42d555c2b68a@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-07-12firewire: ohci: reduce the size of common context structure by extracting ↵Takashi Sakamoto1-43/+49
members into AT structure In commit 386a4153a2c1 ("firewire: ohci: cache the context run bit"), a running member was added to the context structure to cache the running state of a given DMA context. Although this member is accessible from IR, IT, and AT contexts, it is currently used only by the AT context. Additionally, the context structure includes a work item, which is also used by the AT context. Both members are unnecessary for IR and IT contexts. This commit refactors the code by moving these two members into a new structure specific to AT context. Link: https://lore.kernel.org/r/20250710131916.31289-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-07-12md: allow removing faulty rdev during resyncZheng Qixing1-7/+17
During RAID resync, faulty rdev cannot be removed and will result in "Device or resource busy" error when attempting hot removal. Reproduction steps: mdadm -Cv /dev/md0 -l1 -n3 -e1.2 /dev/sd{b..d} mdadm /dev/md0 -f /dev/sdb mdadm /dev/md0 -r /dev/sdb -> mdadm: hot remove failed for /dev/sdb: Device or resource busy After commit 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery"), when a device becomes faulty during resync, the md_choose_sync_action() function returns early without calling remove_and_add_spares(), preventing faulty device removal. This patch extracts a helper function remove_spares() to support removing faulty devices during RAID resync operations. Fixes: 4b10a3bc67c1 ("md: ensure resync is prioritized over recovery") Signed-off-by: Zheng Qixing <zhengqixing@huawei.com> Reviewed-by: Li Nan <linan122@huawei.com> Link: https://lore.kernel.org/linux-raid/20250707075412.150301-1-zhengqixing@huaweicloud.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-07-12md/raid5: unset WQ_CPU_INTENSIVE for raid5 unbound workqueueRyo Takakura1-1/+1
When specified with WQ_CPU_INTENSIVE, the workqueue doesn't participate in concurrency management. This behaviour is already accounted for WQ_UNBOUND workqueues given that they are assigned to their own worker threads. Unset WQ_CPU_INTENSIVE as the use of flag has no effect when used with WQ_UNBOUND. Signed-off-by: Ryo Takakura <ryotkkr98@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/linux-raid/20250601013702.64640-1-ryotkkr98@gmail.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-07-12md: remove/add redundancy group only in level changeXiao Ni1-2/+0
del_gendisk is called in synchronous way now. So it doesn't need to handle redundancy group in stop path separately. Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Link: https://lore.kernel.org/linux-raid/20250611073108.25463-4-xni@redhat.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-07-12md: Don't clear MD_CLOSING until mddev is freedXiao Ni1-12/+4
UNTIL_STOP is used to avoid mddev is freed on the last close before adding disks to mddev. And it should be cleared when stopping an array which is mentioned in commit efeb53c0e572 ("md: Allow md devices to be created by name."). So reset ->hold_active to 0 in md_clean. And MD_CLOSING should be kept until mddev is freed to avoid reopen. Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Link: https://lore.kernel.org/linux-raid/20250611073108.25463-3-xni@redhat.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-07-12md: call del_gendisk in control pathXiao Ni2-12/+47
Now del_gendisk and put_disk are called asynchronously in workqueue work. The asynchronous way has a problem that the device node can still exist after mdadm --stop command returns in a short window. So udev rule can open this device node and create the struct mddev in kernel again. So put del_gendisk in control path and still leave put_disk in md_kobj_release to avoid uaf of gendisk. Function del_gendisk can't be called with reconfig_mutex. If it's called with reconfig mutex, a deadlock can happen. del_gendisk waits all sysfs files access to finish and sysfs file access waits reconfig mutex. So put del_gendisk after releasing reconfig mutex. But there is still a window that sysfs can be accessed between mddev_unlock and del_gendisk. So some actions (add disk, change level, .e.g) can happen which lead unexpected results. MD_DELETED is used to resolve this problem. MD_DELETED is set before releasing reconfig mutex and it should be checked for these sysfs access which need reconfig mutex. For sysfs access which don't need reconfig mutex, del_gendisk will wait them to finish. But it doesn't need to do this in function mddev_lock_nointr. There are ten places that call it. * Five of them are in dm raid which we don't need to care. MD_DELETED is only used for md raid. * stop_sync_thread, md_do_sync and md_start_sync are related sync request, and it needs to wait sync thread to finish before stopping an array. * md_ioctl: md_open is called before md_ioctl, so ->openers is added. It will fail to stop the array. So it doesn't need to check MD_DELETED here * md_set_readonly: It needs to call mddev_set_closing_and_sync_blockdev when setting readonly or read_auto. So it will fail to stop the array too because MD_CLOSING is already set. Reviewed-by: Yu Kuai <yukuai3@huawei.com> Signed-off-by: Xiao Ni <xni@redhat.com> Link: https://lore.kernel.org/linux-raid/20250611073108.25463-2-xni@redhat.com Signed-off-by: Yu Kuai <yukuai3@huawei.com>
2025-07-12media: rkvdec: Unstage the driverDetlev Casanova11-3/+2
The TODO list for unstaging being empty, the driver can now be moved to the main media folder. Also add myself as maintainer. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-07-12media: rkvdec: Remove TODO fileDetlev Casanova1-11/+0
2 items are present in the TODO file: - HEVC support - Evaluate adding helper for rkvdec_request_validate Missing HEVC support is not a reason for a driver to be in staging, support for different features of the hardware can be added in drivers in the main tree. The rkvdec_request_validate function was simplified in commit 54676d5f5630 ("media: rkvdec: Do not require all controls to be present in every request") by not setting controls that have not changed. As it now basically just calls vb2_request_validate(), there is no need for a helper. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-07-12media: amphion: Support dmabuf and v4l2 buffer without bindingMing Qian4-48/+220
When using VB2_DMABUF, the relationship between dma-buf and v4l2 buffer may not one-to-one, a single dma-buf may be queued via different v4l2 buffers, and different dma-bufs may be queued via the same v4l2 buffer, so it's not appropriate to use the v4l2 buffer index as the frame store id. We can generate a frame store id according to the dma address. Then for a given dma-buf, the id is fixed. Driver now manages the frame store and vb2-buffer states independently. When a dmabuf is queued via another v4l2 buffer before the buffer is released by firmware, need to pend it until firmware release it. Signed-off-by: Ming Qian <ming.qian@oss.nxp.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-07-12media: verisilicon: postproc: 4K supportHugues Fruchet3-2/+8
Support input larger than 4096x2048 using extended input width/height fields of swreg92. This is needed to decode large WebP or JPEG pictures. Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-07-12media: v4l2: Add support for NV12M tiled variants to v4l2_format_info()Marek Szyprowski1-0/+6
Commit 6f1466123d73 ("media: s5p-mfc: Add YV12 and I420 multiplanar format support") added support for the new formats to s5p-mfc driver, what in turn required some internal calls to the v4l2_format_info() function while setting up formats. This in turn broke support for the "old" tiled NV12MT* formats, which are not recognized by this function. Fix this by adding those variants of NV12M pixel format to v4l2_format_info() function database. Fixes: 6f1466123d73 ("media: s5p-mfc: Add YV12 and I420 multiplanar format support") Cc: stable@vger.kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-07-12habanalabs: fix UAF in export_dmabuf()Al Viro1-16/+7
As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF. dma_buf_fd() is a combination of reserving a descriptor and fd_install(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close. In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that "will be" is actually "might have already been". Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up. As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail. Fixes: db1a8dd916aa ("habanalabs: add support for dma-buf exporter") Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2025-07-12loop: Avoid updating block size under exclusive ownerJan Kara1-8/+30
Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it. Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz> Tested-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20250711163202.19623-2-jack@suse.cz Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-12Merge branch '100GbE' of ↵Jakub Kicinski14-69/+378
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ice: cleanups and preparation for live migration Jake Keller says: Various cleanups and preparation to the ice driver code for supporting SR-IOV live migration. The logic for unpacking Rx queue context data is added. This is the inverse of the existing packing logic. Thanks to <linux/packing.h> this is trivial to add. Code to enable both reading and writing the Tx queue context for a queue over a shared hardware register interface is added. Thanks to ice_adapter, this is locked across all PFs that need to use it, preventing concurrency issues with multiple PFs. The RSS hash configuration requested by a VF is cached within the VF structure. This will be used to track and restore the same configuration during migration load. ice_sriov_set_msix_vec_count() is updated to use pci_iov_vf_id() instead of open-coding a worse equivalent, and checks to avoid rebuilding MSI-X if the current request is for the existing amount of vectors. A new ice_get_vf_by_dev() helper function is added to simplify accessing a VF from its PCI device structure. This will be used more heavily within the live migration code itself. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: introduce ice_get_vf_by_dev() wrapper ice: avoid rebuilding if MSI-X vector count is unchanged ice: use pci_iov_vf_id() to get VF ID ice: expose VF functions used by live migration ice: move ice_vsi_update_l2tsel to ice_lib.c ice: save RSS hash configuration for migration ice: add functions to get and set Tx queue context ice: add support for reading and unpacking Rx queue context ==================== Link: https://patch.msgid.link/20250710214518.1824208-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-12Merge tag 'pci-v6.16-fixes-3' of ↵Linus Torvalds3-8/+51
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Track apple Root Ports explicitly and look up the driver data from the struct device instead of using dev->driver_data, which is used by pci_host_common_init() for the generic host bridge pointer (Marc Zyngier) - Set dev->driver_data before pci_host_common_init() calls gen_pci_init() because some drivers need it to set up ECAM mappings; this fixes a regression on MicroChip MPFS Icicle (Geert Uytterhoeven) - Revert the now-unnecessary use of ECAM pci_config_window.priv to store a copy of dev->driver_data (Marc Zyngier) * tag 'pci-v6.16-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: Revert "PCI: ecam: Allow cfg->priv to be pre-populated from the root port device" PCI: host-generic: Set driver_data before calling gen_pci_init() PCI: apple: Add tracking of probed root ports
2025-07-12Merge tag 'drm-fixes-2025-07-12' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds22-86/+165
Pull drm fixes from Simona Vetter: "Cross-subsystem Changes: - agp/amd64 binding dmesg noise regression fix Core Changes: - fix race in gem_handle_create_tail - fixup handle_count fb refcount regression from -rc5, popular with reports ... - call rust dtor for drm_device release Driver Changes: - nouveau: magic 50ms suspend fix, acpi leak fix - tegra: dma api error in nvdec - pvr: fix device reset - habanalbs maintainer update - intel display: fix some dsi mipi sequences - xe fixes: SRIOV fixes, small GuC fixes, disable indirect ring due to issues, compression fix for fragmented BO, doc update * tag 'drm-fixes-2025-07-12' of https://gitlab.freedesktop.org/drm/kernel: (22 commits) drm/xe/guc: Default log level to non-verbose drm/xe/bmg: Don't use WA 16023588340 and 22019338487 on VF drm/xe/guc: Recommend GuC v70.46.2 for BMG, LNL, DG2 drm/xe/pm: Correct comment of xe_pm_set_vram_threshold() drm/xe: Release runtime pm for error path of xe_devcoredump_read() drm/xe/pm: Restore display pm if there is error after display suspend drm/i915/bios: Apply vlv_fixup_mipi_sequences() to v2 mipi-sequences too drm/gem: Fix race in drm_gem_handle_create_tail() drm/framebuffer: Acquire internal references on GEM handles agp/amd64: Check AGP Capability before binding to unsupported devices drm/xe/bmg: fix compressed VRAM handling Revert "drm/xe/xe2: Enable Indirect Ring State support for Xe2" drm/xe: Allocate PF queue size on pow2 boundary drm/xe/pf: Clear all LMTT pages on alloc drm/nouveau/gsp: fix potential leak of memory used during acpi init rust: drm: remove unnecessary imports MAINTAINERS: Change habanalabs maintainer drm/imagination: Fix kernel crash when hard resetting the GPU drm/tegra: nvdec: Fix dma_alloc_coherent error check rust: drm: device: drop_in_place() the drm::Device in release() ...
2025-07-12net: ll_temac: Fix incorrect PHY node reference in debug messageAlok Tiwari1-1/+1
In temac_probe(), the debug message intended to print the resolved PHY node was mistakenly using the controller node temac_np instead of the actual PHY node lp->phy_node. This patch corrects the log to reference the correct device tree node. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/20250710183737.2385156-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-21 03:54:10 +0300