On Thu, Jul 21, 2022 at 8:52 AM Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > On Wed, Jul 20, 2022 at 12:50 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Thu, Jul 7, 2022 at 4:41 PM Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > > On Thu, Jul 7, 2022 at 3:07 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Thu, Jul 7, 2022 at 2:20 PM <Conor.Dooley@xxxxxxxxxxxxx> wrote: > > > > > > lkft just found a build failure: > > > > > > > > https://gitlab.com/Linaro/lkft/users/arnd.bergmann/asm-generic/-/jobs/2691154818 > > > > > > > > I have not investigated what went wrong, but it does look like an actual > > > > regression, so I'll wait for Lukas to follow up with a new version of the patch. > > > > > > Thanks for your testing. I will look into it. Probably it is due to > > > some more rigor during builds (-Werror and new warning types in the > > > default build) since I proposed the patch in October 2021. That should > > > be easy to fix, but let us see. I will send a PATCH v2 soon. > > > > Any update on this? I have another bugfix for asm-generic now and was planning > > to send a pull request with both. If you don't have the updated patch > > ready yet, this > > will have to go into 5.21 instead. > > > > It is still on my TODO list for revisiting, but I had other work on > patches taking me longer than originally expected. I now moved this > patch revisiting to the top of my TODO list; so, I will certainly look > into this today. So far, I have not set up an arm64 build on my local > machine and have not used tuxbuild (which should simplify all this > setup)---the typical challenges for a "part-time kernel > contributor/janitor"... > > Arnd, I will certainly let you know by this evening (European time > zone) how far I got. If that is already too late, it is also perfectly > fine if this goes in 5.21 instead, but I will try my best to make it > 5.20 material. > Arnd, I can reproduce the error from your build system. I think I have an idea what the correct patch would actually be: - either make the function declaration completely unconditional, - or put the function declaration under #ifdef and not #ifndef. I guess the first should actually lead to some compiler warning (at W=2 or so) having a function declared multiple times, for some architectures. And hence, the second option is a better one. This is all educated guessing so far, so to confirm, I need to build the kernel with W=2 on the defconfig all architectures before and after patch application and see if I am right. This is going to take some build time on my local (home) machine. So, I hope that I can spend some time tomorrow on just kicking off builds and looking at diffs and then send out a working patch v2. Lukas
