Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: manual merge of the block tree with Linus' tree
From: Stephen Rothwell @ 2011-11-01  9:03 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig, NeilBrown
In-Reply-To: <4EAFA949.5060200@kernel.dk>

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Hi Jens,

On Tue, 01 Nov 2011 09:09:45 +0100 Jens Axboe <axboe@kernel.dk> wrote:
>
> Fixup looks good, however don't you get the same conflict in basically
> all the raid personalities? Fixup is indeed just the simple int -> void
> transition, conflict is because of the mddev_t -> struct mddev change
> that is now in Linus' tree.

I got these conflicts in all the raid personalities a while ago.  I am
not sure why this turned up for just raid10 again.

> I'll push my pending off to Linus today or tomorrow, so this will be
> resolved shortly.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: build failure after merge of the akpm tree
From: Stephen Rothwell @ 2011-11-01  8:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Jonathan Cameron, James Bottomley

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

next/drivers/scsi/sd.c: In function 'sd_probe':
next/drivers/scsi/sd.c:2583:43: error: 'SD_MAX_DISKS' undeclared (first use in this function)

Caused by commit ddabd33db5a2 ("drivers/scsi/sd.c: use ida_simple_get()
and ida_simple_remove() in place of boilerplate code") (which was fixed
up by me). I am not sure how to fix this properly (SD_MAX_DISKS was
removed by other commits), so I have just reverted that patch for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the akpm tree with Linus' tree
From: Stephen Rothwell @ 2011-11-01  8:16 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Tao Ma

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
fs/direct-io.c between commit eb28be2b4c0a ("direct-io: separate fields
only used in the submission path from struct dio") from Linus' tree and
commit "fs/direct-io.c: salcuate fs_count correctly in get_more_blocks()"
from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/direct-io.c
index d740ab6,b05f24e..0000000
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@@ -575,14 -564,13 +575,13 @@@ static inline int dio_bio_reap(struct d
   * buffer_mapped().  However the direct-io code will only process holes one
   * block at a time - it will repeatedly call get_block() as it walks the hole.
   */
 -static int get_more_blocks(struct dio *dio)
 +static int get_more_blocks(struct dio *dio, struct dio_submit *sdio,
 +			   struct buffer_head *map_bh)
  {
  	int ret;
 -	struct buffer_head *map_bh = &dio->map_bh;
  	sector_t fs_startblk;	/* Into file, in filesystem-sized blocks */
+ 	sector_t fs_endblk;	/* Into file, in filesystem-sized blocks */
  	unsigned long fs_count;	/* Number of filesystem-sized blocks */
- 	unsigned long dio_count;/* Number of dio_block-sized blocks */
- 	unsigned long blkmask;
  	int create;
  
  	/*
@@@ -591,13 -579,10 +590,10 @@@
  	 */
  	ret = dio->page_errors;
  	if (ret == 0) {
 -		BUG_ON(dio->block_in_file >= dio->final_block_in_request);
 -		fs_startblk = dio->block_in_file >> dio->blkfactor;
 -		fs_endblk = (dio->final_block_in_request - 1) >> dio->blkfactor;
 +		BUG_ON(sdio->block_in_file >= sdio->final_block_in_request);
 +		fs_startblk = sdio->block_in_file >> sdio->blkfactor;
- 		dio_count = sdio->final_block_in_request - sdio->block_in_file;
- 		fs_count = dio_count >> sdio->blkfactor;
- 		blkmask = (1 << sdio->blkfactor) - 1;
- 		if (dio_count & blkmask)	
- 			fs_count++;
++		fs_endblk = (sdio->final_block_in_request - 1) >> sdio->blkfactor;
+ 		fs_count = fs_endblk - fs_startblk + 1;
  
  		map_bh->b_state = 0;
  		map_bh->b_size = fs_count << dio->inode->i_blkbits;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the block tree with Linus' tree
From: Jens Axboe @ 2011-11-01  8:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig, NeilBrown
In-Reply-To: <20111101161500.79aebe8d8f30162ea542a818@canb.auug.org.au>

On 2011-11-01 06:15, Stephen Rothwell wrote:
> Hi Jens,
> 
> Today's linux-next merge of the block tree got a conflict in
> drivers/md/raid10.c between commit fd01b88c75a7 ("md: remove typedefs:
> mddev_t -> struct mddev") from Linus' tree and commit 5a7bbad27a41
> ("block: remove support for bio remapping from ->make_request") from the
> block tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Fixup looks good, however don't you get the same conflict in basically
all the raid personalities? Fixup is indeed just the simple int -> void
transition, conflict is because of the mddev_t -> struct mddev change
that is now in Linus' tree.

I'll push my pending off to Linus today or tomorrow, so this will be
resolved shortly.

-- 
Jens Axboe

^ permalink raw reply

* linux-next: manual merge of the akpm with the scsi tree
From: Stephen Rothwell @ 2011-11-01  7:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Jonathan Cameron, Dave Kleikamp,
	James Bottomley

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/scsi/sd.c between commit 21208ae5a21f ("[SCSI] sd: remove
arbitrary SD_MAX_DISKS namespace limit") from the scsi tree and
"drivers/scsi/sd.c: use ida_simple_get() and ida_simple_remove() in place
of boilerplate code" from the akpm.

I think that the latter supercedes that former, so I used it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: build failure after merge of the moduleh tree
From: Stephen Rothwell @ 2011-11-01  7:38 UTC (permalink / raw)
  To: Paul Gortmaker
  Cc: linux-next, linux-kernel, Mikulas Patocka, Alasdair G Kergon

[-- Attachment #1: Type: text/plain, Size: 8285 bytes --]

Hi Paul,

After merging the moduleh tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/md/dm-bufio.c:988:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:988:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:988:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:997:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:997:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:997:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1006:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1006:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1006:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1036:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1036:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1036:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1049:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1049:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1049:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1059:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1059:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1059:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1135:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1135:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1135:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1158:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1158:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1158:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1232:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1232:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1232:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1238:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1238:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1238:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1245:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1245:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1245:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1251:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1251:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1251:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1257:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1257:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1257:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1263:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1263:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1263:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1269:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1269:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1269:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1489:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1489:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1489:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1534:1: warning: data definition has no type or storage class [enabled by default]
drivers/md/dm-bufio.c:1534:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
drivers/md/dm-bufio.c:1534:1: warning: parameter names (without types) in function declaration [enabled by default]
drivers/md/dm-bufio.c:1676:63: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1677:40: error: expected ')' before string constant
drivers/md/dm-bufio.c:1679:55: error: expected ')' before 'uint'
drivers/md/dm-bufio.c:1680:35: error: expected ')' before string constant
drivers/md/dm-bufio.c:1682:67: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1683:40: error: expected ')' before string constant
drivers/md/dm-bufio.c:1685:79: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1686:46: error: expected ')' before string constant
drivers/md/dm-bufio.c:1688:87: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1689:50: error: expected ')' before string constant
drivers/md/dm-bufio.c:1691:73: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1692:43: error: expected ')' before string constant
drivers/md/dm-bufio.c:1694:73: error: expected ')' before 'ulong'
drivers/md/dm-bufio.c:1695:43: error: expected ')' before string constant
drivers/md/dm-bufio.c:1697:15: error: expected declaration specifiers or '...' before string constant
drivers/md/dm-bufio.c:1698:20: error: expected declaration specifiers or '...' before string constant
drivers/md/dm-bufio.c:1699:16: error: expected declaration specifiers or '...' before string constant

Caused by commit 0b068238c5ef ("The dm-bufio interface allows you to do
cached I/O on devices") interacting with the modul.h split up.  This file
should have included module.h in any case.

I have added this merg fix patch (Alasdair, this could be added to the
device-mapper tree):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 1 Nov 2011 18:30:49 +1100
Subject: [PATCH] device-mapper: dm-bufio.c needs to include module.h

since it uses the module facilities.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/md/dm-bufio.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index cb24666..3a94ef4 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -14,6 +14,7 @@
 #include <linux/vmalloc.h>
 #include <linux/version.h>
 #include <linux/shrinker.h>
+#include <linux/module.h>
 
 #define DM_MSG_PREFIX "bufio"
 
-- 
1.7.7

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related

* Re: linux-next: manual merge of the hwspinlock tree with the arm-soc tree
From: Ohad Ben-Cohen @ 2011-11-01  7:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Kevin Hilman, Benoit Cousson,
	Arnd Bergmann
In-Reply-To: <20111101175602.a1cc534d3819edcb8cd2cc77@canb.auug.org.au>

Hi Stephen,

On Tue, Nov 1, 2011 at 8:56 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I fixed it up (see below) anc can carry the fix as necessary.

Looks good, thanks a lot !

Ohad.

^ permalink raw reply

* linux-next: manual merge of the moduleh tree with the device-mapper tree
From: Stephen Rothwell @ 2011-11-01  7:22 UTC (permalink / raw)
  To: Paul Gortmaker
  Cc: linux-next, linux-kernel, Joe Thornber, Mike Snitzer,
	Alasdair G Kergon

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hi Paul,

Today's linux-next merge of the moduleh tree got a conflict in
drivers/md/persistent-data/dm-space-map-disk.c between commit
661ae8a9604f ("The persistent-data library offers a re-usable framework
for the storage") from the device-mapper tree and fix up patch
"drivers-md-change-module.h-export.h-in-persistent-da.patch" from the
moduleh tree.

I fixed it up (see below) (the include of bitops.h has been removed in
the device-mapper commit).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/persistent-data/dm-space-map-disk.c
index aeff785,e6b9d67..0000000
--- a/drivers/md/persistent-data/dm-space-map-disk.c
+++ b/drivers/md/persistent-data/dm-space-map-disk.c
@@@ -12,7 -11,8 +12,7 @@@
  
  #include <linux/list.h>
  #include <linux/slab.h>
- #include <linux/module.h>
 -#include <linux/bitops.h>
+ #include <linux/export.h>
  #include <linux/device-mapper.h>
  
  #define DM_MSG_PREFIX "space map disk"

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the moduleh tree with the mfd tree
From: Stephen Rothwell @ 2011-11-01  7:05 UTC (permalink / raw)
  To: Paul Gortmaker; +Cc: linux-next, linux-kernel, Linus Walleij, Samuel Ortiz

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Hi Paul,

Today's linux-next merge of the moduleh tree got a conflict in
drivers/mfd/ab3550-core.c between commit 6508204630f4 ("mfd: Delete
ab3550 driver") from the mfd tree and commit 4e36dd331423 ("mfd: Add
module.h to the implicit drivers/mfd users") from the moduleh tree.

The latter deleted the file, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the hwspinlock tree with the arm-soc tree
From: Stephen Rothwell @ 2011-11-01  6:56 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: linux-next, linux-kernel, Kevin Hilman, Benoit Cousson,
	Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hi Ohad,

Today's linux-next merge of the hwspinlock tree got a conflict in
arch/arm/mach-omap2/hwspinlock.c between commits 3528c58eb9e8 ("OMAP:
omap_device: when building return platform_device instead of
omap_device") and f718e2c034bf ("ARM: OMAP2+: devices: Remove all
omap_device_pm_latency structures") from the arm-soc tree and commit
c3c1250e93a7 ("hwspinlock/core/omap: fix id issues on multiple hwspinlock
devices") from the hwspinlock tree.

I fixed it up (see below) anc can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/hwspinlock.c
index 36e2109,eb7e509..0000000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@@ -23,6 -24,18 +24,10 @@@
  #include <plat/omap_hwmod.h>
  #include <plat/omap_device.h>
  
+ static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
+ 	.base_id = 0,
+ };
+ 
 -struct omap_device_pm_latency omap_spinlock_latency[] = {
 -	{
 -		.deactivate_func = omap_device_idle_hwmods,
 -		.activate_func   = omap_device_enable_hwmods,
 -		.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
 -	}
 -};
 -
  int __init hwspinlocks_init(void)
  {
  	int retval = 0;
@@@ -40,11 -53,14 +45,13 @@@
  	if (oh == NULL)
  		return -EINVAL;
  
- 	pdev = omap_device_build(dev_name, 0, oh, NULL, 0, NULL, 0, false);
 -	od = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
++	pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
+ 				sizeof(struct hwspinlock_pdata),
 -				omap_spinlock_latency,
 -				ARRAY_SIZE(omap_spinlock_latency), false);
 -	if (IS_ERR(od)) {
++				NULL, 0, false);
 +	if (IS_ERR(pdev)) {
  		pr_err("Can't build omap_device for %s:%s\n", dev_name,
  								oh_name);
 -		retval = PTR_ERR(od);
 +		retval = PTR_ERR(pdev);
  	}
  
  	return retval;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the crypto-current tree
From: Stephen Rothwell @ 2011-11-01  6:02 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-next, linux-kernel
In-Reply-To: <20111101051810.GA7519@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Hi Herbert,

On Tue, 1 Nov 2011 16:18:10 +1100 Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> So did the change to depends_on fix it?

I have not yet had time to test that ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: build failure after merge of the watchdog tree
From: Stephen Rothwell @ 2011-11-01  5:37 UTC (permalink / raw)
  To: Wim Van Sebroeck; +Cc: linux-next, linux-kernel, Mark Brown

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Hi Wim,

After merging the watchdog tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/watchdog/wm831x_wdt.c: In function 'wm831x_wdt_start':
drivers/watchdog/wm831x_wdt.c:56:40: error: 'struct watchdog_device' has no member named 'priv'
drivers/watchdog/wm831x_wdt.c: In function 'wm831x_wdt_stop':
drivers/watchdog/wm831x_wdt.c:79:40: error: 'struct watchdog_device' has no member named 'priv'
drivers/watchdog/wm831x_wdt.c: In function 'wm831x_wdt_ping':
drivers/watchdog/wm831x_wdt.c:102:40: error: 'struct watchdog_device' has no member named 'priv'
drivers/watchdog/wm831x_wdt.c: In function 'wm831x_wdt_set_timeout':
drivers/watchdog/wm831x_wdt.c:144:40: error: 'struct watchdog_device' has no member named 'priv'
drivers/watchdog/wm831x_wdt.c: In function 'wm831x_wdt_probe':
drivers/watchdog/wm831x_wdt.c:215:12: error: 'struct watchdog_device' has no member named 'parent'
drivers/watchdog/wm831x_wdt.c:216:12: error: 'struct watchdog_device' has no member named 'priv'

Caused by commit 5b04099edc42 ("watchdog: Convert wm831x driver to
watchdog core").

I have used the version of the watchdog tree from next-20111025 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: build failure after merge of the edac tree
From: Stephen Rothwell @ 2011-11-01  6:00 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: linux-next, linux-kernel, Borislav Petkov

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Hi Mauro,

After merging the edac tree, today's linux-next build (x86_64
allmodconfig) failed like this:

arch/x86/kernel/cpu/mcheck/mce.c:39:28: fatal error: linux/edac_mce.h: No such file or directory

Caused by commit cdaf4f4e563c ("i7core_edac: Drop the edac_mce
facility").  This commit removed the file include/linux/edac_mce.h which
is still metioned by the above file (and MAINTAINERS).  Grep is your
friend.

I have used the version of the edac tree from next-20111025 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the mfd tree with the arm-soc tree
From: Stephen Rothwell @ 2011-11-01  5:19 UTC (permalink / raw)
  To: Samuel Ortiz
  Cc: linux-next, linux-kernel, Kyle Manna, Tony Lindgren,
	Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Hi Samuel,

Today's linux-next merge of the mfd tree got a conflict in
arch/arm/mach-omap2/board-omap3beagle.c between commit be7324605873
("ARM: OMAP2+: Remove custom init_irq for remaining boards") from the
arm-soc tree and commit 935bac2b14b0 ("arm: BeagleBoard: add support for
the twl4030-madc") from the mfd tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/board-omap3beagle.c
index 70261bc,0d68c8d..0000000
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@@ -444,6 -445,23 +445,11 @@@ static struct platform_device keys_gpi
  	},
  };
  
 -static void __init omap3_beagle_init_early(void)
 -{
 -	omap2_init_common_infrastructure();
 -	omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
 -				  mt46h32m32lf6_sdrc_params);
 -}
 -
 -static void __init omap3_beagle_init_irq(void)
 -{
 -	omap3_init_irq();
 -}
 -
+ static struct platform_device madc_hwmon = {
+ 	.name	= "twl4030_madc_hwmon",
+ 	.id	= -1,
+ };
+ 
  static struct platform_device *omap3_beagle_devices[] __initdata = {
  	&leds_gpio,
  	&keys_gpio,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the crypto-current tree
From: Herbert Xu @ 2011-11-01  5:18 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20111101152312.5751b7ac8b4a998b6ef867be@canb.auug.org.au>

On Tue, Nov 01, 2011 at 03:23:12PM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> On Tue, 1 Nov 2011 11:58:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Presumbly caused by commit ea8bdfcff175 ("crypto: user - Add dependency
> > on NET").
> > 
> > I have used the crypto-current tree from next-20111025 for today (i.e. that
> > commit has not been added to linux-next today).
> 
> Same problem and solution in the crypto tree (obviously).

So did the change to depends_on fix it?

Thanks,
-- 
Email: Herbert Xu <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 block tree with Linus' tree
From: Stephen Rothwell @ 2011-11-01  5:15 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig, NeilBrown

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
drivers/md/raid10.c between commit fd01b88c75a7 ("md: remove typedefs:
mddev_t -> struct mddev") from Linus' tree and commit 5a7bbad27a41
("block: remove support for bio remapping from ->make_request") from the
block tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/md/raid10.c
index c025a82,ea5fc0b..0000000
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@@ -842,11 -830,11 +842,11 @@@ static void unfreeze_array(struct r10co
  	spin_unlock_irq(&conf->resync_lock);
  }
  
- static int make_request(struct mddev *mddev, struct bio * bio)
 -static void make_request(mddev_t *mddev, struct bio * bio)
++static void make_request(struct mddev *mddev, struct bio * bio)
  {
 -	conf_t *conf = mddev->private;
 -	mirror_info_t *mirror;
 -	r10bio_t *r10_bio;
 +	struct r10conf *conf = mddev->private;
 +	struct mirror_info *mirror;
 +	struct r10bio *r10_bio;
  	struct bio *read_bio;
  	int i;
  	int chunk_sects = conf->chunk_mask + 1;
@@@ -1176,12 -1156,11 +1174,11 @@@ retry_write
  
  	if (do_sync || !mddev->bitmap || !plugged)
  		md_wakeup_thread(mddev->thread);
- 	return 0;
  }
  
 -static void status(struct seq_file *seq, mddev_t *mddev)
 +static void status(struct seq_file *seq, struct mddev *mddev)
  {
 -	conf_t *conf = mddev->private;
 +	struct r10conf *conf = mddev->private;
  	int i;
  
  	if (conf->near_copies < conf->raid_disks)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the crypto-current tree
From: Stephen Rothwell @ 2011-11-01  4:23 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-next, linux-kernel
In-Reply-To: <20111101115851.2e37ac680db78bdba0661691@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hi Herbert,

On Tue, 1 Nov 2011 11:58:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Presumbly caused by commit ea8bdfcff175 ("crypto: user - Add dependency
> on NET").
> 
> I have used the crypto-current tree from next-20111025 for today (i.e. that
> commit has not been added to linux-next today).

Same problem and solution in the crypto tree (obviously).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the kbuild tree with the  tree
From: Stephen Rothwell @ 2011-11-01  3:43 UTC (permalink / raw)
  To: Michal Marek; +Cc: linux-next, linux-kernel, Paul Bolle, Jeff Kirsher

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hi Michal,

Today's linux-next merge of the kbuild tree got a conflict in
drivers/net/ethernet/stmicro/stmmac/Kconfig (drivers/net/stmmac/Kconfig
in the kbuild tree) between commit 7ac6653a085b ("stmmac: Move the
STMicroelectronics driver") from the  tree and commit 2d3def0b73e3
("stmmac: drop unused Kconfig symbol") from the kbuild tree.

I just used the latter version.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* linux-next: manual merge of the logfs tree with Linus' tree
From: Stephen Rothwell @ 2011-11-01  3:10 UTC (permalink / raw)
  To: Prasad Joshi, "Jörn Engel"
  Cc: linux-next, linux-kernel, Josef Bacik, Al Viro

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

Hi all,

Today's linux-next merge of the logfs tree got a conflict in
fs/logfs/file.c between commit 02c24a82187d ("fs: push i_mutex and
filemap_write_and_wait down into ->fsync() handlers") from Linus' tree
and commit 39da12ef4bbe ("logfs: take write mutex lock during fsync and
sync") from the logfs tree.

I have no idea what needs to be done here.  I fixed it like below to make
it build, but a better fix is needed.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/logfs/file.c
index b548c87,f85d603..0000000
--- a/fs/logfs/file.c
+++ b/fs/logfs/file.c
@@@ -219,20 -219,13 +219,22 @@@ long logfs_ioctl(struct file *file, uns
  	}
  }
  
 -int logfs_fsync(struct file *file, int datasync)
 +int logfs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
  {
  	struct super_block *sb = file->f_mapping->host->i_sb;
 +	struct inode *inode = file->f_mapping->host;
 +	int ret;
 +
 +	ret = filemap_write_and_wait_range(inode->i_mapping, start, end);
 +	if (ret)
 +		return ret;
  
 +	mutex_lock(&inode->i_mutex);
+ 	logfs_get_wblocks(sb, NULL, WF_LOCK);
  	logfs_write_anchor(sb);
+ 	logfs_put_wblocks(sb, NULL, WF_LOCK);
 +	mutex_unlock(&inode->i_mutex);
 +
  	return 0;
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the crypto-current tree
From: Herbert Xu @ 2011-11-01  1:11 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20111101115851.2e37ac680db78bdba0661691@canb.auug.org.au>

On Tue, Nov 01, 2011 at 11:58:51AM +1100, Stephen Rothwell wrote:
> Hi Herbert,
> 
> After merging the crypto-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
>   GEN     /scratch/sfr/x86_64_allmodconfig/Makefile
> scripts/kconfig/conf --allmodconfig Kconfig
> net/Kconfig:5:error: recursive dependency detected!
> net/Kconfig:5:	symbol NET is selected by CRYPTO_USER
> crypto/Kconfig:103:	symbol CRYPTO_USER depends on CRYPTO
> crypto/Kconfig:15:	symbol CRYPTO is selected by BT
> net/bluetooth/Kconfig:5:	symbol BT depends on NET
> warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
> warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)

Hmm, don't know why I didn't see that here.

Does making it a dependency cause this to go away?

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 259dea9..527a857 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -102,8 +102,8 @@ config CRYPTO_MANAGER2
 
 config CRYPTO_USER
 	tristate "Userspace cryptographic algorithm configuration"
+	depends on NET
 	select CRYPTO_MANAGER
-	select NET
 	help
 	  Userapace configuration for cryptographic instantiations such as
 	  cbc(aes).

Thanks,
-- 
Email: Herbert Xu <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 related

* linux-next: build failure after merge of the crypto-current tree
From: Stephen Rothwell @ 2011-11-01  0:58 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

Hi Herbert,

After merging the crypto-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

  GEN     /scratch/sfr/x86_64_allmodconfig/Makefile
scripts/kconfig/conf --allmodconfig Kconfig
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5:	symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103:	symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15:	symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5:	symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
#
# configuration written to .config
#
WITHOUT_DISTCC: 
ARCH=x86_64
CCVER=4.6
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5:	symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103:	symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15:	symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5:	symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
*
* Restart config...
*
*
* Security options
*
Enable access key retention support (KEYS) [Y/n/?] y
  TRUSTED KEYS (TRUSTED_KEYS) [M/n/?] m
  ENCRYPTED KEYS (ENCRYPTED_KEYS) [M/n/y/?] m
  Enable the /proc/keys file by which keys may be viewed (KEYS_DEBUG_PROC_KEYS) [Y/n/?] y
Restrict unprivileged access to the kernel syslog (SECURITY_DMESG_RESTRICT) [Y/n/?] y
Enable different security models (SECURITY) [N/y/?] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

Presumbly caused by commit ea8bdfcff175 ("crypto: user - Add dependency
on NET").

I have used the crypto-current tree from next-20111025 for today (i.e. that
commit has not been added to linux-next today).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: git tree URL for IEEE 1394 (FireWire) kernel subsystem
From: Stephen Rothwell @ 2011-10-31 23:19 UTC (permalink / raw)
  To: Stefan Richter; +Cc: linux-next, linux1394-devel, linux-kernel
In-Reply-To: <20111031185701.5c8771c6@stein>

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

Hi Stefan,

On Mon, 31 Oct 2011 18:57:01 +0100 Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> please switch the ieee1394/for-next URL once more, now to
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git for-next
> 
> which is meant to be permanent.  (-2.6 suffix of the former name
> dropped).  Current content is identical with my pull request to
> Linus today.

I have switched to that from today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: git tree URL for IEEE 1394 (FireWire) kernel subsystem
From: Stefan Richter @ 2011-10-31 17:57 UTC (permalink / raw)
  To: Stephen Rothwell, linux-next; +Cc: linux1394-devel, linux-kernel
In-Reply-To: <20110918215144.f33db78e54224626c6ee408e@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Stephen,

please switch the ieee1394/for-next URL once more, now to

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git for-next

which is meant to be permanent.  (-2.6 suffix of the former name
dropped).  Current content is identical with my pull request to
Linus today.

Thanks,
-- 
Stefan Richter
-=====-==-== =-=- =====
http://arcgraph.de/sr/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: linux-next: Tree for Oct 25 (mfd/ab8500)
From: Samuel Ortiz @ 2011-10-30 23:04 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, linux-next, LKML, Linus, Srinidhi Kasagar,
	Linus Walleij
In-Reply-To: <4EA850C1.4060405@xenotime.net>

Hi Randy,

On Wed, Oct 26, 2011 at 11:26:09AM -0700, Randy Dunlap wrote:
> On 10/25/11 02:36, Stephen Rothwell wrote:
> > Hi all,
> 
> 
> drivers/mfd/ab8500-core.c:881:7: error: 'AB8500_CUT3P3' undeclared
Thanks for the report. This is now fixed.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

^ permalink raw reply

* Re: linux-next: Tree for Oct 25 (crypto)
From: Valdis.Kletnieks @ 2011-10-29 23:20 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, Linus,
	linux-crypto
In-Reply-To: <20111027074544.GA19905@gondor.apana.org.au>

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Thu, 27 Oct 2011 09:45:44 +0200, Herbert Xu said:
> On Thu, Oct 27, 2011 at 03:05:16AM -0400, Valdis.Kletnieks@vt.edu wrote:

> > Are there any use cases where a config (probably embedded) would wantq
> > CRYPTO_USER but not CRYPTO_NET?  Would seem a shame to pull in the entire
> 
> Since the CRYPTO_USER interface sits on top of netlink I don't
> see how you could possibly avoid NET.

Oh, OK.  The original bug report looked like just some utility functions not
defined, so I didn't pick up on the "it needs netlink" aspect of it.

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox