On Tue, Mar 15, 2022 at 12:27:29PM +0000, James Morse wrote: > On 3/15/22 12:20 PM, James Morse wrote: > > On 3/11/22 6:42 AM, Greg Kroah-Hartman wrote: > > > On Fri, Mar 11, 2022 at 12:48:59AM +0100, Pavel Machek wrote: > > > > What is going on here? > > > > > > > > > commit 5bdf3437603d4af87f9c7f424b0c8aeed2420745 upstream. > > > > > > > > Upstream commit 5bdf is very different from this. In particular, > > > > > > > > > arch/arm64/kvm/hyp/smccc_wa.S | 66 +++++++++++++++++++++++++++++++++++++++ > > > > > > > > I can't find smccc_wa.S, neither in mainline, nor in -next. And it > > > > looks buggy. I suspect loop_k24 should loop 24 times, but it does 8 > > > > loops AFAICT. Same problem with loop_k32. > > > > Yup, that's a bug. Thanks for spotting it! > > I'll post a replacement for this patch. > > Looking more closely at this: when I originally did this the 'new' code for stable was > in a separate patch to make it clear it was new code. Here it looks like Greg has merged > it into this patch. I did? I don't recall doing that at all, sorry. But getting the 5.10 arm64 tree into the stable queue was not easy from what I recall. > I'm not sure what the 'rules' are for this sort of thing, obviously Greg gets the last say. > > I'll try and restructure the other backports to look like this, it is certainly simpler > than trrying to pull all the prerequisites for all the upstream patches in. I tried to also take a lot of prerequisite patches for the cpu id stuff, to make those merges easier, so I have no problem with taking what is in Linus's tree to make backports simpler. But it's a balencing act, especially for tougher stuff like this :( thanks, greg k-h
