Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp1925369ybb; Fri, 29 Mar 2019 14:20:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqwjFWjTmXQN7Y6Ydz4QkiWMlci6fr4qhgOk3m8iiMY1IuHqC+2iVNrC+/et5j+oZ/g2LtXe X-Received: by 2002:a65:6091:: with SMTP id t17mr47529209pgu.328.1553894429049; Fri, 29 Mar 2019 14:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553894429; cv=none; d=google.com; s=arc-20160816; b=taTYDm1QH7PNgpeGkBqcLC7CFfLInxu5KrBsMms4geZy+WI/zrkrYcdiZi4NwpNyCB lpcw8W7JYtcyNK3jsuBxHKKpN73SImoNezaPZuq8s0/enhUYtqwtr88HKGxk61ye/yZX X0QAscT4iIARlyPQ5lLhrE/VXYz/MrTXhNqbhZCJ0225mqIq8ob6vwpGrN0nTT8fz5gf 5hkJaKLSM7bu+Plv9AtoztIP8D0QY9aXqaPYEUuQ7IbEKHDah910f+3XPfIIByDRInT0 4eBM8cws7mFbbMiNepYTrFeVKsthQL3m70KNoAmGt1RLxIXwhgYkiCoOds/3hKn3eEKK iyhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4pQ7tDekHozc1girhjFRBmExj8JbTOaw9anomtPC8ws=; b=NR1NzXC7NTxF0k6PY7/SrL2BjQbIaX5U2FnKOXOKuzzs7vYgoGM9wPh6j5XHwFverb mru29AigvFPKxM/sC/GRq/bc9BdGEIxmyoUZqZVf4dNbjx6TtgVCZK5VD5bfozPBW9Mt 8nk8al+qYxa3BXHuP0VhsocA6/rifGSyY/QyHDa1SJN/q0MWSv7MFSdklKQlzjhU6BRx OeAcznE153Zi7yK+ivfZvuhTBWHDDiXqtHhS1vONaGqEvQA2lZA73NnRFZbSDUhWE9hF YAkh2tVxstMc7mOiMROA0zLUpuUgCXTOcQcsUPzfFj7XkI9BqZj4PhNEocgJ4KXJolY4 CumQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RSnF650g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l65si2750095plb.338.2019.03.29.14.20.12; Fri, 29 Mar 2019 14:20:29 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RSnF650g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730001AbfC2VTb (ORCPT + 99 others); Fri, 29 Mar 2019 17:19:31 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:46916 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729484AbfC2VTa (ORCPT ); Fri, 29 Mar 2019 17:19:30 -0400 Received: by mail-oi1-f195.google.com with SMTP id x188so2775110oia.13 for ; Fri, 29 Mar 2019 14:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4pQ7tDekHozc1girhjFRBmExj8JbTOaw9anomtPC8ws=; b=RSnF650gigpL0fFv5eOwHHEhqEg13rRKKandV5oHd1WrzR9XPBGcqwkoLWo8i2/Gak vaUjx0t4RBEbbHXNNxg9speMyZb+CLbtkG1lX7uJtMJJedLd2IfQUxYTQeSRqtkj4u/O TWx85r1XviQ+y/zvlrZwyePUxcHjZ23dTtwGP3jPNkgfCDJ6a5xe4meSXM10BQO6WdzQ uqvQ5wOC6FIKj+iDVm/ZS6Q7Ztx4h5lwHFEV7fQhNi3dFFc4RL3Hp7sRw3+yg7ctrSX6 b68bE91lzwVIeU8QdGf5/V7knwU0FHDDCfnAAOX/jn+OlKzZv+/yGvQ8oRbZo1Fbt21v 4F+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4pQ7tDekHozc1girhjFRBmExj8JbTOaw9anomtPC8ws=; b=GPCIscCciyjyR4YhYdCoeBpe/PkzqtydicfETolVrochCWpqU8VImaXn/G9YfUVZdO B2QTN4iXZioMC+NhPYh31WMnqsmIpymZMOcRafSfPPSBTXGLPeXCqfp1UCOsrR2OWD/P 2pIpX/bHLilZ0cTkasGaFGh7qlg5Mq/FtF1U9p+QP1aTOygHQIkKilA9BIlxTUWEf/S/ BYz9MEkHkSN17Lfph4Pg9UplVSd9bs4zZ0YlstyQDTK77/nPKjq/e402Q2XOunIwAT1s GjATECtUEZStAVPjNWS0FoR+AXDdQ87xeO3k5r9ImP2RsPsyzSA3Tdj75e7AU8rMHu1S yoNQ== X-Gm-Message-State: APjAAAXPiqXv/nZZxrIiNoa+rA5UXqJnv4Exdx+VMBK4wkrVzvfbd59o jih+DXEZLv+GRVOxs6JFLpMsaVOWuIwi18UpW+NqiA== X-Received: by 2002:aca:360a:: with SMTP id d10mr5210537oia.68.1553894369516; Fri, 29 Mar 2019 14:19:29 -0700 (PDT) MIME-Version: 1.0 References: <20190328225925.241998-1-jannh@google.com> <530a0823-5dcd-9006-2057-ae5b9da2389a@codeaurora.org> In-Reply-To: From: Jann Horn Date: Fri, 29 Mar 2019 22:19:03 +0100 Message-ID: Subject: Re: [PATCH] x86/calgary: fix bitcast type warnings To: Mukesh Ojha , Logan Gunthorpe , =?UTF-8?Q?Horia_Geant=C4=83?= Cc: Muli Ben-Yehuda , Jon Mason , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , iommu@lists.linux-foundation.org, kernel list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +Logan Gunthorpe and Horia Geant=C4=83, since they've written a bunch of th= is code On Fri, Mar 29, 2019 at 5:48 PM Jann Horn wrote: > On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha wrote: > > On 3/29/2019 4:29 AM, Jann Horn wrote: > > > The sparse checker attempts to ensure that all conversions between > > > fixed-endianness numbers and numbers with native endianness are expli= cit. > > > However, the calgary code reads and writes big-endian numbers from/to= IO > > > memory using {read,write}{l,q}(), which return native-endian numbers. > > > > > > This could be addressed by putting __force casts all over the place, = but > > > that would kind of defeat the point of the warning. Instead, create n= ew > > > helpers {read,write}{l,q}_be() for big-endian IO that convert from/to > > > native endianness. > > > > > > Most of this patch is a straightforward conversion; the following par= ts > > > aren't just mechanical replacement: > > > > > > - ->tar_val is now a native-endian number instead of big-endian > > > - calioc2_handle_quirks() did `cpu_to_be32(readl(target))` when it > > > intended to do `be32_to_cpu(readl(target))` (but that has no actu= al > > > effects outside of type warnings) > > > > > > This gets rid of 108 lines of sparse warnings. > > > > > > Signed-off-by: Jann Horn > > > --- > > > compile-tested only > > > > > > arch/x86/kernel/pci-calgary_64.c | 108 ++++++++++++++++++----------= --- > > > 1 file changed, 64 insertions(+), 44 deletions(-) > > > > > > diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-c= algary_64.c > > > index c70720f61a34..36cd66d940fb 100644 > > > --- a/arch/x86/kernel/pci-calgary_64.c > > > +++ b/arch/x86/kernel/pci-calgary_64.c > > > @@ -534,6 +534,26 @@ static inline int is_cal_pci_dev(unsigned short = device) > > > return (is_calgary(device) || is_calioc2(device)); > > > } > > > > > > Can the existing api's not be used here like iowrite64be/ioread64be/ or > > similar variant in "include/asm-generic/io.h" > > Oooh! I didn't realize that those exist. I'll change that and send a v2. Actually, that doesn't work at the moment on x86-64: include/asm-generic/io.h only defines these things if CONFIG_GENERIC_IOMAP isn't defined; and X86 unconditionally defines it. With CONFIG_GENERIC_IOMAP set, these functions are provided by include/asm-generic/iomap.h. include/asm-generic/iomap.h has extern definitions of them: extern unsigned int ioread8(void __iomem *); extern unsigned int ioread16(void __iomem *); extern unsigned int ioread16be(void __iomem *); extern unsigned int ioread32(void __iomem *); extern unsigned int ioread32be(void __iomem *); #ifdef CONFIG_64BIT extern u64 ioread64(void __iomem *); extern u64 ioread64be(void __iomem *); #endif [...] extern void iowrite8(u8, void __iomem *); extern void iowrite16(u16, void __iomem *); extern void iowrite16be(u16, void __iomem *); extern void iowrite32(u32, void __iomem *); extern void iowrite32be(u32, void __iomem *); #ifdef CONFIG_64BIT extern void iowrite64(u64, void __iomem *); extern void iowrite64be(u64, void __iomem *); #endif The definitions for these are in lib/iomap.c, except that there are no definitions for ioread64be() and iowrite64be(); if you try to use them, you get linker errors. I guess maybe the fix for that would be to, in iomap.c, just implement iowrite64{,be} the same way as iowrite32{,be}, just under a "#ifdef CONFIG_64BIT"?