Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1455043ybt; Mon, 15 Jun 2020 00:10:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+XurpZpYxDiOKC2kQnFkfwYL3wTV//CdFSxqNXYHLUDvKk7d18PZs8pbGIgfLSeNef33E X-Received: by 2002:a05:6402:13ca:: with SMTP id a10mr23031235edx.224.1592205004961; Mon, 15 Jun 2020 00:10:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592205004; cv=none; d=google.com; s=arc-20160816; b=N6fI7tDbBVinFOGervLfMfVTuHZ3oSF/SmSmIeE6ch3MR674QdbgOGTcDxS+wWUxzl CdoZOV4F13MRMx1viX71Hr4tZ4/9AmlWUWG7gGpSJOrOwYACe4XXrQL8zl+C5Twjjuv/ kCl5xG69dVgHsBrv6pdlQsCEBJ/QUb0ZxvsMCdCM9ufWCz+nFuDh19fUoJ6HdX9Rnx75 ymIhvZ7zIhXT7no7IA8t8a+Lf8kGve3i4YNHBO8fmQpHekIv+Xdnct3jrQeReRXsK7Dz vFKb/QEOYbguPPWb0juyCiMIZe+4YcxHOFHex3XKUy6JN/GT4RXkVbqtoCGU76nzsIst Q4gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=kTjOCBlPVlnrCu0IN1s8O8tCqC42SLjW7XKvoGA7tcI=; b=h0CdcQtAjAEDJ508WkSKk6XNvqbZjAzUUXFT8347IhI+kNiEk62uGtsXXpLCPmRnry peuHHkbK7nbA8Pls23G8vj1oxNW9KXgfSPwlptPYhEBckIYrpGdovM0ocAjIsS7n84WN 20hsrmdBQlVHm5/Tc5w+v6UxwZgeU2ON8fNiy4I/A2ngWoiGUVPbk/oD8nKS1Xj2Sif4 TVDEwfimvXINd+kZ4l7jla4/edMGRoYnveVPZBjJby0ubNNYkBbMlBj9/P5a1WFeqE2q 24V+3bnriZG/LeBn/fZnMzj/oDfJyH8fbQO9Ng0ayrSN08V1UGjrZB6PopMmAA4KdyJq jhdA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dj11si2090468edb.333.2020.06.15.00.09.42; Mon, 15 Jun 2020 00:10:04 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728426AbgFOHHU (ORCPT + 99 others); Mon, 15 Jun 2020 03:07:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:51908 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728180AbgFOHHU (ORCPT ); Mon, 15 Jun 2020 03:07:20 -0400 Received: from [10.44.0.192] (unknown [103.48.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F354120707; Mon, 15 Jun 2020 07:07:16 +0000 (UTC) Subject: Re: drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression To: Luc Van Oostenryck Cc: Marc Kleine-Budde , kernel test robot , Henning Colliander , kbuild-all@lists.01.org, linux-kernel@vger.kernel.org, Jimmy Assarsson , Christer Beskow References: <202006121356.lKucoVPo%lkp@intel.com> <9b599221-3c15-909c-168a-766c554827d9@linux-m68k.org> <20200612163509.6ieqxm4peqcfgd7o@ltop.local> From: Greg Ungerer Message-ID: <044ff868-00f1-90a4-25e6-9f62f7a042ad@linux-m68k.org> Date: Mon, 15 Jun 2020 17:07:13 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612163509.6ieqxm4peqcfgd7o@ltop.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/6/20 2:35 am, Luc Van Oostenryck wrote: > On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote: >>>> 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. That is unfortunate, the use of le32_to_cpu() made it very clear what was going on - for those that don't choose to read comments. In any case that would seem to be the cleanest solution. Patch to follow. Regards Greg