[PATCH] ARM: mach-bcm: offer a new maintainer and process

Add myself as a third maintainer to the mach-bcm code to increase the
chances the redundancy in the merging/reviewing process.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 809ecd680d88..e0762fea2d02 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2004,6 +2004,7 @@ F: drivers/net/ethernet/broadcom/bnx2x/
BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE
T: git git://github.com/broadcom/mach-bcm
S: Maintained
--
1.9.1

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

Olof Johansson

2014-09-23 05:10:03 UTC

Post by Florian Fainelli
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
- 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?

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.

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.

-Olof

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

Florian Fainelli

2014-09-23 05:30:02 UTC

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 leave it to Scott for more details, but last we talked he mentioned
what has been upstreamed is useful for some other platforms he cares
about.

Post by Olof Johansson
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.
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.

Right, let's adopt that approach for now, and we can revisit that
later in light of Scott and his group's work.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Matt Porter

2014-09-23 13:00:02 UTC

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?
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Scott Branden

2014-09-23 15:10:03 UTC

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.

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.

Post by Olof Johansson
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.

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

Matt Porter

2014-09-23 15:30:02 UTC

Post by Scott Branden

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.

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.

Post by Olof Johansson
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

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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Olof Johansson

2014-09-23 16:30:02 UTC

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.

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.

Post by Olof Johansson
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

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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Matt Porter

2014-09-23 12:50:02 UTC