summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-01-10serial: sc16is7xx: Add polling mode if no IRQ pin is availableAndre Werner
Fall back to polling mode if no interrupt is configured because there is no possibility to connect the interrupt pin. If "interrupts" property is missing in devicetree the driver uses a delayed worker to pull the state of interrupt status registers. Signed-off-by: Andre Werner <andre.werner@systec-electronic.com> Link: https://lore.kernel.org/r/20250110073104.1029633-2-andre.werner@systec-electronic.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10tty: serial: atmel: make it selectable for ARCH_LAN969XRobert Marko
LAN969x uses the Atmel serial, so make it selectable for ARCH_LAN969X. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20250108131045.40642-3-robert.marko@sartura.hr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10tty: mips_ejtag_fdc: fix one more u8 warningJiri Slaby (SUSE)
The LKP robot complains about: drivers/tty/mips_ejtag_fdc.c:1224:31: error: incompatible pointer types passing 'const char *[1]' to parameter of type 'const u8 **' (aka 'const unsigned char **') Fix this by turning the missing pieces (fetch from kgdbfdc_wbuf) to u8 too. Note the filling part (kgdbfdc_write_char()) already receives and stores u8 to kgdbfdc_wbuf. Fixes: ce7cbd9a6c81 ("tty: mips_ejtag_fdc: use u8 for character pointers") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501101327.oGdWbmuk-lkp@intel.com/ Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20250110115228.603980-1-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10HID: lenovo: Fix undefined platform_profile_cycle in ThinkPad X12 keyboard patchVishnu Sankar
The commit "HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd Fn keys" introduced an issue where the CI failed with the following error: ERROR: modpost: "platform_profile_cycle" [drivers/hid/hid-lenovo.ko] undefined! This issue occurs because platform_profile_cycle is used without ensuring the kernel is configured with CONFIG_ACPI_PLATFORM_PROFILE. To address this, this patch adds conditional support for platform profile management to the Fn+F8 key handling. The functionality for platform_profile_cycle is now included only when CONFIG_ACPI_PLATFORM_PROFILE is enabled in the kernel configuration. This ensures compatibility with kernels that do not include the ACPI platform profile feature, resolving the CI build issue. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Signed-off-by: Vishnu Sankar <vsankar@lenovo.com> Suggested-by: Benjamin Tissoires <bentiss@kernel.org> Suggested-by: Jiri Kosina <jikos@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-01-10staging: rtl8723bs: Remove ioctl interface谢致邦 (XIE Zhibang)
Wireless drivers should not use the ioctl interface, so remove this interface for the rtl8723bs driver. (found by code inspection) Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/tencent_E4A835D41FF1F35C7BDFCF4EA0136D548F06@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10spi-nand/spi-mem DTR supportMark Brown
Merge series from Miquel Raynal <miquel.raynal@bootlin.com>: Here is a (big) series supposed to bring DTR support in SPI-NAND.
2025-01-10perf: arm_spe: Add format option for discard modeJames Clark
FEAT_SPEv1p2 (optional from Armv8.6) adds a discard mode that allows all SPE data to be discarded rather than written to memory. Add a format bit for this mode. If the mode isn't supported, the format bit isn't published and attempts to use it will result in -EOPNOTSUPP. Allocating an aux buffer is still allowed even though it won't be written to so that old tools continue to work, but updated tools can choose to skip this step. Signed-off-by: James Clark <james.clark@linaro.org> Reviewd-by: Yeoreum Yun <yeoreum.yun@arm.com> Link: https://lore.kernel.org/r/20250108142904.401139-2-james.clark@linaro.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-10devres: add devm_remove_action_nowarn()Danilo Krummrich
devm_remove_action() warns if the action to remove does not exist (anymore). The Rust devres abstraction, however, has a use-case to call devm_remove_action() at a point where it can't be guaranteed that the corresponding action hasn't been released yet. In particular, an instance of `Devres<T>` may be dropped after the action has been released. So far, `Devres<T>` worked around this by keeping the inner type alive. Hence, add devm_remove_action_nowarn(), which returns an error code if the action has been removed already. A subsequent patch uses devm_remove_action_nowarn() to remove the action when `Devres<T>` is dropped. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250107122609.8135-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10cdx: disable cdx bus from bus shutdown callbackAbhijit Gangurde
disable cdx bus when bus shutdown is called. Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://lore.kernel.org/r/20241203084409.2747897-2-abhijit.gangurde@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10drivers/card_reader/rtsx_usb: Restore interrupt based detectionSean Rhodes
This commit reintroduces interrupt-based card detection previously used in the rts5139 driver. This functionality was removed in commit 00d8521dcd23 ("staging: remove rts5139 driver code"). Reintroducing this mechanism fixes presence detection for certain card readers, which with the current driver, will taken approximately 20 seconds to enter S3 as `mmc_rescan` has to be frozen. Fixes: 00d8521dcd23 ("staging: remove rts5139 driver code") Cc: stable@vger.kernel.org Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sean Rhodes <sean@starlabs.systems> Link: https://lore.kernel.org/r/20241119085815.11769-1-sean@starlabs.systems Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10drivers: core: remove device_link argument from ↵Heiner Kallweit
class_compat_[create|remove]_link After 7e722083fcc3 ("i2c: Remove I2C_COMPAT config symbol and related code") there's no caller left passing a non-null device_link argument. So remove this argument to simplify the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/db49131d-fd79-4f23-93f2-0ab541a345fa@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10loop: remove the use_dio field in struct loop_deviceChristoph Hellwig
This field duplicate the LO_FLAGS_DIRECT_IO flag in lo_flags. Remove it to have a single source of truth about using direct I/O. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-9-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: don't freeze the queue in loop_update_dioChristoph Hellwig
All callers of loop_update_dio except for loop_configure already have the queue frozen, and loop_configure works on an unbound device. Remove the superfluous recursive freezing in loop_update_dio and add asserts for the locking and freezing state instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-8-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: allow loop_set_status to re-enable direct I/OChristoph Hellwig
Unlike all other calls of (__)loop_update_dio, loop_set_status never looks at the O_DIRECT flag of the backing file, and thus doesn't re-enable direct I/O on an O_DIRECT backing file if e.g. the new block size would allow it. Fix that and remove the need for the separate __loop_update_dio flag. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-7-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: open code the direct I/O flag update in loop_set_dioChristoph Hellwig
loop_set_dio is different from the other (__)loop_update_dio callers in that it doesn't take any implicit conditions into account and wants to update the direct I/O flag to the user passed in value and fail if that can't be done. Open code the logic here to prepare for simplifying the other direct I/O flag updates and to make the error handling less convoluted. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-6-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: only write back pagecache when starting to to use direct I/OChristoph Hellwig
There is no point in doing an fdatasync to write out pages when switching away from direct I/O, as there won't be any. The writeback is only needed when switching to direct I/O, which would have to invalidate the pagecache less efficiently from the I/O path. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-5-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: create a lo_can_use_dio helperChristoph Hellwig
Factor out a part of __loop_update_dio in preparation for further refactoring. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: update commands in loop_set_status still referring to transfersChristoph Hellwig
The concept of transfers is gone since commit 47e9624616c8 ("block: remove support for cryptoloop and the xor transfer"). Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: move updating lo_flags out of loop_set_status_from_infoChristoph Hellwig
While loop_configure simplify assigns the flags passed in by userspace, loop_set_status only looks at the two changeable flags, and currently has to do a complicate dance to implement that. Move assign lo->lo_flags out of loop_set_status_from_info into the callers and thus drastically simplify the lo_flags handling in loop_set_status. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20250110073750.1582447-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: fix queue freeze vs limits lock orderChristoph Hellwig
Match the locking order used by the core block code by only freezing the queue after taking the limits lock using the queue_limits_commit_update_frozen helper and document the callers that do not freeze the queue at all. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-12-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10loop: refactor queue limits updatesChristoph Hellwig
Replace loop_reconfigure_limits with a slightly less encompassing loop_update_limits that expects the caller to acquire and commit the queue limits to prepare for sorting out the freeze vs limits lock ordering. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Link: https://lore.kernel.org/r/20250110054726.1499538-11-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10usb-storage: fix queue freeze vs limits lock orderChristoph Hellwig
Match the locking order used by the core block code by only freezing the queue after taking the limits lock using the queue_limits_commit_update_frozen helper. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-10-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10nbd: fix queue freeze vs limits lock orderChristoph Hellwig
Match the locking order used by the core block code by only freezing the queue after taking the limits lock using the queue_limits_commit_update_frozen helper. This also allows removes the need for the separate __nbd_set_size helper, so remove it. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-9-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10nvme: fix queue freeze vs limits lock orderChristoph Hellwig
Match the locking order used by the core block code by only freezing the queue after taking the limits lock. Unlike most queue updates this does not use the queue_limits_commit_update_frozen helper as the nvme driver want the queue frozen for more than just the limits update. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-8-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10block: add a queue_limits_commit_update_frozen helperChristoph Hellwig
Add a helper that freezes the queue, updates the queue limits and unfreezes the queue and convert all open coded versions of that to the new helper. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-01-10driver core: Move two simple APIs for finding child device to headerZijun Hu
The following two APIs are for finding child device, and both only have one line code in function body. device_find_child_by_name() device_find_any_child() Move them to header as static inline function. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-8-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10driver core: Introduce device_iter_t for device iterating APIsZijun Hu
There are several for_each APIs which has parameter with type below: int (*fn)(struct device *dev, void *data) They iterate over various device lists and call @fn() for each device with caller provided data @*data, and they usually need to modify @*data. Give the type an dedicated typedef with advantages shown below: typedef int (*device_iter_t)(struct device *dev, void *data) - Shorter API declarations and definitions - Prevent further for_each APIs from using bad parameter type So introduce device_iter_t and apply it to various existing APIs below: bus_for_each_dev() (class|driver)_for_each_device() device_for_each_child(_reverse|_reverse_from)(). Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-7-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10driver core: Correct API device_for_each_child_reverse_from() prototypeZijun Hu
For API device_for_each_child_reverse_from(..., const void *data, int (*fn)(struct device *dev, const void *data)) - Type of @data is const pointer, and means caller's data @*data is not allowed to be modified, but that usually is not proper for such non finding device iterating API. - Types for both @data and @fn are not consistent with all other for_each device iterating APIs device_for_each_child(_reverse)(), bus_for_each_dev() and (driver|class)_for_each_device(). Correct its prototype by removing const from parameter types, then adapt for various existing usages. An dedicated typedef device_iter_t will be introduced as @fn() type for various for_each device interating APIs later. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-6-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10driver core: Correct parameter check for API ↵Zijun Hu
device_for_each_child_reverse_from() device_for_each_child_reverse_from() checks (!parent->p) for its parameter @parent, and that is not consistent with other APIs of its cluster as shown below: device_for_each_child_reverse_from() // check (!parent->p) device_for_each_child_reverse() // check (!parent || !parent->p) device_for_each_child() // same above device_find_child() // same above Correct the API's parameter @parent check by (!parent || !parent->p). Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-5-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10driver core: Move true expression out of if condition in 3 device finding APIsZijun Hu
For bus_find_device(), driver_find_device(), and device_find_child(), all of their function body have pattern below: { struct klist_iter i; struct device *dev; ... while ((dev = next_device(&i))) if (match(dev, data) && get_device(dev)) break; ... } The expression 'get_device(dev)' in the if condition always returns true since @dev != NULL. Move the expression to if body to make logic of these APIs more clearer. Reviewed-by: Fan Ni <fan.ni@samsung.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-3-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()Zijun Hu
There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage: // All members of @iter are wild pointers. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...); // Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... }; // Also dereference these wild pointers here. class_dev_iter_exit(&iter); Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next(). Fixes: 7b884b7f24b4 ("driver core: class.c: convert to only use class_to_subsys") Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250105-class_fix-v6-1-3a2f1768d4d4@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10bus: fsl-mc: constify the struct device_type usageRicardo B. Marliere
Since commit aed65af1cc2f ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move all the device_type variables used in the bus to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo.marliere@suse.com> Link: https://lore.kernel.org/r/20240904-class_cleanup-fsl-mc-bus-v2-1-83fa25cbdc68@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10misc: fastrpc: Rename tgid and pid to client_idEkansh Gupta
The information passed as request tgid and pid is actually the client id of the process. This client id is used as an identifier by DSP to identify the DSP PD corresponding to the process. Currently process tgid is getting passed as the identifier which is getting replaced by a custom client id. Rename the data which uses this client id. Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20250110134308.123739-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10misc: fastrpc: Add support for multiple PD from one processEkansh Gupta
Memory intensive applications(which requires more tha 4GB) that wants to offload tasks to DSP might have to split the tasks to multiple user PD to make the resources available. For every call to DSP, fastrpc driver passes the process tgid which works as an identifier for the DSP to enqueue the tasks to specific PD. With current design, if any process opens device node more than once and makes PD init request, same tgid will be passed to DSP which will be considered a bad request and this will result in failure as the same identifier cannot be used for multiple DSP PD. Assign and pass a client ID to DSP which would be assigned during device open and will be dependent on the index of session allocated for the PD. This will allow the same process to open the device more than once and spawn multiple dynamic PD for ease of processing. Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20250110134308.123739-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10Merge tag 'usb-serial-6.13-rc7' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial device ids for 6.13-rc7 Here are some new modem and cp210x device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-6.13-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Neoway N723-EA support USB: serial: option: add MeiG Smart SRM815 USB: serial: cp210x: add Phoenix Contact UPS Device
2025-01-10drivers/perf: apple_m1: Map generic branch eventsOliver Upton
Map the generic perf events for branch prediction stats to the corresponding hardware events. Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Tested-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/r/20241217212048.3709204-4-oliver.upton@linux.dev Signed-off-by: Will Deacon <will@kernel.org>
2025-01-10iommu/arm-smmu-v3: Add missing #include of linux/string_choices.hWill Deacon
Commit f2c77f6e41e6 ("iommu/arm-smmu-v3: Use str_read_write helper w/ logs") introduced a call to str_read_write() in the SMMUv3 driver but without an explicit #include of <linux/string_choices.h>. This breaks the build for custom configurations where CONFIG_ACPI=n: drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:1909:4: error: call to undeclared function 'str_read_write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 1909 | str_read_write(evt->read), | ^ Add the missing #include. Link: https://lore.kernel.org/r/d07e82a4-2880-4ae3-961b-471bfa7ac6c4@samsung.com Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: f2c77f6e41e6 ("iommu/arm-smmu-v3: Use str_read_write helper w/ logs") Signed-off-by: Will Deacon <will@kernel.org>
2025-01-10Merge tag 'amd-pstate-v6.14-2025-01-07' of ↵Rafael J. Wysocki
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux Merge amd-pstate changes for 6.14 from Mario Limonciello: "Fix a regression with preferred core rankings not being used. Fix a precision issue with frequency calculation." * tag 'amd-pstate-v6.14-2025-01-07' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux: cpufreq/amd-pstate: Refactor max frequency calculation cpufreq/amd-pstate: Fix prefcore rankings
2025-01-10wifi: brcmfmac: Add missing Return: to function documentationJeff Johnson
Running 'scripts/kernel-doc -Wall -Werror -none' flagged the following kernel-doc issues: drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:823: warning: No description found for return value of 'brcmf_apsta_add_vif' drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:907: warning: No description found for return value of 'brcmf_mon_add_vif' drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7419: warning: No description found for return value of 'brcmf_setup_ifmodes' Add the missing 'Return:' tags to the kernel-doc of these functions. Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20250106-brcmfmac-kdoc-v1-1-ed72196e21a1@oss.qualcomm.com
2025-01-10wifi: iwlegacy: Remove unused il_get_single_channel_number()Dr. David Alan Gilbert
THe last use of il_get_single_channel_number() was removed in 2011 by commit dd6d2a8aef69 ("iwlegacy: remove reset rf infrastructure") when it was still called iwl_legacy_get_single_channel_number. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241226011355.135417-3-linux@treblig.org
2025-01-10wifi: iwlegacy: Remove unused il3945_calc_db_from_ratio()Dr. David Alan Gilbert
The last use of il3945_calc_db_from_ratio() was removed in 2010 by commit ed1b6e99b5e6 ("iwlwifi: remove noise reporting") when it was still called iwl3945_calc_db_from_ratio(). Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241226011355.135417-2-linux@treblig.org
2025-01-10wifi: rt2x00: Remove unused rfval valuesAriel Otilibili
The intention here is not clear but as this was already tested and matches vendor driver it's better not to change behavior even if it looks suspicious. So just remove the unused values. Coverity-ID: 1525307 Signed-off-by: Ariel Otilibili <ariel.otilibili-anieli@eurecom.fr> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> [kvalo@kernel.org: write commit message] Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241221124445.1094460-2-ariel.otilibili-anieli@eurecom.fr
2025-01-10wifi: brcmfmac: Check the return value of of_property_read_string_index()Stefan Dösinger
Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup(). The crash I am getting looks like this: BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: error_code(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac] Signed-off-by: Stefan Dösinger <stefan@codeweavers.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20250106170958.3595-1-stefan@codeweavers.com
2025-01-10wifi: wlcore: fix unbalanced pm_runtime callsAndreas Kemnade
If firmware boot failes, runtime pm is put too often: [12092.708099] wlcore: ERROR firmware boot failed despite 3 retries [12092.708099] wl18xx_driver wl18xx.1.auto: Runtime PM usage count underflow! Fix that by redirecting all error gotos before runtime_get so that runtime is not put. Fixes: c40aad28a3cf ("wlcore: Make sure firmware is initialized in wl1271_op_add_interface()") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Michael Nemanov <michael.nemanov@ti.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20250104195507.402673-1-akemnade@kernel.org
2025-01-10wifi: wilc1000: unregister wiphy only if it has been registeredAlexis Lothoré
There is a specific error path in probe functions in wilc drivers (both sdio and spi) which can lead to kernel panic, as this one for example when using SPI: Unable to handle kernel paging request at virtual address 9f000000 when read [9f000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22 Hardware name: Atmel SAMA5 PC is at wiphy_unregister+0x244/0xc40 [cfg80211] LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211] [...] wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000] wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi] wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4 spi_probe from really_probe+0x270/0xb2c really_probe from __driver_probe_device+0x1dc/0x4e8 __driver_probe_device from driver_probe_device+0x5c/0x140 driver_probe_device from __driver_attach+0x220/0x540 __driver_attach from bus_for_each_dev+0x13c/0x1a8 bus_for_each_dev from bus_add_driver+0x2a0/0x6a4 bus_add_driver from driver_register+0x27c/0x51c driver_register from do_one_initcall+0xf8/0x564 do_one_initcall from do_init_module+0x2e4/0x82c do_init_module from load_module+0x59a0/0x70c4 load_module from init_module_from_file+0x100/0x148 init_module_from_file from sys_finit_module+0x2fc/0x924 sys_finit_module from ret_fast_syscall+0x0/0x1c The issue can easily be reproduced, for example by not wiring correctly a wilc device through SPI (and so, make it unresponsive to early SPI commands). It is due to a recent change decoupling wiphy allocation from wiphy registration, however wilc_netdev_cleanup has not been updated accordingly, letting it possibly call wiphy unregister on a wiphy which has never been registered. Fix this crash by moving wiphy_unregister/wiphy_free out of wilc_netdev_cleanup, and by adjusting error paths in both drivers Fixes: fbdf0c5248dc ("wifi: wilc1000: Register wiphy after reading out chipid") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241223-wilc_fix_probe_error_path-v1-1-91fa7bd8e5b6@bootlin.com
2025-01-10wifi: mt76: mt7996: fix invalid interface combinationsShayne Chen
Setting beacon_int_min_gcd and NL80211_IFTYPE_ADHOC in the same interface combination is invalid, which will trigger the following warning trace and get error returned from wiphy_register(). [ 10.080325] Call trace: [ 10.082761] wiphy_register+0xc4/0x76c [cfg80211] [ 10.087465] ieee80211_register_hw+0x800/0xac4 [mac80211] [ 10.092868] mt76_register_device+0x16c/0x2c0 [mt76] [ 10.097829] mt7996_register_device+0x740/0x844 [mt7996e] Fix this by removing unused adhoc iftype. Fixes: 948f65249868 ("wifi: mt76: mt7996: advertize beacon_int_min_gcd") Reported-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Tested-By: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241007135133.5336-1-shayne.chen@mediatek.com
2025-01-10can: kvaser_pciefd: Add support for CAN_CTRLMODE_BERR_REPORTINGJimmy Assarsson
Add support for CAN_CTRLMODE_BERR_REPORTING, allowing Bus Error Reporting to be enabled or disabled. Previously, Bus Error Reporting was always active. Co-developed-by: Alison Below <alisonbelow@gmail.com> Signed-off-by: Alison Below <alisonbelow@gmail.com> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20241230142645.128244-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-01-10can: kvaser_pciefd: Update stats and state even if alloc_can_err_skb() failsJimmy Assarsson
Ensure statistics, error counters, and CAN state are updated consistently, even when alloc_can_err_skb() fails during state changes or error message frame reception. Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20241230142645.128244-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-01-10can: kvaser_usb: Add support for CAN_CTRLMODE_BERR_REPORTINGJimmy Assarsson
Add support for CAN_CTRLMODE_BERR_REPORTING, allowing Bus Error Reporting to be enabled or disabled. Previously, Bus Error Reporting was always active. Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20241230142645.128244-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-01-10can: kvaser_usb: Update stats and state even if alloc_can_err_skb() failsJimmy Assarsson
Ensure statistics, error counters, and CAN state are updated consistently, even when alloc_can_err_skb() fails during state changes or error message frame reception. Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20241230142645.128244-1-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>