Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753173AbcKTIVy (ORCPT ); Sun, 20 Nov 2016 03:21:54 -0500 Received: from mail-yw0-f196.google.com ([209.85.161.196]:36626 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbcKTIVx (ORCPT ); Sun, 20 Nov 2016 03:21:53 -0500 MIME-Version: 1.0 In-Reply-To: <20161119132003.GA19781@kroah.com> References: <1479491838-10311-1-git-send-email-sergio.paracuellos@gmail.com> <1479491838-10311-2-git-send-email-sergio.paracuellos@gmail.com> <20161119132003.GA19781@kroah.com> From: Sergio Paracuellos Date: Sun, 20 Nov 2016 09:21:51 +0100 Message-ID: Subject: Re: [PATCH v4] staging: slicoss: fix different address space warnings To: Greg KH Cc: devel@driverdev.osuosl.org, linux-kernel , Lior Dotan Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1430 Lines: 40 On Sat, Nov 19, 2016 at 2:20 PM, Greg KH wrote: > On Fri, Nov 18, 2016 at 06:57:18PM +0100, Sergio Paracuellos wrote: >> Remove incorrect __iomem annotation. >> >> This patch fix the following sparse warnings in slicoss driver: >> warning: incorrect type in assignment (different address spaces) >> >> Signed-off-by: Sergio Paracuellos >> --- >> drivers/staging/slicoss/slic.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h >> index 420546d..14d7555 100644 >> --- a/drivers/staging/slicoss/slic.h >> +++ b/drivers/staging/slicoss/slic.h >> @@ -380,7 +380,7 @@ struct slic_shmemory { >> dma_addr_t isr_phaddr; >> dma_addr_t lnkstatus_phaddr; >> dma_addr_t stats_phaddr; >> - struct slic_shmem_data __iomem *shmem_data; >> + struct slic_shmem_data *shmem_data; > > But, is this the correct fix? It looks like shmem_data is being treated > like a pointer to io memory, so we need to use the correct accessors for > that memory, and not just a "raw" pointer, right? Removing this marking > seems to be moving backwards... That was the intention of v3 of the patch. But after Dan suggestions I though that just removing this mark would be enough because it was wrong. I am a little lost now :) Cheers, Sergio Paracuellos > > thanks, > > greg k-h