On Fri, 2012-03-02 at 15:09 +0100, Arnaud Patard wrote: > Ben Hutchings <ben@decadent.org.uk> writes: > > > On Thu, 2012-03-01 at 07:39 +0000, Ian Campbell wrote: > >> An initial set of patches for the Dreamplug (basically a descendant of > >> shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC > >> maintainer's tree. > >> > >> Would it be acceptable to backport these to the Wheezy kernel? I'm happy > >> to do the backporting and test them etc. I recently started running a > >> Dreamplug as my home firewall so I'm motivated to have this h/w > >> supported in Debian. > > > > So long as one of the existing flavours (kirkwood?) can support this as > > well, I see no problem with it. I'll leave it to the ARM maintainers to > > assess the state of the code. > > It's not a matter of kirkwood only. iirc, one needs more patches than > the 2 mentionned here and some a modifying code inside plat-orion. FYI I have just rebuilt 3.2.9-1 with exactly those two patches (plus a one liner backport patch) and the system boots fine using a u-boot with FDT support enabled. I didn't try the CONFIG_ARM_APPENDED_DTB mode and the help text indicates that updating the bootloader is preferable. It looks like the exact patches which are going upstream have evolved a bit since then (and there are now others which cover more functionality) so I will retry with those. > This > means it can have some side effects on orion and mv78xxx platforms too > (and I think that the patches merged have been tested only on dreamplug > and not on orion/mv78xxx). I don't think the patches touch anything near orion or mv78xxx, the diffstat of the patches I tested is: arch/arm/boot/dts/kirkwood-dreamplug.dts | 25 ++++ arch/arm/boot/dts/kirkwood.dtsi | 6 + arch/arm/mach-kirkwood/Kconfig | 14 +++ arch/arm/mach-kirkwood/Makefile | 1 + arch/arm/mach-kirkwood/Makefile.boot | 2 + arch/arm/mach-kirkwood/board-dt.c | 179 ++++++++++++++++++++++++++++++ 6 files changed, 227 insertions(+), 0 deletions(-) > Also, I don't know if the kirkwood kernels > made with device tree stuff enabled in kernel have no bad side effect on > other kirkwood devices Given the diffstat above I think this is very unlikely to be the case, at least for this round of patches. Wouldn't these concerns about damaging other boards be alleviated by using the patches which have been accepted into mainline already? (once they have been) > I'll have a look but it does not mean it'll be merged. If one needs to > backport the whole arm-soc tree to get it, I fear wear we'll be in > troubles. I'm fairly certain that things are not as bad as you fear. The series has been structured so that we could just take the first patch if we wanted. This first patch uses DTB only to identify the board, but then goes on to initialise it statically, again just like the old mach-types system. Subsequent patches just transition the device one by one from the static scheme to the DTB based scheme. Anyway, thanks for looking into this, I look forward to your conclusions. Ian.
Attachment:
signature.asc
Description: This is a digitally signed message part