linux-stable.git/drivers/leds, branch v6.7

leds: trigger: netdev: fix RTNL handling to prevent potential deadlock

2023-12-06T15:36:55+00:00

When working on LED support for r8169 I got the following lockdep
warning. Easiest way to prevent this scenario seems to be to take
the RTNL lock before the trigger_data lock in set_device_name().

======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc2-next-20231124+ #2 Not tainted
------------------------------------------------------
bash/383 is trying to acquire lock:
ffff888103aa1c68 (&trigger_data->lock){+.+.}-{3:3}, at: netdev_trig_notify+0xec/0x190 [ledtrig_netdev]

but task is already holding lock:
ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (rtnl_mutex){+.+.}-{3:3}:
       __mutex_lock+0x9b/0xb50
       mutex_lock_nested+0x16/0x20
       rtnl_lock+0x12/0x20
       set_device_name+0xa9/0x120 [ledtrig_netdev]
       netdev_trig_activate+0x1a1/0x230 [ledtrig_netdev]
       led_trigger_set+0x172/0x2c0
       led_trigger_write+0xf1/0x140
       sysfs_kf_bin_write+0x5d/0x80
       kernfs_fop_write_iter+0x15d/0x210
       vfs_write+0x1f0/0x510
       ksys_write+0x6c/0xf0
       __x64_sys_write+0x14/0x20
       do_syscall_64+0x3f/0xf0
       entry_SYSCALL_64_after_hwframe+0x6c/0x74

-> #0 (&trigger_data->lock){+.+.}-{3:3}:
       __lock_acquire+0x1459/0x25a0
       lock_acquire+0xc8/0x2d0
       __mutex_lock+0x9b/0xb50
       mutex_lock_nested+0x16/0x20
       netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
       call_netdevice_register_net_notifiers+0x5a/0x100
       register_netdevice_notifier+0x85/0x120
       netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev]
       led_trigger_set+0x172/0x2c0
       led_trigger_write+0xf1/0x140
       sysfs_kf_bin_write+0x5d/0x80
       kernfs_fop_write_iter+0x15d/0x210
       vfs_write+0x1f0/0x510
       ksys_write+0x6c/0xf0
       __x64_sys_write+0x14/0x20
       do_syscall_64+0x3f/0xf0
       entry_SYSCALL_64_after_hwframe+0x6c/0x74

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(rtnl_mutex);
                               lock(&trigger_data->lock);
                               lock(rtnl_mutex);
  lock(&trigger_data->lock);

 *** DEADLOCK ***

8 locks held by bash/383:
 #0: ffff888103ff33f0 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x6c/0xf0
 #1: ffff888103aa1e88 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x114/0x210
 #2: ffff8881036f1890 (kn->active#82){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x11d/0x210
 #3: ffff888108e2c358 (&led_cdev->led_access){+.+.}-{3:3}, at: led_trigger_write+0x30/0x140
 #4: ffffffff8cdd9e10 (triggers_list_lock){++++}-{3:3}, at: led_trigger_write+0x75/0x140
 #5: ffff888108e2c270 (&led_cdev->trigger_lock){++++}-{3:3}, at: led_trigger_write+0xe3/0x140
 #6: ffffffff8cdde3d0 (pernet_ops_rwsem){++++}-{3:3}, at: register_netdevice_notifier+0x1c/0x120
 #7: ffffffff8cddf808 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x12/0x20

stack backtrace:
CPU: 0 PID: 383 Comm: bash Not tainted 6.7.0-rc2-next-20231124+ #2
Hardware name: Default string Default string/Default string, BIOS ADLN.M6.SODIMM.ZB.CY.015 08/08/2023
Call Trace:
 
 dump_stack_lvl+0x5c/0xd0
 dump_stack+0x10/0x20
 print_circular_bug+0x2dd/0x410
 check_noncircular+0x131/0x150
 __lock_acquire+0x1459/0x25a0
 lock_acquire+0xc8/0x2d0
 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
 __mutex_lock+0x9b/0xb50
 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
 ? __this_cpu_preempt_check+0x13/0x20
 ? netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
 ? __cancel_work_timer+0x11c/0x1b0
 ? __mutex_lock+0x123/0xb50
 mutex_lock_nested+0x16/0x20
 ? mutex_lock_nested+0x16/0x20
 netdev_trig_notify+0xec/0x190 [ledtrig_netdev]
 call_netdevice_register_net_notifiers+0x5a/0x100
 register_netdevice_notifier+0x85/0x120
 netdev_trig_activate+0x1d4/0x230 [ledtrig_netdev]
 led_trigger_set+0x172/0x2c0
 ? preempt_count_add+0x49/0xc0
 led_trigger_write+0xf1/0x140
 sysfs_kf_bin_write+0x5d/0x80
 kernfs_fop_write_iter+0x15d/0x210
 vfs_write+0x1f0/0x510
 ksys_write+0x6c/0xf0
 __x64_sys_write+0x14/0x20
 do_syscall_64+0x3f/0xf0
 entry_SYSCALL_64_after_hwframe+0x6c/0x74
RIP: 0033:0x7f269055d034
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d 35 c3 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48
RSP: 002b:00007ffddb7ef748 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000007 RCX: 00007f269055d034
RDX: 0000000000000007 RSI: 000055bf5f4af3c0 RDI: 0000000000000001
RBP: 000055bf5f4af3c0 R08: 0000000000000073 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000007
R13: 00007f26906325c0 R14: 00007f269062ff20 R15: 0000000000000000
 

Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode")
Cc: stable@vger.kernel.org
Signed-off-by: Heiner Kallweit 
Reviewed-by: Andrew Lunn 
Acked-by: Lee Jones 
Link: https://lore.kernel.org/r/fb5c8294-2a10-4bf5-8f10-3d2b77d2757e@gmail.com
Signed-off-by: Jakub Kicinski

leds: class: Don't expose color sysfs entry

2023-11-22T11:46:03+00:00

The commit c7d80059b086 ("leds: class: Store the color index in struct
led_classdev") introduced a new sysfs entry "color" that is commonly
created for the led classdev.  Unfortunately, this conflicts with the
"color" sysfs entry of already existing drivers such as Logitech HID
or System76 ACPI drivers.  The driver probe fails due to the conflict,
hence it leads to a severe regression with the missing keyboard, for
example.

This patch reverts partially the change in the commit above for
removing the led class color sysfs entries again for addressing the
regressions.  The newly introduced led_classdev.color field is kept as
it's already used by other driver.

Fixes: c7d80059b086 ("leds: class: Store the color index in struct led_classdev")
Reported-by: Johannes Penßel 
Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155
Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172
Signed-off-by: Takashi Iwai 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de
Signed-off-by: Lee Jones

Merge tag 'pwm/for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

2023-11-09T21:47:52+00:00

Pull pwm updates from Thierry Reding:
 "This contains a few fixes and a bunch of cleanups, a lot of which is
  in preparation for Uwe's character device support that may be ready in
  time for the next merge window"

* tag 'pwm/for-6.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits)
  pwm: samsung: Document new member .channel in struct samsung_pwm_chip
  pwm: bcm2835: Add support for suspend/resume
  pwm: brcmstb: Checked clk_prepare_enable() return value
  pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume
  pwm: pxa: Explicitly include correct DT includes
  pwm: cros-ec: Simplify using devm_pwmchip_add() and dev_err_probe()
  pwm: samsung: Consistently use the same name for driver data
  pwm: vt8500: Simplify using devm functions
  pwm: sprd: Simplify using devm_pwmchip_add() and dev_err_probe()
  pwm: sprd: Provide a helper to cast a chip to driver data
  pwm: spear: Simplify using devm functions
  pwm: mtk-disp: Simplify using devm_pwmchip_add()
  pwm: imx-tpm: Simplify using devm functions
  pwm: brcmstb: Simplify using devm functions
  pwm: bcm2835: Simplify using devm functions
  pwm: bcm-iproc: Simplify using devm functions
  pwm: Adapt sysfs API documentation to reality
  pwm: dwc: add PWM bit unset in get_state call
  pwm: dwc: make timer clock configurable
  pwm: dwc: split pci out of core driver
  ...

Merge tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds

2023-11-03T00:53:19+00:00

Pull LED updates from Lee Jones:
 "Core Frameworks:
   - Add support for a bunch more colours

  New Drivers:
   - Add support for Kinetic KTD2026/7 RGB/White LEDs

  New Functionality:
   - Add support for device to enter HW Controlled Mode to Turris Omnia
     LEDs
   - Add support for HW Gamma Correction to Turris Omnia LEDs

  Fix-ups:
   - Apply new __counted_by() annotation to several data structures
     containing flexible arrays
   - Rid the return value from Platform's .remove() operation
   - Use *_cansleep() variants for instances were threads can sleep
   - Improve the semantics when setting the brightness
   - Generic clean-ups; code reduction, coding style, standard patterns
   - Replace strncpy() with strscpy()
   - Fix-up / add various documentation
   - Re-author the GPIO associated Trigger to use trigger-sources
   - Move to using standard APIs and helpers
   - Improve error checking
   - Stop using static GPIO bases

  Bug Fixes:
   - Fix Pointer to Enum casing warnings
   - Do not pretend that I2C backed device supports SMBUS
   - Ensure PWM LEDs are extinguished when disabled, rather than held in
     a state
   - Fix 'output may be truncated' warnings"

* tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (43 commits)
  leds: lp5521: Add an error check in lp5521_post_init_device
  leds: gpio: Update headers
  leds: gpio: Remove unneeded assignment
  leds: gpio: Move temporary variable for struct device to gpio_led_probe()
  leds: gpio: Refactor code to use devm_gpiod_get_index_optional()
  leds: gpio: Utilise PTR_ERR_OR_ZERO()
  leds: gpio: Keep driver firmware interface agnostic
  leds: core: Refactor led_update_brightness() to use standard pattern
  leds: turris-omnia: Fix brightness setting and trigger activating
  leds: sc27xx: Move mutex_init() down
  leds: trigger: netdev: Move size check in set_device_name
  leds: Add ktd202x driver
  dt-bindings: leds: Add Kinetic KTD2026/2027 LED
  leds: core: Add more colors from DT bindings to led_colors
  dt-bindings: leds: Last color ID is now 14 (LED_COLOR_ID_LIME)
  leds: tca6507: Don't use fixed GPIO base
  leds: lp3952: Convert to use maple tree register cache
  leds: lm392x: Convert to use maple tree register cache
  leds: aw200xx: Convert to use maple tree register cache
  leds: lm3601x: Convert to use maple tree register cache
  ...

leds: lp5521: Add an error check in lp5521_post_init_device

2023-11-01T11:29:26+00:00

lp55xx_write() can return an error code, add a check for this.

Signed-off-by: Su Hui 
Link: https://lore.kernel.org/r/20231020091930.207870-1-suhui@nfschina.com
Signed-off-by: Lee Jones

leds: gpio: Update headers

2023-11-01T11:29:24+00:00

Include headers which we are direct users of, no need
to have proxies.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231016161005.1471768-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones

leds: gpio: Remove unneeded assignment

2023-11-01T11:29:23+00:00

The initial ret is not used anywhere, drop the unneeded assignment.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231016161005.1471768-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones

leds: gpio: Move temporary variable for struct device to gpio_led_probe()

2023-11-01T11:29:22+00:00

Use temporary variable for struct device in gpio_led_probe() in order
to make code neater.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231016161005.1471768-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones

leds: gpio: Refactor code to use devm_gpiod_get_index_optional()

2023-11-01T11:29:21+00:00

Instead of checking for the specific error codes, replace
devm_gpiod_get_index() with devm_gpiod_get_index_optional().
In this case we just return all errors to the caller and
simply check for NULL in case if legacy GPIO is being used.
As the result the code is easier to read and maintain.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231016161005.1471768-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones

leds: gpio: Utilise PTR_ERR_OR_ZERO()

2023-11-01T11:29:20+00:00

Avoid a boilerplate code by using PTR_ERR_OR_ZERO() in create_gpio_led().

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20231016161005.1471768-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones