Received: by 10.223.176.46 with SMTP id f43csp1076058wra; Fri, 19 Jan 2018 06:35:54 -0800 (PST) X-Google-Smtp-Source: ACJfBou3XnMoCo5TO57rIQZSAVVbRbz+DxAueY76AGa46ZTY9LkJZ9odW+B1CMq1xs4QYxmaQhzi X-Received: by 10.99.181.3 with SMTP id y3mr40719960pge.196.1516372553943; Fri, 19 Jan 2018 06:35:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516372553; cv=none; d=google.com; s=arc-20160816; b=p3nw64bBxeZ1MQP93G1SitpmcbIECLyns+ykwOyczZtBZHDn3tZnj9QDk+uFyHi5tz 9K3Jz6nF/ENRTqwPFJwpcc0kbTOb1RDUaDxodTB9zDRk+ZKV8DgQgaFbBNjzCuEbU0y5 p+UQjiyGVXVLAd91MjKuzAG2ZNrvkOIpv8YrRyeubS4JDkiccvKCKBeqPhfMrL1UnY9D 2dB8rldLlglsrIxDOINSj7Bhk3rhTrgWGRJqGctS/RLYFFQWFdnSDkGOcKcfk69q6a7V X1NINAvnmZC1lqWFeuWFrVvrejn7OIC13e1P1kNaQ/l4D/bDH8BNdQX1fsaPQ3oxSXQS egag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=7Mppc0onfWsrM1vYcrCymZYEmf2fmeYou9qnq8lAZJI=; b=V/uHYODuWAMDzpiCs1icDDT+O3TD23K7pQ+XywjbCt7BdydNg2W0QLqE9Do0fwsqsu k7yJMl+q3P2155ngLNdlNrZPuF9141Qr4PMULDZnHIMvtNB+10RvyGHqlKrji6uKKIUo sU68MVLbSIGHabILvJAH0SIB3Qi2UEqNOYaCaAIgGKPvR9uyhZwGdGl4BuhF1xbo+/DF QuRk+/mXgvtfIQJwmuUiN7oejKBC4hJMTYM/N6jjSL9OgUotRiGoAS6fzTeO/o619ED7 vpoCeqsxjk8ORqDguYEMpKwvsvSaJncwBwXmoEmRu86y78YeWwoFkWWu734FWwanQX1C yZkw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p2si8436166pgr.379.2018.01.19.06.35.39; Fri, 19 Jan 2018 06:35:53 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755929AbeASOdd (ORCPT + 99 others); Fri, 19 Jan 2018 09:33:33 -0500 Received: from mga05.intel.com ([192.55.52.43]:39908 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755878AbeASOd2 (ORCPT ); Fri, 19 Jan 2018 09:33:28 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2018 06:33:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,381,1511856000"; d="scan'208";a="20730272" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga003.jf.intel.com with ESMTP; 19 Jan 2018 06:33:23 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id A527DC5; Fri, 19 Jan 2018 16:33:22 +0200 (EET) From: Andy Shevchenko To: Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Andy Shevchenko , Hitoshi Mitake , "Mehta, Sohil" Subject: [PATCH v1] x86/io: Define readq()/writeq() to use 64-bit type Date: Fri, 19 Jan 2018 16:33:22 +0200 Message-Id: <20180119143322.16555-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.15.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since non atomic readq() and writeq() were added some of the drivers would like to use it in a manner of: #include ... pr_debug("Debug value of some register: %016llx\n", readq(addr)); However, lo_hi_readq() always returns __u64 data, while readq() on x86_64 defines it as unsigned long. and thus compiler warns about type mismatch, although they are both 64-bit on x86_64. Convert readq() and writeq() on x86 to operate on deterministic 64-bit type. The most of architectures in the kernel already are using either unsigned long long, or u64 type for readq() / writeq(). This change propagates consistency in that sense. While this is not an issue per se, though if someone wants to address it, the anchor could be the commit 797a796a13df ("asm-generic: architecture independent readq/writeq for 32bit environment") where non-atomic variants had been introduced. Note, there are only few users of above pattern and they will not be affected because they do cast returned value. The actual warning has been issued on not-yet-upstreamed code. Potentially we might get a new warnings if some 64-bit only code assigns returned value to unsigned long type of variable. This is assumed to be addressed on case-by-case basis. Reported-by: lkp Cc: Hitoshi Mitake Cc: "Mehta, Sohil" Signed-off-by: Andy Shevchenko --- arch/x86/include/asm/io.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 95e948627fd0..365f5ba9222b 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -94,10 +94,10 @@ build_mmio_write(__writel, "l", unsigned int, "r", ) #ifdef CONFIG_X86_64 -build_mmio_read(readq, "q", unsigned long, "=r", :"memory") -build_mmio_read(__readq, "q", unsigned long, "=r", ) -build_mmio_write(writeq, "q", unsigned long, "r", :"memory") -build_mmio_write(__writeq, "q", unsigned long, "r", ) +build_mmio_read(readq, "q", unsigned long long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long long, "=r", ) +build_mmio_write(writeq, "q", unsigned long long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long long, "r", ) #define readq_relaxed(a) __readq(a) #define writeq_relaxed(v, a) __writeq(v, a) -- 2.15.1