All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Baoquan He <bhe@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"wangkefeng.wang@huawei.com" <wangkefeng.wang@huawei.com>,
	"schnelle@linux.ibm.com" <schnelle@linux.ibm.com>,
	"David.Laight@aculab.com" <David.Laight@aculab.com>,
	"shorne@gmail.com" <shorne@gmail.com>
Subject: Re: [RFC PATCH 3/8] mm/ioremap: Define generic_ioremap_prot() and generic_iounmap()
Date: Sun, 16 Oct 2022 16:54:32 +0000	[thread overview]
Message-ID: <d00b3561-8f79-23a7-ac87-89766adf6513@csgroup.eu> (raw)
In-Reply-To: <Y0u9ec0Bi+FWtyA5@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com>



Le 16/10/2022 à 10:14, Alexander Gordeev a écrit :
> On Wed, Oct 12, 2022 at 12:09:39PM +0200, Christophe Leroy wrote:
>> Define a generic version of ioremap_prot() and iounmap() that
>> architectures can call after they have performed the necessary
>> alteration to parameters and/or necessary verifications.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> 
> [...]
> 
>> diff --git a/mm/ioremap.c b/mm/ioremap.c
>> index 8652426282cc..9f34a8f90b58 100644
>> --- a/mm/ioremap.c
>> +++ b/mm/ioremap.c
>> @@ -11,8 +11,8 @@
>>   #include <linux/io.h>
>>   #include <linux/export.h>
>>   
>> -void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size,
>> -			   unsigned long prot)
>> +void __iomem *generic_ioremap_prot(phys_addr_t phys_addr, size_t size,
>> +				   pgprot_t prot)
>>   {
>>   	unsigned long offset, vaddr;
>>   	phys_addr_t last_addr;
>> @@ -28,7 +28,7 @@ void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size,
>>   	phys_addr -= offset;
>>   	size = PAGE_ALIGN(size + offset);
>>   
>> -	if (!ioremap_allowed(phys_addr, size, prot))
>> +	if (!ioremap_allowed(phys_addr, size, pgprot_val(prot)))
>>   		return NULL;
> 
> It seems to me ioremap_allowed() is not needed anymore.
> Whatever is checked here would move to architecture-
> specific implementation.

Yes can probably be removed as a follow-up. I didn't want to change 
existing implementations at the first place, and see what it looks like 
once all architectures have been looked at.

> 
>>   	area = get_vm_area_caller(size, VM_IOREMAP,
>> @@ -38,17 +38,24 @@ void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size,
>>   	vaddr = (unsigned long)area->addr;
>>   	area->phys_addr = phys_addr;
>>   
>> -	if (ioremap_page_range(vaddr, vaddr + size, phys_addr,
>> -			       __pgprot(prot))) {
>> +	if (ioremap_page_range(vaddr, vaddr + size, phys_addr, prot)) {
>>   		free_vm_area(area);
>>   		return NULL;
>>   	}
>>   
>>   	return (void __iomem *)(vaddr + offset);
>>   }
>> +
>> +#ifndef ioremap_prot
> 
> I guess, this is also needed:
> 
> #define ioremap_prot ioremap_prot

Why would it need that ? We are in ioremap.c, any define done here is 
exclusively seen here in this C file. It's not like a header file.

> 
>> +void __iomem *ioremap_prot(phys_addr_t phys_addr, size_t size,
>> +			   unsigned long prot)
>> +{
>> +	return generic_ioremap_prot(phys_addr, size, __pgprot(prot));
>> +}
>>   EXPORT_SYMBOL(ioremap_prot);
>> +#endif
>>   
>> -void iounmap(volatile void __iomem *addr)
>> +void generic_iounmap(volatile void __iomem *addr)
>>   {
>>   	void *vaddr = (void *)((unsigned long)addr & PAGE_MASK);
>>   
>> @@ -58,4 +65,11 @@ void iounmap(volatile void __iomem *addr)
>>   	if (is_vmalloc_addr(vaddr))
>>   		vunmap(vaddr);
>>   }
>> +
>> +#ifndef iounmap
> 
> Same here.

Same, I don't see what it would add.

> 
>> +void iounmap(volatile void __iomem *addr)
>> +{
>> +	generic_iounmap(addr);
>> +}
>>   EXPORT_SYMBOL(iounmap);
>> +#endif

  reply	other threads:[~2022-10-16 16:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 10:09 [RFC PATCH 0/8] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way (Alternative) Christophe Leroy
2022-10-12 10:09 ` [RFC PATCH 1/8] hexagon: mm: Convert to GENERIC_IOREMAP Christophe Leroy
2022-10-12 17:21   ` kernel test robot
2022-10-12 19:15   ` kernel test robot
2022-10-12 10:09 ` [RFC PATCH 2/8] openrisc: mm: remove unneeded early ioremap code Christophe Leroy
2022-10-12 10:09   ` Christophe Leroy
2022-10-12 16:47   ` Stafford Horne
2022-10-12 16:47     ` Stafford Horne
2022-10-12 10:09 ` [RFC PATCH 3/8] mm/ioremap: Define generic_ioremap_prot() and generic_iounmap() Christophe Leroy
2022-10-12 21:11   ` kernel test robot
2022-10-16  8:14   ` Alexander Gordeev
2022-10-16 16:54     ` Christophe Leroy [this message]
2022-10-12 10:09 ` [RFC PATCH 4/8] mm: ioremap: allow ARCH to have its own ioremap definition Christophe Leroy
2022-10-12 10:09 ` [RFC PATCH 5/8] arc: mm: Convert to GENERIC_IOREMAP Christophe Leroy
2022-10-12 10:09   ` Christophe Leroy
2022-10-12 10:09 ` [RFC PATCH 6/8] ia64: " Christophe Leroy
2022-10-12 10:09   ` Christophe Leroy
2022-10-12 10:09 ` [RFC PATCH 7/8] mm/ioremap: Consider IOREMAP space in generic ioremap Christophe Leroy
2022-10-12 10:39   ` Arnd Bergmann
2022-10-16  7:54     ` Alexander Gordeev
2022-10-16 11:51       ` Arnd Bergmann
2022-10-16 16:56         ` Christophe Leroy
2022-10-16 16:56           ` Christophe Leroy
2022-10-17 12:50         ` Michael Ellerman
2022-10-17 20:52           ` Arnd Bergmann
2022-10-12 10:09 ` [RFC PATCH 8/8] powerpc: mm: Convert to GENERIC_IOREMAP Christophe Leroy
2022-10-17  0:37 ` [RFC PATCH 0/8] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way (Alternative) Baoquan He
2022-10-17 17:06   ` Christophe Leroy
2022-10-19  0:25     ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d00b3561-8f79-23a7-ac87-89766adf6513@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=David.Laight@aculab.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=schnelle@linux.ibm.com \
    --cc=shorne@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.