From: Arnd Bergmann <arnd@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Christoph Hellwig <hch@lst.de>,
Matthew Wilcox <willy@infradead.org>,
kernel test robot <lkp@intel.com>, Linux-MM <linux-mm@kvack.org>,
kbuild-all@lists.01.org, clang-built-linux@googlegroups.com,
open list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"David S. Miller" <davem@davemloft.net>,
Matteo Croce <mcroce@linux.microsoft.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Bogus struct page layout on 32-bit
Date: Fri, 16 Apr 2021 16:10:37 +0200 [thread overview]
Message-ID: <CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com> (raw)
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
>
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").
I completely missed this change in the past, and I don't really agree
with it either.
Most 32-bit Arm platforms are in fact limited to 32-bit DMA, even when they have
MMIO or RAM areas above the 4GB boundary that require LPAE.
> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using
> things like (__force u32) for example.
>
> Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.
This is of course a good idea, drivers should work with any
combination of 32-bit
or 64-bit phys_addr_t and dma_addr_t.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: kbuild-all@lists.01.org, kernel test robot <lkp@intel.com>,
clang-built-linux@googlegroups.com,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
Linux-MM <linux-mm@kvack.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
linux-fsdevel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Matteo Croce <mcroce@linux.microsoft.com>,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig <hch@lst.de>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Bogus struct page layout on 32-bit
Date: Fri, 16 Apr 2021 16:10:37 +0200 [thread overview]
Message-ID: <CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com> (raw)
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
>
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").
I completely missed this change in the past, and I don't really agree
with it either.
Most 32-bit Arm platforms are in fact limited to 32-bit DMA, even when they have
MMIO or RAM areas above the 4GB boundary that require LPAE.
> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using
> things like (__force u32) for example.
>
> Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.
This is of course a good idea, drivers should work with any
combination of 32-bit
or 64-bit phys_addr_t and dma_addr_t.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Christoph Hellwig <hch@lst.de>,
Matthew Wilcox <willy@infradead.org>,
kernel test robot <lkp@intel.com>, Linux-MM <linux-mm@kvack.org>,
kbuild-all@lists.01.org, clang-built-linux@googlegroups.com,
open list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"David S. Miller" <davem@davemloft.net>,
Matteo Croce <mcroce@linux.microsoft.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Bogus struct page layout on 32-bit
Date: Fri, 16 Apr 2021 16:10:37 +0200 [thread overview]
Message-ID: <CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com> (raw)
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
>
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").
I completely missed this change in the past, and I don't really agree
with it either.
Most 32-bit Arm platforms are in fact limited to 32-bit DMA, even when they have
MMIO or RAM areas above the 4GB boundary that require LPAE.
> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using
> things like (__force u32) for example.
>
> Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.
This is of course a good idea, drivers should work with any
combination of 32-bit
or 64-bit phys_addr_t and dma_addr_t.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: kbuild-all@lists.01.org
Subject: Re: Bogus struct page layout on 32-bit
Date: Fri, 16 Apr 2021 16:10:37 +0200 [thread overview]
Message-ID: <CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com> (raw)
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
>
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").
I completely missed this change in the past, and I don't really agree
with it either.
Most 32-bit Arm platforms are in fact limited to 32-bit DMA, even when they have
MMIO or RAM areas above the 4GB boundary that require LPAE.
> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using
> things like (__force u32) for example.
>
> Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.
This is of course a good idea, drivers should work with any
combination of 32-bit
or 64-bit phys_addr_t and dma_addr_t.
Arnd
next prev parent reply other threads:[~2021-04-16 14:10 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 18:50 [PATCH v7 00/28] Memory Folios Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 01/28] mm: Optimise nth_page for contiguous memmap Matthew Wilcox (Oracle)
2021-04-12 6:08 ` Christoph Hellwig
2021-04-09 18:50 ` [PATCH v7 02/28] mm: Introduce struct folio Matthew Wilcox (Oracle)
2021-04-09 22:45 ` kernel test robot
2021-04-09 22:45 ` kernel test robot
2021-04-10 2:43 ` Bogus struct page layout on 32-bit Matthew Wilcox
2021-04-10 2:43 ` Matthew Wilcox
2021-04-10 2:43 ` Matthew Wilcox
2021-04-10 2:43 ` Matthew Wilcox
2021-04-10 6:21 ` Jesper Dangaard Brouer
2021-04-10 6:21 ` Jesper Dangaard Brouer
2021-04-10 6:21 ` Jesper Dangaard Brouer
2021-04-10 6:21 ` Jesper Dangaard Brouer
2021-04-10 8:52 ` Ilias Apalodimas
2021-04-10 8:52 ` Ilias Apalodimas
2021-04-10 8:52 ` Ilias Apalodimas
2021-04-10 8:52 ` Ilias Apalodimas
2021-04-10 8:52 ` Ilias Apalodimas
2021-04-10 14:06 ` Matthew Wilcox
2021-04-10 14:06 ` Matthew Wilcox
2021-04-10 14:06 ` Matthew Wilcox
2021-04-10 14:06 ` Matthew Wilcox
2021-04-10 15:54 ` Russell King - ARM Linux admin
2021-04-10 15:54 ` Russell King - ARM Linux admin
2021-04-10 15:54 ` Russell King - ARM Linux admin
2021-04-10 15:54 ` Russell King - ARM Linux admin
2021-04-16 9:26 ` Grygorii Strashko
2021-04-16 9:26 ` Grygorii Strashko
2021-04-16 9:26 ` Grygorii Strashko
2021-04-16 9:26 ` Grygorii Strashko
2021-04-16 14:10 ` Arnd Bergmann [this message]
2021-04-16 14:10 ` Arnd Bergmann
2021-04-16 14:10 ` Arnd Bergmann
2021-04-16 14:10 ` Arnd Bergmann
2021-04-16 14:10 ` Arnd Bergmann
2021-04-17 13:08 ` David Laight
2021-04-17 13:08 ` David Laight
2021-04-17 13:08 ` David Laight
2021-04-17 13:08 ` David Laight
2021-04-17 13:08 ` David Laight
2021-04-10 14:17 ` David Laight
2021-04-10 14:17 ` David Laight
2021-04-10 14:17 ` David Laight
2021-04-10 14:17 ` David Laight
2021-04-10 14:17 ` David Laight
2021-04-10 19:10 ` Arnd Bergmann
2021-04-10 19:10 ` Arnd Bergmann
2021-04-10 19:10 ` Arnd Bergmann
2021-04-10 19:10 ` Arnd Bergmann
2021-04-10 19:10 ` Arnd Bergmann
2021-04-11 22:35 ` Matthew Wilcox
2021-04-11 22:35 ` Matthew Wilcox
2021-04-11 22:35 ` Matthew Wilcox
2021-04-11 22:35 ` Matthew Wilcox
2021-04-10 2:51 ` [PATCH v7 02/28] mm: Introduce struct folio kernel test robot
2021-04-10 2:51 ` kernel test robot
2021-04-16 15:55 ` Matthew Wilcox
2021-04-19 9:06 ` Kirill A. Shutemov
2021-04-09 18:50 ` [PATCH v7 03/28] mm: Add folio_pgdat and folio_zone Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 04/28] mm/vmstat: Add functions to account folio statistics Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 05/28] mm/debug: Add VM_BUG_ON_FOLIO and VM_WARN_ON_ONCE_FOLIO Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 06/28] mm: Add folio reference count functions Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 07/28] mm: Add put_folio Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 08/28] mm: Add get_folio Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 09/28] mm: Create FolioFlags Matthew Wilcox (Oracle)
2021-04-19 13:25 ` Peter Zijlstra
2021-04-19 13:55 ` Matthew Wilcox
2021-04-09 18:50 ` [PATCH v7 10/28] mm: Handle per-folio private data Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 11/28] mm/filemap: Add folio_index, folio_file_page and folio_contains Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 12/28] mm/filemap: Add folio_next_index Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 13/28] mm/filemap: Add folio_offset and folio_file_offset Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 14/28] mm/util: Add folio_mapping and folio_file_mapping Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 15/28] mm: Add folio_mapcount Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 16/28] mm/memcg: Add folio wrappers for various functions Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 17/28] mm/filemap: Add unlock_folio Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 18/28] mm/filemap: Add lock_folio Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 19/28] mm/filemap: Add lock_folio_killable Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 20/28] mm/filemap: Add __lock_folio_async Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 21/28] mm/filemap: Add __lock_folio_or_retry Matthew Wilcox (Oracle)
2021-04-09 18:50 ` [PATCH v7 22/28] mm/filemap: Add wait_on_folio_locked Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 23/28] mm/filemap: Add end_folio_writeback Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 24/28] mm/writeback: Add wait_on_folio_writeback Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 25/28] mm/writeback: Add wait_for_stable_folio Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 26/28] mm/filemap: Convert wait_on_page_bit to wait_on_folio_bit Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 27/28] mm/filemap: Convert wake_up_page_bit to wake_up_folio_bit Matthew Wilcox (Oracle)
2021-04-09 18:51 ` [PATCH v7 28/28] mm/filemap: Convert page wait queues to be folios Matthew Wilcox (Oracle)
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=CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com \
--to=arnd@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=brouer@redhat.com \
--cc=clang-built-linux@googlegroups.com \
--cc=davem@davemloft.net \
--cc=grygorii.strashko@ti.com \
--cc=hch@lst.de \
--cc=ilias.apalodimas@linaro.org \
--cc=kbuild-all@lists.01.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=mcroce@linux.microsoft.com \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=paulus@samba.org \
--cc=willy@infradead.org \
/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.