linux-kernel - Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXdJbidb3DPyRaxB@smile.fi.intel.com>
Date: Mon, 26 Jan 2026 13:01:02 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, tools@...nel.org
Cc: linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
	Thomas Gleixner <tglx@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Puranjay Mohan <puranjay@...nel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	Marcus Folkesson <marcus.folkesson@...il.com>,
	Kent Gustavsson <kent@...oris.se>,
	Gustavo Silva <gustavograzs@...il.com>,
	Nishant Malpani <nish.malpani25@...il.com>,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

On Mon, Jan 26, 2026 at 11:10:34AM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-26 11:51:13 [+0200], Andy Shevchenko wrote:
> > > > > Cc: Lars-Peter Clausen <lars@...afoo.de>
> > > > > Cc: Michael Hennerich <Michael.Hennerich@...log.com>
> > > > > Cc: Puranjay Mohan <puranjay@...nel.org>
> > > > > Cc: Jonathan Cameron <jic23@...nel.org>
> > > > > Cc: David Lechner <dlechner@...libre.com>
> > > > > Cc: "Nuno Sá" <nuno.sa@...log.com>
> > > > > Cc: Andy Shevchenko <andy@...nel.org>
> > > > > Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>
> > > > > Cc: Marcus Folkesson <marcus.folkesson@...il.com>
> > > > > Cc: Kent Gustavsson <kent@...oris.se>
> > > > > Cc: Gustavo Silva <gustavograzs@...il.com>
> > > > > Cc: Nishant Malpani <nish.malpani25@...il.com>
> > > > > Cc: linux-iio@...r.kernel.org
> > > > 
> …
> > I didn't follow. How? What tools do you use?
> 
> b4/ git.

> > > So I have to move them for each submission. Or is there something I am not
> > > aware of?
> > 
> > Make them in the tail of commit messages locally with a delimiter, they will
> > always be present as long as they are in your tree.
> > 
> > I dunno if `b4` manages the Cc lists separately. At least I see no-one using
> > `b4` *and* putting the Cc noise into the commit messages, so I assume it
> > behaves nicely.
> 
> I point is if I move them for one submission,

It will be in your Git tree as a part of the commit message.

What I mean is that your commit message will be like

  $PREFIX: $SUMMARY
  ...blank line...
  $COMMIT_MESSAGE
  ...blank line...
  $TAG
  Signed-off-by: ...
  ---
  Cc: person 1
  Cc: person 2

Just don't reimport them via `git am`.

> I lose it on the next if I update patches in tree and re-export them. 

I don't understand this, sorry. Can you provide a step-by-step example?
Do you mean that you are taking previous version from the list and reapplying
it via `git am`? But shouldn't `b4` take care of that as long as it knows the
Change-ID and it matches?

...

Hmm... The https://b4.docs.kernel.org/en/latest/contributor/prep.html
doesn't clearly tell me if there is a carry-on procedure for the Cc
list between versions.

...

> > > > > +		ret = devm_request_irq(dev, st->irq,
> > > > > +				       iio_trigger_generic_data_rdy_poll,
> > > > > +				       IRQF_TRIGGER_RISING | IRQF_NO_THREAD,
> > > > > +				       indio_dev->name, st->dready_trig);
> > > > >  		if (ret < 0)
> > > > >  			return ret;
> > > > 
> > > > Interestingly that this driver ignores the flags from firmware... Seems to me
> > > > like a bug (not in your patch, obviously). Ditto for other drivers doing similar
> > > > things.
> > > 
> > > If the irq-chip is level or unknown mode on boot up/ default and the
> > > device can only operate as an edge-rising then I don't see why this
> > > should be a bug.
> > 
> > But if FW says use "level", wouldn't this setting override it?
> 
> Yes, it will. It was common to use it pre-device-tree time where this
> information was not configured automatically before ->probe. Now it
> might be missing/wrong in the dt for some of the old devices.
> It might be a left-over which continued to grow and spread.

It may be considered as a bug, especially in the cases when the driver works
only on DT/ACPI platforms.

-- 
With Best Regards,
Andy Shevchenko