Re: [PATCH 03/13] iio: chemical: Remove redundant dev_err()/dev_err_probe()

[Pan Chuang]

On 2026/7/18 17:11, Maxwell Doose wrote:
> On Fri, Jul 17, 2026 at 6:24 PM Jonathan Cameron
> <jonathan.cameron@xxxxxxxxxxxxxxxx> wrote:
>>
>> On Fri, 17 Jul 2026 17:05:22 -0500
>> "Maxwell Doose" <maxwell@xxxxxxxxxxx> wrote:
>>
>>> Hi Pan,
>>>
>>> On Fri Jul 17, 2026 at 4:42 AM CDT
>>> Pan Chuang <panchuang@xxxxxxxx> wrote:
>>>
>>>> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
>>>> devm_request_*_irq()"),
>>>> devm_request_irq() and devm_request_threaded_irq() automatically log
>>>> detailed error messages on failure. Remove the now-redundant
>>>> driver-specific dev_err() and dev_err_probe() calls.
>>>>
>>>> Signed-off-by: Pan Chuang <panchuang@xxxxxxxx>
>>>> ---
>>>>  drivers/iio/chemical/ccs811.c      | 4 +---
>>>>  drivers/iio/chemical/ens160_core.c | 2 +-
>>>>  drivers/iio/chemical/scd30_core.c  | 2 +-
>>>>  3 files changed, 3 insertions(+), 5 deletions(-)
>>>>
>>> ...
>>>>
>>>> diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c
>>>> index f85cdd8bd84f..770571c21521 100644
>>>> --- a/drivers/iio/chemical/scd30_core.c
>>>> +++ b/drivers/iio/chemical/scd30_core.c
>>>> @@ -686,7 +686,7 @@ static int scd30_setup_trigger(struct iio_dev *indio_dev)
>>>>                                     IRQF_NO_AUTOEN,
>>>>                                     indio_dev->name, indio_dev);
>>>>     if (ret)
>>>> -           return dev_err_probe(dev, ret, "failed to request irq\n");
>>>> +           return ret;
>>>>
>>>>     return 0;
>>>>  }
>>>
>>> Please split per driver and resubmit and feel free to add
>>
>> For large and simple repeat actions like this it's a trade off between
>> the noise of a lot of patches vs easy handling of any future conflicts in
>> backports.  Given there are 60ish patches if this is broken up, it is a
>> bit marginal for which approach is preferable.
>>
>> For more complex changes I would entirely agree that one patch per driver.
>>
>> So I think I'm fine either way for this particular series.  One patch
>> per directory, or one patch per driver.
>
> Just personal preference given multiple drivers and multiple
> maintainers. I suppose either is fine but I would prefer it split for
> this one.

Hi Jonathan, Maxwell, and  Andy,

Thank you for the feedback. I completely understand the trade-off, and
I've been struggling with the same question myself: whether to split by
driver or submit as a larger series.

My primary goal is to make the patches as easy to merge and as maintainable
as possible in the long run. I know that different subsystems have different
preferences on this.

Therefore, I would like to ask for your guidance specifically for the IIO
subsystem: would you prefer one patch per driver, or one patch per directory?

Also, for directories with many changes, like light, would it be better to
submit them separately in a follow-up series to keep the initial series 
more focused?

Additionally, I will also adopt all the other suggestions from this patchset
and resubmit in v2.

Looking forward to your reply.


Best Regards,

PanChuang