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;
Message-ID: <6a6f5552fac1427eafbca1288fe5d5cb0cb6a333.camel@linux.ibm.com>
Subject: Re: [PATCH v5 RESEND 10/17] s390: mm: Convert to GENERIC_IOREMAP
From:   Niklas Schnelle <schnelle@linux.ibm.com>
To:     Christoph Hellwig <hch@infradead.org>, Baoquan He <bhe@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-mm@kvack.org, arnd@arndb.de, christophe.leroy@csgroup.eu,
        agordeev@linux.ibm.com, wangkefeng.wang@huawei.com,
        David.Laight@aculab.com, shorne@gmail.com, willy@infradead.org,
        deller@gmx.de, 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
Date:   Wed, 17 May 2023 09:58:26 +0200
In-Reply-To: <ZGR15/aAYufCZ9qV@infradead.org>
References: <20230515090848.833045-1-bhe@redhat.com>
         <20230515090848.833045-11-bhe@redhat.com> <ZGR15/aAYufCZ9qV@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Tue, 2023-05-16 at 23:36 -0700, Christoph Hellwig wrote:
> On Mon, May 15, 2023 at 05:08:41PM +0800, Baoquan He wrote:
> > +#define ioremap_wc(addr, size)  \
> > +	ioremap_prot((addr), (size), pgprot_val(pgprot_writecombine(PAGE_KERN=
EL)))
>=20
> I'd move this out of line and just apply mio_wb_bit_mask directly
> instead of the unbox/box/unbox/box dance.
>=20
> > +#define ioremap_wt(addr, size)  \
> > +	ioremap_prot((addr), (size), pgprot_val(pgprot_writethrough(PAGE_KERN=
EL)))
>=20
> and just define this to ioremap_wc.  Note that defining _wt to _wc is
> very odd and seems wrong, but comes from the existing code.  Maybe the
> s390 maintainers can chime on on the background and we can add a comment
> while we're at it.

I'm a bit confused where you see ioremap_wt() defined to ioremap_wc()
in the existing code? Our current definitions are:


void __iomem *ioremap_wc(phys_addr_t addr, size_t size)
{
	return __ioremap(addr, size,
pgprot_writecombine(PAGE_KERNEL));
}

void __iomem *ioremap_wt(phys_addr_t addr, size_t size)
{
	return __ioremap(addr, size,
pgprot_writethrough(PAGE_KERNEL));
}

Now if we don't have support for the enhanced PCI load/store
instructions (memory I/O aka MIO) then yes this gets ignored and both
.._wc() and .._wt() act the same but if we do have them
pgprot_writecombine() / pgprot_writethrough() set respectively clear=20
the mio_wb bit in the PTE. It's a bit odd here because the exact
position of the bit is read from a firmware interface and could in
theory change but other than that it looks fine to me and yes I agree
that it would be odd and broken to define _wt to _wc.

Thanks,
Niklas