Thread (26 messages) 26 messages, 4 authors, 2021-02-24

Re: [PATCH 0/8] arm64: Support FIQ controller registration

From: Mark Rutland <mark.rutland@arm.com>
Date: 2021-02-19 16:14:12
Also in: lkml

On Sat, Feb 20, 2021 at 12:41:01AM +0900, Hector Martin wrote:
Hi Mark,

Thanks for tackling this side of the problem!
No problem -- I have a vested interest in the arm64 exception management
code lookin the way I expect/prefer! ;)
On 19/02/2021 20.38, Mark Rutland wrote:
quoted
I'm hoping that we can somehow queue the first 6 patches of this series as a
base for the M1 support. With that we can either cherry-pick a later version of
the DAIF.IF patch here, or the M1 support series can take the FIQ handling
patch. I've pushed the series out to my arm64/fiq branch [4] on kernel.org,
atop v5.11.
Looks good! I cherry picked my updated version of the DAIF.IF patch into
your series at [1] (3322522d), and then rebased the M1 series on top of it
(with the change to use set_handle_fiq(), minus all the other obsoleted FIQ
stuff) at [2]. It all boots and works as expected.

I think it makes sense for you to take the DAIF.IF patch, as it goes along
with this series. Then we can base the M1 series off of it. 
Sure; that works for me!
If you think that works, I can send it off as a one-off reply to the
version in this series and we can review it here if you want, or
otherwise feel free to cherry-pick it into a v2 (CC as appropriate).
If you could do a one-off reply, that'd be fantastic -- that way
lore.kernel.org will archive it and it gives people a chance to provide
any tags or comments before the next respin of the whole series.
If this all makes sense, the v3 of the M1 series will then be based off of
this patchset as in [2], and I'll link to your tree in the cover letter so
others know where to apply it.
As a heads-up, I'm currently treating my arm64/fiq branch as unstable
(and I've already applied a typo fix since this posting), but I can tag
versions of that to make it possible to refer to a specific version.

I'll make sure to do that once I fold in the new DAIF.[IF] patch, since
I assume that's the first version worth noting as a base.
Arnd (CCed) is going to be merging that one via the SoC tree, so as
long as we coordinate a stable base once everything is reviewed and
ready to merge, I believe it should all work out fine on the way up.
That sounds about right to me.

I think the first step is for Marc and I to figure out how the core IRQ
bits go in (some of that might be an fix early in the current v5.12
cycle), and I'd expect to have a stable branch atop somewhere between
v5.12-rc1 and v5.12-rc4. For context, usually the arm64 core bits get
based on the previous rc3/rc4.

Thanks,
Mark.
Just for completeness, the current DAIF.IF patch in the context of the
original series is at [3] (4dd6330f), in case that's useful to someone for
some reason (since there were conflicts due to the refactoring happening
before it, it changed a bit).

[1] https://github.com/AsahiLinux/linux/tree/fiq
[2] https://github.com/AsahiLinux/linux/tree/upstream-bringup-v3
[3] https://github.com/AsahiLinux/linux/tree/upstream-bringup-v2.5

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help