Received: by 10.223.185.116 with SMTP id b49csp657053wrg; Fri, 16 Feb 2018 05:11:43 -0800 (PST) X-Google-Smtp-Source: AH8x227INAUSf4PRzb5ceHJRT5h43h1Y9aAU+twpq55DofRT5UeQk7l0oo2IYLItfmx9G6RpcLM9 X-Received: by 2002:a17:902:848c:: with SMTP id c12-v6mr5987521plo.329.1518786703817; Fri, 16 Feb 2018 05:11:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518786703; cv=none; d=google.com; s=arc-20160816; b=SHAMXtk/vp2kz9gaTmRpYJ9m6AEbcekbhE/WNWsNYNiRfU51HKv7ZApSiKkNfvpOmV SqvAqyUxTVtD7qqKETbDIr1h73BAhIYXVa97ykuUCW7EppkiLSiNfQKoTjuUEM6WlMzx PETKTfmgT0/5ZG3rWENNLf7jGWV2lM0OuLAd29mKQX8R9lhajYf6S+m9VIbw3ztWe539 T+4ipghgYqKWoPvvMATdGKoGHw6WTRdy2x/LYTEwc+xN7GmaZ2LZBa2Ezw33GcbNwUHF FY/Xwjxi6eIfEPGTKrvTtmf8ghWlupv3i/C0ZL4cReQ+jN1bxcIp97UsLuR2NuK7ffp/ 2DOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=9BQVHqH1trABK5omGNsxNDruLI1/FOPnuSFCK00E3rk=; b=XyuX11PF7ejb+1Ii/8SgSZNcZ4xWaajuB26GjqZmBAefTKJUDt51meNhf3pCc8TE6b WswTrDe330CdD6QOEjnDQ5sImYOb6fan37GdB2hAnvRL5IzEhDUWmPmJ9yJKMOYPkDw9 5mvKSSq2MCTDF2XPjOTcuV+CxJzLXX2Ta5MANDmmCJm8w2D6LSyEZWU3dpY2yOoz9haN IWPNeRBgXvBgAlKWMzinxi3sOCWjFUW4+WYDTxJJtar4auu+infTDc5BPVAISqaR5ik3 Jbiys4QMJiLxEY4Db7N7Ks6loM7+NUJ+kIZ74K7baCPVOQIGE3QomVnpuy9mEfK6C0p2 ardQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m18-v6si1194030pli.760.2018.02.16.05.11.29; Fri, 16 Feb 2018 05:11:43 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1166420AbeBOSZo (ORCPT + 99 others); Thu, 15 Feb 2018 13:25:44 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53934 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1163288AbeBOSZl (ORCPT ); Thu, 15 Feb 2018 13:25:41 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 64C074023112; Thu, 15 Feb 2018 18:25:41 +0000 (UTC) Received: from redhat.com (ovpn-121-190.rdu2.redhat.com [10.10.121.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA3E110102FB; Thu, 15 Feb 2018 18:25:36 +0000 (UTC) Date: Thu, 15 Feb 2018 20:25:36 +0200 From: "Michael S. Tsirkin" To: Marc-Andre Lureau Cc: =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Linux Kernel Mailing List , Baoquan He , Sergio Lopez Pascual , "Somlo, Gabriel" , xiaolong.ye@intel.com Subject: Re: [PATCH v14 3/9] fw_cfg: fix sparse warnings in fw_cfg_sel_endianness() Message-ID: <20180215202216-mutt-send-email-mst@kernel.org> References: <20180214141850.4017-1-marcandre.lureau@redhat.com> <20180214141850.4017-4-marcandre.lureau@redhat.com> <20180214224149-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 15 Feb 2018 18:25:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 15 Feb 2018 18:25:41 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 15, 2018 at 10:34:28AM +0100, Marc-Andre Lureau wrote: > On Wed, Feb 14, 2018 at 9:46 PM, Michael S. Tsirkin wrote: > > On Wed, Feb 14, 2018 at 03:18:44PM +0100, Marc-Andr? Lureau wrote: > >> The function is used for both LE & BE target type, use __force casting. > >> > >> Fixes: > >> $ make C=1 CF=-D__CHECK_ENDIAN__ drivers/firmware/qemu_fw_cfg.o > >> > >> drivers/firmware/qemu_fw_cfg.c:55:33: warning: restricted __be16 degrades to integer > >> drivers/firmware/qemu_fw_cfg.c:55:52: warning: restricted __le16 degrades to integer > >> > >> Signed-off-by: Marc-Andr? Lureau > >> --- > >> drivers/firmware/qemu_fw_cfg.c | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c > >> index 90f467232777..85e693287d87 100644 > >> --- a/drivers/firmware/qemu_fw_cfg.c > >> +++ b/drivers/firmware/qemu_fw_cfg.c > >> @@ -52,7 +52,9 @@ static DEFINE_MUTEX(fw_cfg_dev_lock); > >> /* pick appropriate endianness for selector key */ > >> static inline u16 fw_cfg_sel_endianness(u16 key) > >> { > >> - return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key); > >> + return fw_cfg_is_mmio ? > >> + (u16 __force)cpu_to_be16(key) : > >> + (u16 __force)cpu_to_le16(key); > >> } > >> > >> /* read chunk of given fw_cfg blob (caller responsible for sanity-check) */ > > > > Well the caller does cpu_to_le16 on the result ... > > All this makes my head spin. > > > > IMHO what you want is a wrapper that does iowrite and iowritebe > > rather than __force. > > iowrite16(key) is the same as iowrite16(cpu_to_le16(key)) ? There is > no iowrite16le()... Yes. > Is this equivalent, and not introducing regressions? > > static inline u16 fw_cfg_sel_endianness(u16 key) > +static void fw_cfg_sel_endianness(u16 key) > { > - return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key); For mmio on LE it does 1 swap. On BE 1 swap. For non mmio on LE it does no swaps. On BE 1 swap. Fair summary? And is this actually the intended behaviour. > + if (fw_cfg_is_mmio) > + iowrite16be(key, fw_cfg_reg_ctrl); > + else > + iowrite16(key, fw_cfg_reg_ctrl); this behaves differently. donnu if that's a bug or a feature. You will have to find out. > } > > /* read chunk of given fw_cfg blob (caller responsible for sanity-check) */ > @@ -74,7 +77,7 @@ static inline void fw_cfg_read_blob(u16 key, > } > > mutex_lock(&fw_cfg_dev_lock); > - iowrite16(fw_cfg_sel_endianness(key), fw_cfg_reg_ctrl); > + fw_cfg_sel_endianness(key); > > > > > > >> -- > >> 2.16.1.73.g5832b7e9f2