From: Wolfram Sang <wsa@the-dreams.de>
To: Stephen Boyd <swboyd@chromium.org>
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 16:26:46 +0200 [thread overview]
Message-ID: <20190731142645.GA1680@kunai> (raw)
In-Reply-To: <20190730053845.126834-1-swboyd@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
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)
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Rob Herring <robh@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"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 16:26:46 +0200 [thread overview]
Message-ID: <20190731142645.GA1680@kunai> (raw)
In-Reply-To: <20190730053845.126834-1-swboyd@chromium.org>
[-- Attachment #1.1: Type: text/plain, Size: 1401 bytes --]
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)
Thanks,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 136 bytes --]
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
next prev parent reply other threads:[~2019-07-31 14:26 UTC|newest]
Thread overview: 32+ 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 ` [Cocci] " 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 9:44 ` Markus Elfring
2019-07-30 12:30 ` 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 10:00 ` 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 5:38 ` [Cocci] " Stephen Boyd
2019-07-30 8:49 ` Markus Elfring
2019-07-30 8:49 ` [Cocci] " Markus Elfring
2019-07-30 8:49 ` Markus Elfring
2019-07-31 14:26 ` Wolfram Sang [this message]
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
2019-07-31 14:52 ` Stephen Boyd
2019-08-01 12:25 ` Wolfram Sang
2019-08-01 12:25 ` Wolfram Sang
2019-08-08 7:51 ` Geert Uytterhoeven
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=20190731142645.GA1680@kunai \
--to=wsa@the-dreams.de \
--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=swboyd@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.