| Message ID | b2e1e59a752395314a20e846337cb70cf22f2959.1485720503.git.baruch@tkos.co.il (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@lists.infradead.org > (moderated for non-subscribers) > L: linux-arm-kernel@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?
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@lists.infradead.org > > (moderated for non-subscribers) > > L: linux-arm-kernel@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
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
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@lists.infradead.or > > g > > (moderated for non-subscribers) > > L: linux-arm-kernel@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.
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@lists.infradead. > > > org > > > (moderated for non-subscribers) > > > L: linux-arm-kernel@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.
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
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...
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.
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
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.
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
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.
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>
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?
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.
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.
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@lists.infradead.org (moderated for non-subscribers) L: linux-arm-kernel@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
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(-)