From: Baoquan He <bhe@redhat.com>
To: Niklas Schnelle <schnelle@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, hch@infradead.org,
agordeev@linux.ibm.com, wangkefeng.wang@huawei.com,
christophe.leroy@csgroup.eu, David.Laight@aculab.com,
shorne@gmail.com, Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 09/11] s390: mm: Convert to GENERIC_IOREMAP
Date: Wed, 12 Oct 2022 17:20:29 +0800 [thread overview]
Message-ID: <Y0aG3bLkPKVKcuTv@MiWiFi-R3L-srv> (raw)
In-Reply-To: <d78edb587ecda0aa09ba80446d0f1883e391996d.camel@linux.ibm.com>
On 10/12/22 at 09:37am, Niklas Schnelle wrote:
> On Wed, 2022-10-12 at 13:52 +0800, Baoquan He wrote:
> > On 10/11/22 at 05:16pm, Niklas Schnelle wrote:
> > > On Sun, 2022-10-09 at 18:31 +0800, Baoquan He wrote:
> > > > By taking GENERIC_IOREMAP method, the generic ioremap_prot() and
> > > > iounmap() are visible and available to arch. Arch only needs to
> > > > provide implementation of arch_ioremap() or arch_iounmap() if there's
> > > > arch specific handling needed in its ioremap() or iounmap(). This
> > > > change will simplify implementation by removing duplicated codes with
> > > > generic ioremap() and iounmap(), and has the equivalent functioality
> > > > as before.
> > > >
> > > > For s390, add hooks arch_ioremap() and arch_iounmap() for s390's special
> > > > operation when ioremap() and iounmap(), then ioremap_[wc|wt]() are
> > > > converted to use ioremap_prot() from GENERIC_IOREMAP.
> > > >
> > > > Signed-off-by: Baoquan He <bhe@redhat.com>
> > > > Cc: Niklas Schnelle <schnelle@linux.ibm.com>
> > > > Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> > > > Cc: Heiko Carstens <hca@linux.ibm.com>
> > > > Cc: Vasily Gorbik <gor@linux.ibm.com>
> > > > Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> > > > Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
> > > > Cc: Sven Schnelle <svens@linux.ibm.com>
> > > > Cc: linux-s390@vger.kernel.org
> > > > ---
> > > > v2->v3:
> > > > - Add code comment inside arch_ioremap() to help uderstand the
> > > > obsucre code. Christoph suggested this, Niklas provided the
> > > > paragraph of text.
> > > >
> > > > arch/s390/Kconfig | 1 +
> > > > arch/s390/include/asm/io.h | 25 +++++++++------
> > > > arch/s390/pci/pci.c | 65 ++++++++------------------------------
> > > > 3 files changed, 30 insertions(+), 61 deletions(-)
> > > >
> > > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > > > index 318fce77601d..c59e1b25f59d 100644
> > > > --- a/arch/s390/Kconfig
> > > > +++ b/arch/s390/Kconfig
> > > > @@ -135,6 +135,7 @@ config S390
> > > > select GENERIC_SMP_IDLE_THREAD
> > > > select GENERIC_TIME_VSYSCALL
> > > > select GENERIC_VDSO_TIME_NS
> > > > + select GENERIC_IOREMAP
> > >
> > > I think you should add the "if PCI" from the diff in your last mail to
> > > this patch.
> >
> > That's reasonable, will do.
> >
> > The code change in driver should be posted separately to get reviewing
> > from the relevant drvier maintainers. I may wrap it into this series in
> > next post so that people know its background.
>
> I agree about doing the driver change separately. Since the problem
> already exists one could send it separately. If you want I can take of
> that too.
Both is fine to me, since you suggested the fix.
>
> >
> > > > select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> > > > select HAVE_ARCH_AUDITSYSCALL
> > > > select HAVE_ARCH_JUMP_LABEL
> > ......
> > > > diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> > > > index 73cdc5539384..3c00dc7d79bc 100644
> > > > --- a/arch/s390/pci/pci.c
> > > > +++ b/arch/s390/pci/pci.c
> > > > @@ -244,64 +244,25 @@ void __iowrite64_copy(void __iomem *to, const void *from, size_t count)
> > > > zpci_memcpy_toio(to, from, count);
> > > > }
> > > >
> > > > -static void __iomem *__ioremap(phys_addr_t addr, size_t size, pgprot_t prot)
> > > > +void __iomem *
> > > > +arch_ioremap(phys_addr_t *paddr, size_t size, unsigned long *prot_val)
> > > > {
> > > > - unsigned long offset, vaddr;
> > > > - struct vm_struct *area;
> > > > - phys_addr_t last_addr;
> > > > -
> > > > - last_addr = addr + size - 1;
> > > > - if (!size || last_addr < addr)
> > > > - return NULL;
> > > > -
> > > > + /*
> > > > + * When PCI MIO instructions are unavailable the "physical" address
> > > > + * encodes a hint for accessing the PCI memory space it represents.
> > > > + * Just pass it unchanged such that ioread/iowrite can decode it.
> > > > + */
> > > > if (!static_branch_unlikely(&have_mio))
> > > > - return (void __iomem *) addr;
> > > > -
> > > > - offset = addr & ~PAGE_MASK;
> > > > - addr &= PAGE_MASK;
> > > > - size = PAGE_ALIGN(size + offset);
> > > > - area = get_vm_area(size, VM_IOREMAP);
> > > > - if (!area)
> > > > - return NULL;
> > > > -
> > > > - vaddr = (unsigned long) area->addr;
> > > > - if (ioremap_page_range(vaddr, vaddr + size, addr, prot)) {
> > > > - free_vm_area(area);
> > > > - return NULL;
> > > > - }
> > > > - return (void __iomem *) ((unsigned long) area->addr + offset);
> > > > + return (void __iomem *) *paddr;
> > >
> > > nit: no space after the cast
> >
> > Sorry, remember you pointed this out in v2, while I didn't get what
> > it is. Could you be more specific or give the right line of code?
> >
> > Are you suggesting below line?
> >
> > - return (void __iomem *) ((unsigned long) area->addr + offset);
> > + return (void __iomem *)*paddr;
>
> Yes, though I did just check and somehow checkpatch doesn't complain,
> maybe because of the dereference. I do think I remember it complaining
> but I guess if it doesn't you might as well keep it this way.
OK, I will keep it unless checkpatch complaim about it. Thanks.
next prev parent reply other threads:[~2022-10-12 9:21 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 10:31 [PATCH v3 00/11] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way Baoquan He
2022-10-09 10:31 ` [PATCH v3 01/11] hexagon: mm: Convert to GENERIC_IOREMAP Baoquan He
2022-10-09 16:39 ` Christophe Leroy
2022-10-10 0:17 ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 02/11] openrisc: mm: remove unneeded early ioremap code Baoquan He
2022-10-09 10:31 ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 03/11] mm/ioremap: change the return value of io[re|un]map_allowed and rename Baoquan He
2022-10-09 10:31 ` Baoquan He
2022-10-09 11:13 ` Kefeng Wang
2022-10-09 11:13 ` Kefeng Wang
2022-10-10 0:25 ` Baoquan He
2022-10-10 0:25 ` Baoquan He
2022-10-10 0:55 ` Kefeng Wang
2022-10-10 0:55 ` Kefeng Wang
2022-10-09 10:31 ` [PATCH v3 04/11] mm: ioremap: allow ARCH to have its own ioremap definition Baoquan He
2022-10-09 10:31 ` [PATCH v3 05/11] arc: mm: Convert to GENERIC_IOREMAP Baoquan He
2022-10-09 10:31 ` Baoquan He
2022-10-12 10:17 ` Christophe Leroy
2022-10-12 10:17 ` Christophe Leroy
2022-10-13 9:51 ` Baoquan He
2022-10-13 9:51 ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 06/11] ia64: " Baoquan He
2022-10-09 10:31 ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 07/11] openrisc: " Baoquan He
2022-10-09 10:31 ` Baoquan He
2022-10-09 10:31 ` [PATCH v3 08/11] parisc: " Baoquan He
2022-10-09 10:31 ` [PATCH v3 09/11] s390: " Baoquan He
2022-10-09 13:54 ` kernel test robot
2022-10-10 10:38 ` Baoquan He
2022-10-10 10:38 ` Baoquan He
2022-10-10 11:53 ` Niklas Schnelle
2022-10-10 11:53 ` Niklas Schnelle
2022-10-11 3:00 ` Baoquan He
2022-10-11 3:00 ` Baoquan He
2022-10-11 15:16 ` Niklas Schnelle
2022-10-12 5:52 ` Baoquan He
2022-10-12 7:37 ` Niklas Schnelle
2022-10-12 9:20 ` Baoquan He [this message]
2022-10-09 10:31 ` [PATCH v3 10/11] sh: " Baoquan He
2022-10-09 14:16 ` kernel test robot
2022-10-09 10:31 ` [PATCH v3 11/11] xtensa: " Baoquan He
2022-10-09 16:12 ` kernel test robot
2022-10-10 2:47 ` Baoquan He
2022-10-10 2:47 ` Baoquan He
2022-10-12 10:08 ` [PATCH v3 00/11] mm: ioremap: Convert architectures to take GENERIC_IOREMAP way Christophe Leroy
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=Y0aG3bLkPKVKcuTv@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=David.Laight@aculab.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=shorne@gmail.com \
--cc=svens@linux.ibm.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.