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;
Date:   Fri, 12 Jun 2020 18:35:09 +0200
From:   Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To:     Greg Ungerer <gerg@linux-m68k.org>
Cc:     Marc Kleine-Budde <mkl@pengutronix.de>,
        kernel test robot <lkp@intel.com>,
        Henning Colliander <henning.colliander@evidente.se>,
        kbuild-all@lists.01.org, linux-kernel@vger.kernel.org,
        Jimmy Assarsson <extja@kvaser.com>,
        Christer Beskow <chbe@kvaser.com>
Subject: Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast
 removes address space '<asn:2>' of expression
Message-ID: <20200612163509.6ieqxm4peqcfgd7o@ltop.local>
References: <202006121356.lKucoVPo%lkp@intel.com>
 <e93fe895-a6b8-34ff-f9c8-00ec7138b1c1@pengutronix.de>
 <9b599221-3c15-909c-168a-766c554827d9@linux-m68k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9b599221-3c15-909c-168a-766c554827d9@linux-m68k.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote:
> Hi Marc,
> 
> On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
> > the k-build robot found this sparse problem, triggered by building a CAN driver
> > for m68k. Is this a problem in our CAN driver or in the m68k headers?
> 
> I suspect a problem with the m68k (specifically non-mmu) headers.

Indeed.

> I think this one is due to not forcing the volatile cast in __raw_write().
> So this change will fix that:
> 
> diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
> index 0498192e1d98..1bc739f1f1ad 100644
> --- a/arch/m68k/include/asm/io_no.h
> +++ b/arch/m68k/include/asm/io_no.h
> @@ -14,15 +14,15 @@
>   * that behavior here first before we include asm-generic/io.h.
>   */
>  #define __raw_readb(addr) \
> -    ({ unsigned char __v = (*(volatile unsigned char *) (addr)); __v; })
> +    ({ u8 __v = (*(__force volatile u8 *) (addr)); __v; })
>  #define __raw_readw(addr) \
> -    ({ unsigned short __v = (*(volatile unsigned short *) (addr)); __v; })
> +    ({ u16 __v = (*(__force volatile u16 *) (addr)); __v; })
>  #define __raw_readl(addr) \
> -    ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
> +    ({ u32 __v = (*(__force volatile u32 *) (addr)); __v; })
> -#define __raw_writeb(b, addr) (void)((*(volatile unsigned char *) (addr)) = (b))
> -#define __raw_writew(b, addr) (void)((*(volatile unsigned short *) (addr)) = (b))
> -#define __raw_writel(b, addr) (void)((*(volatile unsigned int *) (addr)) = (b))
> +#define __raw_writeb(b, addr) (void)((*(__force volatile u8 *) (addr)) = (b))
> +#define __raw_writew(b, addr) (void)((*(__force volatile u16 *) (addr)) = (b))
> +#define __raw_writel(b, addr) (void)((*(__force volatile u32 *) (addr)) = (b))

Look good to me but isn't easier to leave them undefined and include
asm-generic/io.h?

> > >     arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32
> 
> This one I am not sure about yet.
> Still investigating.

	swab32(__raw_readl(addr)) ?

Keeping __le32_to_cpu() will only force you to use ugly casts for no benefits
and the comment above explain clearly the situation about the endianness.

Best regards,
-- Luc