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

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

[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
process:

- our group has now full access to these platforms, putting us in the best
  position to support Mobile SoCs questions

- over time, we think that the brcmstb, bcm5301x, bcm63xx and now Cygnus code
  bases will represent the major bulk of the mach-bcm code changes submitted,
  mobile SoCs being in deep maintenance mode

- we want to keep our submission pace high, and keep a smooth and responsive
  process in place for other maintainers such as Hauke Merthens and Stephen
  Warren and now Scott Branden and his team for Cygnus/Northstar+.

- there is little to no code sharing within mach-bcm, so we think each group
  of maintainers should send individual pull requests towards Arnd and Olof,
  the only conflicts they should ever have to resolve are for the Makefile and
  Kconfig files, not different than any other pull requests

Ideally, we would like Christian and Matt to acknowledge that change, if we
cannot get an answer within the next 3 weeks, we think this change
should go in to unblock the current situation.

Florian Fainelli (1):
  MAINTAINERS: add a third maintainer to mach-bcm

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

-- 
1.9.1

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

[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
process:

- our group has now full access to these platforms, putting us in the best
  position to support Mobile SoCs questions

- over time, we think that the brcmstb, bcm5301x, bcm63xx and now Cygnus code
  bases will represent the major bulk of the mach-bcm code changes submitted,
  mobile SoCs being in deep maintenance mode

- we want to keep our submission pace high, and keep a smooth and responsive
  process in place for other maintainers such as Hauke Merthens and Stephen
  Warren and now Scott Branden and his team for Cygnus/Northstar+.

- there is little to no code sharing within mach-bcm, so we think each group
  of maintainers should send individual pull requests towards Arnd and Olof,
  the only conflicts they should ever have to resolve are for the Makefile and
  Kconfig files, not different than any other pull requests

Ideally, we would like Christian and Matt to acknowledge that change, if we
cannot get an answer within the next 3 weeks, we think this change
should go in to unblock the current situation.

Florian Fainelli (1):
  MAINTAINERS: add a third maintainer to mach-bcm

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

-- 
1.9.1

[PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Florian Fainelli]

Add myself as a third maintainer to the mach-bcm code to increase the
chances the redundancy in the merging/reviewing process.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 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
 M:	Christian Daudt <bcm@fixthebug.org>
 M:	Matt Porter <mporter@linaro.org>
+M:	Florian Fainelli <f.fainelli@gmail.com>
 L:	bcm-kernel-feedback-list@broadcom.com
 T:	git git://github.com/broadcom/mach-bcm
 S:	Maintained
-- 
1.9.1

[PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Florian Fainelli]

Add myself as a third maintainer to the mach-bcm code to increase the
chances the redundancy in the merging/reviewing process.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 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
 M:	Christian Daudt <bcm@fixthebug.org>
 M:	Matt Porter <mporter@linaro.org>
+M:	Florian Fainelli <f.fainelli@gmail.com>
 L:	bcm-kernel-feedback-list at broadcom.com
 T:	git git://github.com/broadcom/mach-bcm
 S:	Maintained
-- 
1.9.1

Re: [PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Scott Branden]

On 14-09-19 11:17 AM, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Scott Branden <sbranden@broadcom.com>
> ---
>   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
>   M:	Christian Daudt <bcm@fixthebug.org>
>   M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>   L:	bcm-kernel-feedback-list@broadcom.com
>   T:	git git://github.com/broadcom/mach-bcm
>   S:	Maintained
>

[PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Scott Branden]

On 14-09-19 11:17 AM, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Scott Branden <sbranden@broadcom.com>
> ---
>   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
>   M:	Christian Daudt <bcm@fixthebug.org>
>   M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>   L:	bcm-kernel-feedback-list at broadcom.com
>   T:	git git://github.com/broadcom/mach-bcm
>   S:	Maintained
>

Re: [PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Brian Norris]

On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Brian Norris <computersforpeace@gmail.com>

> ---
>  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
>  M:	Christian Daudt <bcm@fixthebug.org>
>  M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>  L:	bcm-kernel-feedback-list@broadcom.com
>  T:	git git://github.com/broadcom/mach-bcm
>  S:	Maintained
> -- 
> 1.9.1
> 

[PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Brian Norris]

On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Brian Norris <computersforpeace@gmail.com>

> ---
>  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
>  M:	Christian Daudt <bcm@fixthebug.org>
>  M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>  L:	bcm-kernel-feedback-list at broadcom.com
>  T:	git git://github.com/broadcom/mach-bcm
>  S:	Maintained
> -- 
> 1.9.1
> 

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

[Olof Johansson]

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?

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

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

[Olof Johansson]

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?

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

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

[Florian Fainelli]

2014-09-22 22:03 GMT-07:00 Olof Johansson <olof@lixom.net>:
> 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 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.

>
> 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

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

[Florian Fainelli]

2014-09-22 22:03 GMT-07:00 Olof Johansson <olof@lixom.net>:
> 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 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.

>
> 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

Re: [PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Matt Porter]

On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Matt Porter <mporter@linaro.org>

Thanks for offering to take the lead on this. With my change in role at
Linaro and lack of access to Broadcom documentation and tribal knowledge
on Broadcom mobile parts I can't do this justice any longer.

-Matt

> ---
>  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
>  M:	Christian Daudt <bcm@fixthebug.org>
>  M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>  L:	bcm-kernel-feedback-list@broadcom.com
>  T:	git git://github.com/broadcom/mach-bcm
>  S:	Maintained
> -- 
> 1.9.1
> 

[PATCH] MAINTAINERS: add a third maintainer to mach-bcm

[Matt Porter]

On Fri, Sep 19, 2014 at 11:17:12AM -0700, Florian Fainelli wrote:
> Add myself as a third maintainer to the mach-bcm code to increase the
> chances the redundancy in the merging/reviewing process.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Acked-by: Matt Porter <mporter@linaro.org>

Thanks for offering to take the lead on this. With my change in role at
Linaro and lack of access to Broadcom documentation and tribal knowledge
on Broadcom mobile parts I can't do this justice any longer.

-Matt

> ---
>  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
>  M:	Christian Daudt <bcm@fixthebug.org>
>  M:	Matt Porter <mporter@linaro.org>
> +M:	Florian Fainelli <f.fainelli@gmail.com>
>  L:	bcm-kernel-feedback-list at broadcom.com
>  T:	git git://github.com/broadcom/mach-bcm
>  S:	Maintained
> -- 
> 1.9.1
> 

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

[Matt Porter]

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?
> 
> 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

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

[Matt Porter]

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?
> 
> 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

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

[Scott Branden]

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.

Regards,
  Scott

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

[Scott Branden]

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.

Regards,
  Scott

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

[Matt Porter]

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

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

[Matt Porter]

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

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

[Olof Johansson]

On Tue, Sep 23, 2014 at 8:00 AM, Scott Branden <sbranden@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

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

[Olof Johansson]

On Tue, Sep 23, 2014 at 8:00 AM, Scott Branden <sbranden@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