user/sven/linux.git/net/rfkill, branch v4.14.335

net: rfkill: gpio: set GPIO direction

2024-01-08T10:25:04Z

commit 23484d817082c3005252d8edfc8292c8a1006b5b upstream. Fix the undefined usage of the GPIO consumer API after retrieving the GPIO description with GPIO_ASIS. The API documentation mentions that GPIO_ASIS won't set a GPIO direction and requires the user to set a direction before using the GPIO. This can be confirmed on i.MX6 hardware, where rfkill-gpio is no longer able to enabled/disable a device, presumably because the GPIO controller was never configured for the output direction. Fixes: b2f750c3a80b ("net: rfkill: gpio: prevent value glitch during probe") Cc: stable@vger.kernel.org Signed-off-by: Rouven Czerwinski Link: https://msgid.link/20231207075835.3091694-1-r.czerwinski@pengutronix.de Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

net: rfkill: gpio: prevent value glitch during probe

2023-10-25T09:13:32Z

commit b2f750c3a80b285cd60c9346f8c96bd0a2a66cde upstream. When either reset- or shutdown-gpio have are initially deasserted, e.g. after a reboot - or when the hardware does not include pull-down, there will be a short toggle of both IOs to logical 0 and back to 1. It seems that the rfkill default is unblocked, so the driver should not glitch to output low during probe. It can lead e.g. to unexpected lte modem reconnect: [1] root@localhost:~# dmesg | grep "usb 2-1" [ 2.136124] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd [ 21.215278] usb 2-1: USB disconnect, device number 2 [ 28.833977] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd The glitch has been discovered on an arm64 board, now that device-tree support for the rfkill-gpio driver has finally appeared :). Change the flags for devm_gpiod_get_optional from GPIOD_OUT_LOW to GPIOD_ASIS to avoid any glitches. The rfkill driver will set the intended value during rfkill_sync_work. Fixes: 7176ba23f8b5 ("net: rfkill: add generic gpio rfkill driver") Signed-off-by: Josua Mayer Link: https://lore.kernel.org/r/20231004163928.14609-1-josua@solid-run.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

rfkill: Fix incorrect check to avoid NULL pointer dereference

2020-01-12T11:11:57Z

[ Upstream commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7 ] In rfkill_register, the struct rfkill pointer is first derefernced and then checked for NULL. This patch removes the BUG_ON and returns an error to the caller in case rfkill is NULL. Signed-off-by: Aditya Pakki Link: https://lore.kernel.org/r/20191215153409.21696-1-pakki001@umn.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

rfkill: allocate static minor

2019-12-31T11:37:21Z

[ Upstream commit 8670b2b8b029a6650d133486be9d2ace146fd29a ] udev has a feature of creating /dev/ device-nodes if it finds a devnode: modalias. This allows for auto-loading of modules that provide the node. This requires to use a statically allocated minor number for misc character devices. However, rfkill uses dynamic minor numbers and prevents auto-loading of the module. So allocate the next static misc minor number and use it for rfkill. Signed-off-by: Marcel Holtmann Link: https://lore.kernel.org/r/20191024174042.19851-1-marcel@holtmann.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

rfkill: gpio: fix memory leak in probe error path

2018-05-16T08:10:26Z

commit 4bf01ca21e2e0e4561d1a03c48c3d740418702db upstream. Make sure to free the rfkill device in case registration fails during probe. Fixes: 5e7ca3937fbe ("net: rfkill: gpio: convert to resource managed allocation") Cc: stable # 3.13 Cc: Heikki Krogerus Signed-off-by: Johan Hovold Reviewed-by: Heikki Krogerus Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

net: rfkill: gpio: Switch to devm_acpi_dev_add_driver_gpios()

2017-06-13T09:07:51Z

Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify error path and fix potentially wrong assingment if ->probe() fails. Signed-off-by: Andy Shevchenko Signed-off-by: Johannes Berg

rfkill: remove rfkill-regulator

2017-01-24T10:07:35Z

There are no users of this ("vrfkill") in the tree, so it's just dead code - remove it. This also isn't really how rfkill is supposed to be used - it's intended as a signalling mechanism to/from the device, which the driver (and partially cfg80211) will handle - having a separate rfkill instance for a regulator is confusing, the driver should use the regulator instead to turn off the device when requested. Signed-off-by: Johannes Berg

rfkill: Add rfkill-any LED trigger

2017-01-09T10:40:33Z

Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any, which may be useful on laptops with a single "radio LED" and multiple radio transmitters. The trigger is meant to turn a LED on whenever there is at least one radio transmitter active and turn it off otherwise. Signed-off-by: Michał Kępień Signed-off-by: Johannes Berg

Revert "rfkill: Add rfkill-any LED trigger"

2016-12-20T07:45:54Z

This reverts commit 73f4f76a196d7adb11a1e192bd8024fe0bc83910. As Mike reported, and I should've seen in review, we can't call the new LED functions, which acquire the mutex, from places like rfkill_set_sw_state() that are documented to be callable from any context the user likes to use. For Mike's case it led to a deadlock, but other scenarios are possible. Reported-by: Михаил Кринкин Signed-off-by: Johannes Berg

rfkill: hide unused goto label

2016-12-16T09:05:39Z

A cleanup introduced a harmless warning in some configurations: net/rfkill/core.c: In function 'rfkill_init': net/rfkill/core.c:1350:1: warning: label 'error_input' defined but not used [-Wunused-label] This adds another #ifdef around the label to match that around the caller. Fixes: 6124c53edeea ("rfkill: Cleanup error handling in rfkill_init()") Signed-off-by: Arnd Bergmann Signed-off-by: Johannes Berg