Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753038AbcKSNT5 (ORCPT ); Sat, 19 Nov 2016 08:19:57 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:38892 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752690AbcKSNTy (ORCPT ); Sat, 19 Nov 2016 08:19:54 -0500 Date: Sat, 19 Nov 2016 14:20:03 +0100 From: Greg KH To: Sergio Paracuellos Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, liodot@gmail.com Subject: Re: [PATCH v4] staging: slicoss: fix different address space warnings Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1479491838-10311-2-git-send-email-sergio.paracuellos@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1094 Lines: 30 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... thanks, greg k-h