All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Toan Le" <toan@os.amperecomputing.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v8 01/14] sizes.h: Add SZ_1T macro
Date: Thu, 10 Mar 2022 12:21:43 -0600	[thread overview]
Message-ID: <20220310182143.GA170924@bhelgaas> (raw)
In-Reply-To: <969d885d-dcff-61b9-50cd-cdaf511505ab@csgroup.eu>

On Thu, Mar 10, 2022 at 06:09:51PM +0000, Christophe Leroy wrote:
> 
> 
> Le 10/03/2022 à 17:52, Bjorn Helgaas a écrit :
> > On Wed, Mar 09, 2022 at 06:44:35PM +0100, Christophe Leroy wrote:
> >> Today drivers/pci/controller/pci-xgene.c defines SZ_1T
> >>
> >> Move it into linux/sizes.h so that it can be re-used elsewhere.
> >>
> >> Link: https://lore.kernel.org/r/575cb7164cf124c75df7cb9242ea7374733942bf.1642752946.git.christophe.leroy@csgroup.eu
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
> >> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> Cc: Toan Le <toan@os.amperecomputing.com>
> >> Cc: linux-pci@vger.kernel.org
> >> ---
> >>   This patch is already in linux-next but not in Linus' tree yet
> > 
> > What would you like me to do about this?  It's in linux-next, which
> > means it will go to Linus' tree during the next merge window.
> > 
> > But this is 01/14; are there other patches that I should be looking
> > at?  Do I need to coordinate this with other patches that depend on
> > it?
> 
> Yes sorry I should have said it. Patch 14/14 depends on it.
> 
> Don't know yet what's the merge strategy for this series, there as not 
> been any changes since v6 mid December and core parts are acked/reviewed 
> so I would be happy if at least core mm parts could go this cycle. I 
> sent a question to Michael and Andrew about it.

Since PCI is only minimally affected in this series, it would probably
make more sense for it to be merged along with the rest of the series
via a non-PCI tree.

It has my ack, so this can certainly happen.  If it does, I can easily
drop it from the PCI tree.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"will@kernel.org" <will@kernel.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"Toan Le" <toan@os.amperecomputing.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 01/14] sizes.h: Add SZ_1T macro
Date: Thu, 10 Mar 2022 12:21:43 -0600	[thread overview]
Message-ID: <20220310182143.GA170924@bhelgaas> (raw)
In-Reply-To: <969d885d-dcff-61b9-50cd-cdaf511505ab@csgroup.eu>

On Thu, Mar 10, 2022 at 06:09:51PM +0000, Christophe Leroy wrote:
> 
> 
> Le 10/03/2022 à 17:52, Bjorn Helgaas a écrit :
> > On Wed, Mar 09, 2022 at 06:44:35PM +0100, Christophe Leroy wrote:
> >> Today drivers/pci/controller/pci-xgene.c defines SZ_1T
> >>
> >> Move it into linux/sizes.h so that it can be re-used elsewhere.
> >>
> >> Link: https://lore.kernel.org/r/575cb7164cf124c75df7cb9242ea7374733942bf.1642752946.git.christophe.leroy@csgroup.eu
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
> >> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> Cc: Toan Le <toan@os.amperecomputing.com>
> >> Cc: linux-pci@vger.kernel.org
> >> ---
> >>   This patch is already in linux-next but not in Linus' tree yet
> > 
> > What would you like me to do about this?  It's in linux-next, which
> > means it will go to Linus' tree during the next merge window.
> > 
> > But this is 01/14; are there other patches that I should be looking
> > at?  Do I need to coordinate this with other patches that depend on
> > it?
> 
> Yes sorry I should have said it. Patch 14/14 depends on it.
> 
> Don't know yet what's the merge strategy for this series, there as not 
> been any changes since v6 mid December and core parts are acked/reviewed 
> so I would be happy if at least core mm parts could go this cycle. I 
> sent a question to Michael and Andrew about it.

Since PCI is only minimally affected in this series, it would probably
make more sense for it to be merged along with the rest of the series
via a non-PCI tree.

It has my ack, so this can certainly happen.  If it does, I can easily
drop it from the PCI tree.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Toan Le" <toan@os.amperecomputing.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v8 01/14] sizes.h: Add SZ_1T macro
Date: Thu, 10 Mar 2022 12:21:43 -0600	[thread overview]
Message-ID: <20220310182143.GA170924@bhelgaas> (raw)
In-Reply-To: <969d885d-dcff-61b9-50cd-cdaf511505ab@csgroup.eu>

On Thu, Mar 10, 2022 at 06:09:51PM +0000, Christophe Leroy wrote:
> 
> 
> Le 10/03/2022 à 17:52, Bjorn Helgaas a écrit :
> > On Wed, Mar 09, 2022 at 06:44:35PM +0100, Christophe Leroy wrote:
> >> Today drivers/pci/controller/pci-xgene.c defines SZ_1T
> >>
> >> Move it into linux/sizes.h so that it can be re-used elsewhere.
> >>
> >> Link: https://lore.kernel.org/r/575cb7164cf124c75df7cb9242ea7374733942bf.1642752946.git.christophe.leroy@csgroup.eu
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
> >> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> Cc: Toan Le <toan@os.amperecomputing.com>
> >> Cc: linux-pci@vger.kernel.org
> >> ---
> >>   This patch is already in linux-next but not in Linus' tree yet
> > 
> > What would you like me to do about this?  It's in linux-next, which
> > means it will go to Linus' tree during the next merge window.
> > 
> > But this is 01/14; are there other patches that I should be looking
> > at?  Do I need to coordinate this with other patches that depend on
> > it?
> 
> Yes sorry I should have said it. Patch 14/14 depends on it.
> 
> Don't know yet what's the merge strategy for this series, there as not 
> been any changes since v6 mid December and core parts are acked/reviewed 
> so I would be happy if at least core mm parts could go this cycle. I 
> sent a question to Michael and Andrew about it.

Since PCI is only minimally affected in this series, it would probably
make more sense for it to be merged along with the rest of the series
via a non-PCI tree.

It has my ack, so this can certainly happen.  If it does, I can easily
drop it from the PCI tree.

Bjorn

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

  reply	other threads:[~2022-03-10 18:22 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 17:44 [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8) Christophe Leroy
2022-03-09 17:44 ` Christophe Leroy
2022-03-09 17:44 ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 01/14] sizes.h: Add SZ_1T macro Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-10 16:52   ` Bjorn Helgaas
2022-03-10 16:52     ` Bjorn Helgaas
2022-03-10 16:52     ` Bjorn Helgaas
2022-03-10 18:09     ` Christophe Leroy
2022-03-10 18:09       ` Christophe Leroy
2022-03-10 18:09       ` Christophe Leroy
2022-03-10 18:21       ` Bjorn Helgaas [this message]
2022-03-10 18:21         ` Bjorn Helgaas
2022-03-10 18:21         ` Bjorn Helgaas
2022-03-09 17:44 ` [PATCH v8 02/14] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 03/14] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 04/14] mm: Add len and flags parameters to arch_get_mmap_end() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 05/14] mm, hugetlbfs: Allow for "high" userspace addresses Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 06/14] powerpc/mm: Move vma_mmu_pagesize() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 07/14] powerpc/mm: Make slice specific to book3s/64 Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 08/14] powerpc/mm: Remove CONFIG_PPC_MM_SLICES Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 09/14] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 10/14] powerpc/mm: Use generic_hugetlb_get_unmapped_area() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 11/14] powerpc/mm: Move get_unmapped_area functions to slice.c Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 12/14] powerpc/mm: Enable full randomisation of memory mappings Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 13/14] powerpc/mm: Convert to default topdown mmap layout Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44 ` [PATCH v8 14/14] powerpc: Simplify and move arch_randomize_brk() Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-09 17:44   ` Christophe Leroy
2022-03-10  6:51 ` [PATCH v8 00/14] Convert powerpc to default topdown mmap layout (v8) Christophe Leroy
2022-03-10  6:51   ` Christophe Leroy
2022-03-10  6:51   ` Christophe Leroy
2022-03-11  4:26   ` Michael Ellerman
2022-03-11  4:26     ` Michael Ellerman
2022-03-11  4:26     ` Michael Ellerman
2022-03-11  4:49     ` Andrew Morton
2022-03-11  4:49       ` Andrew Morton
2022-03-11  4:49       ` Andrew Morton
2022-04-04  5:22       ` Christophe Leroy
2022-04-04  5:22         ` Christophe Leroy
2022-04-04  5:22         ` Christophe Leroy
2022-04-07 18:30         ` Christophe Leroy
2022-04-07 18:30           ` Christophe Leroy
2022-04-07 18:30           ` Christophe Leroy
2022-04-08  4:18           ` Michael Ellerman
2022-04-08  4:18             ` Michael Ellerman
2022-04-08  4:18             ` Michael Ellerman
2022-04-08  4:17       ` Michael Ellerman
2022-04-08  4:17         ` Michael Ellerman
2022-04-08  4:17         ` Michael Ellerman

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=20220310182143.GA170924@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=toan@os.amperecomputing.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.