Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Andy Shevchenko]

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@metafoo.de>
> > > > > Cc: Michael Hennerich <Michael.Hennerich@analog.com>
> > > > > Cc: Puranjay Mohan <puranjay@kernel.org>
> > > > > Cc: Jonathan Cameron <jic23@kernel.org>
> > > > > Cc: David Lechner <dlechner@baylibre.com>
> > > > > Cc: "Nuno Sá" <nuno.sa@analog.com>
> > > > > Cc: Andy Shevchenko <andy@kernel.org>
> > > > > Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > > > Cc: Marcus Folkesson <marcus.folkesson@gmail.com>
> > > > > Cc: Kent Gustavsson <kent@minoris.se>
> > > > > Cc: Gustavo Silva <gustavograzs@gmail.com>
> > > > > Cc: Nishant Malpani <nish.malpani25@gmail.com>
> > > > > Cc: linux-iio@vger.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

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Konstantin Ryabitsev]

On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote:
> > 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?

That's not the intended workflow -- the series is kept as a branch in your
local tree and any updates happen to that branch, so any entries in a commit
falling under "---" will persist across revisions.

> 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.

There isn't any special procedure. ¯\_(ツ)_/¯

-K

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Andy Shevchenko]

On Mon, Jan 26, 2026 at 09:29:45AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote:
> > > 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?
> 
> That's not the intended workflow -- the series is kept as a branch in your
> local tree and any updates happen to that branch, so any entries in a commit
> falling under "---" will persist across revisions.

Right. I found `b4 trailers` do a really good job to inject collected trailers
into the Git repo without need of any `git reset; b4 am; git am` dances.

> > 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.
> 
> There isn't any special procedure. ¯\_(ツ)_/¯

What I have i mind is rather the scenario when I see already sent (by somebody
else) patch in the mailing list and I want develop a followup with the same
To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore`
type of functionality.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Konstantin Ryabitsev]

On Mon, Jan 26, 2026 at 04:57:24PM +0200, Andy Shevchenko wrote:
> What I have i mind is rather the scenario when I see already sent (by somebody
> else) patch in the mailing list and I want develop a followup with the same
> To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore`
> type of functionality.

To understand it better -- you want to send a new revision to a patch sent by
someone else? If so, you should be able to "b4 prep --from-thread <msgid>",
but it's actually a good question if that will do the right thing with content
under "---" or not, as I'm not sure this part was ever properly tested.

-K

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Andy Shevchenko]

On Mon, Jan 26, 2026 at 10:09:25AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Jan 26, 2026 at 04:57:24PM +0200, Andy Shevchenko wrote:
> > What I have i mind is rather the scenario when I see already sent (by somebody
> > else) patch in the mailing list and I want develop a followup with the same
> > To/Cc list. So I want `b4 ... --use/restore-to-cc-from-the-mailing-list / lore`
> > type of functionality.

> To understand it better -- you want to send a new revision to a patch sent by
> someone else?

Like this or when I want to send another patch on top of what has been sent to
the same people.

> If so, you should be able to "b4 prep --from-thread <msgid>",
> but it's actually a good question if that will do the right thing with content
> under "---" or not, as I'm not sure this part was ever properly tested.

But that's not needed, as it's assumed to be in the *email* Cc and To already,
so that's it then. I will try the suggested command, thanks!

More complex case is to preserve that locally, but it might be not needed after
all.

Thanks for the suggestions and nice tool!


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Sebastian Andrzej Siewior]

On 2026-01-26 13:01:02 [+0200], Andy Shevchenko wrote:
>   ---
>   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?

So doing this and switching to b4 trailers to grab the tags actually
help. Then I have been playing with prep. So thank you.

Then I stumbled upon --auto-to-cc which picked up all addresses and
added it to the cover letter which was fine. But then `send' used those
for every patch in the series which I did not want. So for that part I
probably stick with git-send-mail since this not in everyone's workflow
(sending a series across multiple subsystems and avoiding flooding
everyone).

Anyway. This seems to have turned out nice.

Sebastian

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Andy Shevchenko]

On Wed, Jan 28, 2026 at 11:07:36AM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-26 13:01:02 [+0200], Andy Shevchenko wrote:
> >   ---
> >   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?
> 
> So doing this and switching to b4 trailers to grab the tags actually
> help. Then I have been playing with prep. So thank you.

You're welcome!

> Then I stumbled upon --auto-to-cc which picked up all addresses and
> added it to the cover letter which was fine. But then `send' used those
> for every patch in the series which I did not want. So for that part I
> probably stick with git-send-mail since this not in everyone's workflow
> (sending a series across multiple subsystems and avoiding flooding
> everyone).

I'm not an (advanced) user of `b4` yet. I have my own script to send based on
some heuristics [1].

> Anyway. This seems to have turned out nice.

Good!

[1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Nuno Sá]

On Mon, 2026-01-26 at 09:29 -0500, Konstantin Ryabitsev wrote:
> On Mon, Jan 26, 2026 at 01:01:02PM +0200, Andy Shevchenko wrote:
> > > 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?
> 
> That's not the intended workflow -- the series is kept as a branch in your
> local tree and any updates happen to that branch, so any entries in a commit
> falling under "---" will persist across revisions.
> 

Hi Konstantin,

Since I have you here, I might ask about something that I'm not sure how to handle. Might be dumb
but here it goes. One problem is when I send v1 based on a branch and when I'm starting to work on
v2 that branch was force-updated and I want to base my v2 on it. Is there any good way to handle
this?


What I currently do is more or less:

git cat-file -p $COVER_SHA
git reset --hard origin/branch
git commit --allow-empty (and past all the cover with b4 metadata)
// apply my series patches.

Thx!
- Nuno Sá
> 

Re: [PATCH 18/21] iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

[Konstantin Ryabitsev]

On Wed, Jan 28, 2026, at 05:45, Nuno Sá wrote:
> Since I have you here, I might ask about something that I'm not sure
> how to handle. Might be dumb but here it goes. One problem is when I
> send v1 based on a branch and when I'm starting to work on v2 that
> branch was force-updated and I want to base my v2 on it. Is there any
> good way to handle this?

You should be able to just rebase the b4 branch.

git switch b4/your-branch
git rebase tracking-branch

You can do this at any point, not necessarily between revisions. Since we have the tracking empty commit, we'll always know the base-commit automatically.

-K