[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d5c41a6-0478-bd5c-a37b-06a37101fc31@huawei.com>
Date: Thu, 28 Apr 2022 14:16:39 +0800
From: Kefeng Wang <wangkefeng.wang@...wei.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>
Subject: Re: [PATCH 2/4] mm: ioremap: Add arch_ioremap/iounmap_check()
On 2022/4/28 1:04, Andrew Morton wrote:
> On Wed, 27 Apr 2022 20:14:11 +0800 Kefeng Wang <wangkefeng.wang@...wei.com> wrote:
>
>> Add special check hook for architecture to verify addr, size
>> or prot when ioremap() or iounmap(), which will make the generic
>> ioremap more useful.
>>
>> ...
>>
>> --- a/include/asm-generic/io.h
>> +++ b/include/asm-generic/io.h
>> @@ -964,6 +964,9 @@ static inline void iounmap(volatile void __iomem *addr)
>> #elif defined(CONFIG_GENERIC_IOREMAP)
>> #include <linux/pgtable.h>
>>
>> +bool arch_ioremap_check(phys_addr_t addr, size_t size, unsigned long prot);
>> +bool arch_iounmap_check(void __iomem *addr);
> Pet peeve. The word "check" is a poor one. I gives no sense of what
> the function is checking and it gives no sense of how the function's
> return value relates to the thing which it checks.
>
> Maybe it returns 0 on success and -EINVAL on failure. Don't know!
>
> Don't you think that better names would be io_remap_ok(),
> io_remap_valid(), io_remap_allowed(), etc?
Will use arch_ioremap/unmap_allowed(), and I'd like to keep return bool
for now if there is no special requirements.
>
>
> Other than that,
>
> Acked-by: Andrew Morton <akpm@...ux-foundation.org>
Thanks.
> .
Powered by blists - more mailing lists