Coccinelle archive on
 help / color / Atom feed
From: Stephen Boyd <>
To: Wolfram Sang <>
Cc: Rob Herring <>,
	Michal Marek <>,
	Bartlomiej Zolnierkiewicz <>,
	Greg Kroah-Hartman <>,
	"Rafael J . Wysocki" <>,
	Nicolas Palix <>,,
	Javier Martinez Canillas <>,
	Andrzej Hajda <>,
	Andy Shevchenko <>,
	Mark Brown <>,
	Russell King - ARM Linux <>,,
	Marek Szyprowski <>
Subject: Re: [Cocci] [PATCH v5 0/3] Add error message to platform_get_irq*()
Date: Wed, 31 Jul 2019 07:52:27 -0700
Message-ID: <> (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.

Cocci mailing list

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30  5:38 Stephen Boyd
2019-07-30  5:38 ` [Cocci] [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 publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Coccinelle archive on

Archives are clonable:
	git clone --mirror cocci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 cocci cocci/ \
	public-inbox-index cocci

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox