All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<akpm@linux-foundation.org>,  <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,  <rppt@kernel.org>,
	<lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>,
	<sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>,
	<song.bao.hua@hisilicon.com>, <ardb@kernel.org>,
	<anshuman.khandual@arm.com>,  <bhelgaas@google.com>,
	<guro@fb.com>, <robh+dt@kernel.org>, <stable@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>,
	<wangkefeng.wang@huawei.com>
Subject: Re: [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA
Date: Mon, 8 Mar 2021 11:20:03 +0800	[thread overview]
Message-ID: <604597E3.5000605@huawei.com> (raw)
In-Reply-To: <YETwL6QGWFyJTAzk@kroah.com>



On 2021/3/7 23:24, Greg KH wrote:
> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
>>>> Hi Greg.
>>>>
>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
>>>>>> Using two distinct DMA zones turned out to be problematic. Here's an
>>>>>> attempt go back to a saner default.
>>>>> What problem does this solve?  How does this fit into the stable kernel
>>>>> rules?
>>>> We changed the way we setup memory zones in arm64 in order to cater for
>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
>>>> memory that crosses zone boundaries, this broke crashkernel allocations on big
>>>> machines. This series fixes all this by parsing the HW description and checking
>>>> for DMA constrained buses. When not found, the unnecessary zone creation is
>>>> skipped.
>>> What kernel/commit caused this "breakage"?
>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> Thanks for the info, all now queued up.
There is a fix in 5.11. Please consider applying the following commit to 
5.10.y:

aed5041ef9a3 of: unittest: Fix build on architectures without 
CONFIG_OF_ADDRES

Thanks

>
> greg k-h
> .
>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Jing Xiangfeng <jingxiangfeng@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<akpm@linux-foundation.org>,  <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,  <rppt@kernel.org>,
	<lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>,
	<sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>,
	<song.bao.hua@hisilicon.com>, <ardb@kernel.org>,
	<anshuman.khandual@arm.com>,  <bhelgaas@google.com>,
	<guro@fb.com>, <robh+dt@kernel.org>, <stable@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>,
	<wangkefeng.wang@huawei.com>
Subject: Re: [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA
Date: Mon, 8 Mar 2021 11:20:03 +0800	[thread overview]
Message-ID: <604597E3.5000605@huawei.com> (raw)
In-Reply-To: <YETwL6QGWFyJTAzk@kroah.com>



On 2021/3/7 23:24, Greg KH wrote:
> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
>>>> Hi Greg.
>>>>
>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
>>>>>> Using two distinct DMA zones turned out to be problematic. Here's an
>>>>>> attempt go back to a saner default.
>>>>> What problem does this solve?  How does this fit into the stable kernel
>>>>> rules?
>>>> We changed the way we setup memory zones in arm64 in order to cater for
>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
>>>> memory that crosses zone boundaries, this broke crashkernel allocations on big
>>>> machines. This series fixes all this by parsing the HW description and checking
>>>> for DMA constrained buses. When not found, the unnecessary zone creation is
>>>> skipped.
>>> What kernel/commit caused this "breakage"?
>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> Thanks for the info, all now queued up.
There is a fix in 5.11. Please consider applying the following commit to 
5.10.y:

aed5041ef9a3 of: unittest: Fix build on architectures without 
CONFIG_OF_ADDRES

Thanks

>
> greg k-h
> .
>


_______________________________________________
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: Jing Xiangfeng <jingxiangfeng@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>,
	<akpm@linux-foundation.org>, <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <rppt@kernel.org>,
	<lorenzo.pieralisi@arm.com>, <guohanjun@huawei.com>,
	<sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>,
	<song.bao.hua@hisilicon.com>, <ardb@kernel.org>,
	<anshuman.khandual@arm.com>, <bhelgaas@google.com>, <guro@fb.com>,
	<robh+dt@kernel.org>, <stable@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <frowand.list@gmail.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-mm@kvack.org>, <linux-riscv@lists.infradead.org>,
	<wangkefeng.wang@huawei.com>
Subject: Re: [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA
Date: Mon, 8 Mar 2021 11:20:03 +0800	[thread overview]
Message-ID: <604597E3.5000605@huawei.com> (raw)
In-Reply-To: <YETwL6QGWFyJTAzk@kroah.com>



On 2021/3/7 23:24, Greg KH wrote:
> On Thu, Mar 04, 2021 at 04:09:28PM +0100, Nicolas Saenz Julienne wrote:
>> On Thu, 2021-03-04 at 15:17 +0100, Greg KH wrote:
>>> On Thu, Mar 04, 2021 at 03:05:32PM +0100, Nicolas Saenz Julienne wrote:
>>>> Hi Greg.
>>>>
>>>> On Thu, 2021-03-04 at 14:46 +0100, Greg KH wrote:
>>>>> On Wed, Mar 03, 2021 at 03:33:12PM +0800, Jing Xiangfeng wrote:
>>>>>> Using two distinct DMA zones turned out to be problematic. Here's an
>>>>>> attempt go back to a saner default.
>>>>> What problem does this solve?  How does this fit into the stable kernel
>>>>> rules?
>>>> We changed the way we setup memory zones in arm64 in order to cater for
>>>> Raspberry Pi 4's weird DMA constraints: ZONE_DMA spans the lower 1GB of memory
>>>> and ZONE_DMA32 the rest of the 32bit address space. Since you can't allocate
>>>> memory that crosses zone boundaries, this broke crashkernel allocations on big
>>>> machines. This series fixes all this by parsing the HW description and checking
>>>> for DMA constrained buses. When not found, the unnecessary zone creation is
>>>> skipped.
>>> What kernel/commit caused this "breakage"?
>> 1a8e1cef7603 arm64: use both ZONE_DMA and ZONE_DMA32
> Thanks for the info, all now queued up.
There is a fix in 5.11. Please consider applying the following commit to 
5.10.y:

aed5041ef9a3 of: unittest: Fix build on architectures without 
CONFIG_OF_ADDRES

Thanks

>
> greg k-h
> .
>


  reply	other threads:[~2021-03-08  3:21 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03  7:33 [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA Jing Xiangfeng
2021-03-03  7:33 ` Jing Xiangfeng
2021-03-03  7:33 ` Jing Xiangfeng
2021-03-03  7:33 ` [PATCH stable v5.10 1/7] arm64: mm: Move reserve_crashkernel() into mem_init() Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "arm64: mm: Move reserve_crashkernel() into mem_init()" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 2/7] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 3/7] of/address: Introduce of_dma_get_max_cpu_address() Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "of/address: Introduce of_dma_get_max_cpu_address()" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 4/7] of: unittest: Add test for of_dma_get_max_cpu_address() Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "of: unittest: Add test for of_dma_get_max_cpu_address()" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 6/7] arm64: mm: Set ZONE_DMA size based on early IORT scan Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "arm64: mm: Set ZONE_DMA size based on early IORT scan" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-03  7:33 ` [PATCH stable v5.10 7/7] mm: Remove examples from enum zone_type comment Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-03  7:33   ` Jing Xiangfeng
2021-03-07 15:25   ` Patch "mm: Remove examples from enum zone_type comment" has been added to the 5.10-stable tree gregkh
2021-03-07 15:25     ` gregkh
2021-03-07 15:25     ` gregkh
2021-03-04 13:46 ` [PATCH stable v5.10 0/7] arm64: Default to 32-bit wide ZONE_DMA Greg KH
2021-03-04 13:46   ` Greg KH
2021-03-04 13:46   ` Greg KH
2021-03-04 14:05   ` Nicolas Saenz Julienne
2021-03-04 14:05     ` Nicolas Saenz Julienne
2021-03-04 14:05     ` Nicolas Saenz Julienne
2021-03-04 14:17     ` Greg KH
2021-03-04 14:17       ` Greg KH
2021-03-04 14:17       ` Greg KH
2021-03-04 15:09       ` Nicolas Saenz Julienne
2021-03-04 15:09         ` Nicolas Saenz Julienne
2021-03-04 15:09         ` Nicolas Saenz Julienne
2021-03-07 15:24         ` Greg KH
2021-03-07 15:24           ` Greg KH
2021-03-07 15:24           ` Greg KH
2021-03-08  3:20           ` Jing Xiangfeng [this message]
2021-03-08  3:20             ` Jing Xiangfeng
2021-03-08  3:20             ` Jing Xiangfeng
2021-03-08  9:58             ` Greg KH
2021-03-08  9:58               ` Greg KH
2021-03-08  9:58               ` Greg KH
2021-05-11 12:35               ` Kefeng Wang
2021-05-11 12:35                 ` Kefeng Wang
2021-05-11 12:35                 ` Kefeng Wang
2021-05-12 12:06                 ` Greg KH
2021-05-12 12:06                   ` Greg KH
2021-05-12 12:06                   ` Greg KH
2021-06-23  6:59                 ` Kefeng Wang
2021-06-23  6:59                   ` Kefeng Wang
2021-06-23  7:12                   ` Greg KH
2021-06-23  7:12                     ` Greg KH
2021-06-23  7:25                     ` Kefeng Wang
2021-06-23  7:25                       ` Kefeng Wang
2021-06-23  7:34                       ` Greg KH
2021-06-23  7:34                         ` Greg KH
2021-06-23  8:01                         ` Kefeng Wang
2021-06-23  8:01                           ` Kefeng Wang
2021-06-25 10:19                           ` Greg KH
2021-06-25 10:19                             ` Greg KH
2021-06-26  1:19                             ` Kefeng Wang
2021-06-26  1:19                               ` Kefeng Wang

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=604597E3.5000605@huawei.com \
    --to=jingxiangfeng@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=guro@fb.com \
    --cc=lenb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=rppt@kernel.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.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.