linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] Add support for generic BCM SoC chipsets
Date: Mon, 12 Nov 2012 17:05:28 +0000	[thread overview]
Message-ID: <201211121705.29191.arnd@arndb.de> (raw)
In-Reply-To: <20121112160404.GA22739@glitch>

On Monday 12 November 2012, Domenico Andreoli wrote:
> On Mon, Nov 12, 2012 at 03:00:57PM +0000, Arnd Bergmann wrote:
> > On Sunday 11 November 2012, Stephen Warren wrote:
> > > > I'm following the other mobile ARM SoCs which all have a single mach-
> > > > directory for various families of chips (mach-tegra, mach-omap2,
> > > > etc...). Plus the intent is to have a single set of mach files that
> > > > works across bcm SoCs, so it is preferable to keep it in a single mach-bcm.
> > > 
> > > It's quite possible to create one directory now, e.g. mach-bcm281xx, and
> > > then when consolidation with other mach-bcm* happens, merge all those
> > > directories into a single mach-bcm. I would tend to prefer (but only
> > > lightly) using mach-bcm281xx now and then renaming later, unless you
> > > plan on expanding the SoC support in the pretty near future.
> > 
> > I think the main question is how many files we expect to see in the
> > platform directories for each of bcm3528, bcm281xx and bcm476x. Right
> > now, my feeling is that each of them can be a single file, since most
> > of the stuff that has traditionally been in mach-* directories is
> > moving out to drivers now.
> 
> I expect only DT-only stuff will be mainlined so one directory
> (plat-brcm?) should be ok, right?

Right. The usual naming is to use 'mach-*' for one platform, and 'plat-*'
for stuff that spreads multiple 'mach-*' directories. In this case, the
name I would expect is either 'mach-bcm' as Christian suggested, or
'mach-brcm' if people have strong opinions in favor of that, but not
'plat-brcm'.

> > You still have to work out how you want to maintain that directory though,
> > either just having per-file maintainers, or having multiple people
> > take responsible for the entire directory.
> 
> I'd like to take care of the bcm476x and related drivers unless Broadcom
> wants to do it.

Yes, of course.

> Let me know in which directory.

I'll let you work that out with Stephen and Christian. I think just
'mach-bcm' is sufficent, but I think the three of you should come to
an agreement first.

	Arnd

  reply	other threads:[~2012-11-12 17:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-11 14:57 [PATCH v2] Add support for generic BCM SoC chipsets Christian Daudt
2012-11-11 15:53 ` Florian Fainelli
2012-11-11 17:32   ` Christian Daudt
2012-11-11 18:43     ` Florian Fainelli
2012-11-11 21:40     ` Stephen Warren
2012-11-12 15:00       ` Arnd Bergmann
2012-11-12 16:04         ` Domenico Andreoli
2012-11-12 17:05           ` Arnd Bergmann [this message]
2012-11-12 17:15             ` Stephen Warren
2012-11-13 17:53               ` Christian Daudt
2012-11-13 21:31                 ` Domenico Andreoli
2012-11-12 15:17 ` Russell King - ARM Linux
2012-11-13 17:58   ` Christian Daudt
2012-11-13  4:45 ` Stephen Warren
2012-11-13 19:02   ` Christian Daudt

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=201211121705.29191.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.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 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).