linux-toradex.git/drivers/mfd/stmfx.c, branch v6.1-rc3

i2c: Make remove callback return void

2022-08-16T10:46:26+00:00

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 
Reviewed-by: Jeremy Kerr 
Reviewed-by: Benjamin Mugnier 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Crt Mori 
Reviewed-by: Heikki Krogerus 
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Behún  # for leds-turris-omnia
Acked-by: Andy Shevchenko 
Reviewed-by: Petr Machata  # for mlxsw
Reviewed-by: Maximilian Luz  # for surface3_power
Acked-by: Srinivas Pandruvada  # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil  # for media/* + staging/media/*
Acked-by: Miguel Ojeda  # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli  # for versaclock5
Reviewed-by: Ajay Gupta  # for ucsi_ccg
Acked-by: Jonathan Cameron  # for iio
Acked-by: Peter Rosin  # for i2c-mux-*, max9860
Acked-by: Adrien Grassein  # for lontium-lt8912b
Reviewed-by: Jean Delvare  # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard  # for IPMI
Reviewed-by: Vladimir Oltean 
Acked-by: Dmitry Torokhov 
Acked-by: Sebastian Reichel  # for drivers/power
Acked-by: Krzysztof Hałasa 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang

mfd: stmfx: Improve error message triggered by regulator fault in .remove()

2022-03-08T09:44:05+00:00

Returning a non-zero value in an i2c remove callback results in the i2c
core emitting a very generic error message ("remove failed (-ESOMETHING),
will be ignored") and as the message indicates not further error handling
is done.

Instead emit a more specific error message and then return zero in
.remove().

The long-term goal is to make the i2c remove prototype return void, making
all implementations return 0 is preparatory work for this change.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Lee Jones 
Link: https://lore.kernel.org/r/20220214150710.312269-1-u.kleine-koenig@pengutronix.de

mfd: stmfx: Drop of_match_ptr from of_device_id table

2020-11-27T08:02:11+00:00

The driver can match only via the DT table so the table should be always
used and the of_match_ptr does not have any sense (this also allows ACPI
matching via PRP0001, even though it is not relevant here).  This fixes
compile warning (!CONFIG_OF on x86_64):

  drivers/mfd/stmfx.c:542:34: warning: ‘stmfx_of_match’ defined but not used [-Wunused-const-variable=]

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Lee Jones

mfd: stmfx: Fix dev_err_probe() call in stmfx_chip_init()

2020-11-19T08:34:28+00:00

'ret' may be 0 so, dev_err_probe() should be called only when 'ret' is
an error code.

Fixes: 41c9c06c491a ("mfd: stmfx: Simplify with dev_err_probe()")
Signed-off-by: Amelie Delaunay 
Signed-off-by: Lee Jones

mfd: stmfx: Simplify with dev_err_probe()

2020-09-30T15:24:59+00:00

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and also it prints the error value.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Lee Jones

mfd: stmfx: Disable IRQ in suspend to avoid spurious interrupt

2020-05-26T09:51:21+00:00

When STMFX supply is stopped, spurious interrupt can occur. To avoid that,
disable the interrupt in suspend before disabling the regulator and
re-enable it at the end of resume.

Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
Signed-off-by: Amelie Delaunay 
Signed-off-by: Lee Jones

mfd: stmfx: Fix stmfx_irq_init error path

2020-05-26T09:51:21+00:00

In case the interrupt signal can't be configured, IRQ domain needs to be
removed.

Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
Signed-off-by: Amelie Delaunay 
Signed-off-by: Lee Jones

mfd: stmfx: Reset chip on resume as supply was disabled

2020-05-26T09:51:20+00:00

STMFX supply is disabled during suspend. To avoid a too early access to
the STMFX firmware on resume, reset the chip and wait for its firmware to
be loaded.

Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
Signed-off-by: Amelie Delaunay 
Signed-off-by: Lee Jones

mfd: stmfx: Fix an endian bug in stmfx_irq_handler()

2019-06-24T14:19:31+00:00

It's not okay to cast a "u32 *" to "unsigned long *" when you are
doing a for_each_set_bit() loop because that will break on big
endian systems.

Fixes: 386145601b82 ("mfd: stmfx: Uninitialized variable in stmfx_irq_handler()")
Reported-by: Linus Torvalds 
Signed-off-by: Dan Carpenter 
Tested-by: Amelie Delaunay 
Signed-off-by: Lee Jones

mfd: stmfx: Uninitialized variable in stmfx_irq_handler()

2019-06-17T09:51:15+00:00

The problem is that on 64bit systems then we don't clear the higher
bits of the "pending" variable.  So when we do:

        ack = pending & ~BIT(STMFX_REG_IRQ_SRC_EN_GPIO);
        if (ack) {

the if (ack) condition relies on uninitialized data.  The fix it that
I've changed "pending" from an unsigned long to a u32.  I changed "n" as
well, because that's a number in the 0-10 range and it fits easily
inside an int.  We do need to add a cast to "pending" when we use it in
the for_each_set_bit() loop, but that doesn't cause a problem, it's
fine.

Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
Signed-off-by: Dan Carpenter 
Acked-by: Amelie Delaunay 
Signed-off-by: Lee Jones