All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Porter <mporter@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	devicetree@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
	Christian Daudt <bcm@fixthebug.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	Gregory Fong <gregory.0xf0@gmail.com>,
	Olof Johansson <olof@lixom.net>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
Date: Tue, 22 Jul 2014 17:33:50 -0400	[thread overview]
Message-ID: <20140722213350.GX2593@beef> (raw)
In-Reply-To: <5044348.IEPQPrahyu@wuerfel>

On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> > 
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
> 
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
> 
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> > 
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
> 
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.

We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:

BROADCOM BCM5301X ARM ARCHICTURE
M:      Hauke Mehrtens <hauke@hauke-m.de>
L:      linux-arm-kernel@lists.infradead.org
S:      Maintained
F:      arch/arm/mach-bcm/bcm_5301x.c
F:      arch/arm/boot/dts/bcm5301x.dtsi
F:      arch/arm/boot/dts/bcm470*

which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.

> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
> 
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.

I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.

I would like to see a consistent path for all BCM platform maintainers.

-Matt

WARNING: multiple messages have this Message-ID (diff)
From: Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Brian Norris
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Florian Fainelli
	<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Dmitry Eremin-Solenikov
	<dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Christian Daudt <bcm-xK7y4jjYLqYh9ZMKESR00Q@public.gmane.org>,
	Linux Kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Gregory Fong
	<gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
Date: Tue, 22 Jul 2014 17:33:50 -0400	[thread overview]
Message-ID: <20140722213350.GX2593@beef> (raw)
In-Reply-To: <5044348.IEPQPrahyu@wuerfel>

On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> > 
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
> 
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
> 
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> > 
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
> 
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.

We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:

BROADCOM BCM5301X ARM ARCHICTURE
M:      Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
L:      linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
S:      Maintained
F:      arch/arm/mach-bcm/bcm_5301x.c
F:      arch/arm/boot/dts/bcm5301x.dtsi
F:      arch/arm/boot/dts/bcm470*

which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.

> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
> 
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.

I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.

I would like to see a consistent path for all BCM platform maintainers.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: mporter@linaro.org (Matt Porter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
Date: Tue, 22 Jul 2014 17:33:50 -0400	[thread overview]
Message-ID: <20140722213350.GX2593@beef> (raw)
In-Reply-To: <5044348.IEPQPrahyu@wuerfel>

On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> > 
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
> 
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
> 
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> > 
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
> 
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.

We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:

BROADCOM BCM5301X ARM ARCHICTURE
M:      Hauke Mehrtens <hauke@hauke-m.de>
L:      linux-arm-kernel at lists.infradead.org
S:      Maintained
F:      arch/arm/mach-bcm/bcm_5301x.c
F:      arch/arm/boot/dts/bcm5301x.dtsi
F:      arch/arm/boot/dts/bcm470*

which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.

> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
> 
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.

I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.

I would like to see a consistent path for all BCM platform maintainers.

-Matt

  reply	other threads:[~2014-07-22 21:33 UTC|newest]

Thread overview: 121+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-21 21:07 [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support Brian Norris
2014-07-21 21:07 ` Brian Norris
2014-07-21 21:07 ` Brian Norris
2014-07-21 21:07 ` [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-30  9:26   ` Russell King - ARM Linux
2014-07-30  9:26     ` Russell King - ARM Linux
2014-07-31  2:36     ` Brian Norris
2014-07-31  2:36       ` Brian Norris
2014-07-31  2:36       ` Brian Norris
2014-07-30 17:09   ` Rob Herring
2014-07-30 17:09     ` Rob Herring
2014-07-30 17:09     ` Rob Herring
2014-07-31  2:23     ` Brian Norris
2014-07-31  2:23       ` Brian Norris
2014-07-31  2:23       ` Brian Norris
2014-07-31  8:43       ` Russell King - ARM Linux
2014-07-31  8:43         ` Russell King - ARM Linux
2014-07-31  8:43         ` Russell King - ARM Linux
2014-07-31 22:06         ` Brian Norris
2014-07-31 22:06           ` Brian Norris
2014-07-31 22:06           ` Brian Norris
2014-08-02  9:27           ` Russell King - ARM Linux
2014-08-02  9:27             ` Russell King - ARM Linux
2014-08-02  9:27             ` Russell King - ARM Linux
2014-08-13 23:47             ` Brian Norris
2014-08-13 23:47               ` Brian Norris
2014-08-13 23:47               ` Brian Norris
2014-08-19  0:02               ` Brian Norris
2014-08-19  0:02                 ` Brian Norris
2014-08-19  0:02                 ` Brian Norris
2014-08-01 14:33       ` Rob Herring
2014-08-01 14:33         ` Rob Herring
2014-08-01 14:33         ` Rob Herring
2014-08-01 19:29         ` Florian Fainelli
2014-08-01 19:29           ` Florian Fainelli
2014-08-01 19:29           ` Florian Fainelli
2014-08-01 19:46           ` Matt Porter
2014-08-01 19:46             ` Matt Porter
2014-08-01 19:46             ` Matt Porter
2014-08-02  8:21         ` Russell King - ARM Linux
2014-08-02  8:21           ` Russell King - ARM Linux
2014-08-02  8:21           ` Russell King - ARM Linux
2014-08-02  8:19   ` Russell King - ARM Linux
2014-08-02  8:19     ` Russell King - ARM Linux
2014-08-04 17:39     ` Brian Norris
2014-08-04 17:39       ` Brian Norris
2014-07-21 21:07 ` [PATCH v8 02/11] power: reset: Add reboot driver for brcmstb Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-22  7:28   ` Arnd Bergmann
2014-07-22  7:28     ` Arnd Bergmann
2014-07-22  7:28     ` Arnd Bergmann
2014-07-22 20:02     ` Brian Norris
2014-07-22 20:02       ` Brian Norris
2014-07-22 20:02       ` Brian Norris
2014-07-22 21:02       ` Arnd Bergmann
2014-07-22 21:02         ` Arnd Bergmann
2014-07-22 21:02         ` Arnd Bergmann
2014-07-22 22:51         ` Brian Norris
2014-07-22 22:51           ` Brian Norris
2014-07-21 21:07 ` [PATCH v8 03/11] ARM: brcmstb: add debug UART for earlyprintk support Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-08-02  8:30   ` Russell King - ARM Linux
2014-08-02  8:30     ` Russell King - ARM Linux
2014-08-04 16:56     ` Brian Norris
2014-08-04 16:56       ` Brian Norris
2014-08-13 22:11       ` Brian Norris
2014-08-13 22:11         ` Brian Norris
2014-08-13 22:11         ` Brian Norris
2014-08-13 22:16         ` Olof Johansson
2014-08-13 22:16           ` Olof Johansson
2014-08-13 22:16           ` Olof Johansson
2014-09-02 22:22           ` Florian Fainelli
2014-09-02 22:22             ` Florian Fainelli
2014-09-02 22:22             ` Florian Fainelli
2014-09-02 22:44             ` Brian Norris
2014-09-02 22:44               ` Brian Norris
2014-09-02 22:44               ` Brian Norris
2014-07-21 21:07 ` [PATCH v8 04/11] ARM: do CPU-specific init for Broadcom Brahma15 cores Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-21 21:07   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 05/11] ARM: Enable erratum 798181 for Broadcom Brahma-B15 Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 06/11] ARM: brcmstb: add CPU binding for Broadcom Brahma15 Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 07/11] ARM: brcmstb: add misc. DT bindings for brcmstb Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 08/11] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15 Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 09/11] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445 Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 10/11] ARM: brcmstb: select GISB arbiter and interrupt drivers Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08 ` [PATCH v8 11/11] MAINTAINERS: add entry for Broadcom ARM STB architecture Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-21 21:08   ` Brian Norris
2014-07-22  7:35 ` [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support Arnd Bergmann
2014-07-22  7:35   ` Arnd Bergmann
2014-07-22  7:35   ` Arnd Bergmann
2014-07-22 20:44   ` Brian Norris
2014-07-22 20:44     ` Brian Norris
2014-07-22 20:57     ` Arnd Bergmann
2014-07-22 20:57       ` Arnd Bergmann
2014-07-22 20:57       ` Arnd Bergmann
2014-07-22 21:33       ` Matt Porter [this message]
2014-07-22 21:33         ` Matt Porter
2014-07-22 21:33         ` Matt Porter
2014-07-22 22:24         ` Arnd Bergmann
2014-07-22 22:24           ` Arnd Bergmann
2014-07-22 22:24           ` Arnd Bergmann
2014-07-22 22:30           ` Brian Norris
2014-07-22 22:30             ` Brian Norris

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=20140722213350.GX2593@beef \
    --to=mporter@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bcm@fixthebug.org \
    --cc=computersforpeace@gmail.com \
    --cc=dbaryshkov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=gregory.0xf0@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=sre@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.