[PATCH] MAINTAINERS: extend Raspberry Pi entry

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Baruch Siach]

Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 26edd832c64e..d69449735876 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2612,7 +2612,7 @@ N:	bcm216*
 N:	kona
 F:	arch/arm/mach-bcm/
 
-BROADCOM BCM2835 ARM ARCHITECTURE
+BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
 M:	Stephen Warren <swarren@wwwdotorg.org>
 M:	Lee Jones <lee@kernel.org>
 M:	Eric Anholt <eric@anholt.net>
@@ -2620,7 +2620,7 @@ L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
 S:	Maintained
-N:	bcm2835
+N:	bcm283[5-7x]
 F:	drivers/staging/vc04_services
 
 BROADCOM BCM47XX MIPS ARCHITECTURE
-- 
2.11.0

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Sun, 2017-01-29 at 22:08 +0200, Baruch Siach wrote:
> Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> ?MAINTAINERS | 4 ++--
> ?1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26edd832c64e..d69449735876 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2612,7 +2612,7 @@ N:	bcm216*
> ?N:	kona
> ?F:	arch/arm/mach-bcm/
> ?
> -BROADCOM BCM2835 ARM ARCHITECTURE
> +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
> ?M:	Stephen Warren <swarren@wwwdotorg.org>
> ?M:	Lee Jones <lee@kernel.org>
> ?M:	Eric Anholt <eric@anholt.net>
> @@ -2620,7 +2620,7 @@ L:	linux-rpi-kernel at lists.infradead.org
> (moderated for non-subscribers)
> ?L:	linux-arm-kernel at lists.infradead.org (moderated for non-
> subscribers)
> ?T:	git
> git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> ?S:	Maintained
> -N:	bcm2835
> +N:	bcm283[5-7x]
> ?F:	drivers/staging/vc04_services
> ?
> ?BROADCOM BCM47XX MIPS ARCHITECTURE

This is all cool and whatnot, but being new I'm a bit confused how this
works.

1. Is everything still going to be e-mail based, because the e-mail
based system could use some improvement.

2. Are all the BCM283* files going to be clustered together or still
scattered through the tree?

3. Why do the branches of the git all contain very old versions of the
kernel?

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Baruch Siach]

Hi Michael,

On Sun, Jan 29, 2017 at 12:52:30PM -0800, Michael Zoran wrote:
> On Sun, 2017-01-29 at 22:08 +0200, Baruch Siach wrote:
> > Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
> > 
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > ?MAINTAINERS | 4 ++--
> > ?1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 26edd832c64e..d69449735876 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2612,7 +2612,7 @@ N:	bcm216*
> > ?N:	kona
> > ?F:	arch/arm/mach-bcm/
> > ?
> > -BROADCOM BCM2835 ARM ARCHITECTURE
> > +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
> > ?M:	Stephen Warren <swarren@wwwdotorg.org>
> > ?M:	Lee Jones <lee@kernel.org>
> > ?M:	Eric Anholt <eric@anholt.net>
> > @@ -2620,7 +2620,7 @@ L:	linux-rpi-kernel at lists.infradead.org
> > (moderated for non-subscribers)
> > ?L:	linux-arm-kernel at lists.infradead.org (moderated for non-
> > subscribers)
> > ?T:	git
> > git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> > ?S:	Maintained
> > -N:	bcm2835
> > +N:	bcm283[5-7x]
> > ?F:	drivers/staging/vc04_services
> > ?
> > ?BROADCOM BCM47XX MIPS ARCHITECTURE
> 
> This is all cool and whatnot, but being new I'm a bit confused how this
> works.
> 
> 1. Is everything still going to be e-mail based, because the e-mail
> based system could use some improvement.

Kernel development is email based. See "Why kernel development still uses 
email"[1]. What would you like to see improved?

> 2. Are all the BCM283* files going to be clustered together or still
> scattered through the tree?

The hardware module type determines its driver location in the kernel tree. 
The i2c-bcm2835.c has much more in common with other i2c master drivers than 
with spi-bcm2835.c.

> 3. Why do the branches of the git all contain very old versions of the
> kernel?

Which git branches?

[1] https://lwn.net/Articles/702177/

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Sun, 2017-01-29 at 23:06 +0200, Baruch Siach wrote:
> Hi Michael,
> 
> On Sun, Jan 29, 2017 at 12:52:30PM -0800, Michael Zoran wrote:
> > On Sun, 2017-01-29 at 22:08 +0200, Baruch Siach wrote:
> > > Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
> > > 
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > ---
> > > ?MAINTAINERS | 4 ++--
> > > ?1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 26edd832c64e..d69449735876 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -2612,7 +2612,7 @@ N:	bcm216*
> > > ?N:	kona
> > > ?F:	arch/arm/mach-bcm/
> > > ?
> > > -BROADCOM BCM2835 ARM ARCHITECTURE
> > > +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
> > > ?M:	Stephen Warren <swarren@wwwdotorg.org>
> > > ?M:	Lee Jones <lee@kernel.org>
> > > ?M:	Eric Anholt <eric@anholt.net>
> > > @@ -2620,7 +2620,7 @@ L:	linux-rpi-kernel at lists.infradead.
> > > org
> > > (moderated for non-subscribers)
> > > ?L:	linux-arm-kernel at lists.infradead.org (moderated for
> > > non-
> > > subscribers)
> > > ?T:	git
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> > > ?S:	Maintained
> > > -N:	bcm2835
> > > +N:	bcm283[5-7x]
> > > ?F:	drivers/staging/vc04_services
> > > ?
> > > ?BROADCOM BCM47XX MIPS ARCHITECTURE
> > 
> > This is all cool and whatnot, but being new I'm a bit confused how
> > this
> > works.
> > 
> > 1. Is everything still going to be e-mail based, because the e-mail
> > based system could use some improvement.
> 
> Kernel development is email based. See "Why kernel development still
> uses?
> email"[1]. What would you like to see improved?
> 
> 

No offense to any of the maintainers, but the e-mail system is
optimized for a very large number of very, very small changes. It isn't
optimized for large changes.  In a way it tends to discourage any kind
of big improvements.

The idea of checking in a very large number of small patches makes
sense for auditing.  And yes having both isn't totally possible, so I
don't know really where the line should go between the two.  But taking
things to one extreme or the other doesn't make sense either.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Baruch Siach]

Hi Michael,

On Sun, Jan 29, 2017 at 01:41:49PM -0800, Michael Zoran wrote:
> On Sun, 2017-01-29 at 23:06 +0200, Baruch Siach wrote:
> > Kernel development is email based. See "Why kernel development still
> > uses? email"[1]. What would you like to see improved?
> 
> No offense to any of the maintainers, but the e-mail system is
> optimized for a very large number of very, very small changes. It isn't
> optimized for large changes.  In a way it tends to discourage any kind
> of big improvements.
> 
> The idea of checking in a very large number of small patches makes
> sense for auditing.  And yes having both isn't totally possible, so I
> don't know really where the line should go between the two.  But taking
> things to one extreme or the other doesn't make sense either.

In extreme cases like the examples below sending email patches doesn't make 
sense, so direct git pulls can be used instead. But these cases are quite 
rare.

Commit 07a8c03f3e0 (ARM: reduce defconfigs) shortstat is:

 177 files changed, 652 insertions(+), 194157 deletions(-)

Commit 607ca46e97 (UAPI: (Scripted) Disintegrate include/linux) shortstat is:

 578 files changed, 32659 insertions(+), 30108 deletions(-)

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Sun, 2017-01-29 at 23:52 +0200, Baruch Siach wrote:
> On Sun, Jan 29, 2017 at 01:41:49PM -0800, Michael Zoran wrote:
> > On Sun, 2017-01-29 at 23:06 +0200, Baruch Siach wrote:
> > > Kernel development is email based. See "Why kernel development
> > > still
> > > uses? email"[1]. What would you like to see improved?
> > 
> > No offense to any of the maintainers, but the e-mail system is
> > optimized for a very large number of very, very small changes. It
> > isn't
> > optimized for large changes.? In a way it tends to discourage any
> > kind
> > of big improvements.
> > 
> > The idea of checking in a very large number of small patches makes
> > sense for auditing.? And yes having both isn't totally possible, so
> > I
> > don't know really where the line should go between the two.? But
> > taking
> > things to one extreme or the other doesn't make sense either.
> 
> In extreme cases like the examples below sending email patches
> doesn't make?
> sense, so direct git pulls can be used instead. But these cases are
> quite?
> rare.
> 
> Commit 07a8c03f3e0 (ARM: reduce defconfigs) shortstat is:
> 
> ?177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> Commit 607ca46e97 (UAPI: (Scripted) Disintegrate include/linux)
> shortstat is:
> 
> ?578 files changed, 32659 insertions(+), 30108 deletions(-)

Pulls make sense, but perhaps a concept of a pull that only allows a
subtree to be modified makes sense.

Perhaps you have some idiot that doesn't know what they are doing.  If
you confine their changes to a certain directory, in theory it would
limit that amount of damage that could be done(to a certain extent).

At the very minimum, I would think that hardware specific drivers
should be handled differently then core drivers or non-platform
specific drivers.

I mean really, why should the vendor of the RPI have to deal with a
gazillion requests to change the default built configuration.

But then again, having everything in one tree makes it easy to make
sure everything can be rebuilt from a clean build...


  

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Sun, 2017-01-29 at 14:02 -0800, Michael Zoran wrote:
> Perhaps you have some idiot that doesn't know what they are doing.?
> If
> you confine their changes to a certain directory, in theory it would
> limit that amount of damage that could be done(to a certain extent).
> 
> At the very minimum, I would think that hardware specific drivers
> should be handled differently then core drivers or non-platform
> specific drivers.
> 
> I mean really, why should the vendor of the RPI have to deal with a
> gazillion requests to change the default built configuration.
> 
> But then again, having everything in one tree makes it easy to make

Basically, what I'm thinking is this:

Have a bcm283x module that is somehow changed locally and tested
locally, but the whole module gets published to the larger tree as a
snapshot.  Anybody that normally submits changes to bcm283x can change
any file.  I wouldn't take things to the extreme of having an owner of
the i2c module and another owner of the SPI module. The modules should
be reasonably large.

If it's better to have binary drops or source code drops I'm not sure. 
Source drops with some change history makes more sense to me.

As for the signed off part or requiring multiple signed off bys, that
seems broken to me.  The idea of having multiple people approve of
every single change is awesome.  But at the same time it needs to be
built into the software revision control system.  I mean, I e-mail a
patch or change with my name.  I really don't have any idea, control,
or verification that the change I e-mail is actually the change that is
getting applied with my name on it.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Uwe Kleine-König]

On Sun, Jan 29, 2017 at 02:24:08PM -0800, Michael Zoran wrote:
> On Sun, 2017-01-29 at 14:02 -0800, Michael Zoran wrote:
> > Perhaps you have some idiot that doesn't know what they are doing.?
> > If you confine their changes to a certain directory, in theory it
> > would limit that amount of damage that could be done(to a certain
> > extent).

That's why you get a shortstat when doing a pull or merge. And given
these responsibilites are not sharp. So sometimes a dt change comes in
the i2c pull. Then the i2c maintainer points that out in the pull
request and the commit has an ack from a dt guy.

I think you cannot simplify this with technical means that stop you when
a tree contains changes not in its area of responsibility.

> > At the very minimum, I would think that hardware specific drivers
> > should be handled differently then core drivers or non-platform
> > specific drivers.

I don't agree. To be able to review a driver to a Broadcom specific spi
driver, you need to know more about spi than about Broadcom.

> > I mean really, why should the vendor of the RPI have to deal with a
> > gazillion requests to change the default built configuration.

I cannot follow. If you want to change the defconfig for the RPI you
modify a file in arch/arm/boot/config and send the change to the ARM
people.

> > But then again, having everything in one tree makes it easy to make
> 
> Basically, what I'm thinking is this:
> 
> Have a bcm283x module that is somehow changed locally and tested
> locally, but the whole module gets published to the larger tree as a

There is nothing stopping you here to provide a tree with all adaptions
needed for your machine. You won't probably get this merged into next
(or another tree) though.

> snapshot.  Anybody that normally submits changes to bcm283x can change
> any file.  I wouldn't take things to the extreme of having an owner of
> the i2c module and another owner of the SPI module. The modules should

It's well possible (and usual) that the "owner" of the spi and the i2c
driver are the same.

> be reasonably large.
> 
> If it's better to have binary drops or source code drops I'm not sure. 
> Source drops with some change history makes more sense to me.
> 
> As for the signed off part or requiring multiple signed off bys, that
> seems broken to me.  The idea of having multiple people approve of
> every single change is awesome.  But at the same time it needs to be
> built into the software revision control system.  I mean, I e-mail a
> patch or change with my name.  I really don't have any idea, control,
> or verification that the change I e-mail is actually the change that is
> getting applied with my name on it.

Yes, you have a mean to verify. For example git patch-id works.

And I wonder what you suggest to make sure that nobody is able to fake
being you and get a patch committed in your name. (Maybe there exists
even another guy with your name?)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Mon, 2017-01-30 at 08:56 +0100, Uwe Kleine-K?nig wrote:
> On Sun, Jan 29, 2017 at 02:24:08PM -0800, Michael Zoran wrote:
> I don't agree. To be able to review a driver to a Broadcom specific
> spi
> driver, you need to know more about spi than about Broadcom.
> 

I would say that's 50/50.  Some of these drivers like I2C or SPI
are?not really that complex.  The complexity happens when people begin
to try to connect the various drivers in arbitrary ways at which point
things begin to break.

SOCs are designed with cost in mind, so allowing arbitrary
configurations are not aways possible because of attempts to limits the
amount of hardware resources required and the complexity. And I don't
think this is specific to Broadcom or anybody. It's just the way SOCs
work.

This is all vary different from PCs where you expect people to buy
random parts and start connecting them together.  For the reasons I
have given, SOCs arn't quite as flexible.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Uwe Kleine-König]

On Mon, Jan 30, 2017 at 12:09:32AM -0800, Michael Zoran wrote:
> On Mon, 2017-01-30 at 08:56 +0100, Uwe Kleine-K?nig wrote:
> > On Sun, Jan 29, 2017 at 02:24:08PM -0800, Michael Zoran wrote:
> > I don't agree. To be able to review a driver to a Broadcom specific
> > spi
> > driver, you need to know more about spi than about Broadcom.
> > 
> 
> I would say that's 50/50.  Some of these drivers like I2C or SPI
> are?not really that complex.  The complexity happens when people begin
> to try to connect the various drivers in arbitrary ways at which point
> things begin to break.
> 
> SOCs are designed with cost in mind, so allowing arbitrary
> configurations are not aways possible because of attempts to limits the
> amount of hardware resources required and the complexity. And I don't
> think this is specific to Broadcom or anybody. It's just the way SOCs
> work.
> 
> This is all vary different from PCs where you expect people to buy
> random parts and start connecting them together.  For the reasons I
> have given, SOCs arn't quite as flexible.

I fail to follow here. Can you please show an example where you see a
benefit from having the drivers grouped by SoC instead of bus type?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Mon, 2017-01-30 at 09:51 +0100, Uwe Kleine-K?nig wrote:
> On Mon, Jan 30, 2017 at 12:09:32AM -0800, Michael Zoran wrote:
> > On Mon, 2017-01-30 at 08:56 +0100, Uwe Kleine-K?nig wrote:
> > > On Sun, Jan 29, 2017 at 02:24:08PM -0800, Michael Zoran wrote:
> > > I don't agree. To be able to review a driver to a Broadcom
> > > specific
> > > spi
> > > driver, you need to know more about spi than about Broadcom.
> > > 
> > 
> > I would say that's 50/50.??Some of these drivers like I2C or SPI
> > are?not really that complex.??The complexity happens when people
> > begin
> > to try to connect the various drivers in arbitrary ways at which
> > point
> > things begin to break.
> > 
> > SOCs are designed with cost in mind, so allowing arbitrary
> > configurations are not aways possible because of attempts to limits
> > the
> > amount of hardware resources required and the complexity. And I
> > don't
> > think this is specific to Broadcom or anybody. It's just the way
> > SOCs
> > work.
> > 
> > This is all vary different from PCs where you expect people to buy
> > random parts and start connecting them together.??For the reasons I
> > have given, SOCs arn't quite as flexible.
> 
> I fail to follow here. Can you please show an example where you see a
> benefit from having the drivers grouped by SoC instead of bus type?
> 

Two that instantly come to mind are GPIO function assignment and clock
management.   Most SOCs and I'm not just talking about the RPI can't
handle arbitrary configuration of GPIO function mapping.  They also
tend to generate one clock off the other for different peripherals. 
Change the clock of one peripheral or the CPU, and other peripheral
breaks.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Stefan Wahren]

Hi Michael,

> 
> 3. Why do the branches of the git all contain very old versions of the
> kernel?
> 

since it's Stephen's repo. Eric uses his github repo for up- and downstream work.

Stefan

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Michael Zoran]

On Sun, 2017-01-29 at 12:52 -0800, Michael Zoran wrote:
> On Sun, 2017-01-29 at 22:08 +0200, Baruch Siach wrote:
> > Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
> > 
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > ?MAINTAINERS | 4 ++--
> > ?1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 26edd832c64e..d69449735876 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2612,7 +2612,7 @@ N:	bcm216*
> > ?N:	kona
> > ?F:	arch/arm/mach-bcm/
> > ?
> > -BROADCOM BCM2835 ARM ARCHITECTURE
> > +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
> > ?M:	Stephen Warren <swarren@wwwdotorg.org>
> > ?M:	Lee Jones <lee@kernel.org>
> > ?M:	Eric Anholt <eric@anholt.net>
> > @@ -2620,7 +2620,7 @@ L:	linux-rpi-kernel at lists.infradead.or
> > g
> > (moderated for non-subscribers)
> > ?L:	linux-arm-kernel at lists.infradead.org (moderated for non-
> > subscribers)
> > ?T:	git
> > git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
> > ?S:	Maintained
> > -N:	bcm2835
> > +N:	bcm283[5-7x]
> > ?F:	drivers/staging/vc04_services
> > ?
> > ?BROADCOM BCM47XX MIPS ARCHITECTURE
> 
> This is all cool and whatnot, but being new I'm a bit confused how
> this
> works.
> 
> 1. Is everything still going to be e-mail based, because the e-mail
> based system could use some improvement.
> 
> 2. Are all the BCM283* files going to be clustered together or still
> scattered through the tree?
> 
> 3. Why do the branches of the git all contain very old versions of
> the
> kernel?

Just want to add a few more two cents here:

1. Perhaps instead of scattering the drivers, maybe their should be a
single driver/module for bcm283x. That way it's wouldn't be neccessary
to have all these crazy runtime dependencies.

I bought an ODROID awhile ago, and they put all their drivers in the
same directory.  The only problem is that they are not continuing to
maintain it for newer kernel versions.

2. The whole runtime device tree thing for a SOC doesn't make sense.  
On a PC you can have all kinds of combinations of devices that the end
user randomly connects together.  But for a SOC, the parts are
essentially all permanently connected together. So what is the purpose
of all the runtime configuration complexity?

I once looked at another attempt at runtime configuration of a SOC by
another company called Microchip.  It's called "Harmony" and everybody
thiks the whole thing is a mess.

3. If someone is implying to rollback the kernel version to an older
kernel, I'm not sure that makes sense.   Newer linux distros won't run
on older versions.  That's one of the issues I saw right away with the
ODROID device I bought.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Stephen Warren]

On 01/29/2017 01:08 PM, Baruch Siach wrote:
> Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).

> -BROADCOM BCM2835 ARM ARCHITECTURE
> +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
...
>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git

It would make sense to update that too, if Eric isn't using this. 
However, that's a subject for a different patch perhaps.

Acked-by: Stephen Warren <swarren@wwwdotorg.org>

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 01/29/2017 01:08 PM, Baruch Siach wrote:
>> Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
>
>> -BROADCOM BCM2835 ARM ARCHITECTURE
>> +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
> ...
>>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>
> It would make sense to update that too, if Eric isn't using this. 
> However, that's a subject for a different patch perhaps.
>
> Acked-by: Stephen Warren <swarren@wwwdotorg.org>

Pulled this patch, sent a followup for the tree location.

Thinking of MAINTAINERS, I was wondering if you and Lee were both still
interested in being on the list?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170131/367272f6/attachment.sig>

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Stephen Warren]

On 01/31/2017 12:49 PM, Eric Anholt wrote:
> Stephen Warren <swarren@wwwdotorg.org> writes:
>
>> On 01/29/2017 01:08 PM, Baruch Siach wrote:
>>> Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
>>
>>> -BROADCOM BCM2835 ARM ARCHITECTURE
>>> +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
>> ...
>>>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>>
>> It would make sense to update that too, if Eric isn't using this.
>> However, that's a subject for a different patch perhaps.
>>
>> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
>
> Pulled this patch, sent a followup for the tree location.
>
> Thinking of MAINTAINERS, I was wondering if you and Lee were both still
> interested in being on the list?

To be honest, I was thinking about sending a patch to remove myself 
since you've been taking care of everything well and I've been too lazy 
to do anything RPi related recently.

[PATCH] MAINTAINERS: extend Raspberry Pi entry

[Eric Anholt]

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 01/31/2017 12:49 PM, Eric Anholt wrote:
>> Stephen Warren <swarren@wwwdotorg.org> writes:
>>
>>> On 01/29/2017 01:08 PM, Baruch Siach wrote:
>>>> Add bcm2836 (Raspberry Pi 2) and bcm2837 (Raspberry Pi 3).
>>>
>>>> -BROADCOM BCM2835 ARM ARCHITECTURE
>>>> +BROADCOM BCM2835/BCM2836/BCM2837 ARM ARCHITECTURE
>>> ...
>>>>  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
>>>
>>> It would make sense to update that too, if Eric isn't using this.
>>> However, that's a subject for a different patch perhaps.
>>>
>>> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
>>
>> Pulled this patch, sent a followup for the tree location.
>>
>> Thinking of MAINTAINERS, I was wondering if you and Lee were both still
>> interested in being on the list?
>
> To be honest, I was thinking about sending a patch to remove myself 
> since you've been taking care of everything well and I've been too lazy 
> to do anything RPi related recently.

Sounds good.

I've been mulling over a couple of ideas about bcm2835 maintainership of
the tree since LCA: one is asking Florian if he'd like me to just be a
co-maintainer with a limited role within the stblinux tree (bcm2835 is
pretty low traffic, I don't see the need for a separate tree), and the
other is picking up one of the more active current Pi developers as a
co-maintainer within the current tree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170201/a05e6cb6/attachment.sig>