linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	linux-input@vger.kernel.org, Daniel Mack <daniel@zonque.org>,
	Michael Hennerich <michael.hennerich@analog.com>,
	Tomohiro Yoshidomi <sylph23k@gmail.com>,
	Javier Martinez Canillas <javier@dowhile0.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Lauri Kasanen <cand@gmx.com>, Daniel Hung-yu Wu <hywu@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH 0/9] Input: Fix insufficent DMA alignment.
Date: Tue, 29 Nov 2022 17:23:56 -0800	[thread overview]
Message-ID: <Y4awrNpT00v6TItm@google.com> (raw)
In-Reply-To: <20221129091828.0000530d@Huawei.com>

On Tue, Nov 29, 2022 at 09:18:28AM +0000, Jonathan Cameron wrote:
> On Mon, 28 Nov 2022 10:16:31 -0800
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > Hi Jonathan,
> > 
> > On Sun, Nov 27, 2022 at 02:41:07PM +0000, Jonathan Cameron wrote:
> > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > 
> > > This problem was discovered in IIO as a side effect of the discussions about
> > > relaxing kmalloc alignment on arm64 and resulted in a series of large
> > > patch sets.
> > > 
> > > https://lore.kernel.org/linux-iio/20220508175712.647246-1-jic23@kernel.org/
> > > 
> > > Unsurprisingly there are cases of it in other subsystems.
> > > 
> > > The short version of this is that there are a few known arm64 chips where
> > > ___cacheline_aligned enforces 64 byte alignment which is what we typically
> > > want for performance optimization as the size of the L1 cache lines.
> > > However, further out in the cache hierarchy we have caches with 128 byte
> > > lines.  Those are the ones that matter for DMA safety.
> > > So we need the larger alignment guarantees of ARCH_KMALLOC_MINALIGN which
> > > in this case is 128 bytes.  
> > 
> > I wonder if we could have something like ____dmasafe_aligned instead of
> > sprinkling ARCH_KMALLOC_MINALIGN around?
> 
> I agree in principle and eventually that will be ARCH_DMA_MINALIGN.
> But it isn't useable yet for backports.

Sorry, I do not follow. Are talking about backports because the code is
broken in the mainline right now, or it will become broken when
Catalin's changes land? And even if it is broken right now why can't we
add

#define ____dmasafe_aligned __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN)))

somewhere in include/linux/cache.h? Then you can tweak it as needed
independently of kmalloc alignment and without need to touch drivers
again and it should be easy to backport still.

Thanks.

-- 
Dmitry

      reply	other threads:[~2022-11-30  1:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-27 14:41 [PATCH 0/9] Input: Fix insufficent DMA alignment Jonathan Cameron
2022-11-27 14:41 ` [PATCH 1/9] Input: psxpad - Fix padding for DMA safe buffers Jonathan Cameron
2022-11-27 14:41 ` [PATCH 2/9] Input: ad714x " Jonathan Cameron
2022-11-28  7:14   ` Hennerich, Michael
2022-11-27 14:41 ` [PATCH 3/9] Input: ad7887 " Jonathan Cameron
2022-11-28  7:14   ` Hennerich, Michael
2022-11-27 14:41 ` [PATCH 4/9] Input: ads7846 " Jonathan Cameron
2022-11-27 14:41 ` [PATCH 5/9] Input: cyttsp " Jonathan Cameron
2022-11-27 14:41 ` [PATCH 6/9] Input: surface3 " Jonathan Cameron
2022-11-27 16:26   ` Jonathan Cameron
2022-11-27 14:41 ` [PATCH 7/9] Input: n64joy - Fix DMA buffer alignment Jonathan Cameron
2022-11-27 16:48   ` Lauri Kasanen
2022-11-27 18:01     ` Jonathan Cameron
2022-11-28  6:49       ` Lauri Kasanen
2022-11-28 18:04     ` Dmitry Torokhov
2022-11-27 14:41 ` [PATCH 8/9] Input: atmel_captouch - Avoid suspect " Jonathan Cameron
2022-11-27 14:41 ` [PATCH 9/9] Input: elants - Fix " Jonathan Cameron
2022-11-28 18:16 ` [PATCH 0/9] Input: Fix insufficent DMA alignment Dmitry Torokhov
2022-11-29  9:18   ` Jonathan Cameron
2022-11-30  1:23     ` Dmitry Torokhov [this message]

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=Y4awrNpT00v6TItm@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=cand@gmx.com \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@zonque.org \
    --cc=hywu@google.com \
    --cc=javier@dowhile0.org \
    --cc=jic23@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=michael.hennerich@analog.com \
    --cc=sylph23k@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).