Message-ID: <20140923152646.GC17710@beef>
Date:	Tue, 23 Sep 2014 11:26:46 -0400
From:	Matt Porter <mporter@...aro.org>
To:	Scott Branden <sbranden@...adcom.com>
Cc:	Olof Johansson <olof@...om.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	linux-arm-kernel@...ts.infradead.org, arnd@...db.de,
	arm@...nel.org, bcm@...thebug.org, jonathar@...adcom.com,
	rjui@...adcom.com, linux-kernel@...r.kernel.org,
	bcm-kernel-feedback-list@...adcom.com, hauke@...ke-m.de,
	swarren@...dotorg.org, computersforpeace@...il.com,
	marc.ceeeee@...il.com, cernekee@...il.com, gregory.0xf0@...il.com
Subject: Re: [PATCH] ARM: mach-bcm: offer a new maintainer and process

On Tue, Sep 23, 2014 at 08:00:41AM -0700, Scott Branden wrote:
> On 14-09-23 05:54 AM, Matt Porter wrote:
> >On Mon, Sep 22, 2014 at 10:03:39PM -0700, Olof Johansson wrote:
> >>On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote:
> >>>Hi all,
> >>>
> >>>As some of you may have seen in the news, Broadcom has recently stopped
> >>>its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs
> >>>was an effort initially started by Christian Daudt and his team, and then
> >>>continued by Alex Eleder and Matter Porter assigned to a particular landing
> >>>team within Linaro to help Broadcom doing so.
> >>>
> >>>As part of this effort, Christian and Matt volunteered for centralizing pull
> >>>requests coming from the arch/arm/mach-bcm/* directory and as of today, they
> >>>are still responsible for merging mach-bcm pull requests coming from brcmstb,
> >>>bcm5301x, bcm2835 and bcm63xx, creating an intermediate layer to the arm-soc
> >>>tree.
> >>>
> >>>Following the mobile group shut down, our group (in which Brian, Gregory, Marc,
> >>>Kevin and myself are) inherited these mobile SoC platforms, although at this
> >>>point we cannot comment on the future of mobile platforms, we know that our
> >>>Linaro activities have been stopped.
> >>>
> >>>We have not heard much from Christian and Matt in a while, and some of our pull
> >>>requests have been stalling as a result. We would like to offer both a new
> >>>maintainer for the mobile platforms as well as reworking the pull request
> >>>process:
> >>>
> >>>- our group has now full access to these platforms, putting us in the best
> >>>   position to support Mobile SoCs questions
> >>
> >>So, one question I have is whether it makes sense to keep the mobile
> >>platforms in the kernel if the line of business is ending?
> I guess one problem is that BCM_MOBILE is quite misnamed.  It should
> really be called BCM_KONA.  bcm281xx was a successful product in the
> mobile space.  But mobile products have short lifespans as new
> versions become available every year.  In fact - there have already
> been more products made with this chipset that are not mobile based
> nor in the consumer space.  The happen to be based on an older
> kernel version but we are planning on moving to a newer kernel
> version in the future. Variants of this chipset will continue to be
> used in many non-mobile products for many years going forward.  We
> could also rename it BCM_IMMOBILE going forward if that helps
> clarify things.
> >>
> >>While I truly do appreciate the work done by Matt and others, there's
> >>also little chance that it'll see substantial use by anyone. The Capri
> >>boards aren't common out in the wild and I'm not aware of any dev
> >>boards or consumer products with these SoCs that might want to run
> >>mainline? Critical things such as power management and graphics are
> >>missing from the current platform support in the kernel, so nobody is
> >>likely to want it on their Android phone, etc.
> Yes, thanks for all the hard work in upstreaming this code.  It will
> be built upon and highly leveraged for other purposes beyond Android
> phones and power management.
> >>
> >>Maybe the answer to this is "keep it for now, revisit sometime later",
> >>which is perfectly sane -- it has practically no cost to keep it around
> >>the way it's looking now.
> >
> >It won't hurt my feelings if it's decided that it has no value being in
> >the kernel. :) All I can offer is that *maybe* somebody will have a root
> >exploit for the bcm281xx Roku platforms (that lasts) and/or some of the
> >capri and hawaii handsets out there and find it useful as a starting
> >point to work from an Android vendor tree. I don't know if anybody cares
> >about hacking those platforms or not.
> >
> >As mentioned in a followup, the VoIP parts (or some of them, at least)
> >are part of the bcm281xx family and we were expecting them to submit an
> >ethernet driver for the past year. There were repeated reminders that
> >they really care about mainline so I would expect it would be premature
> >to remove that support until we hear from them.
> >
> >-Matt
> >
> Yes, variants of this chipset will be developed in new products.
> bcm281xx was also a poor choice of naming as well. Capri or Kona
> family would have been much more appropriate.  This product is used
> in VoIP and other non-mobile markets.

Understood, for some reason Broadcom chose that naming when first
upstreaming the base code. We did manage to name the drivers with "kona"
after that point. Be aware that bcm281xx/capri aren't the only parts in the
kernel stuck with terrible legacy names. There's a ton of Davinci/OMAP
code that suffers the same curse of initial naming not matching up to
later or even current uses of the same IP.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists