summaryrefslogtreecommitdiff
path: root/drivers/leds/leds-lp50xx.c
AgeCommit message (Collapse)AuthorFilesLines
2023-05-25leds: Switch i2c drivers back to use .probe()Uwe Kleine-König1-1/+1
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("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>
2022-08-16i2c: Make remove callback return voidUwe Kleine-König1-3/+1
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-05-08leds: lp50xx: Remove duplicated error reporting in .remove()Uwe Kleine-König1-3/+1
Returning an error value from an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As stk3310_set_state() already emits an error message on failure and the additional error message by the i2c core doesn't add any useful information, don't pass the error value up the stack. Instead continue to clean up and return 0. This patch is a preparation for making i2c remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12leds: lp50xx: remove unused variableSven Schuchmann1-1/+0
During code review this unused variable was found. Remove it. Signed-off-by: Sven Schuchmann <schuchmann@schleissheimer.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-05-28leds: lp50xx: Put fwnode in error case during ->probe()Andy Shevchenko1-1/+1
fwnode_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. OTOH, the successful iteration will drop reference count under the hood, no need to do it twice. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Get rid of redundant explicit castingAndy Shevchenko1-2/+2
In the line like u32 bar = ...; u8 foo = (u8)(bar >> 8) & 0xff; is no need to have neither explicit casting nor ' & 0xff' part. Get rid of them. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Update headers block to reflect realityAndy Shevchenko1-2/+1
The OF is not used in the driver, thus the OF headers are not needed, but mod_devicetable.h is missed. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Get rid of redundant check in lp50xx_enable_disable()Andy Shevchenko1-5/+3
Since GPIO is optional the API is NULL aware and will check descriptor anyway. Remove duplicate redundant check in lp50xx_enable_disable(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Reduce level of dereferencesAndy Shevchenko1-14/+12
The priv->dev is effectively the same as &priv->client->dev. So, drop the latter for the former. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Switch to new style i2c-driver probe functionAndy Shevchenko1-17/+16
Switch to the new style i2c-driver probe_new probe function. Note we do not have any old style board files using this but user still has a possibility to instantiate device from sysfs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-20leds: lp50xx: Don't spam logs when probe is deferredAndy Shevchenko1-6/+3
When requesting GPIO line the probe can be deferred. In such case don't spam logs with an error message. This can be achieved by switching to dev_err_probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-11-25leds: lp50xx: Fix an error handling path in 'lp50xx_probe_dt()'Christophe JAILLET1-2/+4
In case of memory allocation failure, we must release some resources as done in all other error handling paths of the function. 'goto child_out' instead of a direct return so that 'fwnode_handle_put()' is called when we break out of a 'device_for_each_child_node' loop. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-26leds: parse linux,default-trigger DT property in LED coreMarek Behún1-3/+0
Do the parsing of `linux,default-trigger` DT property to LED core. Currently it is done in many different drivers and the code is repeated. This patch removes the parsing from 23 drivers: an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio, is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593, max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia. There is one driver in drivers/input which parses this property on it's own. I shall send a separate patch there after this is applied. There are still 8 drivers that parse this property on their own because they do not pass the led_init_data structure to the registering function. I will try to refactor those in the future. Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-08-17leds: lp50xx: Add the LP50XX family of the RGB LED driverDan Murphy1-0/+634
Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP5009 can control 9 LEDs The device has the ability to group LED outputs into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Or the LED outputs can also be controlled independently. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>