Re: [PATCH] irqchip/gic-v3: fix OF_BAD_ADDR error handling

[Arnd Bergmann]

On Wed, Mar 24, 2021 at 11:14 AM Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> On Tue, 23 Mar 2021 22:06:22 +0000,
> Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > On Tue, Mar 23, 2021 at 6:18 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > >
> > > From: Arnd Bergmann <arnd@xxxxxxxx>
> > >
> > > When building with extra warnings enabled, clang points out a
> > > mistake in the error handling:
> > >
> > > drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > Looks like based on CONFIG_PHYS_ADDR_T_64BIT, phys_addr_t can be u64
> > or u32, but of_translate_address always returns a u64.  This is fine
> > for the current value of OF_BAD_ADDR, but I think there's a risk of
> > losing the top 32b of the return value of of_translate_address() here?
>
> If the DT describes a 64bit physical address, and that the (32bit)
> kernel isn't built to grok these addresses, then I'd say that the
> kernel cannot run on this HW, and that we don't need to worry much
> about this case.
>
> In general, CONFIG_PHYS_ADDR_T_64BIT must be selected by the arch code
> if anything above 32bit can be described in the PA space.

Right, this generally works fine, the OF_BAD_ADDR is just a little
hard to get right. Fortunately there are very few comparisons to
OF_BAD_ADDR in other drivers, so I don't think we have to do
anything about it. I looked through every other user of this and found
no problems there, either they use 64-bit temporaries, or they correctly
cast the results.

         Arnd