* Re: linux-next: voltage tree build failure
From: Jonathan Cameron @ 2009-01-21 14:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Liam Girdwood, linux-next
In-Reply-To: <20090121134600.d6e60b2f.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Liam,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/regulator/wm8350-regulator.c: In function 'pmic_uv_handler':
> drivers/regulator/wm8350-regulator.c:1296: error: dereferencing pointer to incomplete type
> drivers/regulator/wm8350-regulator.c:1305: error: dereferencing pointer to incomplete type
>
> Immediate cause is commit 872ed3fe176833f7d43748eb88010da4bbd2f983
> ("Regulator: Push lock out of _notifier_call_chain + add voltage change
> event").
>
> I have dropped the voltage tree for today.
Sorry, my error... It's always the simple changes that you don't build
test properly that catch you out.
Liam, can you revert this patch for now and I'll send a version
that doesn't have this problem shortly.
Jonathan
^ permalink raw reply
* Re: [PATCH] regulator: Hoist struct regulator_dev out of core to fix notifiers
From: Jonathan Cameron @ 2009-01-21 14:24 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-next, linux-kernel
In-Reply-To: <1232546920-14915-1-git-send-email-broonie@opensource.wolfsonmicro.com>
Mark Brown wrote:
> Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers
> to take the struct regulator_dev lock themselves which requires that the
> struct be visible to them. Band aid this by making the struct visible.
Sorry all for introducing the problem in the first place.
Other option for a fix would be to move the lock into the
regulator_notifier_call_chain function. Probably not ideal as would lead
to possibility of releasing then immediately retaking the lock that we
were trying to avoid by pushing the locks out in the first place.
Guess it's a case of how much we want to put people off directly accessing
elements of regulator_dev.
Thanks for posting the fix Mark (just beat me to it ;)
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> drivers/regulator/core.c | 27 ---------------------------
> include/linux/regulator/driver.h | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index f17362a..0ed13c2 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -30,33 +30,6 @@ static LIST_HEAD(regulator_list);
> static LIST_HEAD(regulator_map_list);
>
> /*
> - * struct regulator_dev
> - *
> - * Voltage / Current regulator class device. One for each regulator.
> - */
> -struct regulator_dev {
> - struct regulator_desc *desc;
> - int use_count;
> -
> - /* lists we belong to */
> - struct list_head list; /* list of all regulators */
> - struct list_head slist; /* list of supplied regulators */
> -
> - /* lists we own */
> - struct list_head consumer_list; /* consumers we supply */
> - struct list_head supply_list; /* regulators we supply */
> -
> - struct blocking_notifier_head notifier;
> - struct mutex mutex; /* consumer lock */
> - struct module *owner;
> - struct device dev;
> - struct regulation_constraints *constraints;
> - struct regulator_dev *supply; /* for tree */
> -
> - void *reg_data; /* regulator_dev data */
> -};
> -
> -/*
> * struct regulator_map
> *
> * Used to provide symbolic supply names to devices.
> diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
> index 2254ad9..c263e36 100644
> --- a/include/linux/regulator/driver.h
> +++ b/include/linux/regulator/driver.h
> @@ -137,6 +137,38 @@ struct regulator_desc {
> struct module *owner;
> };
>
> +/*
> + * struct regulator_dev
> + *
> + * Voltage / Current regulator class device. One for each
> + * regulator.
> + *
> + * This should *not* be used directly by anything except the regulator
> + * core and notification injection (which should take the mutex and do
> + * no other direct access).
> + */
> +struct regulator_dev {
> + struct regulator_desc *desc;
> + int use_count;
> +
> + /* lists we belong to */
> + struct list_head list; /* list of all regulators */
> + struct list_head slist; /* list of supplied regulators */
> +
> + /* lists we own */
> + struct list_head consumer_list; /* consumers we supply */
> + struct list_head supply_list; /* regulators we supply */
> +
> + struct blocking_notifier_head notifier;
> + struct mutex mutex; /* consumer lock */
> + struct module *owner;
> + struct device dev;
> + struct regulation_constraints *constraints;
> + struct regulator_dev *supply; /* for tree */
> +
> + void *reg_data; /* regulator_dev data */
> +};
> +
> struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> struct device *dev, struct regulator_init_data *init_data,
> void *driver_data);
^ permalink raw reply
* [PATCH] regulator: Hoist struct regulator_dev out of core to fix notifiers
From: Mark Brown @ 2009-01-21 14:08 UTC (permalink / raw)
To: Liam Girdwood; +Cc: linux-next, linux-kernel, Jonathan Cameron, Mark Brown
Commit 872ed3fe176833f7d43748eb88010da4bbd2f983 caused regulator drivers
to take the struct regulator_dev lock themselves which requires that the
struct be visible to them. Band aid this by making the struct visible.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/regulator/core.c | 27 ---------------------------
include/linux/regulator/driver.h | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f17362a..0ed13c2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -30,33 +30,6 @@ static LIST_HEAD(regulator_list);
static LIST_HEAD(regulator_map_list);
/*
- * struct regulator_dev
- *
- * Voltage / Current regulator class device. One for each regulator.
- */
-struct regulator_dev {
- struct regulator_desc *desc;
- int use_count;
-
- /* lists we belong to */
- struct list_head list; /* list of all regulators */
- struct list_head slist; /* list of supplied regulators */
-
- /* lists we own */
- struct list_head consumer_list; /* consumers we supply */
- struct list_head supply_list; /* regulators we supply */
-
- struct blocking_notifier_head notifier;
- struct mutex mutex; /* consumer lock */
- struct module *owner;
- struct device dev;
- struct regulation_constraints *constraints;
- struct regulator_dev *supply; /* for tree */
-
- void *reg_data; /* regulator_dev data */
-};
-
-/*
* struct regulator_map
*
* Used to provide symbolic supply names to devices.
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 2254ad9..c263e36 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -137,6 +137,38 @@ struct regulator_desc {
struct module *owner;
};
+/*
+ * struct regulator_dev
+ *
+ * Voltage / Current regulator class device. One for each
+ * regulator.
+ *
+ * This should *not* be used directly by anything except the regulator
+ * core and notification injection (which should take the mutex and do
+ * no other direct access).
+ */
+struct regulator_dev {
+ struct regulator_desc *desc;
+ int use_count;
+
+ /* lists we belong to */
+ struct list_head list; /* list of all regulators */
+ struct list_head slist; /* list of supplied regulators */
+
+ /* lists we own */
+ struct list_head consumer_list; /* consumers we supply */
+ struct list_head supply_list; /* regulators we supply */
+
+ struct blocking_notifier_head notifier;
+ struct mutex mutex; /* consumer lock */
+ struct module *owner;
+ struct device dev;
+ struct regulation_constraints *constraints;
+ struct regulator_dev *supply; /* for tree */
+
+ void *reg_data; /* regulator_dev data */
+};
+
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
struct device *dev, struct regulator_init_data *init_data,
void *driver_data);
--
1.5.6.5
^ permalink raw reply related
* [PATCH] sysrq: include interrupt.h instead of irq.h
From: Heiko Carstens @ 2009-01-21 13:49 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, Mike Travis
Cc: linux-next, LKML, Martin Schwidefsky
In-Reply-To: <20090121150249.a87aca09.sfr@canb.auug.org.au>
From: Heiko Carstens <heiko.carstens@de.ibm.com>
With "cpumask: update irq_desc to use cpumask_var_t" in linux-next
we get this compile bug on s390:
CC drivers/char/sysrq.o
In file included from drivers/char/sysrq.c:38:
include/linux/irq.h: In function 'init_alloc_desc_masks':
include/linux/irq.h:442: error: dereferencing pointer to incomplete type
drivers/char/sysrq.c should include interrupt.h instead of irq.h.
Cc: Mike Travis <travis@sgi.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
drivers/char/sysrq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-next/drivers/char/sysrq.c
===================================================================
--- linux-next.orig/drivers/char/sysrq.c
+++ linux-next/drivers/char/sysrq.c
@@ -35,7 +35,7 @@
#include <linux/vt_kern.h>
#include <linux/workqueue.h>
#include <linux/kexec.h>
-#include <linux/irq.h>
+#include <linux/interrupt.h>
#include <linux/hrtimer.h>
#include <linux/oom.h>
^ permalink raw reply
* linux-next: Tree for January 21
From: Stephen Rothwell @ 2009-01-21 4:02 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 6715 bytes --]
Hi all,
Changes since 20090120:
Undropped trees:
crypto
cpufreq
Dropped trees (temporarily):
quota (build problem)
voltage (build problem)
cpu_alloc (build problem)
audit (difficult conflicts)
I merged the mfd tree immediately after Linus' tree instead of applying
the build fix patch it has.
The voltage tree gained a build failure and was dropped.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 132 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging mfd/for-next
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
CONFLICT (delete/modify): arch/m68knommu/include/asm/Kbuild deleted in m68knommu/for-next and modified in HEAD. Version HEAD of arch/m68knommu/include/asm/Kbuild left in tree.
$ git rm -f arch/m68knommu/include/asm/Kbuild
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
$ git reset --hard HEAD^
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in mm/slob.c
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in kernel/fork.c
Merging generic-ipi/auto-generic-ipi-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
$ git reset --hard HEAD^
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging squashfs/master
Merging omap/for-next
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: voltage tree build failure
From: Stephen Rothwell @ 2009-01-21 2:46 UTC (permalink / raw)
To: Liam Girdwood; +Cc: linux-next, Jonathan Cameron
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hi Liam,
Today's linux-next build (x86_64 allmodconfig) failed like this:
drivers/regulator/wm8350-regulator.c: In function 'pmic_uv_handler':
drivers/regulator/wm8350-regulator.c:1296: error: dereferencing pointer to incomplete type
drivers/regulator/wm8350-regulator.c:1305: error: dereferencing pointer to incomplete type
Immediate cause is commit 872ed3fe176833f7d43748eb88010da4bbd2f983
("Regulator: Push lock out of _notifier_call_chain + add voltage change
event").
I have dropped the voltage tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the m68knommu tree with Linus' treee
From: Greg Ungerer @ 2009-01-21 0:59 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, linux-next, Harvey Harrison
In-Reply-To: <20090120070609.GA16511@uranus.ravnborg.org>
Hi Sam,
Sam Ravnborg wrote:
> On Tue, Jan 20, 2009 at 10:24:08AM +1000, Greg Ungerer wrote:
>> Hi Stephen,
>>
>> Stephen Rothwell wrote:
>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>> arch/m68knommu/include/asm/Kbuild between commit
>>> 74d96f018673759d04d032c137d132f6447bfb1e ("byteorder: make swab.h include
>>> asm/swab.h like a regular header") from Linus' tree and commit
>>> 49148020bcb6910ce71417bd990a5ce7017f9bd3 ("m68k,m68knommu: merge header
>>> files") from the m68knommu tree.
>>>
>>> The latter removed the file and the former removed a line from it. So I
>>> just removed the file. I can keep doing that or you could do a merge
>>> with Linus' tree.
>> The current thinking was to merge this with Linus' tree as quick
>> as possible. But at the very least that will have to wait till he
>> gets back from LCA.
>
> Just try to push it to Linus. He may very well take it depite
> having fun at LCA.
> It is:
> - only touching m68k and m68knommu
> - he is usual quick to take the header move patches
> - it removes more lines than it add (IIRC)
Pull request sent. Lets see what happens.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear, a McAfee Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: linux-next: manual merge of the cpufreq tree with the cpus4096 tree
From: Ingo Molnar @ 2009-01-20 8:21 UTC (permalink / raw)
To: Dave Jones; +Cc: Stephen Rothwell, linux-next, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20090120052554.GA31797@redhat.com>
* Dave Jones <davej@redhat.com> wrote:
> On Tue, Jan 20, 2009 at 01:47:13PM +1100, Stephen Rothwell wrote:
> > Hi Dave,
> >
> > Today's linux-next merge of the cpufreq tree got a conflict in
> > arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c between commit
> > 5cd7376200be7b8bab085557ff5876b04bd84191 ("fix: crash: IP:
> > __bitmap_intersects+0x48/0x73") from the cpus4096 tree and commit
> > 6fc619dc092a0a159cf5fb46afa52f2f8128b1d4 ("[CPUFREQ] checkpatch cleanups
> > for acpi-cpufreq") from the cpufreq tree.
> >
> > Just changing context. I fixed it up (see below) and can carry the fix
> > as necessary.
>
> Yep, looks sane.
> I can't wait for this cpumask stuff to be over with, it's been a
> pain in the ass for merge collisions.
yeah, same here ... To resolve the conflicts you could merge the current
x86 fixes tree:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus
that's all the pending stuff we have.
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the m68knommu tree with Linus' treee
From: Sam Ravnborg @ 2009-01-20 7:06 UTC (permalink / raw)
To: Greg Ungerer; +Cc: Stephen Rothwell, linux-next, Harvey Harrison
In-Reply-To: <497519A8.3020706@snapgear.com>
On Tue, Jan 20, 2009 at 10:24:08AM +1000, Greg Ungerer wrote:
> Hi Stephen,
>
> Stephen Rothwell wrote:
> >Today's linux-next merge of the m68knommu tree got a conflict in
> >arch/m68knommu/include/asm/Kbuild between commit
> >74d96f018673759d04d032c137d132f6447bfb1e ("byteorder: make swab.h include
> >asm/swab.h like a regular header") from Linus' tree and commit
> >49148020bcb6910ce71417bd990a5ce7017f9bd3 ("m68k,m68knommu: merge header
> >files") from the m68knommu tree.
> >
> >The latter removed the file and the former removed a line from it. So I
> >just removed the file. I can keep doing that or you could do a merge
> >with Linus' tree.
>
> The current thinking was to merge this with Linus' tree as quick
> as possible. But at the very least that will have to wait till he
> gets back from LCA.
Just try to push it to Linus. He may very well take it depite
having fun at LCA.
It is:
- only touching m68k and m68knommu
- he is usual quick to take the header move patches
- it removes more lines than it add (IIRC)
Sam
^ permalink raw reply
* linux-next: Tree for January 20
From: Stephen Rothwell @ 2009-01-20 6:30 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7252 bytes --]
Hi all,
Our build server is back.
Changes since 20090119:
Undropped trees:
stackprotector
hid
Dropped trees (temporarily):
quota (build problem)
crypto (build problem)
cpufreq (build problem)
cpu_alloc (build problem)
audit (difficult conflicts)
I merged the mfd tree immediately after Linus' tree instead of applying
the build fix patch it has.
The m68knommu tree gained a conflict against Linus' tree.
The stackprotector tree lost its conflicts.
The hid tree lost its build problem.
The crypto tree gained a build failure and was dropped.
The cpufreq tree gained a conflict against the cpus4096 tree and a build
failure and was dropped.
The slab tree gained a conflict against the ftrace tree.
The proc tree gained a conflict against the security-testing tree.
The kmemleak tree gained a conflict against the ftrace and slab trees.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig,
ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES) and
i386, sparc and sparc64 defconfig.
Below is a summary of the state of the merge.
We are up to 132 trees (counting Linus' and 18 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging mfd/for-next
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging dwmw2/master
Merging arm/devel
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
CONFLICT (delete/modify): arch/m68knommu/include/asm/Kbuild deleted in m68knommu/for-next and modified in HEAD. Version HEAD of arch/m68knommu/include/asm/Kbuild left in tree.
$ git rm -f arch/m68knommu/include/asm/Kbuild
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging pci/linux-next
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
$ git reset --hard HEAD^
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging mtd/master
Merging wireless/master
Merging crypto/master
$ git reset --hard HEAD^
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
$ git reset --hard HEAD^
Merging v9fs/for-next
Merging quilt/rr
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in mm/slob.c
Merging uclinux/for-next
Merging md/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in kernel/fork.c
Merging generic-ipi/auto-generic-ipi-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
Merging agp/agp-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
CONFLICT (content): Merge conflict in drivers/pci/intel-iommu.c
CONFLICT (content): Merge conflict in include/linux/dma_remapping.h
Merging cputime/cputime
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging squashfs/master
Merging omap/for-next
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: cpufreq tree build failure
From: Stephen Rothwell @ 2009-01-20 6:23 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-next
In-Reply-To: <20090120053022.GB31797@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Hi Dave,
On Tue, 20 Jan 2009 00:30:22 -0500 Dave Jones <davej@redhat.com> wrote:
>
> I regenerated the tree with the missing line.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the slab tree with the ftrace tree
From: Matt Mackall @ 2009-01-20 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Pekka Enberg, Christoph Lameter, linux-next,
"Américo Wang", Eduard - Gabriel Munteanu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20090120145759.e707b9de.sfr@canb.auug.org.au>
On Tue, 2009-01-20 at 14:57 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the slab tree got a conflict in mm/slob.c
> between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> hooks") from the ftrace tree and commit
> 6e9ed0cc4b963fde66ab47d9fb19147631e44555 ("slob: clean up the code") from
> the slab tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good, thanks Stephen.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* linux-next: manual merge of the kmemleak tree with the ftrace and slab trees
From: Stephen Rothwell @ 2009-01-20 5:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-next, "Américo Wang", Matt Mackall,
Pekka Enberg, Christoph Lameter, Eduard - Gabriel Munteanu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Hi Catalin,
Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
between commits 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
hooks") from the ftrace tree and 6e9ed0cc4b963fde66ab47d9fb19147631e44555
("slob: clean up the code") from the slab tree and commit
1d5ae58738519c5228a022f22d560f27f99b8d4b ("kmemleak: Add the slob memory
allocation/freeing hooks") from the kmemleak tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc mm/slob.c
index f6b0d07,30b870f..0000000
--- a/mm/slob.c
+++ b/mm/slob.c
@@@ -499,12 -482,9 +500,13 @@@ void *__kmalloc_node(size_t size, gfp_
page = virt_to_page(ret);
page->private = size;
}
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, PAGE_SIZE << order, gfp, node);
}
+ kmemleak_alloc(ret, size, 1, gfp);
return ret;
}
EXPORT_SYMBOL(__kmalloc_node);
@@@ -515,9 -495,10 +517,10 @@@ void kfree(const void *block
if (unlikely(ZERO_OR_NULL_PTR(block)))
return;
+ kmemleak_free(block);
- sp = (struct slob_page *)virt_to_page(block);
- if (slob_page(sp)) {
+ sp = slob_page(block);
+ if (is_slob_page(sp)) {
int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
unsigned int *m = (unsigned int *)(block - align);
slob_free(m, *m + align);
^ permalink raw reply
* Re: linux-next: crypto tree build failure
From: Stephen Rothwell @ 2009-01-20 5:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-next, Huang Ying
In-Reply-To: <20090120052141.GA19696@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Hi Herbert,
On Tue, 20 Jan 2009 16:21:41 +1100 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Sorry for the screw up. It shold be fixed now.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: cpufreq tree build failure
From: Dave Jones @ 2009-01-20 5:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20090120135059.6841cdc8.sfr@canb.auug.org.au>
On Tue, Jan 20, 2009 at 01:50:59PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernow_k8_cpu_init_acpi':
> arch/x86/kernel/cpu/cpufreq/powernow-k8.c:836: error: 'space_id' undeclared (first use in this function)
>
> Immediate cause is commit 77a33c31a78c6cd11395c8b554152be684110e94
> ("[CPUFREQ] checkpatch cleanups for powernow-k8") which clearly wasn't
> build tested.
wtf, I dropped a hunk somehow.
> I have dropped the cpufreq tree for today.
I regenerated the tree with the missing line.
Thanks for catching this.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: linux-next: manual merge of the cpufreq tree with the cpus4096 tree
From: Dave Jones @ 2009-01-20 5:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Ingo Molnar, Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20090120134713.1fd5fd3a.sfr@canb.auug.org.au>
On Tue, Jan 20, 2009 at 01:47:13PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the cpufreq tree got a conflict in
> arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c between commit
> 5cd7376200be7b8bab085557ff5876b04bd84191 ("fix: crash: IP:
> __bitmap_intersects+0x48/0x73") from the cpus4096 tree and commit
> 6fc619dc092a0a159cf5fb46afa52f2f8128b1d4 ("[CPUFREQ] checkpatch cleanups
> for acpi-cpufreq") from the cpufreq tree.
>
> Just changing context. I fixed it up (see below) and can carry the fix
> as necessary.
Yep, looks sane.
I can't wait for this cpumask stuff to be over with, it's been a
pain in the ass for merge collisions.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: linux-next: crypto tree build failure
From: Herbert Xu @ 2009-01-20 5:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Huang Ying
In-Reply-To: <20090120133043.29efee3f.sfr@canb.auug.org.au>
On Tue, Jan 20, 2009 at 01:30:43PM +1100, Stephen Rothwell wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> arch/x86/crypto/aesni-intel_glue.c:22:21: error: asm/aes.h: No such file or directory
> arch/x86/crypto/aesni-intel_glue.c: In function 'aes_encrypt':
> arch/x86/crypto/aesni-intel_glue.c:98: error: implicit declaration of function 'crypto_aes_encrypt_x86'
> arch/x86/crypto/aesni-intel_glue.c: In function 'aes_decrypt':
> arch/x86/crypto/aesni-intel_glue.c:111: error: implicit declaration of function 'crypto_aes_decrypt_x86'
>
> Immediate cause is commit 9afc33f2f32204a779ef6c96728a034bcf4df29f
> ("crypto: aes-ni - Add support to Intel AES-NI instructions for x86_64
> platform").
>
> I have dropped the crypto tree for today.
Sorry for the screw up. It shold be fixed now.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* linux-next: manual merge of the proc tree with the security-testing tree
From: Stephen Rothwell @ 2009-01-20 5:05 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-next, Eric W. Biederman, David P. Quigley, James Morris
Hi Alexey,
Today's linux-next merge of the proc tree got a conflict in
security/selinux/hooks.c between commit
0d90a7ec48c704025307b129413bc62451b20ab3 ("SELinux: Condense super block
security structure flags and cleanup necessary code") from the
security-testing tree and commit c0f23e402155f510dd27d05b4f8d3c0a967dbf69
("proc 3/6: make /proc/net it's own filesystem") from the proc tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
P.S. James, your email address in the SOB line and committer info of that
securty-testing commit is not very useful ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc security/selinux/hooks.c
index 3bb4942,38c88e1..0000000
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@@ -714,11 -698,12 +714,12 @@@ static int selinux_set_mnt_opts(struct
goto out;
}
- if (strcmp(sb->s_type->name, "proc") == 0)
+ /* "proc", "proc/net" */
+ if (strncmp(sb->s_type->name, "proc", 4) == 0)
- sbsec->proc = 1;
+ sbsec->flags |= SE_SBPROC;
/* Determine the labeling behavior to use for this filesystem type. */
- rc = security_fs_use(sbsec->proc ? "proc" : sb->s_type->name, &sbsec->behavior, &sbsec->sid);
+ rc = security_fs_use((sbsec->flags & SE_SBPROC) ? "proc" : sb->s_type->name, &sbsec->behavior, &sbsec->sid);
if (rc) {
printk(KERN_WARNING "%s: security_fs_use(%s) returned %d\n",
__func__, sb->s_type->name, rc);
^ permalink raw reply
* Re: linux-next: crypto tree build failure
From: Herbert Xu @ 2009-01-20 4:57 UTC (permalink / raw)
To: Huang Ying; +Cc: linux-next@vger.kernel.org, Stephen Rothwell
In-Reply-To: <1232420667.13948.62.camel@yhuang-dev.sh.intel.com>
On Tue, Jan 20, 2009 at 11:04:27AM +0800, Huang Ying wrote:
>
> I don't know why. But it seems that asm/aes.h is not included in git,
> while it is in my original patch. I will submit a fix patch.
Don't worry. I'll fix it up in my tree.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* linux-next: manual merge of the slab tree with the ftrace tree
From: Stephen Rothwell @ 2009-01-20 3:57 UTC (permalink / raw)
To: Pekka Enberg, Christoph Lameter
Cc: linux-next, "Américo Wang", Matt Mackall,
Eduard - Gabriel Munteanu, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin
Hi all,
Today's linux-next merge of the slab tree got a conflict in mm/slob.c
between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
hooks") from the ftrace tree and commit
6e9ed0cc4b963fde66ab47d9fb19147631e44555 ("slob: clean up the code") from
the slab tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc mm/slob.c
index 4d1c0fc,c9cd31d..0000000
--- a/mm/slob.c
+++ b/mm/slob.c
@@@ -475,15 -482,11 +485,15 @@@ void *__kmalloc_node(size_t size, gfp_
if (!m)
return NULL;
*m = size;
- return (void *)m + align;
+ ret = (void *)m + align;
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, size + align, gfp, node);
} else {
- void *ret;
+ unsigned int order = get_order(size);
- ret = slob_new_page(gfp | __GFP_COMP, order, node);
- ret = slob_new_pages(gfp | __GFP_COMP, get_order(size), node);
++ ret = slob_new_pages(gfp | __GFP_COMP, order, node);
if (ret) {
struct page *page;
page = virt_to_page(ret);
@@@ -583,19 -579,10 +593,19 @@@ void *kmem_cache_alloc_node(struct kmem
{
void *b;
- if (c->size < PAGE_SIZE)
+ if (c->size < PAGE_SIZE) {
b = slob_alloc(c->size, flags, c->align, node);
- else
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_CACHE,
+ _RET_IP_, b, c->size,
+ SLOB_UNITS(c->size) * SLOB_UNIT,
+ flags, node);
+ } else {
- b = slob_new_page(flags, get_order(c->size), node);
+ b = slob_new_pages(flags, get_order(c->size), node);
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_CACHE,
+ _RET_IP_, b, c->size,
+ PAGE_SIZE << get_order(c->size),
+ flags, node);
+ }
if (c->ctor)
c->ctor(b);
^ permalink raw reply
* Re: linux-next: crypto tree build failure
From: Huang Ying @ 2009-01-20 3:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-next@vger.kernel.org, Stephen Rothwell
In-Reply-To: <20090120133043.29efee3f.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hi, Herbert,
On Tue, 2009-01-20 at 10:30 +0800, Stephen Rothwell wrote:
> Hi Herbert,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> arch/x86/crypto/aesni-intel_glue.c:22:21: error: asm/aes.h: No such file or directory
I don't know why. But it seems that asm/aes.h is not included in git,
while it is in my original patch. I will submit a fix patch.
Best Regards,
Huang Ying
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: cpufreq tree build failure
From: Stephen Rothwell @ 2009-01-20 2:50 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) failed like this:
arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernow_k8_cpu_init_acpi':
arch/x86/kernel/cpu/cpufreq/powernow-k8.c:836: error: 'space_id' undeclared (first use in this function)
Immediate cause is commit 77a33c31a78c6cd11395c8b554152be684110e94
("[CPUFREQ] checkpatch cleanups for powernow-k8") which clearly wasn't
build tested.
I have dropped the cpufreq tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the cpufreq tree with the cpus4096 tree
From: Stephen Rothwell @ 2009-01-20 2:47 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-next, Ingo Molnar, Thomas Gleixner, H. Peter Anvin
Hi Dave,
Today's linux-next merge of the cpufreq tree got a conflict in
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c between commit
5cd7376200be7b8bab085557ff5876b04bd84191 ("fix: crash: IP:
__bitmap_intersects+0x48/0x73") from the cpus4096 tree and commit
6fc619dc092a0a159cf5fb46afa52f2f8128b1d4 ("[CPUFREQ] checkpatch cleanups
for acpi-cpufreq") from the cpufreq tree.
Just changing context. I fixed it up (see below) and can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index 0192767,cba5c6b..0000000
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@@ -138,15 -140,13 +140,13 @@@ struct io_addr
u8 bit_width;
};
- typedef union {
- struct msr_addr msr;
- struct io_addr io;
- } drv_addr_union;
-
struct drv_cmd {
unsigned int type;
- cpumask_var_t mask;
+ const struct cpumask *mask;
- drv_addr_union addr;
+ union {
+ struct msr_addr msr;
+ struct io_addr io;
+ } addr;
u32 val;
};
^ permalink raw reply
* linux-next: crypto tree build failure
From: Stephen Rothwell @ 2009-01-20 2:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-next, Huang Ying
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
Hi Herbert,
Today's linux-next build (x86_64 allmodconfig) failed like this:
arch/x86/crypto/aesni-intel_glue.c:22:21: error: asm/aes.h: No such file or directory
arch/x86/crypto/aesni-intel_glue.c: In function 'aes_encrypt':
arch/x86/crypto/aesni-intel_glue.c:98: error: implicit declaration of function 'crypto_aes_encrypt_x86'
arch/x86/crypto/aesni-intel_glue.c: In function 'aes_decrypt':
arch/x86/crypto/aesni-intel_glue.c:111: error: implicit declaration of function 'crypto_aes_decrypt_x86'
Immediate cause is commit 9afc33f2f32204a779ef6c96728a034bcf4df29f
("crypto: aes-ni - Add support to Intel AES-NI instructions for x86_64
platform").
I have dropped the crypto tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: 2.6.30 material is OK now?
From: Stephen Rothwell @ 2009-01-20 1:01 UTC (permalink / raw)
To: David Miller; +Cc: linux-next
In-Reply-To: <20090119.152809.148322012.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
Hi Dave,
On Mon, 19 Jan 2009 15:28:09 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Stephen is it OK for 2.6.30 bound material to start
> showing up in -next?
Yep, see my other email. Thanks for asking, though.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox