From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78F98C433EF for ; Mon, 14 Feb 2022 14:44:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BA9A6B0071; Mon, 14 Feb 2022 09:44:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86A3C6B007B; Mon, 14 Feb 2022 09:44:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 758C76B007D; Mon, 14 Feb 2022 09:44:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id 65C806B0071 for ; Mon, 14 Feb 2022 09:44:56 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 23B1C820AC80 for ; Mon, 14 Feb 2022 14:44:56 +0000 (UTC) X-FDA: 79141657392.27.0B1E458 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf29.hostedemail.com (Postfix) with ESMTP id 25EF512000D for ; Mon, 14 Feb 2022 14:44:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644849895; x=1676385895; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=HFmG+OgBd9vznO3th8A/8/1Fs68OM1eMkoqopq342RI=; b=hYZ5k5Bh5iH0wbXbTVEFowlAkbYMDB96rbp6fol55BtaNhjhfINZSwsg VeNYPzk5fTWmVbypDUnFDlNHwsdZcY+gvTsMsWq+fMEv8p5dMbbcpU81l jB0QOWsK1Pfr6+fXUQBnAKziH5QpdsWylXobLKFFV81Sr0bItUKE3YymF 61bTca5fkgtIjTpNi9K08qFIvKxBUV2GkzAVp+At9L3WJWJ1dveeY7oNM J32YBv+odXkmJQxPfx+W3FjFopyf3aJAviqMspDzVnILvM65DoI/igl9Z C7awVzUOE9gjU6yhDvaJZzXw7g+w3cEypS6tMqQYBLz/XGo9aEQubVQOT w==; X-IronPort-AV: E=McAfee;i="6200,9189,10257"; a="336529159" X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="336529159" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 06:44:53 -0800 X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="703113880" Received: from unknown (HELO smile.fi.intel.com) ([10.237.72.59]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 06:44:51 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nJca4-004ZQV-IV; Mon, 14 Feb 2022 16:43:56 +0200 Date: Mon, 14 Feb 2022 16:43:56 +0200 From: Andy Shevchenko To: Jan =?utf-8?B?RMSFYnJvxZs=?= Cc: kernel test robot , kbuild-all@lists.01.org, Linux Memory Management List , Wolfram Sang Subject: Re: [linux-next:master 4897/5417] drivers/i2c/busses/i2c-designware-amdpsp.c:165:25: sparse: sparse: incorrect type in argument 1 (different address spaces) Message-ID: References: <202202120520.NbWJGvF2-lkp@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 25EF512000D X-Stat-Signature: r7ex4x13z5its7z63n9cpypqze553urz Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=hYZ5k5Bh; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf29.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=andriy.shevchenko@linux.intel.com X-HE-Tag: 1644849894-579547 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 14, 2022 at 02:59:34PM +0100, Jan D=C4=85bro=C5=9B wrote: > pon., 14 lut 2022 o 14:28 Andy Shevchenko > napisa=C5=82(a): > > > > On Mon, Feb 14, 2022 at 01:27:35PM +0100, Jan D=C4=85bro=C5=9B wrote: > > > pt., 11 lut 2022 o 22:24 kernel test robot napisa=C5= =82(a): > > > > > > 159 > > > > 160 /* Helper to verify status returned by PSP */ > > > > 161 static int check_i2c_req_sts(struct psp_i2c_req *req) > > > > 162 { > > > > 163 int status; > > > > 164 > > > > > 165 status =3D readl(&req->hdr.status); > > > > > > Actually the above error points to something hidden but important - > > > for reading from command-response buffer, we shouldn't use __iomem > > > specifier (nor readl() family of functions) since this is normal > > > memory - however updated by PSP. Thus I will refactor this to use > > > 'volatile u32 *' and reading status by de-referencing pointer. > > > > Not sure volatile is a good idea. Perhaps READ_ONCE() is what you nee= d. > > Is this a system memory? >=20 > Yes, this is system memory. >=20 > Actually looking at asm-generic/rwonce.h: > #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&= (x)) > it is more-less based on volatile, so that compiler will not be able > to (among others) optimize out such reads of memory which may be > changed outside of the scope of "program". >=20 > I believe that I will get the same outcome from using READ_ONCE and > explicit volatile, is the first way preferred in the kernel? READ_ONCE() may be different on different arches. I believe that's why it's preferred. --=20 With Best Regards, Andy Shevchenko