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>
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>
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: 242b81170f ("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>
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>
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>
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>
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>
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>
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>
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: 242b81170f ("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>
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>
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>
