| Message ID | 20120724081732.GR18778@lunn.ch |
|---|---|
| State | New |
| Headers | show |
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@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
> 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
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
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.
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
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
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