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
...
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
...
I have improperly refactored commits
4d5ed2621c24 ("leds: turris-omnia: Make set_brightness() more efficient")
and
aaf38273cf76 ("leds: turris-omnia: Support HW controlled mode via private trigger")
after Lee requested a change in API semantics of the new functions I
introduced in commit
28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls").
Before the change, the function omnia_cmd_write_u8() returned 0 on
success, and afterwards it returned a positive value (number of bytes
written). The latter version was applied, but the following commits did
not properly account for this change.
This results in non-functional LED's .brightness_set_blocking() and
trigger's .activate() methods.
The main reasoning behind the semantics change was that read/write
methods should return the number of read/written bytes on success.
It was pointed to me [1] that this is not always true (for example the
regmap API does not do so), and since the driver never uses this number
of read/written bytes information, I decided to fix this issue by
changing the functions to the original semantics (return 0 on success).
[1] https://lore.kernel.org/linux-gpio/ZQnn+Gi0xVlsGCYA@smile.fi.intel.com/
Fixes: 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls")
Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20231016141538.30037-1-kabel@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
GCC 13.2 complains about array subscript 17 is above array bounds of
'char[16]' with IFNAMSIZ set to 16.
The warning is correct but this scenario is impossible.
set_device_name is called by device_name_store (store sysfs entry) and
netdev_trig_activate.
device_name_store already check if size is >= of IFNAMSIZ and return
-EINVAL. (making the warning scenario impossible)
netdev_trig_activate works on already defined interface, where the name
has already been checked and should already follow the condition of
strlen() < IFNAMSIZ.
Aside from the scenario being impossible, set_device_name can be
improved to both mute the warning and make the function safer.
To make it safer, move size check from device_name_store directly to
set_device_name and prevent any out of bounds scenario.
Cc: stable@vger.kernel.org
Fixes: 28a6a2ef18 ("leds: trigger: netdev: refactor code setting device name")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202309192035.GTJEEbem-lkp@intel.com/
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20231007131042.15032-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
By providing a GPIO line as "trigger-sources" in the FWNODE
(such as from the device tree) and combining with the
GPIO trigger, we can support a GPIO LED trigger in a natural
way from the hardware description instead of using the
custom sysfs and deprecated global GPIO numberspace.
Example:
gpio: gpio@0 {
compatible "my-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
#trigger-source-cells = <2>;
};
leds {
compatible = "gpio-leds";
led-my-gpio {
label = "device:blue:myled";
gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
linux,default-trigger = "gpio";
trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>;
};
};
Make this the norm, unmark the driver as broken.
Delete the sysfs handling of GPIOs.
Since GPIO descriptors inherently can describe inversion,
the inversion handling can just be deleted.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230926-gpio-led-trigger-dt-v2-3-e06e458b788e@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Convert enum->pointer for data in the match tables, so that
device_get_match_data() can do match against OF/ACPI/I2C tables, once i2c
bus type match support added to it.
Replace enum->struct *pca955x_chipdefs for data in the match table.
Simplify the probe() by replacing device_get_match_data() and ID lookup
for retrieving data by i2c_get_match_data().
While at it, add const definition to pca955x_chipdefs[].
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230923171921.53503-2-biju.das.jz@bp.renesas.com
Signed-off-by: Lee Jones <lee@kernel.org>
In order to teach the compiler that 'trig->name' will never be truncated,
we need to tell it that 'cpu' is not negative.
When building with W=1, this fixes the following warnings:
drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~
drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7]
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~
drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8
155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8f88731d05 ("led-triggers: create a trigger for CPU activity")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
