[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200807115304.npzxzzcuxbn7td2h@ltop.local>
Date: Fri, 7 Aug 2020 13:53:04 +0200
From: Luc Van Oostenryck <luc.vanoostenryck@...il.com>
To: kernel test robot <lkp@...el.com>
Cc: kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org
Subject: Re: drivers/video/fbdev/pxafb.c:916:24: sparse: sparse: incorrect
type in assignment (different address spaces)
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 <lkp@...el.com>
>
>
> 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 '<asn:1>', now it's nicely displayed as '__user', same
for '__iomem', '__percpu' and '__rcu').
Isn't it possible to ignore some commits like this one?
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.
Best regards,
-- Luc
Powered by blists - more mailing lists