From: Stephen Boyd <swboyd@chromium.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rob Herring <robh@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Nicolas Palix <nicolas.palix@imag.fr>,
linux-kernel@vger.kernel.org,
Javier Martinez Canillas <javierm@redhat.com>,
Andrzej Hajda <a.hajda@samsung.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Mark Brown <broonie@kernel.org>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
cocci@systeme.lip6.fr,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [Cocci] [PATCH v5 0/3] Add error message to platform_get_irq*()
Date: Wed, 31 Jul 2019 07:52:27 -0700 [thread overview]
Message-ID: <5d41ab2c.1c69fb81.6129.661f@mx.google.com> (raw)
In-Reply-To: <20190731142645.GA1680@kunai>
Quoting Wolfram Sang (2019-07-31 07:26:46)
> Hi Stephen,
>
> > There were some comments about adding an 'optional' platform_get_irq()
> > API in v4. This series doesn't include that, but I can add such an API
> > if it's required. I started to look into how it might work and got hung
> > up on what an optional IRQ means. I suppose it means that in DT there
> > isn't an 'interrupts' property in the device node, but in ACPI based
> > firmware I'm not sure what that would correspond to. Furthermore, the
> > return value is hard to comprehend. Do we return an error when an
> > optional irq can't be found? It doesn't seem safe to return 0 because
> > sometimes 0 is a valid IRQ. Do other errors in parsing the IRQ
> > constitute a failure when the IRQ is optional?
>
> Some time ago, I tried a series like yours and got stuck at this very
> point. I found drivers where using an interrupt was optional and
> platform_get_irq() returning a failure wasn't fatal. The drivers used
> PIO then or dropped some additional functionality. Some of them were
> very old.
>
> I didn't like the idea that platform_get_irq() will spit out errors for
> those drivers, yet I couldn't create a suitable cocci-script to convert
> drivers to use the *_optional callback where possible. So, I neither
> created the optional callback.
>
> I still have doubts of unneeded error messages popping up. Has this been
> discussed already? (Sorry, I missed the first iterations of this series)
Not heavily discussed, but it was mentioned in an earlier round. If
these drivers pop up, I think we can have another function like
platform_get_irq_probe() or platform_get_irq_nowarn() that doesn't print
an error message. Then we can convert the drivers that are poking around
for interrupts to use this new function instead. It isn't the same as a
platform_get_optional_irq() API because it returns an error when the irq
isn't there or we fail to parse something, but at least the error
message is gone.
next prev parent reply other threads:[~2019-07-31 14:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 5:38 [PATCH v5 0/3] Add error message to platform_get_irq*() Stephen Boyd
2019-07-30 5:38 ` [PATCH v5 1/3] driver core: platform: Add an " Stephen Boyd
2019-07-30 9:44 ` Markus Elfring
2019-07-30 12:30 ` Markus Elfring
2019-07-30 5:38 ` [PATCH v5 2/3] treewide: Remove dev_err() usage after platform_get_irq() Stephen Boyd
2019-07-30 6:49 ` Greg Kroah-Hartman
2019-07-30 15:35 ` Stephen Boyd
2019-07-30 15:51 ` Greg Kroah-Hartman
2019-07-30 17:16 ` Andy Shevchenko
2019-07-30 17:17 ` Andy Shevchenko
2019-07-30 17:21 ` Stephen Boyd
2019-07-30 17:31 ` Andy Shevchenko
2019-07-30 10:00 ` [v5 " Markus Elfring
2019-07-30 10:00 ` Markus Elfring
2019-07-30 5:38 ` [PATCH v5 3/3] coccinelle: Add script to check for platform_get_irq() excessive prints Stephen Boyd
2019-07-30 8:49 ` Markus Elfring
2019-07-31 14:26 ` [Cocci] [PATCH v5 0/3] Add error message to platform_get_irq*() Wolfram Sang
2019-07-31 14:52 ` Stephen Boyd [this message]
2019-08-01 12:25 ` Wolfram Sang
2019-08-08 7:51 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d41ab2c.1c69fb81.6129.661f@mx.google.com \
--to=swboyd@chromium.org \
--cc=a.hajda@samsung.com \
--cc=andy.shevchenko@gmail.com \
--cc=b.zolnierkie@samsung.com \
--cc=broonie@kernel.org \
--cc=cocci@systeme.lip6.fr \
--cc=gregkh@linuxfoundation.org \
--cc=javierm@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
--cc=rafael.j.wysocki@intel.com \
--cc=robh@kernel.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).