x86: Use "er" asm constriant for add/sub
cover x86: Use "er" asm constriant for add/sub
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.
Found by a patch that added used mul_u64_add_u64_div_u64() to do a rounding divide by 2^32 (perhaps not the best way to do this).
A quick grep only found one other affected file.
David Laight (2):
lib: mul_u64_add_u64_div_u64: Fix addition of large constants x86/local: local_add/local_sub: Support large immediate values
arch/x86/include/asm/div64.h | 2 +- arch/x86/include/asm/local.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
Signature · 1 line
2.39.5
PATCH 1/2 lib: mul_u64_add_u64_div_u64: Fix addition of large constants
Adding constants over 2^31 fails to compile because the ADD instruction only supports 32bit signed immediates.
Replace the "irm" constraint with "erm" so that the compiler loads large constants into a register.
Found by a patch to drivers/iio/frequency/ad9910.c
--- arch/x86/include/asm/div64.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/div64.h +1 -1
@@ -111,7 +111,7 @@ static inline u64 mul_u64_add_u64_div_u64(u64 rax, u64 mul, u64 add, u64 div)if (!statically_true (!add)) asm ("addq %[add], %[lo]; adcq $0, %[hi]" : - [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"irm" (add)); + [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"erm" (add)); asm ("divq %[div]" :"+a" (rax),"+d" (rdx) : [div]"rm" (div));
Signature · 1 line
2.39.5
Re: [PATCH 1/2] lib: mul_u64_add_u64_div_u64: Fix addition of large constants
Quoted 10 lines · David Laight
Adding constants over 2^31 fails to compile because the ADD instruction only supports 32bit signed immediates.
Replace the "irm" constraint with "erm" so that the compiler loads large constants into a register.
Found by a patch to
drivers/iio/frequency/ad9910.cFixes 6480241f31f5 ("lib: add mul_u64_add_u64_div_u64() and mul_u64_u64_div_u64_roundup()")Signed-off-by David Laight <[email protected]>
So it is.
Quoted 17 lines
--- arch/x86/include/asm/div64.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/x86/include/asm/div64.h +1
-1@@ -111,7 +111,7 @@ static inline u64 mul_u64_add_u64_div_u64(u64 rax, u64 mul, u64 add, u64 div)if (!statically_true (!add)) asm ("addq %[add], %[lo]; adcq $0, %[hi]" : - [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"irm" (add)); + [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"erm" (add)); asm ("divq %[div]" :"+a" (rax),"+d" (rdx) : [div]"rm" (div));
[tip: x86/urgent] x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64()
In reply to David LaightThe following commit has been merged into the x86/urgent branch of tip:
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: f65d38155aef069c897a64643a03db237dd1e0c8 Gitweb: https://git.kernel.org/tip/f65d38155aef069c897a64643a03db237dd1e0c8 Author: David Laight <[email protected]> AuthorDate: Mon, 03 Aug 2026 10:47:01 +01:00 Committer: Borislav Petkov (AMD) <[email protected]> CommitterDate: Thu, 10 Sep 2026 10:40:22 -07:00
x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64()
Adding constants over 2^31 fails to compile because the ADD instruction only supports 32bit signed immediates.
Replace the "irm" constraint with "erm" so that the compiler loads large constants into a register.
Found by a patch to drivers/iio/frequency/ad9910.c
[ bp: Massage commit message. ]
--- arch/x86/include/asm/div64.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/div64.h +1 -1
@@ -111,7 +111,7 @@ static inline u64 mul_u64_add_u64_div_u64(u64 rax, u64 mul, u64 add, u64 div)if (!statically_true (!add)) asm ("addq %[add], %[lo]; adcq $0, %[hi]" : - [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"irm" (add)); + [lo]"+r" (rax), [hi]"+r" (rdx) : [add]"erm" (add)); asm ("divq %[div]" :"+a" (rax),"+d" (rdx) : [div]"rm" (div));
PATCH 2/2 x86/local: local_add/local_sub: Support large immediate values
In reply to David LaightReplace the "ir" constraint with "er" so that constants over 2^31 get loaded into a register.
--- arch/x86/include/asm/local.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/include/asm/local.h +2 -2
@@ -32,14 +32,14 @@ static inline void local_add(long i, local_t *l) { asmvolatile (_ASM_ADD"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }static inline void local_sub (long i,local_t *l) { asmvolatile (_ASM_SUB"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }/**
Signature · 1 line
2.39.5
Re: [PATCH 2/2] x86/local: local_add/local_sub: Support large immediate values
Quoted 17 lines · David Laight
Replace the "ir" constraint with "er" so that constants over 2^31 get loaded into a register.
Signed-off-by David Laight <[email protected]>--- arch/x86/include/asm/local.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/include/asm/local.h +0
-1@@ -32,14 +32,14 @@ static inline void local_add(long i, local_t *l) { asmvolatile (_ASM_ADD"%1,%0" : "+m" (l->a.counter) - :"ir" (i));
arch/x86/include/asm/local.h static inline void local_add(long i, local_t *l) · line 43
Quoted 10 lines
arch/x86/include/asm/local.h +2
-1+ : "er" (i)); }static inline void local_sub (long i,local_t *l) { asmvolatile (_ASM_SUB"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }
And the other two sites already have "er", how inconsistent :/
Re: [PATCH 2/2] x86/local: local_add/local_sub: Support large immediate values
In reply to David LaightQuoted 4 lines · David Laight
Replace the "ir" constraint with "er" so that constants over 2^31 get loaded into a register.
Signed-off-by David Laight <[email protected]>
Yep, that's right.
Quoted 25 lines
--- arch/x86/include/asm/local.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)arch/x86/include/asm/local.h +2
-2@@ -32,14 +32,14 @@ static inline void local_add(long i, local_t *l) { asmvolatile (_ASM_ADD"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }static inline void local_sub (long i,local_t *l) { asmvolatile (_ASM_SUB"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }/**
[tip: x86/asm] x86/local: Support large immediate values in local_(add|sub)()
In reply to David LaightThe following commit has been merged into the x86/asm branch of tip:
The following commit has been merged into the x86/asm branch of tip:
Commit-ID: 966bbfa5f24f601593a0890154e3fb5fddc51e6e Gitweb: https://git.kernel.org/tip/966bbfa5f24f601593a0890154e3fb5fddc51e6e Author: David Laight <[email protected]> AuthorDate: Mon, 03 Aug 2026 10:47:02 +01:00 Committer: Borislav Petkov (AMD) <[email protected]> CommitterDate: Wed, 23 Sep 2026 13:16:13 -07:00
x86/local: Support large immediate values in local_(add|sub)()
Replace the "ir" constraint with "er" so that constants over 2^31 get loaded into a register due to ADD/SUB supporting only 32-bit signed immediates.
[ bp: Massage commit message. ]
--- arch/x86/include/asm/local.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/include/asm/local.h +2 -2
@@ -32,14 +32,14 @@ static inline void local_add(long i, local_t *l) { asmvolatile (_ASM_ADD"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }static inline void local_sub (long i,local_t *l) { asmvolatile (_ASM_SUB"%1,%0" :"+m" (l->a.counter) - :"ir" (i)); + :"er" (i)); }/**
Quoted 8 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
I suppose the percpu stuff works because of __pcpu_cast_4 truncating the value to u32 and then ignoring the whole signed/unsigned business. And __pcpu_reg_imm_8 has "re".
Quoted 8 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
Would be a good idea adding those cases to the test module.
Nicolas
Quoted 6 lines · On Mon, 3 Aug 2026 10:49:40 -0400 (EDT) Nicolas Pitre <[email protected]> wrote:
Quoted 4 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.
Quoted 6 lines
Quoted 4 lines
Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
Would be a good idea adding those cases to the test module.
They fail to compile so it isn't a big deal.
David
Quoted 3 lines
Nicolas
Quoted 9 lines · On Mon, 3 Aug 2026 16:39:55 +0100 David Laight <[email protected]>…
Quoted 6 lines · On Mon, 3 Aug 2026 10:49:40 -0400 (EDT) Nicolas Pitre <[email protected]> wrote:
Quoted 4 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
Would be a good idea adding those cases to the test module.
They fail to compile so it isn't a big deal.
David, thanks for sorting this (and all for reviewing)
Seems like everyone is happy. What route is this taking upstream?
I held Rodrigo's driver to avoid the build breakage and would like to get it queued up early in next cycle. So not that urgent but nice to be able to tick it off the list!
Thanks,
Jonathan
Quoted 6 lines
David
Quoted 3 lines
Nicolas
Jonathan Cameron
maintainerQuoted 21 lines · On Sun, 23 Aug 2026 23:35:36 +0100 Jonathan Cameron…
Quoted 9 lines · On Mon, 3 Aug 2026 16:39:55 +0100 David Laight <[email protected]>…
Quoted 6 lines · On Mon, 3 Aug 2026 10:49:40 -0400 (EDT) Nicolas Pitre <[email protected]> wrote:
Quoted 4 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
Would be a good idea adding those cases to the test module.
They fail to compile so it isn't a big deal.
Quoted 8 lines
David, thanks for sorting this (and all for reviewing)
Seems like everyone is happy. What route is this taking upstream?
I held Rodrigo's driver to avoid the build breakage and would like to get it queued up early in next cycle. So not that urgent but nice to be able to tick it off the list!
Given I have a driver queued up behind this, shall I just take it through the drivers/iio tree?
I can do an immutable branch just in case anyone else needs it this cycle.
Jonathan
Quoted 11 lines
Thanks,
Jonathan
Quoted 6 lines
David
Quoted 3 lines
Nicolas
Jonathan Cameron
maintainerQuoted 33 lines · On Tue, 1 Sep 2026 17:51:01 +0100 Jonathan Cameron <[email protected]> wrote:
Quoted 21 lines · On Sun, 23 Aug 2026 23:35:36 +0100 Jonathan Cameron…
Quoted 9 lines · On Mon, 3 Aug 2026 16:39:55 +0100 David Laight <[email protected]>…
Quoted 6 lines · On Mon, 3 Aug 2026 10:49:40 -0400 (EDT) Nicolas Pitre <[email protected]> wrote:
Quoted 4 lines · David Laight
The x86 instruction set only supports 32bit signed immediate values for add/sub.
Replace the "ir" constraint with "er" to avoid build errors.Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Found by a patch that added used
mul_u64_add_u64_div_u64()to do a rounding divide by 2^32 (perhaps not the best way to do this).A quick grep only found one other affected file.
Would be a good idea adding those cases to the test module.
They fail to compile so it isn't a big deal.
Quoted 8 lines
David, thanks for sorting this (and all for reviewing)
Seems like everyone is happy. What route is this taking upstream?
I held Rodrigo's driver to avoid the build breakage and would like to get it queued up early in next cycle. So not that urgent but nice to be able to tick it off the list!
Quoted 5 lines
Given I have a driver queued up behind this, shall I just take it through the
drivers/iiotree?I can do an immutable branch just in case anyone else needs it this cycle.
I went ahead and picked these up on
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git ib-iio-x86-asm-fix-7.3 and merged that into the main IIO branch. I want to give plenty of time in next for the driver that was relying on them.
Currently this is all in my testing branch but I'll push that out as a non rebasing (ideally) branch a bit later in the week.
Thanks
Jonathan
Quoted 16 lines
Jonathan
Quoted 11 lines
Thanks,
Jonathan
Quoted 6 lines
David
Quoted 3 lines
Nicolas
Borislav Petkov
maintainerQuoted 7 lines · Jonathan Cameron
I went ahead and picked these up on
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git ib-iio-x86-asm-fix-7.3 and merged that into the main IIO branch. I want to give plenty of time in next for the driver that was relying on them.Currently this is all in my testing branch but I'll push that out as a non rebasing (ideally) branch a bit later in the week.
No, this is not how this works. x86 changes go through tip and if you need an immutable branch, we can give you a tag.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteQuoted 11 lines · Borislav Petkov
Quoted 7 lines · Jonathan Cameron
I went ahead and picked these up on
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git ib-iio-x86-asm-fix-7.3 and merged that into the main IIO branch. I want to give plenty of time in next for the driver that was relying on them.Currently this is all in my testing branch but I'll push that out as a non rebasing (ideally) branch a bit later in the week.
No, this is not how this works. x86 changes go through tip and if you need an immutable branch, we can give you a tag.
While x86 usually goes through tip and none of the x86 maintainers commented before Jonathan applied, it got positive feedback from hpa and peterz a month ago and iio depends on it.
So I suggest to do the practical thing and pull Jonathan's branch into tip. Technically that doesn't make a difference (apart from maybe branch vs tag preferences).
Best regards
Uwe
Borislav Petkov
maintainerQuoted 2 lines · Uwe Kleine-König
While x86 usually goes through tip and none of the x86 maintainers commented before Jonathan applied,
You mean it is easy to spot every question to x86 maintainers in the avalance of mails?
Quoted 2 lines
it got positive feedback from hpa and peterz a month ago and iio depends on it.
That's business as usual.
Quoted 3 lines
So I suggest to do the practical thing and pull Jonathan's branch into tip. Technically that doesn't make a difference (apart from maybe branch vs tag preferences).
It does make a difference when the merge window comes and we have to synchronize when to send what. And we send tip stuff very early.
Considering how early it is in the game, I'd prefer if I queue those into tip now and give you an immutable branch or tag and not worry about adding more stuff ontop later.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteQuoted 6 lines · Borislav Petkov
Quoted 2 lines · Uwe Kleine-König
While x86 usually goes through tip and none of the x86 maintainers commented before Jonathan applied,
You mean it is easy to spot every question to x86 maintainers in the avalance of mails?
No, there was no hidden offence, I only meant what I wrote.
Quoted 6 lines
Quoted 3 lines
So I suggest to do the practical thing and pull Jonathan's branch into tip. Technically that doesn't make a difference (apart from maybe branch vs tag preferences).
It does make a difference when the merge window comes and we have to synchronize when to send what. And we send tip stuff very early.
I don't see what you mean. If both the tip tree and the iio tree contain the same commit (with or without a tag on it), it doesn't matter who created that and when and in which repo it appeared first. The first to send it to Linus makes it new for him and all later PRs using it only introduce the follow-up commits. So if you pull Jonathan's branch you still can send the branch/tag that contains it whenever you like independant of when Jonathan sends out his PR.
Best regards
Uwe
Borislav Petkov
maintainerQuoted 7 lines · Uwe Kleine-König
I don't see what you mean. If both the tip tree and the iio tree contain the same commit (with or without a tag on it), it doesn't matter who created that and when and in which repo it appeared first. The first to send it to Linus makes it new for him and all later PRs using it only introduce the follow-up commits. So if you pull Jonathan's branch you still can send the branch/tag that contains it whenever you like independant of when Jonathan sends out his PR.
Yes, I'm going to have to merge that branch into tip now so I'd need the assurance from Jonathan that this branch is not going to change.
Also, those patches are not tip-conform, but whatever, not that important for a one-time thing.
What I really don't understand is, why this rush needs to happen now so that we completely do a one-off on the agreed upon process and we have to do all this unnecessary gymnastics?
We have plenty of time.
So why do we even have to debate this instead of you folks dropping this and we merge it through tip and then everything's going the usual way?
When people start merging x86 patches in their trees, when do you think the process will break down and we'll have to redo branches and go into a crazy dependency madness?
We're not merging other stuff through tip without an Ack - why can't you adhere to the process we've all agreed upon?
Yes, this can work now. Is it necessary? Absolutely not because it is a one-off and will get everyone involved, confused.
So please do not do this in the future. If we don't react to the mail, you can always ping us on IRC like other folks do.
Thx.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteJonathan Cameron
maintainerQuoted 11 lines · On Tue, 8 Sep 2026 09:55:01 -0700 Borislav Petkov <[email protected]> wrote:
Quoted 7 lines · Uwe Kleine-König
I don't see what you mean. If both the tip tree and the iio tree contain the same commit (with or without a tag on it), it doesn't matter who created that and when and in which repo it appeared first. The first to send it to Linus makes it new for him and all later PRs using it only introduce the follow-up commits. So if you pull Jonathan's branch you still can send the branch/tag that contains it whenever you like independant of when Jonathan sends out his PR.
Yes, I'm going to have to merge that branch into tip now so I'd need the assurance from Jonathan that this branch is not going to change.
That's what an immutable branch means to everyone I've ever shared them with in the past, but sure - it wouldn't change. Anyhow, easier solution below.
Quoted 20 lines
Also, those patches are not tip-conform, but whatever, not that important for a one-time thing.
What I really don't understand is, why this rush needs to happen now so that we completely do a one-off on the agreed upon process and we have to do all this unnecessary gymnastics?
We have plenty of time.
So why do we even have to debate this instead of you folks dropping this and we merge it through tip and then everything's going the usual way?
When people start merging x86 patches in their trees, when do you think the process will break down and we'll have to redo branches and go into a crazy dependency madness?
We're not merging other stuff through tip without an Ack - why can't you adhere to the process we've all agreed upon?
Quoted 7 lines
Yes, this can work now. Is it necessary? Absolutely not because it is a one-off and will get everyone involved, confused.
So please do not do this in the future. If we don't react to the mail, you can always ping us on IRC like other folks do.
Thx.
I've dropped the branch from IIO. That's fine because it was still being tested and hasn't gone out as non-rebasing yet.
Next time I'll maybe find an IRC gateway and ping you on that. I can't find any reference to that being your preference in the kernel docs. Given you have a helpful page on tip, might be worth adding a note. I might of course be missing it.
If it goes into a reasonably early rc, I'll just merge the relevant rc rather than needing an immutable. If next cycle, immutable please.
I started out a bit grumpy that I had to hold a non trivial series for a cycle because of an x86 bug (having been very happy when David fixed it incredibly quickly!), that got reviewed then disappeared down a hole and didn't look like it would ever be seen again. Meh, got me on a belligerent day.
Jonathan
Borislav Petkov
maintainerQuoted 2 lines · Jonathan Cameron
I've dropped the branch from IIO. That's fine because it was still being tested and hasn't gone out as non-rebasing yet.
Ack, will do first thing tomorrow.
Quoted 4 lines
Next time I'll maybe find an IRC gateway and ping you on that. I can't find any reference to that being your preference in the kernel docs. Given you have a helpful page on tip, might be worth adding a note. I might of course be missing it.
I'll send you a private note after this.
Quoted 2 lines
If it goes into a reasonably early rc, I'll just merge the relevant rc rather than needing an immutable. If next cycle, immutable please.
First one can go to Linus now, second one would go next cycle. Do you want to base ontop of both?
Quoted 5 lines
I started out a bit grumpy that I had to hold a non trivial series for a cycle because of an x86 bug (having been very happy when David fixed it incredibly quickly!), that got reviewed then disappeared down a hole and didn't look like it would ever be seen again. Meh, got me on a belligerent day.
No worries, happens to all of us.
Thanks!
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteJonathan Cameron
maintainerQuoted 11 lines · On Wed, 9 Sep 2026 20:45:27 -0700 Borislav Petkov <[email protected]> wrote:
Quoted 2 lines · Jonathan Cameron
I've dropped the branch from IIO. That's fine because it was still being tested and hasn't gone out as non-rebasing yet.
Ack, will do first thing tomorrow.
Quoted 4 lines
Next time I'll maybe find an IRC gateway and ping you on that. I can't find any reference to that being your preference in the kernel docs. Given you have a helpful page on tip, might be worth adding a note. I might of course be missing it.
Quoted 7 lines
I'll send you a private note after this.
Quoted 2 lines
If it goes into a reasonably early rc, I'll just merge the relevant rc rather than needing an immutable. If next cycle, immutable please.
First one can go to Linus now, second one would go next cycle. Do you want to base ontop of both?
Only need the first patch, so I'll just pick it up by merging an RC once it this is upstream.
Thanks,
Jonathan
Quoted 11 lines
Quoted 6 lines
I started out a bit grumpy that I had to hold a non trivial series for a cycle because of an x86 bug (having been very happy when David fixed it incredibly quickly!), that got reviewed then disappeared down a hole and didn't look like it would ever be seen again. Meh, got me on a belligerent day.
No worries, happens to all of us.
Thanks!
Borislav Petkov
maintainerQuoted 2 lines · Jonathan Cameron
Only need the first patch, so I'll just pick it up by merging an RC once it this is upstream.
Pushed out into tip:x86/urgent. That branch should be mainline with -rc3.
If something last-minute changes, lemme know and I'll do an immutable branch.
Thanks!
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteBorislav Petkov
maintainerQuoted 4 lines · Borislav Petkov
Pushed out into tip:x86/urgent. That branch should be mainline with -rc3.
If something last-minute changes, lemme know and I'll do an immutable branch.
It changed - -rc3 released and we didn't send the pull in time:
https://lore.kernel.org/r/[email protected]
I can let you know when Linus merges it.
Signature · 4 lines
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette