FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 03-01-2012, 06:39 AM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

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.

The specific patches are:
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077 981c28286
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73 aca4b7a34

I imagine there will be more patches as more stuff is moved over to FDT.

Is this our first platform which requires an FDT? Do we have a plan in
mind for how to deal with those? The FDT file needs to live in /boot so
the bootloader can find it. They aren't big -- it seems that an 8K DTB
would be quite a large one.

Although in principal they describe the hardware in reality the FDTs are
being co-evolved along with the kernel code -- I'm not sure what the
upstream policy is wrt backwards compatibility. I would hope that,
modulo bugs, the most recent FDT would work for all kernels but I don't
know that this is going to be the case.

I think the choices are:
* version the DTB files, like we do for vmlinuz and initrd, and
have all the relevant ones in each linux-image package;
* put all supported DTBs in a single package (linux-base? or
something new? per arch?);
* a new (tiny) package per supported board;
* punt the problem to the bootloader package and/or the user;

I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate
at install time since you can only support a single board at a time that
way.

Ian.

[0] http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx
--
Ian Campbell


BOFH excuse #129:

The ring needs another token
 
Old 03-02-2012, 01:57 AM
Ben Hutchings
 
Default ARM: backporting dreamplug patches for Wheezy

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.

> The specific patches are:
> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077 981c28286
> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73 aca4b7a34
>
> I imagine there will be more patches as more stuff is moved over to FDT.
>
> Is this our first platform which requires an FDT? Do we have a plan in
> mind for how to deal with those? The FDT file needs to live in /boot so
> the bootloader can find it. They aren't big -- it seems that an 8K DTB
> would be quite a large one.

powerpc installs device tree stuff into /usr/lib/<package>/dts. I
believe the appropriate files are compiled and then appended or linked
to the kernel at installation time by mkvmlinuz. (I hope someone who
actually knows powerpc can correct me on this...)

> Although in principal they describe the hardware in reality the FDTs are
> being co-evolved along with the kernel code -- I'm not sure what the
> upstream policy is wrt backwards compatibility. I would hope that,
> modulo bugs, the most recent FDT would work for all kernels but I don't
> know that this is going to be the case.

Doesn't sound like a safe assumption.

> I think the choices are:
> * version the DTB files, like we do for vmlinuz and initrd, and
> have all the relevant ones in each linux-image package;
> * put all supported DTBs in a single package (linux-base? or
> something new? per arch?);
> * a new (tiny) package per supported board;
> * punt the problem to the bootloader package and/or the user;
>
> I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate
> at install time since you can only support a single board at a time that
> way.

Is it safe to assume that boot loaders will be able to pass in DTBs?
Thinking forward, what if existing platforms get DT support and we want
to consolidate flavours without requiring an updated boot loader?

I think ideally we should be able to build a kernel image which can
accept a DTB either appended or passed separately by the boot loader.
Is that supported?

Ben.

> Ian.
>
> [0] http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx

--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
 
Old 03-02-2012, 05:41 AM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

On Fri, 2012-03-02 at 02:57 +0000, Ben Hutchings wrote:
> 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.

Yes it's kirkwood.

> > The specific patches are:
> > http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077 981c28286
> > http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73 aca4b7a34
> >
> > I imagine there will be more patches as more stuff is moved over to FDT.
> >
> > Is this our first platform which requires an FDT? Do we have a plan in
> > mind for how to deal with those? The FDT file needs to live in /boot so
> > the bootloader can find it. They aren't big -- it seems that an 8K DTB
> > would be quite a large one.
>
> powerpc installs device tree stuff into /usr/lib/<package>/dts. I
> believe the appropriate files are compiled and then appended or linked
> to the kernel at installation time by mkvmlinuz. (I hope someone who
> actually knows powerpc can correct me on this...)

This sounds like they use the powerpc equivalent of
CONFIG_ARM_APPENDED_DTB.

I don't see mkvmlinuz on ARM. Is flash-kernel the ARM equivalent?

> > Although in principal they describe the hardware in reality the FDTs are
> > being co-evolved along with the kernel code -- I'm not sure what the
> > upstream policy is wrt backwards compatibility. I would hope that,
> > modulo bugs, the most recent FDT would work for all kernels but I don't
> > know that this is going to be the case.
>
> Doesn't sound like a safe assumption.

No, I suppose not :-(

> > I think the choices are:
> > * version the DTB files, like we do for vmlinuz and initrd, and
> > have all the relevant ones in each linux-image package;
> > * put all supported DTBs in a single package (linux-base? or
> > something new? per arch?);
> > * a new (tiny) package per supported board;
> > * punt the problem to the bootloader package and/or the user;
> >
> > I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate
> > at install time since you can only support a single board at a time that
> > way.
>
> Is it safe to assume that boot loaders will be able to pass in DTBs?

I had to turn on the config option in u-boot. I've sent a patch to
u-boot upstream for this board type. Existing u-boot's for other
kirkwood platforms probably don't have this enabled.

> Thinking forward, what if existing platforms get DT support and we want
> to consolidate flavours without requiring an updated boot loader?

Enabling DTB support does not conflict with the existing mach-types/ATAG
for boards which use that so you can have DTB and non-DTB boards enabled
in the build and the former will use a DTB while the latter will use the
ATAGs mechanism like they do today.

> I think ideally we should be able to build a kernel image which can
> accept a DTB either appended or passed separately by the boot loader.
> Is that supported?

If you enable CONFIG_ARM_APPENDED_DTB then the kernel will get the DTB
from either the bootloader or find it appended (appended appears to take
priority, if I'm reading the asm right).

Ian.
--
Ian Campbell


Time flies like an arrow. Fruit flies like a banana.
 
Old 03-02-2012, 01:09 PM
Arnaud Patard (Rtp)
 
Default ARM: backporting dreamplug patches for Wheezy

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. 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). 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

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.

>
>> The specific patches are:
>> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077 981c28286
>> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73 aca4b7a34
>>
>> I imagine there will be more patches as more stuff is moved over to FDT.
>>
>> Is this our first platform which requires an FDT? Do we have a plan in
>> mind for how to deal with those? The FDT file needs to live in /boot so
>> the bootloader can find it. They aren't big -- it seems that an 8K DTB
>> would be quite a large one.
>
> powerpc installs device tree stuff into /usr/lib/<package>/dts. I
> believe the appropriate files are compiled and then appended or linked
> to the kernel at installation time by mkvmlinuz. (I hope someone who
> actually knows powerpc can correct me on this...)
>

I guess that on armel/armhf, I believe it should be handled on
flash-kernel side, in order to handle it correctly. For instance, we'll
have devices with uboot supporting device tree and other with uboot not
supporting it (and, updating uboot is not always possible).

>> Although in principal they describe the hardware in reality the FDTs are
>> being co-evolved along with the kernel code -- I'm not sure what the
>> upstream policy is wrt backwards compatibility. I would hope that,
>> modulo bugs, the most recent FDT would work for all kernels but I don't
>> know that this is going to be the case.
>
> Doesn't sound like a safe assumption.

device tree code is still work in progress and given that there are
still a lot of places/drivers missing support for it, things may
change. One should be very carefull when making assumptions about it.

>
>> I think the choices are:
>> * version the DTB files, like we do for vmlinuz and initrd, and
>> have all the relevant ones in each linux-image package;
>> * put all supported DTBs in a single package (linux-base? or
>> something new? per arch?);
>> * a new (tiny) package per supported board;
>> * punt the problem to the bootloader package and/or the user;
>>
>> I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate
>> at install time since you can only support a single board at a time that
>> way.
>
> Is it safe to assume that boot loaders will be able to pass in DTBs?
> Thinking forward, what if existing platforms get DT support and we want
> to consolidate flavours without requiring an updated boot loader?

We will have to handle the case of bootloaders not supporting device
tree. Moreover, some systems are not using uboot at all (for instance,
custom vendor bootloader or redboot) or can't update the uboot. Also,
some new devices may use UEFI in future and I've no idea how it'll be
handled.

>
> I think ideally we should be able to build a kernel image which can
> accept a DTB either appended or passed separately by the boot loader.
> Is that supported?

This will have to be checked/tested. At least, the Kconfig entry for
ARM_APPENDED_DTB is quite scary about enabling it and booting without a
DTB appended.

Arnaud


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87pqcvccwm.fsf@lebrac.rtp-net.org">http://lists.debian.org/87pqcvccwm.fsf@lebrac.rtp-net.org
 
Old 03-02-2012, 01:37 PM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

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.

Are you sure? The two patches I'm talking about touch:
$ git diff --stat HEAD~2
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 | 180 ++++++++++++++++++++++++++++++
6 files changed, 228 insertions(+), 0 deletions(-)

I've applied these to v3.3-rc4 and they worked fine.

I also tested a previous non-DT version of dreamplug support on v3.2.
These patches are very similar apart from the user of DT other the
mach-type to identify the dreamplug.

I haven't yet tested backported versions of the two DT patches.

The DT support in the above is very basic and doesn't extend to many
peripherals at all (only the UART). In fact if we only take the first
patch then it only covers board ID and none of the peripherals.

> 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). 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
>
> 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 hope it won't come to that.

Ian.

--
Ian Campbell
Current Noise: Crippled Black Phoenix - Laying Traps

Save yourself from the 'Gates' of hell, use Linux." -- like that one.
-- The_Kind @ LinuxNet


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1330699054.18632.82.camel@zakaz.uk.xensource.com"> http://lists.debian.org/1330699054.18632.82.camel@zakaz.uk.xensource.com
 
Old 03-20-2012, 08:00 AM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

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.
 
Old 04-08-2012, 10:10 AM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

On Tue, 2012-03-20 at 09:00 +0000, Ian Campbell wrote:
> 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.

So... I backported thepatches which went into v3.4-rc1 to v3.2 and
applied them to the Debian kernel package (full diff of that vs 3.2.14-1
is attached). I've also pushed the backported branch to:
git://gitorious.org/ijc/linux.git debian/squeeze/dreamplug
(branch is actually based on 3.2.9)

The upstream commits are:

e871b87a1e97 ARM: kirkwood: use devicetree for rtc-mv
ea983ede1195 ARM: kirkwood: rtc-mv devicetree bindings
163f2cea673a ARM: kirkwood: fdt: define uart[01] as disabled, enable uart0
6fa6b8781fbd ARM: kirkwood: fdt: facilitate new boards during fdt migration
2b45e05f51a7 ARM: kirkwood: fdt: absorb kirkwood_init()
b77816dea3e4 ARM: kirkwood: fdt: use mrvl ticker symbol
a855a7ced4f5 ARM: orion: wdt: use resource vice direct access
7399532065a6 ARM: Kirkwood: Remove tclk from kirkwood_asoc_platform_data.
d34b7d452397 ARM: orion: spi: remove enable_clock_fix which is not used
759a45185ac0 ARM: kirkwood: convert uart0 to devicetree.
3d468b6d6052 ARM: kirkwood: add dreamplug (fdt) support.

There is one additional build fix which I have sent upstream:
http://lists.arm.linux.org.uk/lurker/message/20120406.131038.d940552d.en.html

The total impact is:
$ git diff --stat v3.2.9 HEAD
arch/arm/boot/dts/kirkwood-dreamplug.dts | 24 +++++
arch/arm/boot/dts/kirkwood.dtsi | 36 +++++++
arch/arm/mach-kirkwood/Kconfig | 14 +++
arch/arm/mach-kirkwood/Makefile | 2 +
arch/arm/mach-kirkwood/Makefile.boot | 2 +
arch/arm/mach-kirkwood/board-dreamplug.c | 152 ++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 75 +++++++++++++++
arch/arm/mach-kirkwood/common.c | 11 +-
arch/arm/mach-kirkwood/common.h | 15 +++
arch/arm/plat-orion/common.c | 7 +-
drivers/rtc/rtc-mv.c | 9 ++
drivers/spi/spi-orion.c | 5 -
drivers/watchdog/orion_wdt.c | 24 +++--
include/linux/spi/orion_spi.h | 1 -

Of this the non-kirkwood changes are from:
ea983ede1195 ARM: kirkwood: rtc-mv devicetree bindings
a855a7ced4f5 ARM: orion: wdt: use resource vice direct access
7399532065a6 ARM: Kirkwood: Remove tclk from kirkwood_asoc_platform_data.
d34b7d452397 ARM: orion: spi: remove enable_clock_fix which is not used

By my inspection these changes (which include the plat-orion change and
the rtc, spi and watchdog driver changes) are fine WRT other platforms
using these drivers and obviously if they weren't then that would be a
bug which can & should be fixed with upstream.

The changes to mach-kirkwood/common.[ch] are purely about exporting some
functions (i.e. removing the static and adding a prototype to a header),
this is part of the upstream strategy for minimising the impact on
non-DT kirkwood platforms.

Apart from the build fix all these changes are in the mainline kernel.

Enabling DT on a flavour appears to mangle the ABI in ways which I
expect is not going to be easy to avoid so this change will probably
have to wait until an ABI bump.

These Dreamplug patches add DT support for kirkwood in a way which is
designed not to interfere with existing non-DT platforms and more
generally upstream has done things in a way that FDT and ATAG platforms
can safely be supported using the same kernel image.

Ian.
--
Ian Campbell


BOFH excuse #165:

Backbone Scoliosis
 
Old 04-08-2012, 10:25 AM
Martin Michlmayr
 
Default ARM: backporting dreamplug patches for Wheezy

* Ian Campbell <ijc@hellion.org.uk> [2012-04-08 11:10]:
> These Dreamplug patches add DT support for kirkwood in a way which is
> designed not to interfere with existing non-DT platforms and more
> generally upstream has done things in a way that FDT and ATAG platforms
> can safely be supported using the same kernel image.

I'm no longer on the kernel team but fwiw I'm all in favour of these
patches going into the Debian kernel for wheezy (if we can figure out
a solution for the ABI change).

--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120408102526.GA28516@jirafa.cyrius.com">http://lists.debian.org/20120408102526.GA28516@jirafa.cyrius.com
 
Old 04-08-2012, 08:17 PM
Ben Hutchings
 
Default ARM: backporting dreamplug patches for Wheezy

On Sun, 2012-04-08 at 11:25 +0100, Martin Michlmayr wrote:
> * Ian Campbell <ijc@hellion.org.uk> [2012-04-08 11:10]:
> > These Dreamplug patches add DT support for kirkwood in a way which is
> > designed not to interfere with existing non-DT platforms and more
> > generally upstream has done things in a way that FDT and ATAG platforms
> > can safely be supported using the same kernel image.
>
> I'm no longer on the kernel team but fwiw I'm all in favour of these
> patches going into the Debian kernel for wheezy (if we can figure out
> a solution for the ABI change).

We shouldn't worry too much about ABI changes until shortly before
release.

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
 
Old 04-09-2012, 11:45 AM
Ian Campbell
 
Default ARM: backporting dreamplug patches for Wheezy

On Sun, 2012-04-08 at 21:17 +0100, Ben Hutchings wrote:
> On Sun, 2012-04-08 at 11:25 +0100, Martin Michlmayr wrote:
> > * Ian Campbell <ijc@hellion.org.uk> [2012-04-08 11:10]:
> > > These Dreamplug patches add DT support for kirkwood in a way which is
> > > designed not to interfere with existing non-DT platforms and more
> > > generally upstream has done things in a way that FDT and ATAG platforms
> > > can safely be supported using the same kernel image.
> >
> > I'm no longer on the kernel team but fwiw I'm all in favour of these
> > patches going into the Debian kernel for wheezy (if we can figure out
> > a solution for the ABI change).
>
> We shouldn't worry too much about ABI changes until shortly before
> release.

I suppose we don't want to be bumping it willy-nilly though? Would
adding some ignores be appropriate in the short term? Or shall we wait
until we are bumping for some other reason? The not already ignored new
and changed symbols are:

Added symbols:
irq_create_of_mapping module: vmlinux, version: 0x4e7df11b, export: EXPORT_SYMBOL_GPL
irq_dispose_mapping module: vmlinux, version: 0x2c7db649, export: EXPORT_SYMBOL_GPL
irq_domain_add_simple module: vmlinux, version: 0xdd9fba6c, export: EXPORT_SYMBOL_GPL
irq_domain_generate_simple module: vmlinux, version: 0x96a06d17, export: EXPORT_SYMBOL_GPL
irq_domain_simple_ops module: vmlinux, version: 0x54853294, export: EXPORT_SYMBOL_GPL
irq_of_parse_and_map module: vmlinux, version: 0x1ee9814e, export: EXPORT_SYMBOL_GPL
mmc_spi_get_pdata module: drivers/mmc/host/of_mmc_spi, version: 0xfe4dab60, export: EXPORT_SYMBOL
mmc_spi_put_pdata module: drivers/mmc/host/of_mmc_spi, version: 0x64163f18, export: EXPORT_SYMBOL
of_address_to_resource module: vmlinux, version: 0x8dad55e8, export: EXPORT_SYMBOL_GPL
of_alias_get_id module: vmlinux, version: 0xb0a6e317, export: EXPORT_SYMBOL_GPL
of_dev_get module: vmlinux, version: 0xefdc6847, export: EXPORT_SYMBOL
of_dev_put module: vmlinux, version: 0x15955066, export: EXPORT_SYMBOL
of_device_alloc module: vmlinux, version: 0xc72f5cab, export: EXPORT_SYMBOL
of_device_is_available module: vmlinux, version: 0xa568af0e, export: EXPORT_SYMBOL
of_device_is_compatible module: vmlinux, version: 0xb3eaf07b, export: EXPORT_SYMBOL
of_device_register module: vmlinux, version: 0x286373c8, export: EXPORT_SYMBOL
of_device_unregister module: vmlinux, version: 0x3de3433e, export: EXPORT_SYMBOL
of_fdt_unflatten_tree module: vmlinux, version: 0x14d5945d, export: EXPORT_SYMBOL_GPL
of_find_all_nodes module: vmlinux, version: 0x2c93eb74, export: EXPORT_SYMBOL
of_find_compatible_node module: vmlinux, version: 0x39834109, export: EXPORT_SYMBOL
of_find_device_by_node module: vmlinux, version: 0x9d6e5383, export: EXPORT_SYMBOL
of_find_i2c_device_by_node module: vmlinux, version: 0x5cea3d88, export: EXPORT_SYMBOL
of_find_matching_node module: vmlinux, version: 0xa240cc7f, export: EXPORT_SYMBOL
of_find_node_by_name module: vmlinux, version: 0x5bcf5e7e, export: EXPORT_SYMBOL
of_find_node_by_path module: vmlinux, version: 0xf71b39bb, export: EXPORT_SYMBOL
of_find_node_by_phandle module: vmlinux, version: 0x97515893, export: EXPORT_SYMBOL
of_find_node_by_type module: vmlinux, version: 0xd8a05f87, export: EXPORT_SYMBOL
of_find_node_with_property module: vmlinux, version: 0x4644db5c, export: EXPORT_SYMBOL
of_find_property module: vmlinux, version: 0xa1b43ab9, export: EXPORT_SYMBOL
of_get_address module: vmlinux, version: 0xbfdff814, export: EXPORT_SYMBOL
of_get_mac_address module: vmlinux, version: 0xff917654, export: EXPORT_SYMBOL
of_get_named_gpio_flags module: vmlinux, version: 0x8c7a3757, export: EXPORT_SYMBOL
of_get_next_child module: vmlinux, version: 0x69085435, export: EXPORT_SYMBOL
of_get_parent module: vmlinux, version: 0xbfb1435b, export: EXPORT_SYMBOL
of_get_pci_address module: vmlinux, version: 0x30d70fa9, export: EXPORT_SYMBOL
of_get_phy_mode module: vmlinux, version: 0xa6c38b19, export: EXPORT_SYMBOL_GPL
of_get_property module: vmlinux, version: 0x6701b467, export: EXPORT_SYMBOL
of_gpio_count module: vmlinux, version: 0xd2d51180, export: EXPORT_SYMBOL
of_gpio_simple_xlate module: vmlinux, version: 0x5c9bd695, export: EXPORT_SYMBOL
of_i2c_register_devices module: vmlinux, version: 0xf1bb6d97, export: EXPORT_SYMBOL
of_iomap module: vmlinux, version: 0x89da4432, export: EXPORT_SYMBOL
of_irq_map_one module: vmlinux, version: 0x0d3cc82c, export: EXPORT_SYMBOL_GPL
of_irq_map_pci module: vmlinux, version: 0x10c9b2cc, export: EXPORT_SYMBOL_GPL
of_irq_map_raw module: vmlinux, version: 0x5f46d244, export: EXPORT_SYMBOL_GPL
of_irq_to_resource module: vmlinux, version: 0x0d0c109d, export: EXPORT_SYMBOL_GPL
of_machine_is_compatible module: vmlinux, version: 0xd31ccb06, export: EXPORT_SYMBOL
of_match_device module: vmlinux, version: 0x98d7a85c, export: EXPORT_SYMBOL
of_match_node module: vmlinux, version: 0x8b1dd487, export: EXPORT_SYMBOL
of_mdiobus_register module: drivers/of/of_mdio, version: 0x8e510c51, export: EXPORT_SYMBOL
of_mm_gpiochip_add module: vmlinux, version: 0x112987a9, export: EXPORT_SYMBOL
of_modalias_node module: vmlinux, version: 0x51912c86, export: EXPORT_SYMBOL_GPL
of_n_addr_cells module: vmlinux, version: 0x85e782d6, export: EXPORT_SYMBOL
of_n_size_cells module: vmlinux, version: 0x19cebaf0, export: EXPORT_SYMBOL
of_node_get module: vmlinux, version: 0x100bb8e0, export: EXPORT_SYMBOL
of_node_put module: vmlinux, version: 0x609898f5, export: EXPORT_SYMBOL
of_parse_phandle module: vmlinux, version: 0xd034ea8a, export: EXPORT_SYMBOL
of_parse_phandles_with_args module: vmlinux, version: 0xc40be5d4, export: EXPORT_SYMBOL
of_pci_address_to_resource module: vmlinux, version: 0x55e74041, export: EXPORT_SYMBOL_GPL
of_pci_find_child_device module: vmlinux, version: 0x1d9496fc, export: EXPORT_SYMBOL_GPL
of_phy_connect module: drivers/of/of_mdio, version: 0x0533c72e, export: EXPORT_SYMBOL
of_phy_connect_fixed_link module: drivers/of/of_mdio, version: 0xb417e435, export: EXPORT_SYMBOL
of_phy_find_device module: drivers/of/of_mdio, version: 0x0f086c1c, export: EXPORT_SYMBOL
of_platform_bus_probe module: vmlinux, version: 0x637bf864, export: EXPORT_SYMBOL
of_platform_device_create module: vmlinux, version: 0xc780f8d3, export: EXPORT_SYMBOL
of_property_count_strings module: vmlinux, version: 0xf917873d, export: EXPORT_SYMBOL_GPL
of_property_read_string module: vmlinux, version: 0x090b2bab, export: EXPORT_SYMBOL_GPL
of_property_read_string_index module: vmlinux, version: 0xba259250, export: EXPORT_SYMBOL_GPL
of_property_read_u32_array module: vmlinux, version: 0xb69dc381, export: EXPORT_SYMBOL_GPL
of_property_read_u64 module: vmlinux, version: 0x0091a075, export: EXPORT_SYMBOL_GPL
of_register_spi_devices module: vmlinux, version: 0x8da34a91, export: EXPORT_SYMBOL
of_translate_address module: vmlinux, version: 0xce7ce037, export: EXPORT_SYMBOL
of_translate_dma_address module: vmlinux, version: 0xa1c4b6d2, export: EXPORT_SYMBOL
system_nrt_freezable_wq module: vmlinux, version: 0x44bcfa6d, export: EXPORT_SYMBOL_GPL
unlink_framebuffer module: drivers/video/fb, version: 0xcbab59c0, export: EXPORT_SYMBOL

Changed symbols:
[...]
dma_get_required_mask module: vmlinux, version: 0xba7f4d2a -> 0xf8dcf902, export: EXPORT_SYMBOL_GPL
gpiochip_add module: vmlinux, version: 0xf9580300 -> 0x8dedddf8, export: EXPORT_SYMBOL_GPL
gpiochip_find module: vmlinux, version: 0x4d7cc893 -> 0xbb9be9e5, export: EXPORT_SYMBOL_GPL
gpiochip_is_requested module: vmlinux, version: 0x53033259 -> 0xc5fcc490, export: EXPORT_SYMBOL_GPL
gpiochip_remove module: vmlinux, version: 0xc96cdf63 -> 0x40a13176, export: EXPORT_SYMBOL_GPL
platform_add_devices module: vmlinux, version: 0xb1ffd85b -> 0x1f5122e0, export: EXPORT_SYMBOL_GPL
platform_bus module: vmlinux, version: 0xeb1866e8 -> 0xe491058c, export: EXPORT_SYMBOL_GPL
platform_bus_type module: vmlinux, version: 0xadf5beaa -> 0x9bc500df, export: EXPORT_SYMBOL_GPL
platform_create_bundle module: vmlinux, version: 0x9df51332 -> 0x1c882b19, export: EXPORT_SYMBOL_GPL
platform_device_add module: vmlinux, version: 0xa92e9496 -> 0xd070fb47, export: EXPORT_SYMBOL_GPL
platform_device_add_data module: vmlinux, version: 0x985c51bc -> 0x1135da23, export: EXPORT_SYMBOL_GPL
platform_device_add_resources module: vmlinux, version: 0xe90d36e7 -> 0xb8042331, export: EXPORT_SYMBOL_GPL
platform_device_alloc module: vmlinux, version: 0x84ef2436 -> 0xefb4b527, export: EXPORT_SYMBOL_GPL
platform_device_del module: vmlinux, version: 0xbde4553f -> 0xf0ba3d74, export: EXPORT_SYMBOL_GPL
platform_device_put module: vmlinux, version: 0x9dd6b07c -> 0x0a340dc3, export: EXPORT_SYMBOL_GPL
platform_device_register module: vmlinux, version: 0xd97ea648 -> 0x2b0660e9, export: EXPORT_SYMBOL_GPL
platform_device_register_full module: vmlinux, version: 0xbce5c9f8 -> 0x2e57a4a2, export: EXPORT_SYMBOL_GPL
platform_device_unregister module: vmlinux, version: 0x5bd7371c -> 0x50f358ea, export: EXPORT_SYMBOL_GPL
platform_driver_probe module: vmlinux, version: 0x12e4f677 -> 0xbd3e5d9a, export: EXPORT_SYMBOL_GPL
platform_driver_register module: vmlinux, version: 0xc447c518 -> 0xe1471c0b, export: EXPORT_SYMBOL_GPL
platform_driver_unregister module: vmlinux, version: 0x9d954783 -> 0x5ac60fa6, export: EXPORT_SYMBOL_GPL
platform_get_irq module: vmlinux, version: 0x3db0ad85 -> 0x0efede76, export: EXPORT_SYMBOL_GPL
platform_get_irq_byname module: vmlinux, version: 0x8a841b53 -> 0xf396c28b, export: EXPORT_SYMBOL_GPL
platform_get_resource module: vmlinux, version: 0xc34506af -> 0x8bd2f702, export: EXPORT_SYMBOL_GPL
platform_get_resource_byname module: vmlinux, version: 0x07f4d0ab -> 0xd817e7dc, export: EXPORT_SYMBOL_GPL
spi_add_device module: vmlinux, version: 0x606ce964 -> 0x38f51143, export: EXPORT_SYMBOL_GPL
spi_alloc_device module: vmlinux, version: 0x5381a295 -> 0x93b7b786, export: EXPORT_SYMBOL_GPL
spi_alloc_master module: vmlinux, version: 0x15ad8ef1 -> 0x04d874b7, export: EXPORT_SYMBOL_GPL
spi_async module: vmlinux, version: 0x65463470 -> 0x2cedd15d, export: EXPORT_SYMBOL_GPL
spi_async_locked module: vmlinux, version: 0x19289ec5 -> 0x992d1ae9, export: EXPORT_SYMBOL_GPL
spi_bus_lock module: vmlinux, version: 0x56cd0b61 -> 0xdab708fb, export: EXPORT_SYMBOL_GPL
spi_bus_type module: vmlinux, version: 0xaf1b552a -> 0x9bea2c99, export: EXPORT_SYMBOL_GPL
spi_bus_unlock module: vmlinux, version: 0xc21c9b04 -> 0x888be847, export: EXPORT_SYMBOL_GPL
spi_busnum_to_master module: vmlinux, version: 0x6d4ebe3c -> 0xec2a2b22, export: EXPORT_SYMBOL_GPL
spi_get_device_id module: vmlinux, version: 0x7069a6fa -> 0x4383b6af, export: EXPORT_SYMBOL_GPL
spi_new_device module: vmlinux, version: 0xd88ef8d1 -> 0xd3bc5e79, export: EXPORT_SYMBOL_GPL
spi_register_driver module: vmlinux, version: 0x036b5d4e -> 0xace3696e, export: EXPORT_SYMBOL_GPL
spi_register_master module: vmlinux, version: 0x46a69541 -> 0x018d5d17, export: EXPORT_SYMBOL_GPL
spi_setup module: vmlinux, version: 0x1d99a02a -> 0xae3ce335, export: EXPORT_SYMBOL_GPL
spi_sync module: vmlinux, version: 0x2afdaa5c -> 0xcef6a0a0, export: EXPORT_SYMBOL_GPL
spi_sync_locked module: vmlinux, version: 0x9239cb70 -> 0x37bcb0b4, export: EXPORT_SYMBOL_GPL
spi_unregister_master module: vmlinux, version: 0x6fd06a83 -> 0x58e9d33f, export: EXPORT_SYMBOL_GPL
spi_write_then_read module: vmlinux, version: 0x5ccbcf70 -> 0xd42fd0c1, export: EXPORT_SYMBOL_GPL
Image fits (1587744 <= 2097080). Continuing.


--
Ian Campbell


On Thanksgiving Day all over America, families sit down to dinner at the
same moment -- halftime.
 

Thread Tools




All times are GMT. The time now is 04:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org