Re: [PATCH v5 2/3] iio: adc: Support ROHM BD79112 ADC/GPIO
From: Matti Vaittinen
Date: Tue Sep 16 2025 - 04:14:21 EST
On 16/09/2025 11:02, Jonathan Cameron wrote:
On Tue, 16 Sep 2025 07:52:07 +0300
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
On 15/09/2025 23:13, Jonathan Cameron wrote:
On Mon, 15 Sep 2025 17:12:34 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:
On Mon, Sep 15, 2025 at 10:12:43AM +0300, Matti Vaittinen wrote:
--- a/drivers/iio/adc/rohm-bd79112.c
+++ b/drivers/iio/adc/rohm-bd79112.c
@@ -454,12 +454,18 @@ static int bd79112_probe(struct spi_device *spi)
data->read_xfer[1].rx_buf = &data->read_rx;
data->read_xfer[1].len = sizeof(data->read_rx);
spi_message_init_with_transfers(&data->read_msg, data->read_xfer, 2);
- devm_spi_optimize_message(dev, spi, &data->read_msg);
+ ret = devm_spi_optimize_message(dev, spi, &data->read_msg);
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "Failed to optimize SPI read message\n");
I am not really sure under what conditions the
devm_spi_optimize_message() could fail. It might be enough to print a
warning and proceed, but I don't think returning is a problem either.
No. Don't proceed on an unexpected failure whatever it is. That's
storing up problems that may surface in a weird way later that is much
harder to debug.
Just a generic note, not disagreeing in this case.
I have had similar discussions before - and I have been on the both
sides of the table. Hence, I don't have as strong stance on this as you.
On some situations it is better to just try proceeding as aborting the
operation brings no sane corrective actions but just reduces a device
unusable.
On the other hand, as you say, usually bailing out loud and early is the
best way to pinpoint the problem and get things fixed.
I still think that logging a warning should be a decent hint for someone
doing the debugging.
Well, as I said, returning here is Ok for me - thanks for taking care of
it! :)
Yours,
-- Matti