Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 24 Mar 2021 10:14:47 +0000
Message-ID: <87czvokgdk.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Arnd Bergmann <arnd@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Nathan Chancellor <nathan@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        LKML <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] irqchip/gic-v3: fix OF_BAD_ADDR error handling
In-Reply-To: <CAKwvOdkBEQdVC73_datkwa+meitAGskDgTEr5LzX6AEnE4xd-w@mail.gmail.com>
References: <20210323131842.2773094-1-arnd@kernel.org>
        <CAKwvOdkBEQdVC73_datkwa+meitAGskDgTEr5LzX6AEnE4xd-w@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Tue, 23 Mar 2021 22:06:22 +0000,
Nick Desaulniers <ndesaulniers@google.com> wrote:
> 
> On Tue, Mar 23, 2021 at 6:18 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > 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.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.