On Mon, 15 Mar 2021 at 10:16, Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Mar 15, 2021 at 10:12:31AM +0100, Greg KH wrote:
On Mon, Mar 15, 2021 at 10:08:49AM +0100, Greg KH wrote:
On Fri, Mar 12, 2021 at 11:07:39PM -0500, Sasha Levin wrote:
On Fri, Mar 12, 2021 at 09:28:56AM -0800, Nick Desaulniers wrote:
My mistake, meant to lop those last two commits off of 4.19.y, they were the ones I referred to earlier working their way through the ARM maintainers tree. Regenerated the series' (rather than edit the patch files) additionally with --base=auto. Re-attached.
Queued up, thanks!
This series seems to cause build breakages in a lot of places, so I'm going to drop the whole set of them now: https://lore.kernel.org/r/be846d89-ab5a-f02a-c05e-1cd40acc5baa@roeck-us.net and: https://lore.kernel.org/r/066efc42-0788-8668-2ff5-d431e77068b5@roeck-us.net
Nick, if you want these merged, can you fix up the errors and resend?
Perhaps you might want to run these through the tuxbuild tool before sending? You should have access to it...
Oops, wait, they are fine for 5.10.y, just 4.19 and 5.4 are broken, will go drop those patches only.
Also, these are a lot of churn for 5.4 and 4.19, I'm not convinced it's really needed there. Why again is this required?
I think backporting this stuff is causing more problems than it solves. Note that the 5.4 Thumb2 build is still broken today because it carries
eff8728fe698 vmlinux.lds.h: Add PGO and AutoFDO input sections
but does not carry
f77ac2e378be ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel mode
which is tagged as a fix for the former patch, and landed in v5.11. (Side question: anyone have a clue why the patch in question was never selected for backporting?)
So I really think we should apply more caution here, and have a *really* good story on why it is essential that these patches are backported. In this case, I am not convinced there is one.