Re: [PATCH 1/2] driver core: platform: Introduce platform_get_irq_optional()

From: Thierry Reding
Date: Wed Aug 28 2019 - 05:32:14 EST


On Wed, Aug 28, 2019 at 10:57:24AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 28, 2019 at 10:34:10AM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@xxxxxxxxxx>
> >
> > In some cases the interrupt line of a device is optional. Introduce a
> > new platform_get_irq_optional() that works much like platform_get_irq()
> > but does not output an error on failure to find the interrupt.
> >
> > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
> > ---
> > drivers/base/platform.c | 22 ++++++++++++++++++++++
> > include/linux/platform_device.h | 1 +
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index 8ad701068c11..0dda6ade50fd 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -192,6 +192,28 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> > }
> > EXPORT_SYMBOL_GPL(platform_get_irq);
> >
> > +/**
> > + * platform_get_irq_optional - get an optional IRQ for a device
> > + * @dev: platform device
> > + * @num: IRQ number index
> > + *
> > + * Gets an IRQ for a platform device. Device drivers should check the return
> > + * value for errors so as to not pass a negative integer value to the
> > + * request_irq() APIs. This is the same as platform_get_irq(), except that it
> > + * does not print an error message if an IRQ can not be obtained.
>
> Kind of funny that the work people did to put error messages in a
> central place needs to be worked around at times :)

Indeed. I think it does make sense in this case to have the error
message in a central place, because it really does seem like the vast
majority of users really do want that IRQ. Having the _optional variant
makes it really explicit in the cases where it's fine to continue
without the IRQ.

> Anyway, I have no objection to this, but it looks like it has to go in
> through my tree. I can take the hwmon patch as well through my tree if
> the hwmon maintainer(s) say it is ok to do so.

I suppose we could technically make this go through the driver core and
hwmon trees separately with a bit of timing, but the hwmon patch is so
trivial that it would indeed be simplest to take it through the driver
core tree as well.

Thierry

Attachment: signature.asc
Description: PGP signature