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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 20 Jul 2026 15:45:43 +0800
Pan Chuang <panchuang@vivo.com> wrote:

> On 2026/7/18 17:11, Maxwell Doose wrote:
> > On Fri, Jul 17, 2026 at 6:24 PM Jonathan Cameron
> > <jonathan.cameron@oss.qualcomm.com> wrote:  
> >>
> >> On Fri, 17 Jul 2026 17:05:22 -0500
> >> "Maxwell Doose" <maxwell@maxwelld.cc> wrote:
> >>  
> >>> Hi Pan,
> >>>
> >>> On Fri Jul 17, 2026 at 4:42 AM CDT
> >>> Pan Chuang <panchuang@vivo.com> 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@vivo.com>
> >>>> ---
> >>>>  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?

For this change (not a hard rule!) one per directory is fine.

> 
> 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?

No it is fine to do them in this series.

Jonathan

> 
> Additionally, I will also adopt all the other suggestions from this patchset
> and resubmit in v2.
> 
> Looking forward to your reply.
> 
> 
> Best Regards,
> 
> PanChuang
>