Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3996312pxa; Sun, 9 Aug 2020 19:52:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweTn0DKmPwLEVe17WXSOzEMlqY6XjSItiDRFUHVHaSe6PeLgJCt+bP07Hvxls68nd18/C3 X-Received: by 2002:a05:6402:1457:: with SMTP id d23mr19327141edx.149.1597027947620; Sun, 09 Aug 2020 19:52:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597027947; cv=none; d=google.com; s=arc-20160816; b=W1N1I2tpkLrfHMMfe2Nu5woN0YJaMmZggN2eObzCyL1W2pSunuv3rxSmlFSUcSL+4H tqMTPN/PMDdKUFBmTm1NEqPEh9XITzLKKPwdI4D7GLtnSUpnoin03O9yHB+mlZbi/cYA L9TfbU658ek9oT6f7pOTzrK7VC0Tse2RMwZ2EAsUF8t7yCSjBLRSPLSSriwwgkTddEoE GV0phSDFTKVOU9SsOMC43SVX6T8cWt8J5XgrDTcsTsIDlJVGYAU/UK5CP9CPNtnjLu6I Q+Fj1b6iZi0ehsfOmnOF6cpWkqZQtHxH6Lyrfz0XvJPQ/tagEGCmrec6IqUmjHkLlS1p aCaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=U/CuxxS/DCvKVuL8xQmcnCTMsodGSmQZJ3nTGmu4+6s=; b=y/OWtWrMqDMKQPthSnQFRfewF5tcq5Mbg/CDWltGJeuH0d6r41JHtCzDN4cBhdeUPk V+esZX08CaTm+MnOKQHBpFeEBi9ykcp+n+pdDgmOv9MNt/ob23U4KzoNRGrnvVFAjko0 QWRJpmP06Wgef5Ii/Wm7gYOMZgAZ1KX4p+XWCfTZ4jldp1bsH2rO+1IG8oL6Z+kvnls9 7w0vOE6V6Z48+PGMFsKarz3zCJXGPpzS75xjn84ndwDTkixGkhrIdqeogL30ajz0Lf/0 ga4QxBVa01A/rhcUZnzlD7Eci33wER7ekYJdidsRGjWghWH8/s8oXJUvsf6U8Afw8hnZ +zSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cz6si10988038edb.188.2020.08.09.19.52.04; Sun, 09 Aug 2020 19:52:27 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726415AbgHJCvC (ORCPT + 99 others); Sun, 9 Aug 2020 22:51:02 -0400 Received: from mga18.intel.com ([134.134.136.126]:25766 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbgHJCvC (ORCPT ); Sun, 9 Aug 2020 22:51:02 -0400 IronPort-SDR: OTgRWCw+6go1+kxFHwAaWK40/MkRB28P18gTXlzfpNeOJ9NWW+tDhfdD4wj4e1aD7L4a5B2kC5 cLMqCuQWmsHA== X-IronPort-AV: E=McAfee;i="6000,8403,9708"; a="141076296" X-IronPort-AV: E=Sophos;i="5.75,456,1589266800"; d="scan'208";a="141076296" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2020 19:51:01 -0700 IronPort-SDR: Yy9cvCnNMl0PLHMe4fgB7IiSG/qsjvfOta04elk2Ih3KEUfTPf+nLwngoG4uHBikyj7rnZSHO3 /O6L/9GE9/XA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,456,1589266800"; d="scan'208";a="494646071" Received: from shao2-debian.sh.intel.com (HELO [10.239.13.3]) ([10.239.13.3]) by fmsmga005.fm.intel.com with ESMTP; 09 Aug 2020 19:51:00 -0700 Subject: Re: [kbuild-all] Re: drivers/video/fbdev/pxafb.c:916:24: sparse: sparse: incorrect type in assignment (different address spaces) To: Luc Van Oostenryck , kernel test robot Cc: kbuild-all@lists.01.org, linux-kernel@vger.kernel.org References: <202008071833.kUoyxyIe%lkp@intel.com> <20200807115304.npzxzzcuxbn7td2h@ltop.local> From: Rong Chen Message-ID: <290fcc86-0519-7763-102b-4728eb94a614@intel.com> Date: Mon, 10 Aug 2020 10:50:22 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200807115304.npzxzzcuxbn7td2h@ltop.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/7/20 7:53 PM, Luc Van Oostenryck wrote: > On Fri, Aug 07, 2020 at 06:37:36PM +0800, kernel test robot wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >> head: 86cfccb66937dd6cbf26ed619958b9e587e6a115 >> commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces >> date: 7 weeks ago >> config: arm-randconfig-s031-20200807 (attached as .config) >> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 >> reproduce: >> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # apt-get install sparse >> # sparse version: v0.6.2-118-ge1578773-dirty >> git checkout 670d0a4b10704667765f7d18f7592993d02783aa >> # save the attached .config to linux build tree >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot >> >> >> sparse warnings: (new ones prefixed by >>) >> >>>> drivers/video/fbdev/pxafb.c:916:24: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void [noderef] __iomem *video_mem @@ got void * @@ >>>> drivers/video/fbdev/pxafb.c:916:24: sparse: expected void [noderef] __iomem *video_mem > Hi, > > since late June I receive several mails per day about this commit but > they are all false-positive. > Commit 670d0a4b10704667765f7d18f7592993d02783aa can't introduce *new* > warnings, it only change how address-spaces are displayed in sparse's > warnings (for example, the address space for __user pointers were > displayd as '', now it's nicely displayed as '__user', same > for '__iomem', '__percpu' and '__rcu'). > > Isn't it possible to ignore some commits like this one? Hi Luc, Sorry for the inconvenience, we'll ignore this commit firstly. > Or, even better, should it be possible to only report when a new > warning is effectively added, not when its content is simply modified? > If not it would be nice to be able to see the difference in a diff-like > format. Thanks for your advice, we'll seriously consider it. Best Regards, Rong Chen