On Tue, Apr 28, 2020 at 05:01:43PM +0100, Will Deacon wrote:

On Tue, Apr 28, 2020 at 04:58:12PM +0100, Mark Brown wrote:

quoted

On Tue, Apr 28, 2020 at 04:18:16PM +0100, Will Deacon wrote:

quoted

On Tue, Apr 28, 2020 at 04:12:05PM +0100, Mark Brown wrote:

quoted

quoted

It's probably easier for me if you just use the existing branch, I've
already got a branch based on a merge down.

quoted

Okey doke, I'll funnel that in the direction of linux-next then. It does
mean that any subsequent patches for 5.8 that depend on BTI will need to
be based on this branch, so as long as you're ok with that then it's fine
by me (since I won't be able to apply patches if they refer to changes
introduced in the recent merge window).

That's not a problem, that's what I've got already and if I try to send
everything based off -rc3 directly the series would get unmanagably
large.  Actually unless you think it's a bad idea I think what I'll do
is go and send out a couple of the preparatory changes (the insn updates
and the last bit of annotation conversions) separately for that branch
while I finalize the revisions of the main BTI kernel bit, hopefully
that'll make the review a bit more approachable.

Okey doke, sounds good to me. I'm queuing stuff atm, so as long you tell
me what I need to apply things against then we should be good.

Just a heads up: I've renamed for-next/bti to for-next/bti-user, so it
doesn't get confusing with the pending in-kernel BTI patches. All the commit
SHAs remain unchanged.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel