We've had the regular two-week (and one day) merge window, and -rc1 is
out, and the merge window is closed.
[ I suspect I'll still merge the SCore architecture, I wanted to give it a
quick peek, but I've been busy with all the other patches so I'm closing
the merge window now, but leaving myself the option of merging Score
later - last I looked, the only non-SCore file it touched was the
MAINTAINERS file, so it's not like it should break anything else ]
There's a lot in there, but let me say that as far as the whole merge
window has gone, I've seldom felt happier merging stuff from people. I'm
really hoping it isn't just a fluke, but people kept their git trees
clean, and while there were a couple of times that I said "no, I'm not
going to merge that", on the whole this was a really painless merge window
for me.
I'm not saying that it was necessarily less bug-free than usual, I'm just
saying that on the whole people sent me merge requests that made sense,
explained what they did, and when I pulled I saw clear development lines.
That just makes it much easier for me.
So thanks to everybody involved.
I hope that doesn't mean that it was really painful for others, or that
we'll be chasing down more bugs than usual. And I _really_ hope we can
keep things going this way, and it wasn't a one-off "things just happened
to work this time".
As to the actual changes - too many to list. As usual, the bulk of the
changes are to drivers (70% of the diffs), with drivers/staging being the
bulk of that (about 60% of all driver changes - 40% of the total). But
wonder of wonder, I think drivers/staging actually _shrank_ this time
around, alledgely due to cleanups. Believe that who will.
On the filesystem front, we had btrfs, ext3 and xfs getting active
development (Why xfs? Beats me, but that's what the stats say), and a fair
chunk of work on the whole fsnotify unification work. And the VFS layer
got some TLC wrt ACL and private namespace handling.
On architectures: ARM, powerpc, mips, sh, x86 are the bulk of it. On ARM,
the bulk is new platforms (u300, freescale stmp, whatever), there seems to
be no end to crazy new arm platforms. On x86 (and at least some degree on
powerpc), a noticeable part is the whole new perf-counter subsystem. Along
with lots and lots of other stuff.
On the whole? Tons of stuff. Let's start testign and stabilizing.
Linus
Find below a minor build fix for a new ARM-only driver.
Ingo
--------------->
>From 8bf467c9f4591f77e1d69bd78fb6cc4f1ff387f8 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Thu, 25 Jun 2009 08:27:14 +0200
Subject: [PATCH] i2c: fix build bug in i2c-designware.c
This build error triggers on x86:
drivers/built-in.o: In function `i2c_dw_init':
i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
drivers/built-in.o: In function `dw_i2c_probe':
i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'
Because this new driver uses the clk_*() facilities which is an
ARM-only thing currently.
Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/i2c/busses/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d56351a..0760f25 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -334,6 +334,7 @@ config I2C_DAVINCI
config I2C_DESIGNWARE
tristate "Synopsys DesignWare"
+ depends on HAVE_CLK
help
If you say yes to this option, support will be included for the
Synopsys DesignWare I2C adapter. Only master mode is supported.
On Thu, Jun 25, 2009 at 08:32:21AM +0200, Ingo Molnar wrote:
>
> Find below a minor build fix for a new ARM-only driver.
>
> Ingo
>
> --------------->
> >From 8bf467c9f4591f77e1d69bd78fb6cc4f1ff387f8 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <[email protected]>
> Date: Thu, 25 Jun 2009 08:27:14 +0200
> Subject: [PATCH] i2c: fix build bug in i2c-designware.c
>
> This build error triggers on x86:
>
> drivers/built-in.o: In function `i2c_dw_init':
> i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
> drivers/built-in.o: In function `dw_i2c_probe':
> i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
> i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
> i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
> i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'
>
> Because this new driver uses the clk_*() facilities which is an
> ARM-only thing currently.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> drivers/i2c/busses/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index d56351a..0760f25 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -334,6 +334,7 @@ config I2C_DAVINCI
>
> config I2C_DESIGNWARE
> tristate "Synopsys DesignWare"
> + depends on HAVE_CLK
> help
> If you say yes to this option, support will be included for the
> Synopsys DesignWare I2C adapter. Only master mode is supported.
thanks, missed there not being a 'depends on' line...
Baurch - can you submit a patch to declare which ARM architectures that
this runs on, or whether Ingo's dependency on HAVE_CLK is the fix to merge?
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
Hi Ben,
On Thu, Jun 25, 2009 at 06:40:00PM +0100, Ben Dooks wrote:
> On Thu, Jun 25, 2009 at 08:32:21AM +0200, Ingo Molnar wrote:
> > >From 8bf467c9f4591f77e1d69bd78fb6cc4f1ff387f8 Mon Sep 17 00:00:00 2001
> > From: Ingo Molnar <[email protected]>
> > Date: Thu, 25 Jun 2009 08:27:14 +0200
> > Subject: [PATCH] i2c: fix build bug in i2c-designware.c
> >
> > This build error triggers on x86:
> >
> > drivers/built-in.o: In function `i2c_dw_init':
> > i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
> > drivers/built-in.o: In function `dw_i2c_probe':
> > i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
> > i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
> > i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
> > i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'
> >
> > Because this new driver uses the clk_*() facilities which is an
> > ARM-only thing currently.
> >
> > Signed-off-by: Ingo Molnar <[email protected]>
> > ---
> > drivers/i2c/busses/Kconfig | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index d56351a..0760f25 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -334,6 +334,7 @@ config I2C_DAVINCI
> >
> > config I2C_DESIGNWARE
> > tristate "Synopsys DesignWare"
> > + depends on HAVE_CLK
> > help
> > If you say yes to this option, support will be included for the
> > Synopsys DesignWare I2C adapter. Only master mode is supported.
>
> thanks, missed there not being a 'depends on' line...
>
> Baurch - can you submit a patch to declare which ARM architectures that
> this runs on, or whether Ingo's dependency on HAVE_CLK is the fix to merge?
Ingo's fix should be enough.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
Hi!
> On architectures: ARM, powerpc, mips, sh, x86 are the bulk of it. On ARM,
> the bulk is new platforms (u300, freescale stmp, whatever), there seems to
> be no end to crazy new arm platforms. On x86 (and at least some degree on
HW vendors on arm seem to produce all the new, incompatible devices,
all the time :-(. Arm vendors seem to multiply, and compatibility
seems to be very low on their list of priorities... and it is only
getting worse.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html