Re: [PATCH] asm-generic: correct reference to GENERIC_LIB_DEVMEM_IS_ALLOWED

[Lukas Bulwahn <lukas.bulwahn@gmail.com>]

On Thu, Jul 21, 2022 at 8:52 AM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> On Wed, Jul 20, 2022 at 12:50 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thu, Jul 7, 2022 at 4:41 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > On Thu, Jul 7, 2022 at 3:07 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Thu, Jul 7, 2022 at 2:20 PM <Conor.Dooley@microchip.com> 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