Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field_max()
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        "David S. Miller" <davem@davemloft.net>,
        Johannes Berg <johannes@sipsolutions.net>,
        Jakub Kicinski <kuba@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <natechancellor@gmail.com>,
        Network Development <netdev@vger.kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>
References: <20200311024240.26834-1-elder@linaro.org>
 <20200401173515.142249-1-ndesaulniers@google.com>
 <3659efd7-4e72-6bff-5657-c1270e8553f4@linaro.org>
 <CAKwvOdn7TpsZJ70mRiQARJc9Fy+364PXSAiPnSpc_M9pOaXjGw@mail.gmail.com>
From:   Alex Elder <elder@linaro.org>
Message-ID: <3c878065-8d25-8177-b7c4-9813b60c9ff6@linaro.org>
Date:   Wed, 1 Apr 2020 14:44:31 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAKwvOdn7TpsZJ70mRiQARJc9Fy+364PXSAiPnSpc_M9pOaXjGw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 4/1/20 2:13 PM, Nick Desaulniers wrote:
> On Wed, Apr 1, 2020 at 11:24 AM Alex Elder <elder@linaro.org> wrote:
>>
>> On 4/1/20 12:35 PM, Nick Desaulniers wrote:
>>>> Define FIELD_MAX(), which supplies the maximum value that can be
>>>> represented by a field value.  Define field_max() as well, to go
>>>> along with the lower-case forms of the field mask functions.
>>>>
>>>> Signed-off-by: Alex Elder <elder@linaro.org>
>>>> Acked-by: Jakub Kicinski <kuba@kernel.org>
>>>> ---
>>>> v3: Rebased on latest netdev-next/master.
>>>>
>>>> David, please take this into net-next as soon as possible.  When the
>>>> IPA code was merged the other day this prerequisite patch was not
>>>> included, and as a result the IPA driver fails to build.  Thank you.
>>>>
>>>>   See: https://lkml.org/lkml/2020/3/10/1839
>>>>
>>>>                                      -Alex
>>>
>>> In particular, this seems to now have regressed into mainline for the 5.7
>>> merge window as reported by Linaro's ToolChain Working Group's CI.
>>> Link: https://github.com/ClangBuiltLinux/linux/issues/963
>>
>> Is the problem you're referring to the result of a build done
>> in the midst of a bisect?
>>
>> The fix for this build error is currently present in the
>> torvalds/linux.git master branch:
>>     6fcd42242ebc soc: qcom: ipa: kill IPA_RX_BUFFER_ORDER
> 
> Is that right? That patch is in mainline, but looks unrelated to what
> I'm referring to.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fcd42242ebcc98ebf1a9a03f5e8cb646277fd78
> From my github link above, the issue I'm referring to is a
> -Wimplicit-function-declaration warning related to field_max.
> 6fcd42242ebc doesn't look related.

I'm very sorry, I pointed you at the wrong commit.  This one is
also present in torvalds/linux.git master:

  e31a50162feb bitfield.h: add FIELD_MAX() and field_max()

It defines field_max() as a macro in <linux/bitfield.h>, and
"gsi.c" includes that header file.

This was another commit that got added late, after the initial
IPA code was accepted.

>> I may be mistaken, but I believe this is the same problem I discussed
>> with Maxim Kuvyrkov this morning.  A different build problem led to
>> an automated bisect, which conluded this was the cause because it
>> landed somewhere between the initial pull of the IPA code and the fix
>> I reference above.
> 
> Yes, Maxim runs Linaro's ToolChain Working Group (IIUC, but you work
> there, so you probably know better than I do), that's the CI I was
> referring to.
> 
> I'm more concerned when I see reports of regressions *in mainline*.
> The whole point of -next is that warnings reported there get fixed
> BEFORE the merge window opens, so that we don't regress mainline.  Or
> we drop the patches in -next.

Can you tell me where I can find the commit id of the kernel
that is being built when this error is reported?  I would
like to examine things and build it myself so I can fix it.
But so far haven't found what I need to check out.

Thank you.

					-Alex