Orion Pull request

Orion Pull request

[Andrew Lunn]

Hi Arnd, Olof

I know this is very late, the main pull request direction Linus has
been made, etc. Its been an interesting learning experience for me,
jumping in to take over from Jason.

Please note, there are a few patches between the v3.5-rc7 and the
first patch to be pulled. These patches have been accepted by the I2C
maintainer & SPI maintainer, so should not be pulled.

I also have no pgp keys in place, so there is no signed tag. I will
remedy this for next time.

If you can pull this great. Otherwise, it can wait for 3.7.

Thanks
	Andrew

The following changes since commit bcf32faebf69bfa95f72db4b818fb1358d91d38e:

  SPI: Refactor spi-orion to use SPI framework queue. (2012-07-23 13:04:11 +0200)

are available in the git repository at:

  git://github.com/lunn/linux.git v3.5-rc7-for-next-v6

for you to fetch changes up to e8891dde45f63fd8654a8ba06d95fc0eba51d697:

  ARM: Orion: fix driver probe error handling with respect to clk (2012-07-23 13:04:48 +0200)

----------------------------------------------------------------
Andrew Lunn (15):
      ARM: Orion: DT support for IRQ and GPIO Controllers
      ARM: Kirkwood: Ensure runit clock always ticks.
      ARM: Orion: Add arch support needed for I2C via DT.
      Kirkwood: Add basic device tree support for QNAP TS219.
      ARM: Orion: DTify the watchdog timer.
      ATA: sata_mv: Add device tree support
      ARM: Kirkwood: Use DT to configure SATA device.
      ARM: Kirkwood: Describe DNS325 temperature sensor in DT.
      ARM: Kirkwood: Describe IB62x0 gpio-keys in DT.
      ARM: Kirkwood: Describe iConnects temperature sensor in DT.
      ARM: Kirkwood: Describe Dreamplug LEDs in DT.
      ARM: Kirkwood: Describe GoFlex Net LEDs and SATA in DT.
      ARM: Kirkwood: Describe ib62x0 LEDs in DT.
      ARM: Kirkwood: Describe iConnect LEDs in DT.
      ARM: Kirkwood: Replace mrvl with marvell

Hannes Reinecke (1):
      mach-dove: Fixup ge00 initialisation

Jamie Lentin (3):
      kirkwood: Replace DNS-320/DNS-325 leds with dt bindings
      ARM: Kirkwood: Move common portions into a kirkwood-dnskw.dtsi
      ARM: Kirkwood: Describe DNS32? gpio-keys in DT.

Josh Coombs (1):
      ARM: Kirkwood: Initial DTS support for Kirkwood GoFlex Net

Michael Walle (3):
      ARM: kirkwood: use devicetree for orion-spi
      ARM: kirkwood: use devicetree for SPI on dreamplug
      ARM: kirkwood: Add LS-XHL and LS-CHLv2 support

Simon Baatz (2):
      ARM: Kirkwood: Fix PHY disable clk problems
      ARM: Orion: fix driver probe error handling with respect to clk

 .../devicetree/bindings/arm/mrvl/intc.txt          |   20 +++
 Documentation/devicetree/bindings/ata/marvell.txt  |   16 ++
 .../devicetree/bindings/gpio/mrvl-gpio.txt         |   23 +++
 .../devicetree/bindings/mtd/orion-nand.txt         |    4 +-
 .../devicetree/bindings/watchdog/marvel.txt        |   14 ++
 arch/arm/Kconfig                                   |    1 +
 arch/arm/boot/dts/kirkwood-dns320.dts              |   64 ++++----
 arch/arm/boot/dts/kirkwood-dns325.dts              |   70 ++++-----
 arch/arm/boot/dts/kirkwood-dnskw.dtsi              |   69 ++++++++
 arch/arm/boot/dts/kirkwood-dreamplug.dts           |   52 +++++-
 arch/arm/boot/dts/kirkwood-goflexnet.dts           |   99 ++++++++++++
 arch/arm/boot/dts/kirkwood-ib62x0.dts              |   40 ++++-
 arch/arm/boot/dts/kirkwood-iconnect.dts            |   44 +++++-
 arch/arm/boot/dts/kirkwood-lschlv2.dts             |   20 +++
 arch/arm/boot/dts/kirkwood-lsxhl.dts               |   20 +++
 arch/arm/boot/dts/kirkwood-lsxl.dtsi               |   95 +++++++++++
 arch/arm/boot/dts/kirkwood-ts219-6281.dts          |   21 +++
 arch/arm/boot/dts/kirkwood-ts219-6282.dts          |   21 +++
 arch/arm/boot/dts/kirkwood-ts219.dtsi              |   78 +++++++++
 arch/arm/boot/dts/kirkwood.dtsi                    |   66 +++++++-
 arch/arm/mach-dove/common.c                        |    4 +-
 arch/arm/mach-dove/irq.c                           |   58 +++----
 arch/arm/mach-kirkwood/Kconfig                     |   29 ++++
 arch/arm/mach-kirkwood/Makefile                    |    3 +
 arch/arm/mach-kirkwood/Makefile.boot               |    4 +
 arch/arm/mach-kirkwood/board-dnskw.c               |  143 -----------------
 arch/arm/mach-kirkwood/board-dreamplug.c           |   80 ----------
 arch/arm/mach-kirkwood/board-dt.c                  |   29 +++-
 arch/arm/mach-kirkwood/board-goflexnet.c           |   71 +++++++++
 arch/arm/mach-kirkwood/board-ib62x0.c              |   72 ---------
 arch/arm/mach-kirkwood/board-iconnect.c            |   56 -------
 arch/arm/mach-kirkwood/board-lsxl.c                |  135 ++++++++++++++++
 arch/arm/mach-kirkwood/board-ts219.c               |   82 ++++++++++
 arch/arm/mach-kirkwood/common.c                    |   72 +++++++--
 arch/arm/mach-kirkwood/common.h                    |   17 ++
 arch/arm/mach-kirkwood/irq.c                       |   38 ++---
 arch/arm/mach-mv78xx0/irq.c                        |   22 +--
 arch/arm/mach-orion5x/irq.c                        |   22 +--
 arch/arm/plat-orion/common.c                       |    1 +
 arch/arm/plat-orion/gpio.c                         |  166 +++++++++++++++-----
 arch/arm/plat-orion/include/plat/gpio.h            |   16 +-
 arch/arm/plat-orion/include/plat/irq.h             |    3 +-
 arch/arm/plat-orion/irq.c                          |   40 +++++
 drivers/ata/sata_mv.c                              |   42 +++--
 drivers/crypto/mv_cesa.c                           |    4 +
 drivers/mmc/host/mvsdio.c                          |    4 +
 drivers/mtd/nand/orion_nand.c                      |    6 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c         |    6 +
 drivers/rtc/rtc-mv.c                               |    2 +-
 drivers/usb/host/ehci-orion.c                      |    4 +
 drivers/watchdog/orion_wdt.c                       |    8 +
 sound/soc/kirkwood/kirkwood-i2s.c                  |    8 +-
 52 files changed, 1485 insertions(+), 599 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/marvell.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/marvel.txt
 create mode 100644 arch/arm/boot/dts/kirkwood-dnskw.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-goflexnet.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-lschlv2.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-lsxhl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-lsxl.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6281.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-ts219-6282.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-ts219.dtsi
 create mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
 create mode 100644 arch/arm/mach-kirkwood/board-lsxl.c
 create mode 100644 arch/arm/mach-kirkwood/board-ts219.c

Orion Pull request

[Arnd Bergmann]

On Tuesday 24 July 2012, Andrew Lunn wrote:
> I know this is very late, the main pull request direction Linus has
> been made, etc. Its been an interesting learning experience for me,
> jumping in to take over from Jason.
> 
> Please note, there are a few patches between the v3.5-rc7 and the
> first patch to be pulled. These patches have been accepted by the I2C
> maintainer & SPI maintainer, so should not be pulled.
> 
> I also have no pgp keys in place, so there is no signed tag. I will
> remedy this for next time.
> 
> If you can pull this great. Otherwise, it can wait for 3.7.
> 

Hi Andrew,

I'm looking at the series now, I was making sure to get other stuff
out of the way first for the patches that are now upstream.

I would like to pull at least some of the patches, but I think you
are missing some background on the process actually works.

Most importantly, you should not submit identical patches with
different commit IDs to different maintainers. As you explain,
your branch contains SPI and I2c patches that were applied to
other trees already and that are now upstream. If I pull your branch,
we will end up with a git history that has the same change twice,
which is confusing and causes troubles for bisection and for
dependency tracking. I'm not sure if the fact that they have been
applied to the other branches now means that something is broken
(that should never happen either), but if that is the case, I will
definitely apply the bug fixes that are needed to repair the
situation.

Another important point is that we use "topic branches" in the arm-soc
tree, so you should try to separate bug fixes, cleanups, DT conversions,
new DT files, etc all into their own branch. The "ARM: Kirkwood:
Ensure runit clock always ticks", "mach-dove: Fixup ge00 initialisation"
"ARM: Orion: fix driver probe error handling with respect to clk"
and "ARM: Kirkwood: Replace mrvl with marvell" patches definitely
fall into the "bugfix" category here, so I definitely want them.
You can send me bug fixes at any time and they will get submitted
into the latest development branch, during and after the merge window.
If a bug fix is also relevant for older kernels, please add the line
"Cc: stable at vger.kernel.org", which triggers the process of getting
the patch included into the stable kernel releases (v3.0.x, v3.4.x,
v3.5.x at this time).

Please split the other patches into branches according to what
they do, and make sure that each branch is based on an -rc release
rather than a random point in the git history or patches that
are not upstream. We can then decide which ones to still send
for v3.6 and which branches to delay for v3.7.

As a minor comment, your one-line change descriptions are not
all formatted the same way, you use "ARM: kirkwood",
"mach-kirkwood:" and "kirkwood:" intermixed. Please use just
the first one.

If you have more questions, feel free to also contact us on IRC
(on #armlinux in irc.freenode.net).

	Arnd

Orion Pull request

[Andrew Lunn]

> Please split the other patches into branches according to what
> they do, and make sure that each branch is based on an -rc release
> rather than a random point in the git history or patches that
> are not upstream. We can then decide which ones to still send
> for v3.6 and which branches to delay for v3.7.

Hi Arnd

If i make the branches based on the -rc7 release, how do i test them?
The patches have dependencies on the I2C patch now accepted by the I2C
maintainer and the SPI patches accepted by the SPI maintainer.  These
patches implement the DT support in the drivers. Without those
patches, all i2c devices are missing, and worst still, the root FS is
missing on my Kirkwood QNAP device i test with.

Note there is no compile time dependencies, just run time. So i could
initially build a patchset with those driver patches included, test
the combination works, rebase to discard the driver patches, and then
send a pull-request?

Or is there a better way to handle this?

I'm also not sure what topic branches would be appropriate. All that
is left is DT. One branch could be driver changes and the other
actually using the driver from DT. But there is a clear dependency
between the two. I cannot split the three new boards support via DT
into three topic branches because they cause merge conflicts when you
try to bring them together. What would you suggest?

   Thanks
	Andrew

Orion Pull request

[Arnd Bergmann]

On Wednesday 25 July 2012, Andrew Lunn wrote:
> > Please split the other patches into branches according to what
> > they do, and make sure that each branch is based on an -rc release
> > rather than a random point in the git history or patches that
> > are not upstream. We can then decide which ones to still send
> > for v3.6 and which branches to delay for v3.7.
> 
> Hi Arnd
> 
> If i make the branches based on the -rc7 release, how do i test them?
> The patches have dependencies on the I2C patch now accepted by the I2C
> maintainer and the SPI patches accepted by the SPI maintainer.  These
> patches implement the DT support in the drivers. Without those
> patches, all i2c devices are missing, and worst still, the root FS is
> missing on my Kirkwood QNAP device i test with.

You can merge the i2c and spi branches that went upstream into your
own branch before applying your own patches. This way, they become
"dependencies" and should get merged before yours are sent (in this
case they already are)

> Note there is no compile time dependencies, just run time. So i could
> initially build a patchset with those driver patches included, test
> the combination works, rebase to discard the driver patches, and then
> send a pull-request?
> 
> Or is there a better way to handle this?

Yes, don't rebase the stuff after testing. We want the patches that
go upstream to be the exact version you have tested.

> I'm also not sure what topic branches would be appropriate. All that
> is left is DT. One branch could be driver changes and the other
> actually using the driver from DT. But there is a clear dependency
> between the two. I cannot split the three new boards support via DT
> into three topic branches because they cause merge conflicts when you
> try to bring them together. What would you suggest?

If there are just conflicts between merging the branches (two
patches touching the same code lines), the best way to deal with it
is to let us handle the merge. We're quite experienced with this by
now.

If you have an actual dependency (branch B builds fine without branch
A, but the result doesn't work), then the branches need to be
serialized: You provide one standalone branch that has the more
basic changes (cleanups, dt conversion, ...) and then you have another
branch that starts from the top commit of the first one and has the
more advanced changes.

If you have two branches that both need a few patches but then go
on in different directions, that's also fine: just apply the common
patches first, then make two branches starting with that common
changeset and apply the other patches separately.

	Arnd

Orion Pull request

[Mark Brown]

On Thu, Jul 26, 2012 at 07:07:44AM +0000, Arnd Bergmann wrote:
> On Wednesday 25 July 2012, Andrew Lunn wrote:

> > If i make the branches based on the -rc7 release, how do i test them?
> > The patches have dependencies on the I2C patch now accepted by the I2C
> > maintainer and the SPI patches accepted by the SPI maintainer.  These
> > patches implement the DT support in the drivers. Without those
> > patches, all i2c devices are missing, and worst still, the root FS is
> > missing on my Kirkwood QNAP device i test with.

> You can merge the i2c and spi branches that went upstream into your
> own branch before applying your own patches. This way, they become
> "dependencies" and should get merged before yours are sent (in this
> case they already are)

But only if they're stable branches that won't get rebased - always
check with the subsystem maintainers about this.

Orion Pull request

[Andrew Lunn]

On Thu, Jul 26, 2012 at 07:07:44AM +0000, Arnd Bergmann wrote:
> On Wednesday 25 July 2012, Andrew Lunn wrote:
> > > Please split the other patches into branches according to what
> > > they do, and make sure that each branch is based on an -rc release
> > > rather than a random point in the git history or patches that
> > > are not upstream. We can then decide which ones to still send
> > > for v3.6 and which branches to delay for v3.7.
> > 
> > Hi Arnd
> > 
> > If i make the branches based on the -rc7 release, how do i test them?
> > The patches have dependencies on the I2C patch now accepted by the I2C
> > maintainer and the SPI patches accepted by the SPI maintainer.  These
> > patches implement the DT support in the drivers. Without those
> > patches, all i2c devices are missing, and worst still, the root FS is
> > missing on my Kirkwood QNAP device i test with.
> 
> You can merge the i2c and spi branches that went upstream into your
> own branch before applying your own patches. This way, they become
> "dependencies" and should get merged before yours are sent (in this
> case they already are)

So, here is what i think you mean....

The SPI pull request is here:

https://lkml.org/lkml/2012/7/25/204

and says

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/spi-3.6

I cannot find a pull request for i2c-embedded for 3.6. For 3.5 it was:

git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next

I've no idea if this is stable or not. I need to ask Wolfram.

So

:~/B3/QNAP/linux$ git checkout v3.5-rc7   
:~/B3/QNAP/linux$ git checkout -b v3.5-rc7-dt
:~/B3/QNAP/linux$ git remote add spi git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
:~/B3/QNAP/linux$ git fetch spi
:~/B3/QNAP/linux$ git merge spi-3.6
:~/B3/QNAP/linux$ git remote add i2c-embedded git://git.pengutronix.de/git/wsa/linux.git
:~/B3/QNAP/linux$ git fetch i2c-embedded
:~/B3/QNAP/linux$ git merge i2c-embedded/i2c-embedded/for-next

and then i have

~/B3/QNAP/linux$ git log --oneline
afddda0 Merge remote-tracking branch 'i2c-embedded/i2c-embedded/for-next' into v
0a6f855 Merge tag 'spi-3.6' into v3.5-rc7-dt
5db20c4 Revert "i2c: tegra: convert normal suspend/resume to *_noirq"
b61d157 I2C: MV64XYZ: Add Device Tree support
8ceffa7 spi/orion: remove uneeded spi_info
d76ea24 spi/bcm63xx: fix clock configuration selection
f814f9a spi/orion: add device tree binding
24ab3275 spi/omap2: mark omap2_mcspi_master_setup as __devinit
a3ce9a8 spi: omap2-mcspi: Fix the below warning
b316590 spi: Add AD-FMCOMMS1-EBZ I2C-SPI bridge driver
6f535b9 i2c: stu300: use devm managed resources
84a1caf Linux 3.5-rc7
...

So if i understand you right, i can now cherry-pick my patches into
this branch, test them and send you a pull request?

     Thanks
	Andrew

Orion Pull request

[Arnd Bergmann]

On Thursday 26 July 2012, Andrew Lunn wrote:
> So, here is what i think you mean....
> 
> The SPI pull request is here:
> 
> https://lkml.org/lkml/2012/7/25/204
> 
> and says
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/spi-3.6
> 
> I cannot find a pull request for i2c-embedded for 3.6. For 3.5 it was:
> 
> git://git.pengutronix.de/git/wsa/linux.git i2c-embedded/for-next
> 
> I've no idea if this is stable or not. I need to ask Wolfram.

Right. 

> :~/B3/QNAP/linux$ git checkout v3.5-rc7   
> :~/B3/QNAP/linux$ git checkout -b v3.5-rc7-dt
> :~/B3/QNAP/linux$ git remote add spi git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
> :~/B3/QNAP/linux$ git fetch spi
> :~/B3/QNAP/linux$ git merge spi-3.6
> :~/B3/QNAP/linux$ git remote add i2c-embedded git://git.pengutronix.de/git/wsa/linux.git
> :~/B3/QNAP/linux$ git fetch i2c-embedded
> :~/B3/QNAP/linux$ git merge i2c-embedded/i2c-embedded/for-next

Note that it's also reasonable to base this on v3.5 rather than v3.5-rc7. The important
part is to use a tag from Linus as the base. A shortcut for the 'remote add', 'fetch',
'merge' is to use

'git pull git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/spi-3.6'.

> and then i have
> 
> ~/B3/QNAP/linux$ git log --oneline
> afddda0 Merge remote-tracking branch 'i2c-embedded/i2c-embedded/for-next' into v
> 0a6f855 Merge tag 'spi-3.6' into v3.5-rc7-dt
> 5db20c4 Revert "i2c: tegra: convert normal suspend/resume to *_noirq"
> b61d157 I2C: MV64XYZ: Add Device Tree support
> 8ceffa7 spi/orion: remove uneeded spi_info
> d76ea24 spi/bcm63xx: fix clock configuration selection
> f814f9a spi/orion: add device tree binding
> 24ab3275 spi/omap2: mark omap2_mcspi_master_setup as __devinit
> a3ce9a8 spi: omap2-mcspi: Fix the below warning
> b316590 spi: Add AD-FMCOMMS1-EBZ I2C-SPI bridge driver
> 6f535b9 i2c: stu300: use devm managed resources
> 84a1caf Linux 3.5-rc7
> ...
> 
> So if i understand you right, i can now cherry-pick my patches into
> this branch, test them and send you a pull request?

Yes.

	Arnd