Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH v2 1/2] ARM: Fix some check warnings of tool sparse
To:     "Russell King (Oracle)" <linux@armlinux.org.uk>
CC:     <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>
References: <20221010095346.1957-1-thunder.leizhen@huawei.com>
 <20221010095346.1957-2-thunder.leizhen@huawei.com>
 <Y0RC213QSASPZekQ@shell.armlinux.org.uk>
From:   "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
Message-ID: <3c8c29a8-a757-8f9d-23c6-d5790ce01611@huawei.com>
Date:   Tue, 11 Oct 2022 10:13:50 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <Y0RC213QSASPZekQ@shell.armlinux.org.uk>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2022/10/11 0:05, Russell King (Oracle) wrote:
> On Mon, Oct 10, 2022 at 05:53:45PM +0800, Zhen Lei wrote:
>> Fix the following warnings:
>>  warning: incorrect type in initializer (different address spaces)
>>     expected unsigned short [noderef] __user *register __p
>>     got unsigned short [usertype] *
>>  warning: cast removes address space '__user' of expression
> 
> I have a general principle that not all warnings should be fixed,
> especially when it comes to sparse.

OK, I got it.

> 
> The aim is not to get to zero warnings - it's to get to a point where
> the code is correct, and plastering the code with __force casts means
> it isn't correct - you're just masking the warning.
> 
> So no, I really don't like this. And I really don't like seeing
> __force being used in open code in casts.

OK, I will clear only the first warning and leave the second warning.

> 

-- 
Regards,
  Zhen Lei