On Tue, Sep 23, 2014 at 8:00 AM, Scott Branden <sbran...@broadcom.com> 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.
Ok, cool -- and for those markets having mainline support might actually make sense. So the answer is fairly simple: Keep it for now. I'm glad I asked though since it means we have more knowledge of what's going on with the platform. And hopefully we'll see some of that missing functionality fill in over time. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/