Use gpiod_set_value_cansleep in the init_device function. Without this
change, the driver may print a warning if the LP55xx enable pin is
connected to a GPIO chip which can sleep (e.g. a GPIO expander):
WARNING: CPU: 0 PID: 2719 at drivers/gpio/gpiolib.c:3051 gpiod_set_value+0x64/0xbc
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Link: https://lore.kernel.org/r/20230918143238.75600-1-eichest@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mt6370_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230915201051.never.429-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mt6360_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230915201020.never.433-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
All platform drivers below drivers/leds/ unconditionally return zero in
their remove callback and so can be converted trivially to the variant
returning void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230917130947.1122198-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Make simatic_ipc_leds_gpio_remove() return void instead of returning
zero unconditionally. After that the three remove callbacks that use
this function were trivial to convert to return void, too.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230916164516.1063380-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct lpg_led.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201059.never.086-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct lm3697.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201010.never.399-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct gpio_leds_priv.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915201003.never.148-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct el15203000.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200955.never.871-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct cr0014114.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200948.never.728-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct aw200xx.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230915200938.never.767-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
When building with clang 18 I see the following warning:
| drivers/leds/leds-pca955x.c:487:15: warning: cast to smaller integer
| type 'enum pca955x_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
| 487 | chip_type = (enum pca955x_type)md;
This is due to the fact that `md` is a void* while `enum pca995x_type` has the
size of an int.
Add uintptr_t cast to silence clang warning while also keeping enum cast
for readability and consistency with other `chip_type` assignment just a
few lines below:
| chip_type = (enum pca955x_type)id->driver_data;
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://github.com/ClangBuiltLinux/linux/issues/1910
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20230816-void-drivers-leds-leds-pca955x-v1-1-2967e4c1bdcc@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new low level drivers cannot forget the assignment and
save one line each. The pwm-crc driver didn't assign .owner, that's not
a problem in practice though as the driver cannot be compiled as a
module.
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # Intel LPSS
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # pwm-{bcm,brcm}*.c
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> # sun4i
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # pwm-visconti
Acked-by: Heiko Stuebner <heiko@sntech.de> # pwm-rockchip
Acked-by: Michael Walle <michael@walle.cc> # pwm-sl28cpld
Acked-by: Neil Armstrong <neil.armstrong@linaro.org> # pwm-meson
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230804142707.412137-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Commit c3f853184b ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that
is always false") fixed a no-op BUG_ON. This turned out to cause a
regression, since some in-tree device-tree files already use
LED_COLOR_ID_MULTI.
Drop the BUG_ON altogether.
Fixes: c3f853184b ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false")
Reported-by: Da Xue <da@libre.computer>
Closes: https://lore.kernel.org/linux-leds/ZQLelWcNjjp2xndY@duo.ucw.cz/T/
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230918140724.18634-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
- Add new framework to support Group Multi-Color (GMC) LEDs
- Offer an 'optional' API for non-essential LEDs
- Support obtaining 'max brightness' values from Device Tree
- Provide new led_classdev member 'color' (settable via DT and SYFS)
- Stop TTY Trigger from using the old LED_ON constraints
- Statically allocate leds_class
- New Drivers
- Add support for NXP PCA995x I2C Constant Current LED Driver
- New Device Support
- Add support for Siemens Simatic IPC BX-21 to Simatic IPC
- Fix-ups
- Some dependency / Kconfig tweaking
- Move final probe() functions back over from .probe_new()
- Simplify obtaining resources (memory, device data) using unified API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Fix trivial styling issues; comments
- Ensure correct includes are present and remove some that are not required
- Omit the use of redundant casts and if relevant replace with better ones
- Use purpose-built APIs for various actions; sysfs_emit(), module_led_trigger()
- Remove a bunch of superfluous locking
- Bug Fixes
- Ensure error codes are correctly propagated back up the call chain
- Fix incorrect error values from being returned (missing '-')
- Ensure get'ed resources are put'ed to prevent leaks
- Use correct class when exporting module resources
- Fixing rounding (or lack there of) issues
- Fix 'always false' LED_COLOR_ID_MULTI BUG() check
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmT15DUACgkQUa+KL4f8
d2ER0BAAoejCCnb24JOrYQy7Pq3/ZaaT6PWOB+/U+6s5jyj9ikwHqqH+g/E+FqkE
AHvhkBalgw1l+QRCvrZMEcsiQmjK5ZR010Ju3lCbvUDa1tsm2Fn/K2IZZxI1j9O8
mGnPjYrX3FRfejscw0a+MA75o3DuN97V9mHNk6lyRnm/d0ronu+vv/fRYFON04iY
v2e166/9wfJWvDwOLo+phDS2aCkjLkxzj2lcTtcvuzYqQjOPDqiFTJsft9gOpC9r
hKOqUkexKebShbi08A+x0fmiB9LNs5kZ3xWWLaxVDT58Plkqv905oLVrWARTGhIG
BDAhW2/TLV30bhSiTb/bX0eNEMCU6q6WIPwc3otUYpkDeLgbxLD7Rlhp49oud7j9
5vWX8bxSczIYRir42TKZ+s/d6pKKSvMrsNRDplFb1ahZTv3ssDxuxAA/FY2UPqTt
C83j0hJOwVfj6ric01R+yedPSW8Po8xqEIzjoxzYtsu3IYGiz6ddjd2ZnhNF5YfP
AN7GDuja9r7+Fa8JcTFssHe6HtuzkfpJvrpjV3BxL79q6s1z+lT9szTw5Z65zGmO
k/z4xz95RHUTbpR4rVT+A1pdbQ8OsbVthdy1XnJoYK3NJYJrPldj3Ur3W4wRecP6
32RWF8ZF6WARsSyyACLo/MP6qxwAE2xk5TjmpLqCeK0ObVmlwDM=
=wNmv
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- Add new framework to support Group Multi-Color (GMC) LEDs
- Offer an 'optional' API for non-essential LEDs
- Support obtaining 'max brightness' values from Device Tree
- Provide new led_classdev member 'color' (settable via DT and SYFS)
- Stop TTY Trigger from using the old LED_ON constraints
- Statically allocate leds_class
New Drivers:
- Add support for NXP PCA995x I2C Constant Current LED Driver
New Device Support:
- Add support for Siemens Simatic IPC BX-21 to Simatic IPC
Fix-ups:
- Some dependency / Kconfig tweaking
- Move final probe() functions back over from .probe_new()
- Simplify obtaining resources (memory, device data) using unified
API helpers
- Bunch of Device Tree additions, conversions and adaptions
- Fix trivial styling issues; comments
- Ensure correct includes are present and remove some that are not
required
- Omit the use of redundant casts and if relevant replace with better
ones
- Use purpose-built APIs for various actions; sysfs_emit(),
module_led_trigger()
- Remove a bunch of superfluous locking
Bug Fixes:
- Ensure error codes are correctly propagated back up the call chain
- Fix incorrect error values from being returned (missing '-')
- Ensure get'ed resources are put'ed to prevent leaks
- Use correct class when exporting module resources
- Fixing rounding (or lack there of) issues
- Fix 'always false' LED_COLOR_ID_MULTI BUG() check"
* tag 'leds-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (40 commits)
leds: aw2013: Enable pull-up supply for interrupt and I2C
dt-bindings: leds: Document pull-up supply for interrupt and I2C
dt-bindings: leds: aw2013: Document interrupt
leds: uleds: Use module_misc_device macro to simplify the code
leds: trigger: netdev: Use module_led_trigger macro to simplify the code
dt-bindings: leds: Fix reference to definition of default-state
leds: turris-omnia: Drop unnecessary mutex locking
leds: turris-omnia: Use sysfs_emit() instead of sprintf()
leds: Make leds_class a static const structure
leds: Remove redundant of_match_ptr()
dt-bindings: leds: Add gpio-line-names to PCA9532 GPIO
leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead
dt-bindings: leds: rohm,bd71828: Drop select:false
leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false
leds: multicolor: Use rounded division when calculating color components
leds: rgb: Add a multicolor LED driver to group monochromatic LEDs
dt-bindings: leds: Add binding for a multicolor group of LEDs
leds: class: Store the color index in struct led_classdev
leds: Provide devm_of_led_get_optional()
leds: pca995x: Fix MODULE_DEVICE_TABLE for OF
...
Highlights:
- hp-bioscfg: New firmware-attributes driver for changing BIOS settings
from within Linux
- asus-wmi: Add charger mode, middle fan and eGPU settings support
- ideapad: Support keyboard backlight control on more models
- mellanox: Support for new models
- sel-3350: New LED and power-supply driver for this industrial mainboard
- simatic-ipc: Add RTC battery monitor and various new models support
- Miscellaneous other cleanups / fixes
The following is an automated git shortlog grouped by driver:
Add SEL-3350 platform driver:
- Add SEL-3350 platform driver
Documentation/ABI:
- Add new attribute for mlxreg-io sysfs interfaces
MAINTAINERS:
- Add entries for Siemens IPC modules
Merge remote-tracking branch 'intel-speed-select/intel-sst' into review-hans:
- Merge remote-tracking branch 'intel-speed-select/intel-sst' into review-hans
Merge remote-tracking branch 'pdx86/fixes' into pdx86/for-next:
- Merge remote-tracking branch 'pdx86/fixes' into pdx86/for-next
Merge remote-tracking branch 'pdx86/platform-drivers-x86-simatic-ipc' into review-hans:
- Merge remote-tracking branch 'pdx86/platform-drivers-x86-simatic-ipc' into review-hans
Merge tag 'ib-pdx86-simatic-v6.6' into review-hans:
- Merge tag 'ib-pdx86-simatic-v6.6' into review-hans
Merge tag 'ib-pdx86-simatic-v6.6-2' into review-hans:
- Merge tag 'ib-pdx86-simatic-v6.6-2' into review-hans
Move all simatic ipc drivers to the subdirectory siemens:
- Move all simatic ipc drivers to the subdirectory siemens
asus-wmi:
- corrections to egpu safety check
- Fix support for showing middle fan RPM
- expose dGPU and CPU tunables for ROG
- support setting mini-LED mode
- add safety checks to gpu switching
- don't allow eGPU switching if eGPU not connected
- add WMI method to show if egpu connected
- support middle fan custom curves
- add support for showing middle fan RPM
- add support for showing charger mode
dell-sysman:
- Fix reference leak
doc:
- TPMI: Add debugfs documentation
hp-bioscfg:
- Update steps order list elements are evaluated
- Use kmemdup() to replace kmalloc + memcpy
- Remove duplicate use of variable in inner loop
- Change how password encoding size is evaluated
- Change how enum possible values size is evaluated
- Change how order list size is evaluated
- Change how prerequisites size is evaluated
- Replace the word HACK from source code
- Fix uninitialized variable errors
- Fix memory leaks in attribute packages
- fix error reporting in hp_add_other_attributes()
- prevent a small buffer overflow
- fix a signedness bug in hp_wmi_perform_query()
- MAINTAINERS
- Makefile
- surestart-attributes
- string-attributes
- spmobj-attributes
- passwdobj-attributes
- order-list-attributes
- int-attributes
- enum-attributes
- biosattr-interface
- bioscfg
- bioscfg-h
- Documentation
ideapad-laptop:
- Add support for keyboard backlights using KBLC ACPI symbol
leds:
- simatic-ipc-leds: default config switch to platform switch
mlx-platform:
- Add dependency on PCI to Kconfig
mlxbf-bootctl:
- Support sysfs entries for MFG fields
- Support setting the ARM boot state to "OS up"
- Support the large icmc write/read
p2sb:
- Make the Kconfig symbol hidden
platform:
- mellanox: nvsw-sn2201: change fans i2c busses.
- mellanox: mlxreg-hotplug: Extend condition for notification callback processing
- mellanox: Add initial support for PCIe based programming logic device
- mellanox: mlx-platform: Get interrupt line through ACPI
- mellanox: mlx-platform: Introduce ACPI init flow
- mellanox: mlx-platform: Prepare driver to allow probing through ACPI infrastructure
- mellanox: mlx-platform: Add reset callback
- mellanox: Cosmetic changes
- mellanox: mlx-platform: Modify power off callback
- mellanox: mlx-platform: add support for additional CPLD
- mellanox: mlx-platform: Add reset cause attribute
- mellanox: mlx-platform: Modify health and power hotplug action
- mellanox: Modify reset causes description
- mellanox: Add field upgrade capability register
- mellanox: Add new attributes
- Explicitly include correct DT includes
platform/x86/amd/pmc:
- Fix build error with randconfig
- Move PMC driver to separate directory
platform/x86/amd/pmf:
- Fix a missing cleanup path
- Use str_on_off() helper
platform/x86/intel/tpmi:
- Add debugfs interface
- Read feature control status
platform/x86/siemens:
- simatic-ipc-batt: fix logical error for BX-59A
- simatic-ipc: fix logical error for BX-59A
- simatic-ipc-batt: fix wrong pointer pass to PTR_ERR()
- simatic-ipc-batt: add support for module BX-59A
- simatic-ipc: add new models BX-56A/BX-59A
- Kconfig: adjust help text
- simatic-ipc-batt: fix bat reading in BX_21A
simatic-ipc:
- use extra module loading for watchdog
- add auto-loading of hwmon modules
- add another model
- drop PCI runtime depends and header
- add CMOS battery monitoring
- add another model BX-21A
system76:
- Handle new KBLED ACPI methods
thinkpad_acpi:
- Switch to memdup_user_nul() helper
- use lockdep annotations
- take mutex for hotkey_mask_{set,get}
tools/power/x86/intel-speed-select:
- v1.17 release
- Change mem-frequency display name
- Prevent CPU 0 offline
- Error on CPU count exceed in request
- Support more than 8 sockets.
- Fix CPU count display
watchdog:
- simatic: Use idiomatic selection of P2SB
- simatic: add PCI dependency
- make Siemens Simatic watchdog driver default on platform
- simatic-ipc-wdt: make IO region access of one model muxed
wmi-bmof:
- Update MAINTAINERS entry
- Simplify read_bmof()
- Use device_create_bin_file()
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmTx720UHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9wHYggAgPpl4tcbqUK7S/fwVP2SzBKI+eF3
5PjO7PlMEVzyKyjHdkqoV8miMffWAGVPE+LV33Uifs5WTFjHRq2fq/Esvj9mAstG
1fCoHJ442xYkwNCUT1CCP7VsmcvV5eFXBjBantvwmIs8TyknGHwtq1h+d95evp4n
2uyQlRMmrWh/+8fjD8x5V35T0tky+4a4EX2WNLul13LlHCybGT/F2Kq456WdthjJ
zTQSL+qAMWmAiQKSEmhI3bRnFYPdpTetjiNSTlQczch8Y4qV3mJQlnkyDPX7SM9w
M2uZ4W39Ptxihx0ks/MIcuA4yrTfUX8BnhMTD29ZYCKHS7xBqW8YC5HQug==
=GaQL
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver updates from Hans de Goede:
- hp-bioscfg: New firmware-attributes driver for changing BIOS settings
from within Linux
- asus-wmi: Add charger mode, middle fan and eGPU settings support
- ideapad: Support keyboard backlight control on more models
- mellanox: Support for new models
- sel-3350: New LED and power-supply driver for this industrial
mainboard
- simatic-ipc: Add RTC battery monitor and various new models support
- miscellaneous other cleanups / fixes
* tag 'platform-drivers-x86-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (101 commits)
platform/x86: asus-wmi: corrections to egpu safety check
platform/x86: mlx-platform: Add dependency on PCI to Kconfig
platform/x86: ideapad-laptop: Add support for keyboard backlights using KBLC ACPI symbol
platform/x86/amd/pmc: Fix build error with randconfig
platform/x86/amd/pmf: Fix a missing cleanup path
watchdog: simatic: Use idiomatic selection of P2SB
platform/x86: p2sb: Make the Kconfig symbol hidden
Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces
platform: mellanox: nvsw-sn2201: change fans i2c busses.
platform: mellanox: mlxreg-hotplug: Extend condition for notification callback processing
platform: mellanox: Add initial support for PCIe based programming logic device
platform: mellanox: mlx-platform: Get interrupt line through ACPI
platform: mellanox: mlx-platform: Introduce ACPI init flow
platform: mellanox: mlx-platform: Prepare driver to allow probing through ACPI infrastructure
platform: mellanox: mlx-platform: Add reset callback
platform: mellanox: Cosmetic changes
platform: mellanox: mlx-platform: Modify power off callback
platform: mellanox: mlx-platform: add support for additional CPLD
platform: mellanox: mlx-platform: Add reset cause attribute
platform: mellanox: mlx-platform: Modify health and power hotplug action
...
Commit b655892ffd ("leds: trigger: netdev: expose hw_control status
via sysfs") exposed to sysfs the flag that tells whether the LED trigger
is offloaded to hardware, under the name "hw_control", since that is the
name under which this setting is called in the code.
Everywhere else in kernel when some work that is normally done in
software can be made to be done by hardware instead, we use the word
"offloading" to describe this, e.g. "LED blinking is offloaded to
hardware".
Normally renaming sysfs entries is a no-go because of backwards
compatibility. But since this patch was not yet released in a stable
kernel, I think it is still possible to rename it, if there is
consensus.
Fixes: b655892ffd ("leds: trigger: netdev: expose hw_control status via sysfs")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230821121453.30203-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Request and enable the "vio" regulator that represents the power supply
that is needed for the pull-up resistors of the interrupt and I2C lines
of AW2013. While this regulator is not wired directly to the AW2013
chip it is best managed as part of the AW2013 driver since it decides
when AW2013 is powered on and when the interrupt is enabled or
disabled.
This regulator should always be enabled in conjunction with the main
VCC power supply, so use the bulk regulator functions to enable both
at the same time.
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
[rewrite commit message based on discussion]
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20230815-aw2013-vio-v3-3-2505296b0856@gerhold.net
Signed-off-by: Lee Jones <lee@kernel.org>
Use the module_misc_device macro to simplify the code, which is the
same as declaring with module_init() and module_exit().
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230815075944.1089298-3-lizetao1@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use the module_led_trigger macro to simplify the code, which is the
same as declaring with module_init() and module_exit().
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230815075944.1089298-2-lizetao1@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
Do not lock driver mutex in the global LED panel brightness sysfs
accessors brightness_show() and brightness_store().
The mutex locking is unnecessary here. The I2C transfers are guarded by
I2C core locking mechanism, and the LED commands itself do not interfere
with other commands.
Fixes: 089381b27a ("leds: initial support for Turris Omnia LEDs")
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230802160748.11208-2-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Use the dedicated sysfs_emit() function instead of sprintf() in sysfs
attribute accessor brightness_show().
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230802160748.11208-4-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Now that the driver core allows for struct class to be in read-only
memory, move the leds_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Link: https://lore.kernel.org/r/20230810174905.7997-1-ivan.orlov0322@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The driver depends on CONFIG_OF, so it is not necessary to use
of_match_ptr() here. We remove both CONFIG_OF and of_match_ptr() here.
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Link: https://lore.kernel.org/r/20230808111108.24262-1-wangzhu9@huawei.com
Signed-off-by: Lee Jones <lee@kernel.org>
The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when
setting LED brightness. This is bad because the LED_ON constant is equal
to 1, and so when activating the tty LED trigger on a LED class device
with max_brightness greater than 1, the LED is dimmer than it can be
(when max_brightness is 255, the LED is very dimm indeed; some devices
translate 1/255 to 0, so the LED is OFF all the time).
Instead of directly setting brightness to a specific value, use the
led_blink_set_oneshot() function from LED core to configure the blink.
This function takes the current configured brightness as blink
brightness if not zero, and max brightness otherwise.
This also changes the behavior of the TTY LED trigger. Previously if
rx/tx stats kept changing, the LED was ON all the time they kept
changing. With this patch the LED will blink on TTY activity.
Fixes: fd4a641ac8 ("leds: trigger: implement a tty trigger")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230802090753.13611-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
At the time we call
BUG_ON(props.color == LED_COLOR_ID_MULTI);
the props variable is still initialized to zero.
Call the BUG_ON only after we parse fwnode into props.
Fixes: 77dce3a22e ("leds: disallow /sys/class/leds/*:multi:* for now")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230801151623.30387-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Given channel intensity, LED brightness and max LED brightness, the
multicolor LED framework helper led_mc_calc_color_components() computes
the color channel brightness as
chan_brightness = brightness * chan_intensity / max_brightness
Consider the situation when (brightness, intensity, max_brightness) is
for example (16, 15, 255), then chan_brightness is computed to 0
although the fractional divison would give 0.94, which should be rounded
to 1.
Use DIV_ROUND_CLOSEST here for the division to give more realistic
component computation:
chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity,
max_brightness)
Fixes: 55d5d3b46b ("leds: multicolor: Introduce a multicolor class definition")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20230801124931.8661-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Grouping multiple monochrome LEDs into a multicolor LED device has a few
benefits over handling the group in user-space:
- The state of the LEDs relative to each other is consistent. In other
words, if 2 threads competes to set the LED to green and red, the
end-result cannot be black or yellow.
- The multicolor LED as a whole can be driven through the sysfs LED
interface.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Reviewed-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230728153731.3742339-5-jjhiblot@traphandler.com
Signed-off-by: Lee Jones <lee@kernel.org>
Store the color of the LED so that it is not lost after the LED's
name has been composed. This color information can then be exposed to
the user space or used by the LED consumer.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add an optional variant of devm_of_led_get(). It behaves the same as
devm_of_led_get() except where the LED doesn't exist. In this case,
instead of returning -ENOENT, the function returns NULL.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com
Signed-off-by: Lee Jones <lee@kernel.org>
Fix copy-paste error in MODULE_DEVICE_TABLE() for the OF table,
use the 'of' first parameter instead of duplicate 'i2c'.
Fixes: ee4e80b296 ("leds: pca995x: Add support for PCA995X chips")
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230809125314.531806-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
Ensure that the offloading of blinking is stopped when the trigger is
deactivated. Calling led_set_brightness() is documented as stopping
offload and setting the LED to a constant brightness.
Suggested-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-5-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When the netdev trigger is activates, it tries to determine what
device the LED blinks for, and what the current blink mode is.
The documentation for hw_control_get() says:
* Return 0 on success, a negative error number on failing parsing the
* initial mode. Error from this function is NOT FATAL as the device
* may be in a not supported initial state by the attached LED trigger.
*/
For the Marvell PHY and the Armada 370-rd board, the initial LED blink
mode is not supported by the trigger, so it returns an error. This
resulted in not getting the device the LED is blinking for. As a
result, the device is unknown and offloaded is never performed.
Change to condition to always get the device if offloading is
supported, and reduce the scope of testing for an error from
hw_control_get() to skip setting trigger internal state if there is an
error.
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/20230808210436.838995-2-andrew@lunn.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If a user did choose to enable Siemens Simatic platform support they
likely want the LED drivers to be enabled without having to flip more
config switches. So we make the LED drivers config switch default to
the platform driver switches value.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230719153518.13073-3-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Since commit f9a8ee8c8b ("pwm: Always allocate PWM chip base ID
dynamically") there is no effect any more for assigning this variable. See
pwmchip_add() which unconditionally overwrites this member.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230728065739.580281-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174651.4058753-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Symbol ARCH_BCM4908 has been merged/removed without updating leds
Kconfig.
Fixes: dd5c672d7c ("arm64: bcmbca: Merge ARCH_BCM4908 to ARCH_BCMBCA")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: William Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20230714063214.3791-1-zajec5@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This is used for the Siemens Simatic IPC BX-21A, which has its LEDs
connected to GPIOs provided by the Intel Elkhart Lake pinctrl driver.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20230713115639.16419-3-henning.schild@siemens.com
Signed-off-by: Lee Jones <lee@kernel.org>
The PCA995x chips are I2C controlled LED drivers. Each chip has
up to 16 outputs, each one with an individual 8-bit resolution
PWM for brightness control.
Signed-off-by: Isai Gaspar <isaiezequiel.gaspar@nxp.com>
Signed-off-by: Marek Vasut <marex@denx.de> # Basically rewrite the driver
Link: https://lore.kernel.org/r/20230713163516.21644-2-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
Negative -EINVAL was intended, not positive EINVAL. Fix it.
Fixes: 95138e0127 ("leds: pwm: Make error handling more robust")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/a33b981a-b2c4-4dc2-b00a-626a090d2f11@moroto.mountain
Signed-off-by: Lee Jones <lee@kernel.org>
Normally, the maximum brightness is determined by the hardware, and this
property is not required. This property is used to set a software limit.
It could happen that an LED is made so bright that it gets damaged or
causes damage due to restrictions in a specific system, such as mounting
conditions.
Note that this flag is mainly used for PWM-LEDs, where it is not possible
to map brightness to current. Drivers for other controllers should use
led-max-microamp.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Astrid Rost <astrid.rost@axis.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20230703130313.548519-3-astrid.rost@axis.com
Signed-off-by: Lee Jones <lee@kernel.org>
A recent rework accidentally lost the dependency on LEDS_CLASS, which
leads to a link error when LED support is disbled:
x86_64-linux-ld: drivers/leds/simple/simatic-ipc-leds.o: in function `simatic_ipc_leds_probe':
simatic-ipc-leds.c:(.text+0x10c): undefined reference to `devm_led_classdev_register_ext'
Add back the dependency that was there originally.
Fixes: a6c80bec3c ("leds: simatic-ipc-leds-gpio: Add GPIO version of Siemens driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230623152233.2246285-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
- New Device Support
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
- New Functionality
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
- Fix-ups
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
- Bug Fixes
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmSinb0ACgkQUa+KL4f8
d2FYfg//WWLVfXRuRpY9ueOxvWj65WVPQSQ+wzF/vRTweogR+lN0qxNPH6yT943z
ap2EBxpWf84zCifYG4yhTEYDHQT+nH1fIz6xaK29DK8sCQi4WdRpHuE2pE30R/tf
Q7SyZi9DlWyoqNiqgNNCl7vkTaHpO3trxoxfEfN2YIB0npLf8yyWRz4feVXXsYtg
41S4Mo7oTxphd7OLvw9PKogdTbT29vBMXen8jzv5g8FObj1Gheg0frq2t2W+bfAl
27cJJJS7he4/WLCDzXVQfB46Nva5NpqHiANbgOAApDGx3hFCzZFTCg6K7+VucpjY
bNz3pqmslT5uJxMjqNz8fCSzwWTjyKLHBeGsIT/4HBXD4DnfFbWz9HYkorfNgsu2
lKEp0SYhSmmuS8IVzJvqDqXg6k21hGpuR9P+dI7teoClh0qLTMCz2L2c9p2zNfth
0W+WeLYQ67QTRH9EcHo3dlZH/mP/J1jGmUDbF+DFI6bHsg2iahZUA6ixD18E7sWE
RwtCnb3xyn7eoDe3LwJdKtJMyrX59MbFWqozij2NNhvduXc+m1kH/DX5CSaBUVwf
RtfDZwWHf4qK4CipuuqOLd5fiUArJ3TSHBxXkoo0Wz7NYXK9k86eIZgWrgdEbvuA
oHmSousS19Eiscjtzxl7OjvDJMRc0rTJfD7LzYoHQBL4Vpnd8VI=
=9kd5
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"New Drivers:
- Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs
- Add support for Awinic AW20036/AW20054/AW20072 LEDs
New Device Support:
- Add support for PMI632 LPG to QCom LPG
- Add support for PMI8998 to QCom Flash
- Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC
New Functionality:
- Implement the LP55xx Charge Pump
- Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC
- Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC
- Enable per-pin resolution Pinctrl in LEDs GPIO
Fix-ups:
- Allow thread to sleep by switching from spinlock to mutex
- Add lots of Device Tree bindings / support
- Adapt relationships / dependencies driven by Kconfig
- Switch I2C drivers from .probe_new() to .probe()
- Remove superfluous / duplicate code
- Replace strlcpy() with strscpy() for efficiency and overflow prevention
- Staticify various functions
- Trivial: Fixing coding style
- Simplify / reduce code
Bug Fixes:
- Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename
- Repair race between led_set_brightness(LED_{OFF,FULL})
- Fix Oops relating to sleeping in critical sections
- Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger
- Do not leak resources in error handling paths
- Fix unsigned comparison which can never be negative
- Provide missing NULL terminating entries in tables
- Fix misnaming issues"
* tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits)
leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks
leds: sgm3140: Add richtek,rt5033-led compatible
dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible
dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks"
dt-bindings: leds: Drop unneeded quotes
leds: Fix config reference for AW200xx driver
leds: leds-mt6323: Add support for WLEDs and MT6332
leds: leds-mt6323: Add support for MT6331 leds
leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro
leds: leds-mt6323: Drop MT6323_ prefix from macros and defines
leds: leds-mt6323: Specify registers and specs in platform data
dt-bindings: leds: leds-mt6323: Document mt6332 compatible
dt-bindings: leds: leds-mt6323: Document mt6331 compatible
leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches
leds: simatic-ipc-leds-gpio: Split up into multiple drivers
leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table
leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables
leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative
leds: cht-wcove: Remove unneeded semicolon
leds: cht-wcove: Fix an unsigned comparison which can never be negative
...
Clang's kernel Control Flow Integrity (kCFI) is a compiler-based
security mitigation that ensures the target of an indirect function call
matches the expected type of the call and trapping if they do not match
exactly. The warning -Wincompatible-function-pointer-types-strict aims
to catch these issues at compile time, which reveals:
drivers/leds/leds-mt6323.c:598:49: error: incompatible function pointer types assigning to 'int (*)(struct led_classdev *, enum led_brightness)' from 'int (struct led_classdev *, unsigned int)' [-Werror,-Wincompatible-function-pointer-types-strict]
598 | leds->led[reg]->cdev.brightness_set_blocking =
| ^
599 | mt6323_wled_set_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/leds/leds-mt6323.c:600:40: error: incompatible function pointer types assigning to 'enum led_brightness (*)(struct led_classdev *)' from 'unsigned int (struct led_classdev *)' [-Werror,-Wincompatible-function-pointer-types-strict]
600 | leds->led[reg]->cdev.brightness_get =
| ^
601 | mt6323_get_wled_brightness;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
While 'unsigned int' is ABI compatible with 'enum led_brightness' (hence
no warning from -Wincompatible-function-pointer-types) and the callers
of these callbacks use/pass the values as 'unsigned int', the mismatch
between the prototype and the called function will trip kCFI at runtime.
Change the types in the implementations to match the prototypes, clearing
up the warning and avoiding kCFI failures.
Fixes: 9bb0a9e062 ("leds: leds-mt6323: Add support for WLEDs and MT6332")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230622-mt6323-wled-wincompatible-function-pointer-types-strict-v1-1-6ad256f220e8@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Expose hw_control status via sysfs for the netdev trigger to give
userspace better understanding of the current state of the trigger and
the LED.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add additional modes for specific link duplex. Use ethtool APIs to get the
current link duplex and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link duplex.
Add additional modes:
- half_duplex: Turn on LED when link is half duplex
- full_duplex: Turn on LED when link is full duplex
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add additional modes for specific link speed. Use ethtool APIs to get the
current link speed and enable the LED accordingly. Under netdev event
handler the rtnl lock is already held and is not needed to be set to
access ethtool APIs.
This is especially useful for PHY and Switch that supports LEDs hw
control for specific link speed. (example scenario a PHY that have 2 LED
connected one green and one orange where the green is turned on with
1000mbps speed and orange is turned on with 10mpbs speed)
On mode set from sysfs we check if we have enabled split link speed mode
and reject enabling generic link mode to prevent wrong and redundant
configuration.
Rework logic on the set baseline state to support these new modes to
select if we need to turn on or off the LED.
Add additional modes:
- link_10: Turn on LED when link speed is 10mbps
- link_100: Turn on LED when link speed is 100mbps
- link_1000: Turn on LED when link speed is 1000mbps
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 36a87f371b ("leds: Add AW20xx driver") adds config LEDS_AW200XX
in drivers/leds/Kconfig, but then in drivers/leds/Makefile accidently
refers to CONFIG_LEDS_W200XX; note the missing A!
This typo makes it impossible to add the driver to a kernel build.
Fix this wrong config reference.
Fixes: 36a87f371b ("leds: Add AW20xx driver")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20230609100233.4111-1-lukas.bulwahn@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The qca8k_cled_hw_control_get() function which implements ->hw_control_get
sets the appropriate bits but does not clear them. This leads to an
uninitialized variable bug. Fix this by setting mode to zero at the
start.
Fixes: e0256648c8 ("net: dsa: qca8k: implement hw_control ops")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add basic code to turn on and off WLEDs and wire up MT6332 support
to take advantage of it.
This is a simple approach due to the aforementioned PMIC supporting
only on/off status so, at the time of writing, it is impossible for me
to validate more advanced functionality due to lack of hardware.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230601110813.2373764-9-angelogioacchino.delregno@collabora.com
Add the register offsets for MT6331. The hwspec is the same as MT6323.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230601110813.2373764-8-angelogioacchino.delregno@collabora.com
There is only one instance of using this macro and it's anyway not
simplifying the flow, or increasing the readability of this driver.
Drop this macro by open coding it in mt6323_led_set_blink().
No functional changes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230601110813.2373764-7-angelogioacchino.delregno@collabora.com
This renames all definitions and macros to drop the MT6323_ prefix,
since it is now possible to easily add support to more PMICs in
this driver.
While at it, also fix related formatting where possible.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230601110813.2373764-6-angelogioacchino.delregno@collabora.com
In order to enhance the flexibility of this driver and let it support
more than just one MediaTek LEDs IP for more than just one PMIC,
add platform data structure specifying the register offsets and
data that commonly varies between different IPs.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230601110813.2373764-5-angelogioacchino.delregno@collabora.com
Cross-merge networking fixes after downstream PR.
Conflicts:
net/sched/sch_taprio.c
d636fc5dd6 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping")
dced11ef84 ("net/sched: taprio: don't overwrite "sch" variable in taprio_dump_class_stats()")
net/ipv4/sysctl_net_ipv4.c
e209fee411 ("net/ipv4: ping_group_range: allow GID from 2147483648 to 4294967294")
ccce324dab ("tcp: make the first N SYN RTO backoffs linear")
https://lore.kernel.org/all/20230605100816.08d41a7b@canb.auug.org.au/
No adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
To describe the dependency chain better and allow for potential
fine-grained config tuning, introduce Kconfig switch for the individual
GPIO based drivers.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-5-henning.schild@siemens.com
In order to clearly describe the dependencies between the GPIO
controller drivers and the users the driver is split up into a core,
two drivers and a common header.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-4-henning.schild@siemens.com
There are two special pins needed to init the LEDs. We used to have them
at the end of the gpiod_lookup table to give to "leds-gpio". A cleaner
way is to have a dedicated table for the special pins.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-3-henning.schild@siemens.com
The entries do not seem to be stricly needed when the number of entries
is given via the number of LEDs. But adding them is a safeguard should
anyone ever iterate over the tables to their end, it also gets us in
line with other drivers that register "leds-gpio" tables.
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230524124628.32295-2-henning.schild@siemens.com
The variable 'count' is defined as unsigned type, so the following if
statement is invalid, we can modify the type of count to int.
if (count <= 0) {
dev_err(dev, "No led-sources specified\n");
return -ENODEV;
}
./drivers/leds/flash/leds-qcom-flash.c:546:5-10: WARNING: Unsigned expression compared with zero: count <= 0.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5344
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230531053559.5702-1-jiapeng.chong@linux.alibaba.com
The return value from the call to cht_wc_leds_find_freq() is int.
However, the return value is being assigned to an unsigned
int variable 'ctrl', so making it an int.
Eliminate the following warning:
drivers/leds/leds-cht-wcove.c:236 cht_wc_leds_set_effect() warn: unsigned 'ctrl' is never less than zero.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5341
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230531020238.102684-1-yang.lee@linux.alibaba.com
The introduction of high resolution PWM support changed the order of the
operations in the calculation of min and max period. The result in both
divisions is in most cases a truncation to 0, which limits the period to
the range of [0, 0].
Both numerators (and denominators) are within 64 bits, so the whole
expression can be put directly into the div64_u64, instead of doing it
partially.
Fixes: b00d2ed376 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Acked-by: Lee Jones <lee@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Link: https://lore.kernel.org/r/20230515162604.649203-1-quic_bjorande@quicinc.com
Signed-off-by: Johan Hovold <johan@kernel.org>
This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver.
This driver supports following AW200XX features:
- Individual 64-level DIM currents
Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ru
Signed-off-by: Lee Jones <lee@kernel.org>
Expose netdev trigger modes to make them accessible by LED driver that
will support netdev trigger for hw control.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
On netdev trigger activation, hw control may be already active by
default. If this is the case and a device is actually provided by
hw_control_get_device(), init the already active mode and set the
bool to hw_control bool to true to reflect the already set mode in the
trigger_data.
Co-developed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The netdev which the LED should blink for is configurable in
/sys/class/led/foo/device_name. Ensure when offloading that the
configured netdev is the same as the netdev the LED is associated
with. If it is not, only perform software blinking.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for LED hw control for the netdev trigger.
The trigger on calling set_baseline_state to configure a new mode, will
do various check to verify if hw control can be used for the requested
mode in can_hw_control() function.
It will first check if the LED driver supports hw control for the netdev
trigger, then will use hw_control_is_supported() and finally will call
hw_control_set() to apply the requested mode.
To use such mode, interval MUST be set to the default value and net_dev
MUST be set. If one of these 2 value are not valid, hw control will
never be used and normal software fallback is used.
The default interval value is moved to a define to make sure they are
always synced.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reject interval store with hw_control enabled. It's are currently not
supported and MUST be set to the default value with hw control enabled.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add basic check for hw control support. Check if the required API are
defined and check if the defined trigger supported in hw control for the
LED driver match netdev.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Introduce function to check if the requested mode can use hw control in
preparation for hw control support. Currently everything is handled in
software so can_hw_control will always return false.
Add knob with the new value hw_control in trigger_data struct to
set hw control possible. Useful for future implementation to implement
in set_baseline_state() the required function to set the requested mode
using LEDs hw control ops and in other function to reject set if hw
control is currently active.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Move the code into a helper, ready for it to be called at
other times. No intended behaviour change.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Each gpio-leds DT node DT subnode can have a pinctrl property assigned
to it, parse the DT subnode pinctrl properties and configure each pin
accordingly.
Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230523183151.5460-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20230522105049.1467313-18-schnelle@linux.ibm.com
Signed-off-by: Lee Jones <lee@kernel.org>
The call netdev_{put, hold} of dev_{put, hold} will check NULL,
so there is no need to check before using dev_{put, hold},
remove it to silence the warnings:
./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed.
./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230511070820.52731-1-yang.lee@linux.alibaba.com
Signed-off-by: Lee Jones <lee@kernel.org>
Not all triggers use LED_INIT_DEFAULT_TRIGGER, which means that it
will not get cleared when the default trigger is a trigger which
does not use it such as "default-on".
If the default trigger then later gets replaced by a trigger which
does check LED_INIT_DEFAULT_TRIGGER, such as "timer" then that trigger
will behave as if it is the default trigger which it should not do.
To fix this clear the LED_INIT_DEFAULT_TRIGGER flag when clearing
the current trigger, so that it will not be set for any subsequently
set (non default) triggers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://lore.kernel.org/r/20230510162234.291439-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
led_trigger_blink() calls led_blink_set() from a RCU read-side critical
section so led_blink_set() must not sleep. Note sleeping was not allowed
before the switch to RCU either because a spinlock was held before.
led_blink_set() does not sleep when sw-blinking is used, but
many LED controller drivers with hw blink support have a blink_set
function which may sleep, leading to an oops like this one:
[ 832.605062] ------------[ cut here ]------------
[ 832.605085] Voluntary context switch within RCU read-side critical section!
[ 832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690
<snip>
[ 832.606453] Call Trace:
[ 832.606466] <TASK>
[ 832.606487] __schedule+0x9f/0x1480
[ 832.606527] schedule+0x5d/0xe0
[ 832.606549] schedule_timeout+0x79/0x140
[ 832.606572] ? __pfx_process_timeout+0x10/0x10
[ 832.606599] wait_for_completion_timeout+0x6f/0x140
[ 832.606627] i2c_dw_xfer+0x101/0x460
[ 832.606659] ? psi_group_change+0x168/0x400
[ 832.606680] __i2c_transfer+0x172/0x6d0
[ 832.606709] i2c_smbus_xfer_emulated+0x27d/0x9c0
[ 832.606732] ? __schedule+0x430/0x1480
[ 832.606753] ? preempt_count_add+0x6a/0xa0
[ 832.606778] ? get_nohz_timer_target+0x18/0x190
[ 832.606796] ? lock_timer_base+0x61/0x80
[ 832.606817] ? preempt_count_add+0x6a/0xa0
[ 832.606842] __i2c_smbus_xfer+0xa2/0x3f0
[ 832.606862] i2c_smbus_xfer+0x66/0xf0
[ 832.606882] i2c_smbus_read_byte_data+0x41/0x70
[ 832.606901] ? _raw_spin_unlock_irqrestore+0x23/0x40
[ 832.606922] ? __pm_runtime_suspend+0x46/0xc0
[ 832.606946] cht_wc_byte_reg_read+0x2e/0x60
[ 832.606972] _regmap_read+0x5c/0x120
[ 832.606997] _regmap_update_bits+0x96/0xc0
[ 832.607023] regmap_update_bits_base+0x5b/0x90
[ 832.607053] cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove]
[ 832.607094] led_blink_setup+0x28/0x100
[ 832.607119] led_trigger_blink+0x40/0x70
[ 832.607145] power_supply_update_leds+0x1b7/0x1c0
[ 832.607174] power_supply_changed_work+0x67/0xe0
[ 832.607198] process_one_work+0x1c8/0x3c0
[ 832.607222] worker_thread+0x4d/0x380
[ 832.607243] ? __pfx_worker_thread+0x10/0x10
[ 832.607258] kthread+0xe9/0x110
[ 832.607279] ? __pfx_kthread+0x10/0x10
[ 832.607300] ret_from_fork+0x2c/0x50
[ 832.607337] </TASK>
[ 832.607344] ---[ end trace 0000000000000000 ]---
Add a new led_blink_set_nosleep() function which defers the actual
led_blink_set() call to a workqueue when necessary to fix this.
This also fixes an existing race where a pending led_set_brightness() has
been deferred to set_brightness_work and might then race with a later
led_cdev->blink_set() call. Note this race is only an issue with triggers
mixing led_trigger_event() and led_trigger_blink() calls, sysfs API
calls and led_trigger_blink_oneshot() are not affected.
Note rather then adding a separate blink_set_blocking callback this uses
the presence of the already existing brightness_set_blocking callback to
detect if the blinking call should be deferred to set_brightness_work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
When a trigger wants to switch from blinking to LED on it needs to call:
led_set_brightness(LED_OFF);
led_set_brightness(LED_FULL);
To first call disables blinking and the second then turns the LED on
(the power-supply charging-blink-full-solid triggers do this).
These calls happen immediately after each other, so it is possible
that set_brightness_delayed() from the first call has not run yet
when the led_set_brightness(LED_FULL) call finishes.
If this race hits then this is causing problems for both
sw- and hw-blinking:
For sw-blinking set_brightness_delayed() clears delayed_set_value
when LED_BLINK_DISABLE is set causing the led_set_brightness(LED_FULL)
call effects to get lost when hitting the race, resulting in the LED
turning off instead of on.
For hw-blinking if the race hits delayed_set_value has been
set to LED_FULL by the time set_brightness_delayed() runs.
So led_cdev->brightness_set_blocking() is never called with
LED_OFF as argument and the hw-blinking is never disabled leaving
the LED blinking instead of on.
Fix both issues by adding LED_SET_BRIGHTNESS and LED_SET_BRIGHTNESS_OFF
work_flags making this 2 separate actions to be run by
set_brightness_delayed().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://lore.kernel.org/r/20230510162234.291439-3-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters
are pass by reference, so that hw-blink implementations can report
back the actual achieved delays when the values have been rounded
to something the hw supports.
This is really only interesting for the sysfs API / the timer trigger.
Other triggers don't really care about this and none of the callers of
led_trigger_blink[_oneshot]() do anything with the returned delay values.
Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value,
there are 2 reasons for this:
1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not.
So on hw where led_cdev->blink_set() sleeps the call needs to be deferred
to a workqueue, in which case the actual achieved delays are unknown
(this is a preparation patch for the deferring).
2. Since the callers don't care about the actual achieved delays, allowing
callers to directly pass a value leads to simpler code for most callers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Florian Westphal <fw@strlen.de>
Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
After commit b8a1a4cd5a ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230517180559.166329-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON,
which contains the common code to support TI LMU devices. This means
the user is asked about the common code first, followed by the
individual drivers, if their dependencies are met.
Simplify this, and reduce the number of questions by making
LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be
Signed-off-by: Lee Jones <lee@kernel.org>
The Qualcomm PMI8998 PMIC requires the LED to be disabled when configuring
the brightness. Always disable the LED when setting the brightness and
re-enable it afterwards.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Link: https://lore.kernel.org/r/20230507172941.364852-3-me@dylanvanassche.be
Signed-off-by: Lee Jones <lee@kernel.org>
Add subtype for the Qualcomm PMI8998 PMIC to support it besides the
PM8150 PMIC which has the same registers. Adjust the driver to recognize
both PMIC subtypes as a 3 channel LED driver.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Link: https://lore.kernel.org/r/20230507172941.364852-2-me@dylanvanassche.be
Signed-off-by: Lee Jones <lee@kernel.org>
The desired default behavior of LED1 / the charge LED is breathing
while charging and on/solid when full. Since triggers cannot select
breathing, blink_set() gets called when charging. Use breathing
when the default "charging-blink-full-solid" trigger is used to
achieve the desired default behavior.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230430195952.862527-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>