[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YMqZswFnSNKk4Z7B@atmark-techno.com>
Date: Thu, 17 Jun 2021 09:39:15 +0900
From: Dominique MARTINET <dominique.martinet@...ark-techno.com>
To: Konrad Rzeszutek Wilk <konrad@...nok.org>
Cc: Jianxiong Gao <jxgao@...gle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Christoph Hellwig <hch@....de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Horia Geantă <horia.geanta@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Lukas Hartmann <lukas@...mn.com>,
Aymen Sghaier <aymen.sghaier@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Marc Orr <marcorr@...gle.com>,
Erdem Aktas <erdemaktas@...gle.com>,
Peter Gonda <pgonda@...gle.com>
Subject: Re: swiotlb/caamjr regression (Was: [GIT PULL] (swiotlb)
stable/for-linus-5.12)
Konrad Rzeszutek Wilk wrote on Wed, Jun 16, 2021 at 08:27:39PM -0400:
> Thank you for testing that - and this is a bummer indeed.
Hm, actually not that surprising if it was working without the offset
adjustments and doing non-aligned mappings -- perhaps the nvme code just
needs to round the offsets down instead of expecting swiotlb to do it?
Note I didn't look at that part of the code at all, so I might be
stating the obvious in a way that's difficult to adjust...
> Dominique, Horia,
>
> Are those crypto devices somehow easily available to test out the
> patches?
The one I have is included in the iMX8MP and iMX8MQ socs, the later is
included in the mnt reform and librem 5 and both have evaluation
toolkits but I wouldn't quite say they are easy to get...
I'm happy to test different patch variants if Horia doesn't beat me to
it though, it's not as practical as having the device but don't hesitate
to ask if I can run with extra debugs or something.
--
Dominique
Powered by blists - more mailing lists