* linux-next: tree build failure
@ 2009-10-01 3:19 Stephen Rothwell
2009-10-01 7:58 ` Jens Axboe
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2009-10-01 3:19 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Zdenek Kabelac, Li Zefan
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hi Jens,
Today's linux-next build (powerpc allnoconfig) failed like this:
include/linux/blktrace_api.h:215:40: error: macro parameters must be comma-separated
Caused by commit 1e03edf3b5b16f7f30fa1e397cc9a130305fa8d3 ("Add missing
blk_trace_remove_sysfs to be in pair with blk_trace_init_sysfs") from the
block tree. Half way between a static inline and a macro ...
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-10-01 3:19 linux-next: tree build failure Stephen Rothwell
@ 2009-10-01 7:58 ` Jens Axboe
2009-10-01 10:41 ` Stephen Rothwell
0 siblings, 1 reply; 30+ messages in thread
From: Jens Axboe @ 2009-10-01 7:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Zdenek Kabelac, Li Zefan
On Thu, Oct 01 2009, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next build (powerpc allnoconfig) failed like this:
>
> include/linux/blktrace_api.h:215:40: error: macro parameters must be comma-separated
>
> Caused by commit 1e03edf3b5b16f7f30fa1e397cc9a130305fa8d3 ("Add missing
> blk_trace_remove_sysfs to be in pair with blk_trace_init_sysfs") from the
> block tree. Half way between a static inline and a macro ...
Sorry Stephen, fixed up.
--
Jens Axboe
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-10-01 7:58 ` Jens Axboe
@ 2009-10-01 10:41 ` Stephen Rothwell
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2009-10-01 10:41 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Zdenek Kabelac, Li Zefan
[-- Attachment #1: Type: text/plain, Size: 240 bytes --]
Hi Jens,
On Thu, 1 Oct 2009 09:58:38 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> Sorry Stephen, fixed up.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* linux-next: tree build failure
@ 2009-12-16 7:21 Stephen Rothwell
2009-12-16 9:02 ` Felipe Balbi
2009-12-16 10:10 ` Liam Girdwood
0 siblings, 2 replies; 30+ messages in thread
From: Stephen Rothwell @ 2009-12-16 7:21 UTC (permalink / raw)
To: Liam Girdwood; +Cc: linux-next, linux-kernel, Balaji T K, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 8480 bytes --]
Hi Liam,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/regulator/twl-regulator.c: In function 'twlreg_disable':
drivers/regulator/twl-regulator.c:158: error: 'P1_GRP' undeclared (first use in this function)
drivers/regulator/twl-regulator.c:158: error: 'P2_GRP' undeclared (first use in this function)
drivers/regulator/twl-regulator.c:158: error: 'P3_GRP' undeclared (first use in this function)
drivers/regulator/twl-regulator.c: At top level:
drivers/regulator/twl-regulator.c:358: error: 'twlldo_list_voltage' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:450:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:450: error: 'TWL_ADJUSTABLE_LDO' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:451:40: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:452:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:453:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:454:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:455:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:456:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:457:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:458:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:459:34: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:460:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:461:40: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
drivers/regulator/twl-regulator.c:461: error: 'TWL_FIXED_LDO' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:462:39: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:463:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
drivers/regulator/twl-regulator.c:464:34: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:465:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:466:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
drivers/regulator/twl-regulator.c:467:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
drivers/regulator/twl-regulator.c:468:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
drivers/regulator/twl-regulator.c:469:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
drivers/regulator/twl-regulator.c:474: error: 'VAUX1_6030_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:474: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:474: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:475: error: 'VAUX2_6030_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:475: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:475: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:476: error: 'VAUX3_6030_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:476: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:476: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:477: error: 'VMMC_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:477: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:477: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:478: error: 'VPP_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:478: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:478: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:479: error: 'VUSIM_VSEL_table' undeclared here (not in a function)
drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:479: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
drivers/regulator/twl-regulator.c:479: error: negative width in bit-field '<anonymous>'
drivers/regulator/twl-regulator.c: In function 'twlreg_probe':
drivers/regulator/twl-regulator.c:544: error: implicit declaration of function 'twl4030reg_write'
I guess we knew this was coming :-(
Caused by a bad rebase of the voltage tree onto Linus' tree (in order to
do fixups for commit fc7b92fca4e546184557f1c53f84ad57c66b7695 "mfd:
Rename all twl4030_i2c*" and others).
I have reverted all the commits in the voltage tree that touched
drivers/regulator/twl-regulator.c for today:
6051d7a2786c57d0c5c4227dd9ddfc348a86ce91 "twl4030-regulator: Fixes VAUX1-3 exclusion introduced"
2677c78184a52edcc228c20a1c05c14925118293 "Reset REMAP configuration in regulator probe"
de449258306274739ed3a747f49b9ac8f91f9e4a "Define critical regulators as always_on"
66d65d352f6fd61dd5695925906b140f1e0ac9c3 "twl4030-regulator: Add all TWL regulators to twreg_info"
f33a0d47bd44dbf44a45c33b32e1e3bbbf8d06e6 "twl4030-regulator: Remove regulator from all groups when disabling"
Please fix up this tree properly. You may have been better off merging
Linus' tree into yours and fixing up the merge commit than trying to do
the rebase.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-12-16 7:21 Stephen Rothwell
@ 2009-12-16 9:02 ` Felipe Balbi
2009-12-16 10:10 ` Liam Girdwood
1 sibling, 0 replies; 30+ messages in thread
From: Felipe Balbi @ 2009-12-16 9:02 UTC (permalink / raw)
To: ext Stephen Rothwell
Cc: Liam Girdwood, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Balaji T K, Samuel Ortiz
Hi,
On Wed, Dec 16, 2009 at 08:21:32AM +0100, ext Stephen Rothwell wrote:
>Hi Liam,
>
>Today's linux-next build (powerpc allyesconfig) failed like this:
>
>drivers/regulator/twl-regulator.c: In function 'twlreg_disable':
>drivers/regulator/twl-regulator.c:158: error: 'P1_GRP' undeclared (first use in this function)
>drivers/regulator/twl-regulator.c:158: error: 'P2_GRP' undeclared (first use in this function)
>drivers/regulator/twl-regulator.c:158: error: 'P3_GRP' undeclared (first use in this function)
>drivers/regulator/twl-regulator.c: At top level:
>drivers/regulator/twl-regulator.c:358: error: 'twlldo_list_voltage' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:450:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:450: error: 'TWL_ADJUSTABLE_LDO' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:451:40: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:452:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:453:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:454:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:455:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:456:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:457:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:458:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:459:34: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:460:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:461:40: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
>drivers/regulator/twl-regulator.c:461: error: 'TWL_FIXED_LDO' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:462:39: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:463:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
>drivers/regulator/twl-regulator.c:464:34: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:465:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:466:35: error: macro "TWL_ADJUSTABLE_LDO" requires 4 arguments, but only 3 given
>drivers/regulator/twl-regulator.c:467:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
>drivers/regulator/twl-regulator.c:468:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
>drivers/regulator/twl-regulator.c:469:39: error: macro "TWL_FIXED_LDO" requires 5 arguments, but only 4 given
>drivers/regulator/twl-regulator.c:474: error: 'VAUX1_6030_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:474: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:474: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:474: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:475: error: 'VAUX2_6030_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:475: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:475: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:475: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:476: error: 'VAUX3_6030_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:476: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:476: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:476: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:477: error: 'VMMC_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:477: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:477: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:477: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:478: error: 'VPP_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:478: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:478: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:478: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:479: error: 'VUSIM_VSEL_table' undeclared here (not in a function)
>drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:479: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:479: warning: type defaults to 'int' in declaration of 'type name'
>drivers/regulator/twl-regulator.c:479: error: negative width in bit-field '<anonymous>'
>drivers/regulator/twl-regulator.c: In function 'twlreg_probe':
>drivers/regulator/twl-regulator.c:544: error: implicit declaration of function 'twl4030reg_write'
>
>I guess we knew this was coming :-(
>
>Caused by a bad rebase of the voltage tree onto Linus' tree (in order to
>do fixups for commit fc7b92fca4e546184557f1c53f84ad57c66b7695 "mfd:
>Rename all twl4030_i2c*" and others).
>
>I have reverted all the commits in the voltage tree that touched
>drivers/regulator/twl-regulator.c for today:
>
>6051d7a2786c57d0c5c4227dd9ddfc348a86ce91 "twl4030-regulator: Fixes VAUX1-3 exclusion introduced"
>2677c78184a52edcc228c20a1c05c14925118293 "Reset REMAP configuration in regulator probe"
>de449258306274739ed3a747f49b9ac8f91f9e4a "Define critical regulators as always_on"
>66d65d352f6fd61dd5695925906b140f1e0ac9c3 "twl4030-regulator: Add all TWL regulators to twreg_info"
>f33a0d47bd44dbf44a45c33b32e1e3bbbf8d06e6 "twl4030-regulator: Remove regulator from all groups when disabling"
>
>Please fix up this tree properly. You may have been better off merging
>Linus' tree into yours and fixing up the merge commit than trying to do
>the rebase.
All this crap would not have come if we weren't to rename twl4030 into
twl. The argument that we need to rename files to make the code reusable
is plain STUPID.
I made my point several times that we don't need to rename the files to
make the code reusable, twl4030-*.c were already supporting twl4030,
twl5030, twl5031 and some of the tps versions. Now several trees are
broken because of the stupid mess created by one person who can't even
run make when creating a patch. Now we have to pay the price and have a
broken bisect point, great.
--
balbi
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-12-16 7:21 Stephen Rothwell
2009-12-16 9:02 ` Felipe Balbi
@ 2009-12-16 10:10 ` Liam Girdwood
1 sibling, 0 replies; 30+ messages in thread
From: Liam Girdwood @ 2009-12-16 10:10 UTC (permalink / raw)
To: Stephen Rothwell, Keski-Saari Juha.1 (EXT-Teleca/Helsinki)
Cc: linux-next, linux-kernel, Balaji T K, Samuel Ortiz,
Peter Ujfalusi
Hi Stephen,
On Wed, 2009-12-16 at 18:21 +1100, Stephen Rothwell wrote:
> I guess we knew this was coming :-(
:(
>
> Caused by a bad rebase of the voltage tree onto Linus' tree (in order to
> do fixups for commit fc7b92fca4e546184557f1c53f84ad57c66b7695 "mfd:
> Rename all twl4030_i2c*" and others).
>
> I have reverted all the commits in the voltage tree that touched
> drivers/regulator/twl-regulator.c for today:
>
> 6051d7a2786c57d0c5c4227dd9ddfc348a86ce91 "twl4030-regulator: Fixes VAUX1-3 exclusion introduced"
> 2677c78184a52edcc228c20a1c05c14925118293 "Reset REMAP configuration in regulator probe"
> de449258306274739ed3a747f49b9ac8f91f9e4a "Define critical regulators as always_on"
> 66d65d352f6fd61dd5695925906b140f1e0ac9c3 "twl4030-regulator: Add all TWL regulators to twreg_info"
> f33a0d47bd44dbf44a45c33b32e1e3bbbf8d06e6 "twl4030-regulator: Remove regulator from all groups when disabling"
>
> Please fix up this tree properly. You may have been better off merging
> Linus' tree into yours and fixing up the merge commit than trying to do
> the rebase.
Apologies for this. There is a fix coming from Juha today.
Thanks
Liam
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
@ 2009-09-29 9:28 Jan Beulich
2009-09-29 9:51 ` roel kluin
2009-09-29 23:39 ` Hollis Blanchard
0 siblings, 2 replies; 30+ messages in thread
From: Jan Beulich @ 2009-09-29 9:28 UTC (permalink / raw)
To: sfr, hollisb; +Cc: akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next
>>> Hollis Blanchard 09/29/09 2:00 AM >>>
>First, I think there is a real bug here, and the code should read like
>this (to match the comment):
> /* type has to be known at build time for optimization */
>- BUILD_BUG_ON(__builtin_constant_p(type));
>+ BUILD_BUG_ON(!__builtin_constant_p(type));
>
>However, I get the same build error *both* ways, i.e.
>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>the new BUILD_BUG_ON() macro isn't working...
No, at this point of the compilation process it's neither zero nor one,
it's simply considered non-constant by the compiler at that stage
(this builtin is used for optimization, not during parsing, and the
error gets generated when the body of the function gets parsed,
not when code gets generated from it).
Jan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-09-29 9:28 Jan Beulich
@ 2009-09-29 9:51 ` roel kluin
2009-09-30 6:29 ` Jan Beulich
2009-09-29 23:39 ` Hollis Blanchard
1 sibling, 1 reply; 30+ messages in thread
From: roel kluin @ 2009-09-29 9:51 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, hollisb, akpm, linuxppc-dev, kvm-ppc, linux-kernel,
linux-next
On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> wrote:
>>>> Hollis Blanchard 09/29/09 2:00 AM >>>
>>First, I think there is a real bug here, and the code should read like
>>this (to match the comment):
>> /* type has to be known at build time for optimization */
>>- BUILD_BUG_ON(__builtin_constant_p(type));
>>+ BUILD_BUG_ON(!__builtin_constant_p(type));
>>
>>However, I get the same build error *both* ways, i.e.
>>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>>the new BUILD_BUG_ON() macro isn't working...
>
> No, at this point of the compilation process it's neither zero nor one,
> it's simply considered non-constant by the compiler at that stage
> (this builtin is used for optimization, not during parsing, and the
> error gets generated when the body of the function gets parsed,
> not when code gets generated from it).
>
> Jan
then maybe
if(__builtin_constant_p(type))
BUILD_BUG_ON(1);
would work?
Roel
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-09-29 9:51 ` roel kluin
@ 2009-09-30 6:29 ` Jan Beulich
0 siblings, 0 replies; 30+ messages in thread
From: Jan Beulich @ 2009-09-30 6:29 UTC (permalink / raw)
To: roel kluin
Cc: sfr, akpm, linuxppc-dev, hollisb, kvm-ppc, linux-kernel,
linux-next
>>> roel kluin <roel.kluin@gmail.com> 29.09.09 11:51 >>>
>On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich <jbeulich@novell.com> wrote:
>>>>> Hollis Blanchard 09/29/09 2:00 AM >>>
>>>First, I think there is a real bug here, and the code should read like
>>>this (to match the comment):
>>> /* type has to be known at build time for optimization */
>>>- BUILD_BUG_ON(__builtin_constant_p(type));
>>>+ BUILD_BUG_ON(!__builtin_constant_p(type));
>>>
>>>However, I get the same build error *both* ways, i.e.
>>>__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>>>the new BUILD_BUG_ON() macro isn't working...
>>
>> No, at this point of the compilation process it's neither zero nor one,
>> it's simply considered non-constant by the compiler at that stage
>> (this builtin is used for optimization, not during parsing, and the
>> error gets generated when the body of the function gets parsed,
>> not when code gets generated from it).
>>
>> Jan
>
>then maybe
>
>if(__builtin_constant_p(type))
> BUILD_BUG_ON(1);
>
>would work?
Definitely not - this would result in the compiler *always* generating an
error.
Jan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-09-29 9:28 Jan Beulich
2009-09-29 9:51 ` roel kluin
@ 2009-09-29 23:39 ` Hollis Blanchard
2009-09-30 6:35 ` Jan Beulich
1 sibling, 1 reply; 30+ messages in thread
From: Hollis Blanchard @ 2009-09-29 23:39 UTC (permalink / raw)
To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next
On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard 09/29/09 2:00 AM >>>
> >First, I think there is a real bug here, and the code should read like
> >this (to match the comment):
> > /* type has to be known at build time for optimization */
> >- BUILD_BUG_ON(__builtin_constant_p(type));
> >+ BUILD_BUG_ON(!__builtin_constant_p(type));
> >
> >However, I get the same build error *both* ways, i.e.
> >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
> >the new BUILD_BUG_ON() macro isn't working...
>
> No, at this point of the compilation process it's neither zero nor one,
> it's simply considered non-constant by the compiler at that stage
> (this builtin is used for optimization, not during parsing, and the
> error gets generated when the body of the function gets parsed,
> not when code gets generated from it).
I think I see what you're saying. Do you have a fix to suggest?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-09-29 23:39 ` Hollis Blanchard
@ 2009-09-30 6:35 ` Jan Beulich
2009-10-02 15:48 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Jan Beulich @ 2009-09-30 6:35 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next
>>> Hollis Blanchard <hollisb@us.ibm.com> 30.09.09 01:39 >>>
>On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote:
>> >>> Hollis Blanchard 09/29/09 2:00 AM >>>
>> >First, I think there is a real bug here, and the code should read like
>> >this (to match the comment):
>> > /* type has to be known at build time for optimization */
>> >- BUILD_BUG_ON(__builtin_constant_p(type));
>> >+ BUILD_BUG_ON(!__builtin_constant_p(type));
>> >
>> >However, I get the same build error *both* ways, i.e.
>> >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
>> >the new BUILD_BUG_ON() macro isn't working...
>>
>> No, at this point of the compilation process it's neither zero nor one,
>> it's simply considered non-constant by the compiler at that stage
>> (this builtin is used for optimization, not during parsing, and the
>> error gets generated when the body of the function gets parsed,
>> not when code gets generated from it).
>
>I think I see what you're saying. Do you have a fix to suggest?
The one Rusty suggested the other day may help here. I don't like it
as a drop-in replacement for BUILD_BUG_ON() though (due to it
deferring the error generated to the linking stage), I'd rather view
this as an improvement to MAYBE_BUILD_BUG_ON() (which should
then be used here).
Jan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-09-30 6:35 ` Jan Beulich
@ 2009-10-02 15:48 ` Hollis Blanchard
2009-10-05 6:58 ` Jan Beulich
0 siblings, 1 reply; 30+ messages in thread
From: Hollis Blanchard @ 2009-10-02 15:48 UTC (permalink / raw)
To: Jan Beulich; +Cc: sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel, linux-next
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard <hollisb@us.ibm.com> 30.09.09 01:39 >>>
> >On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote:
> >> >>> Hollis Blanchard 09/29/09 2:00 AM >>>
> >> >First, I think there is a real bug here, and the code should read like
> >> >this (to match the comment):
> >> > /* type has to be known at build time for optimization */
> >> >- BUILD_BUG_ON(__builtin_constant_p(type));
> >> >+ BUILD_BUG_ON(!__builtin_constant_p(type));
> >> >
> >> >However, I get the same build error *both* ways, i.e.
> >> >__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
> >> >the new BUILD_BUG_ON() macro isn't working...
> >>
> >> No, at this point of the compilation process it's neither zero nor one,
> >> it's simply considered non-constant by the compiler at that stage
> >> (this builtin is used for optimization, not during parsing, and the
> >> error gets generated when the body of the function gets parsed,
> >> not when code gets generated from it).
> >
> >I think I see what you're saying. Do you have a fix to suggest?
>
> The one Rusty suggested the other day may help here. I don't like it
> as a drop-in replacement for BUILD_BUG_ON() though (due to it
> deferring the error generated to the linking stage), I'd rather view
> this as an improvement to MAYBE_BUILD_BUG_ON() (which should
> then be used here).
Can you be more specific?
I have no idea what Rusty suggested where. I can't even guess what
MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
All I know is that this used to build...
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-10-02 15:48 ` Hollis Blanchard
@ 2009-10-05 6:58 ` Jan Beulich
2009-10-09 19:14 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Jan Beulich @ 2009-10-05 6:58 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel,
linux-next
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
>>> Hollis Blanchard <hollisb@us.ibm.com> 02.10.09 17:48 >>>
>On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
>> The one Rusty suggested the other day may help here. I don't like it
>> as a drop-in replacement for BUILD_BUG_ON() though (due to it
>> deferring the error generated to the linking stage), I'd rather view
>> this as an improvement to MAYBE_BUILD_BUG_ON() (which should
>> then be used here).
>
>Can you be more specific?
>
>I have no idea what Rusty suggested where. I can't even guess what
I'm attaching Rusty's response I was referring to.
>MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
Agreed - but presumably better than just deleting the bogus instances
altogether...
Jan
[-- Attachment #2: Type: message/rfc822, Size: 2578 bytes --]
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Jan Beulich" <JBeulich@novell.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses of it
Date: Wed, 23 Sep 2009 10:27:00 +0930
Message-ID: <200909231027.01006.rusty@rustcorp.com.au>
On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
> gcc permitting variable length arrays makes the current construct
> used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
> if the controlling expression isn't really constant. Instead, this
> patch makes it so that a bit field gets used here. Consequently, those
> uses where the condition isn't really constant now also need fixing.
>
> Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
> MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
> if the expression is compile time constant (__builtin_constant_p()
> yields true), the array is still deemed of variable length by gcc, and
> hence the whole expression doesn't have the intended effect.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
We used to use an undefined symbol here; diagnostics are worse but it catches
more stuff.
Perhaps a hybrid is the way to go?
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
/* If it's a constant, catch it at compile time, otherwise at link time. */
extern int __build_bug_on_failed;
#define BUILD_BUG_ON(condition) \
do { \
((void)sizeof(char[1 - 2*!!(condition)])); \
if (condition) __build_bug_on_failed = 1; \
} while(0)
#endif
Thanks,
Rusty.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-10-05 6:58 ` Jan Beulich
@ 2009-10-09 19:14 ` Hollis Blanchard
2009-10-14 22:57 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Hollis Blanchard @ 2009-10-09 19:14 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel,
linux-next
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2009-10-05 at 07:58 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard <hollisb@us.ibm.com> 02.10.09 17:48 >>>
> >On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
> >> The one Rusty suggested the other day may help here. I don't like it
> >> as a drop-in replacement for BUILD_BUG_ON() though (due to it
> >> deferring the error generated to the linking stage), I'd rather view
> >> this as an improvement to MAYBE_BUILD_BUG_ON() (which should
> >> then be used here).
> >
> >Can you be more specific?
> >
> >I have no idea what Rusty suggested where. I can't even guess what
>
> I'm attaching Rusty's response I was referring to.
>
> >MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
>
> Agreed - but presumably better than just deleting the bogus instances
> altogether...
>
> Jan
> email message attachment
> > -------- Forwarded Message --------
> > From: Rusty Russell <rusty@rustcorp.com.au>
> > To: Jan Beulich <JBeulich@novell.com>
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses
> > of it
> > Date: Wed, 23 Sep 2009 10:27:00 +0930
> >
> > On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
> > > gcc permitting variable length arrays makes the current construct
> > > used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
> > > if the controlling expression isn't really constant. Instead, this
> > > patch makes it so that a bit field gets used here. Consequently, those
> > > uses where the condition isn't really constant now also need fixing.
> > >
> > > Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
> > > MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
> > > if the expression is compile time constant (__builtin_constant_p()
> > > yields true), the array is still deemed of variable length by gcc, and
> > > hence the whole expression doesn't have the intended effect.
> > >
> > > Signed-off-by: Jan Beulich <jbeulich@novell.com>
> >
> > We used to use an undefined symbol here; diagnostics are worse but it catches
> > more stuff.
> >
> > Perhaps a hybrid is the way to go?
> >
> > #ifndef __OPTIMIZE__
> > #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> > #else
> > /* If it's a constant, catch it at compile time, otherwise at link time. */
> > extern int __build_bug_on_failed;
> > #define BUILD_BUG_ON(condition) \
> > do { \
> > ((void)sizeof(char[1 - 2*!!(condition)])); \
> > if (condition) __build_bug_on_failed = 1; \
> > } while(0)
> > #endif
> >
> > Thanks,
> > Rusty.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-10-09 19:14 ` Hollis Blanchard
@ 2009-10-14 22:57 ` Hollis Blanchard
2009-10-15 7:27 ` Jan Beulich
0 siblings, 1 reply; 30+ messages in thread
From: Hollis Blanchard @ 2009-10-14 22:57 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel,
linux-next
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
>
> original: built but didn't work
> Jan's: doesn't build
> Rusty's: builds and works
>
> Where do you want to go from here?
Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
build, and we still need to fix it.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-10-14 22:57 ` Hollis Blanchard
@ 2009-10-15 7:27 ` Jan Beulich
2009-10-19 18:19 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Jan Beulich @ 2009-10-15 7:27 UTC (permalink / raw)
To: Hollis Blanchard
Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel,
linux-next
>>> Hollis Blanchard <hollisb@us.ibm.com> 15.10.09 00:57 >>>
>On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
>> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
>> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
>>
>> original: built but didn't work
>> Jan's: doesn't build
>> Rusty's: builds and works
>>
>> Where do you want to go from here?
>
>Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
>build, and we still need to fix it.
My perspective is that it just uncovered already existing brokenness. And
honestly, I won't be able to get to look into this within the next days. (And
btw., when I run into issues with other people's code changes, quite
frequently I'm told to propose a patch, so I'm also having some
philosophical problem understanding why I can't simply expect the same
when people run into issues with changes I made, especially in cases like
this where it wasn't me introducing the broken code.) So, if this can wait
for a couple of days, I can try to find time to look into this. Otherwise, I'd
rely on someone running into the actual issue to implement a solution.
Jan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-10-15 7:27 ` Jan Beulich
@ 2009-10-19 18:19 ` Hollis Blanchard
2009-10-20 1:12 ` Rusty Russell
0 siblings, 1 reply; 30+ messages in thread
From: Hollis Blanchard @ 2009-10-19 18:19 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, akpm, linuxppc-dev, Rusty Russell, kvm-ppc, linux-kernel,
linux-next
On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> >>> Hollis Blanchard <hollisb@us.ibm.com> 15.10.09 00:57 >>>
> >On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
> >> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
> >> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
> >>
> >> original: built but didn't work
> >> Jan's: doesn't build
> >> Rusty's: builds and works
> >>
> >> Where do you want to go from here?
> >
> >Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
> >build, and we still need to fix it.
>
> My perspective is that it just uncovered already existing brokenness. And
> honestly, I won't be able to get to look into this within the next days. (And
> btw., when I run into issues with other people's code changes, quite
> frequently I'm told to propose a patch, so I'm also having some
> philosophical problem understanding why I can't simply expect the same
> when people run into issues with changes I made, especially in cases like
> this where it wasn't me introducing the broken code.) So, if this can wait
> for a couple of days, I can try to find time to look into this. Otherwise, I'd
> rely on someone running into the actual issue to implement a solution.
Sorry, I thought it was clear, but to be more explicit: I propose the
following patch, which replaces the current BUILD_BUG_ON implementation
with Rusty's version.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -677,18 +677,19 @@ struct sysinfo {
char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this.. */
};
-/* Force a compilation error if condition is true */
-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
-
-/* Force a compilation error if condition is constant and true */
-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
-
-/* Force a compilation error if condition is true, but also produce a
- result (of value 0 and type size_t), so the expression can be used
- e.g. in a structure initializer (or where-ever else comma expressions
- aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
-#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+/* If it's a constant, catch it at compile time, otherwise at link time. */
+extern int __build_bug_on_failed;
+#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_ON(condition) \
+ do { \
+ ((void)sizeof(char[1 - 2*!!(condition)])); \
+ if (condition) __build_bug_on_failed = 1; \
+ } while(0)
+#define MAYBE_BUILD_BUG_ON(condition) BUILD_BUG_ON(condition)
+#endif
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-10-19 18:19 ` Hollis Blanchard
@ 2009-10-20 1:12 ` Rusty Russell
2009-10-20 1:29 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Rusty Russell @ 2009-10-20 1:12 UTC (permalink / raw)
To: Hollis Blanchard
Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel,
linux-next
On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote:
> On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> > My perspective is that it just uncovered already existing brokenness.
>
> Sorry, I thought it was clear, but to be more explicit: I propose the
> following patch, which replaces the current BUILD_BUG_ON implementation
> with Rusty's version.
OK, I switched my brain back on. Yeah, I agree: we may still want
BUILD_OR_RUNTIME_BUG_ON one day, but I like this.
It's just missing the giant comment that it needs :)
/**
* BUILD_BUG_ON - break compile if a condition is true.
* @cond: the condition which the compiler should know is false.
*
* If you have some code which relies on certain constants being equal, or
* other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
*
* The implementation uses gcc's reluctance to create a negative array, but
* gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
* to inline functions). So as a fallback we use the optimizer; if it can't
* prove the condition is false, it will cause a link error on the undefined
* "__build_bug_on_failed". This error is less neat, and can be harder to
* track down.
*/
Thanks!
Rusty.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: linux-next: tree build failure
2009-10-20 1:12 ` Rusty Russell
@ 2009-10-20 1:29 ` Hollis Blanchard
0 siblings, 0 replies; 30+ messages in thread
From: Hollis Blanchard @ 2009-10-20 1:29 UTC (permalink / raw)
To: Rusty Russell
Cc: Jan Beulich, sfr, akpm, linuxppc-dev, kvm-ppc, linux-kernel,
linux-next
On Tue, 2009-10-20 at 11:42 +1030, Rusty Russell wrote:
> On Tue, 20 Oct 2009 04:49:29 am Hollis Blanchard wrote:
> > On Thu, 2009-10-15 at 08:27 +0100, Jan Beulich wrote:
> > > My perspective is that it just uncovered already existing brokenness.
> >
> > Sorry, I thought it was clear, but to be more explicit: I propose the
> > following patch, which replaces the current BUILD_BUG_ON implementation
> > with Rusty's version.
>
> OK, I switched my brain back on. Yeah, I agree: we may still want
> BUILD_OR_RUNTIME_BUG_ON one day, but I like this.
>
> It's just missing the giant comment that it needs :)
>
> /**
> * BUILD_BUG_ON - break compile if a condition is true.
> * @cond: the condition which the compiler should know is false.
> *
> * If you have some code which relies on certain constants being equal, or
> * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
> * detect if someone changes it.
> *
> * The implementation uses gcc's reluctance to create a negative array, but
> * gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
> * to inline functions). So as a fallback we use the optimizer; if it can't
> * prove the condition is false, it will cause a link error on the undefined
> * "__build_bug_on_failed". This error is less neat, and can be harder to
> * track down.
> */
Do you want to put together a signed-off patch Rusty? It's your code, so
I don't feel comfortable doing that.
Once we have that, can we remove the mysterious MAYBE_BUILD_BUG_ON
statements introduced in previous patches? (Does it BUG or doesn't it??)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread
* linux-next: tree build failure
@ 2009-09-24 5:21 Stephen Rothwell
2009-09-29 0:00 ` Hollis Blanchard
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2009-09-24 5:21 UTC (permalink / raw)
To: ppc-dev
Cc: linux-next, linux-kernel, Jan Beulich, Andrew Morton,
Hollis Blanchard, kvm-ppc
Hi all,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
In file included from arch/powerpc/kvm/booke.c:31:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
In file included from arch/powerpc/kvm/booke.h:26,
from arch/powerpc/kvm/booke_emulate.c:23:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
I applied the following patch for today. This inline function is
only called from one place in one file ...
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Sep 2009 15:13:20 +1000
Subject: [PATCH] powerpc/kvm: build fix for new BUILD_BUG_ON
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kvm/timing.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
index bb13b1f..4c34099 100644
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@ -48,7 +48,7 @@ static inline void kvmppc_set_exit_type(struct kvm_vcpu *vcpu, int type) {}
static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
{
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ //BUILD_BUG_ON(__builtin_constant_p(type));
switch (type) {
case EXT_INTR_EXITS:
vcpu->stat.ext_intr_exits++;
--
1.6.4.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-09-24 5:21 Stephen Rothwell
@ 2009-09-29 0:00 ` Hollis Blanchard
0 siblings, 0 replies; 30+ messages in thread
From: Hollis Blanchard @ 2009-09-29 0:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: ppc-dev, linux-next, linux-kernel, Jan Beulich, Andrew Morton,
kvm-ppc
On Thu, 2009-09-24 at 15:21 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> In file included from arch/powerpc/kvm/booke.c:31:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
> In file included from arch/powerpc/kvm/booke.h:26,
> from arch/powerpc/kvm/booke_emulate.c:23:
> arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
> arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
>
> Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
> ("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
First, I think there is a real bug here, and the code should read like
this (to match the comment):
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ BUILD_BUG_ON(!__builtin_constant_p(type));
However, I get the same build error *both* ways, i.e.
__builtin_constant_p(type) evaluates to both 0 and 1? Either that, or
the new BUILD_BUG_ON() macro isn't working...
> I applied the following patch for today. This inline function is
> only called from one place in one file ...
It's also called via kvmppc_account_exit() from a number of places.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 30+ messages in thread
* linux-next: tree build failure
@ 2009-08-17 8:39 Stephen Rothwell
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2009-08-17 8:39 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-next, linux-kernel
Hi Rafael,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/base/power/runtime.c:948: error: __ksymtab_pm_runtime_disable causes a section type conflict
Caused by commit d9d4cc5169ca18df9ff5afd31c6e6b715ecb454a ("PM: Introduce
core framework for run-time PM of I/O devices (rev. 17)") from the
suspend tree. This commit EXPORTs pm_runtime_disable which is an inline
function that calls __pm_runtime_disable (which is probably what was
meant to be EXPORTed).
I wish we could get these type of errors to fail on x86 as well ...
I have applied the following patch for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 17 Aug 2009 18:34:28 +1000
Subject: [PATCH] suspend: EXPORT the correct function.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/power/runtime.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 28a3f91..38556f6 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -945,7 +945,7 @@ void __pm_runtime_disable(struct device *dev, bool check_resume)
out:
spin_unlock_irq(&dev->power.lock);
}
-EXPORT_SYMBOL_GPL(pm_runtime_disable);
+EXPORT_SYMBOL_GPL(__pm_runtime_disable);
/**
* pm_runtime_enable - Enable run-time PM of a device.
--
1.6.3.3
^ permalink raw reply related [flat|nested] 30+ messages in thread* linux-next: tree build failure
@ 2009-08-03 0:35 Stephen Rothwell
2009-08-03 1:01 ` NeilBrown
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2009-08-03 0:35 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-next, linux-kernel, Andre Noll
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
Hi Neil,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
ERROR: ".md_integrity_add_rdev" [drivers/md/multipath.ko] undefined!
Caused by commit 66f4f3f41f5c334f399e920b2aaad9b82514acda ("md: Push down
data integrity code to personalities") from the md-current and md trees.
Looks like md_integrity_add_rdev needs an EXPORT_SYMBOL.
I have used the version of the md-current and md trees from next-20090731
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 [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-08-03 0:35 Stephen Rothwell
@ 2009-08-03 1:01 ` NeilBrown
2009-08-03 1:30 ` Stephen Rothwell
0 siblings, 1 reply; 30+ messages in thread
From: NeilBrown @ 2009-08-03 1:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Andre Noll
On Mon, August 3, 2009 10:35 am, Stephen Rothwell wrote:
> Hi Neil,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> ERROR: ".md_integrity_add_rdev" [drivers/md/multipath.ko] undefined!
>
> Caused by commit 66f4f3f41f5c334f399e920b2aaad9b82514acda ("md: Push down
> data integrity code to personalities") from the md-current and md trees.
> Looks like md_integrity_add_rdev needs an EXPORT_SYMBOL.
Yes, of course...
Thanks!
Fixed.
NeilBrown
>
> I have used the version of the md-current and md trees from next-20090731
> for today.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-08-03 1:01 ` NeilBrown
@ 2009-08-03 1:30 ` Stephen Rothwell
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2009-08-03 1:30 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-next, linux-kernel, Andre Noll
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
Hi Neil,
On Mon, 3 Aug 2009 11:01:24 +1000 (EST) "NeilBrown" <neilb@suse.de> wrote:
>
> On Mon, August 3, 2009 10:35 am, Stephen Rothwell wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > ERROR: ".md_integrity_add_rdev" [drivers/md/multipath.ko] undefined!
> >
> > Caused by commit 66f4f3f41f5c334f399e920b2aaad9b82514acda ("md: Push down
> > data integrity code to personalities") from the md-current and md trees.
> > Looks like md_integrity_add_rdev needs an EXPORT_SYMBOL.
>
> Yes, of course...
> Thanks!
> Fixed.
OK, so I refetched the md tree and will use it 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 [flat|nested] 30+ messages in thread
* linux-next: tree build failure
@ 2009-07-27 7:53 Stephen Rothwell
2009-07-27 9:21 ` Karsten Keil
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Rothwell @ 2009-07-27 7:53 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, linux-kernel, Karsten Keil
Hi Dave,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/isdn/hisax/built-in.o: In function `setup_w6692':
(.opd+0x4a28): multiple definition of `setup_w6692'
drivers/isdn/hardware/built-in.o:(.opd+0x4e90): first defined here
drivers/isdn/hisax/built-in.o: In function `.setup_w6692':
(.devinit.text+0x5b14): multiple definition of `.setup_w6692'
drivers/isdn/hardware/built-in.o:(.text+0x8b75c): first defined here
Caused by commit 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240
("mISDN: Add driver for Winbond cards").
setup_w6692 appears in drivers/isdn/hardware/mISDN/w6692.c and
drivers/isdn/hisax/w6692.c. I applied the patch below for today (this
may not be correct).
[I also get these warnings:
drivers/isdn/hardware/mISDN/w6692.c:533: warning: 'setvolume' defined but not used
drivers/isdn/hardware/mISDN/w6692.c:560: warning: 'enable_pots' defined but not used
]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Jul 2009 17:45:36 +1000
Subject: [PATCH] net: fix multiple definitions of setup_w6692
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/isdn/hardware/mISDN/w6692.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/w6692.c b/drivers/isdn/hardware/mISDN/w6692.c
index 1b9008f..d3f1077 100644
--- a/drivers/isdn/hardware/mISDN/w6692.c
+++ b/drivers/isdn/hardware/mISDN/w6692.c
@@ -1234,7 +1234,7 @@ w6692_dctrl(struct mISDNchannel *ch, u32 cmd, void *arg)
return err;
}
-int
+static int
setup_w6692(struct w6692_hw *card)
{
u32 val;
--
1.6.3.3
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-07-27 7:53 Stephen Rothwell
@ 2009-07-27 9:21 ` Karsten Keil
2009-07-27 15:06 ` David Miller
0 siblings, 1 reply; 30+ messages in thread
From: Karsten Keil @ 2009-07-27 9:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, linux-next, linux-kernel
Hi Stephen,
On Montag, 27. Juli 2009 09:53:28 you wrote:
> Hi Dave,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/isdn/hisax/built-in.o: In function `setup_w6692':
> (.opd+0x4a28): multiple definition of `setup_w6692'
> drivers/isdn/hardware/built-in.o:(.opd+0x4e90): first defined here
> drivers/isdn/hisax/built-in.o: In function `.setup_w6692':
> (.devinit.text+0x5b14): multiple definition of `.setup_w6692'
> drivers/isdn/hardware/built-in.o:(.text+0x8b75c): first defined here
>
> Caused by commit 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240
> ("mISDN: Add driver for Winbond cards").
>
> setup_w6692 appears in drivers/isdn/hardware/mISDN/w6692.c and
> drivers/isdn/hisax/w6692.c. I applied the patch below for today (this
> may not be correct).
>
Sorry for that, yes this fix is correct - I really should test allyesconfig
more times by myself :-(.
ACK.
> [I also get these warnings:
> drivers/isdn/hardware/mISDN/w6692.c:533: warning: 'setvolume' defined but
> not used drivers/isdn/hardware/mISDN/w6692.c:560: warning: 'enable_pots'
> defined but not used ]
The POTS code is implemented, but the higher level interface is not finally
defined yet, so the two functions are not used at the moment.
The interface will added soon.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 27 Jul 2009 17:45:36 +1000
> Subject: [PATCH] net: fix multiple definitions of setup_w6692
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/isdn/hardware/mISDN/w6692.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/isdn/hardware/mISDN/w6692.c
> b/drivers/isdn/hardware/mISDN/w6692.c index 1b9008f..d3f1077 100644
> --- a/drivers/isdn/hardware/mISDN/w6692.c
> +++ b/drivers/isdn/hardware/mISDN/w6692.c
> @@ -1234,7 +1234,7 @@ w6692_dctrl(struct mISDNchannel *ch, u32 cmd, void
> *arg) return err;
> }
>
> -int
> +static int
> setup_w6692(struct w6692_hw *card)
> {
> u32 val;
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-07-27 9:21 ` Karsten Keil
@ 2009-07-27 15:06 ` David Miller
2009-07-28 4:22 ` Stephen Rothwell
0 siblings, 1 reply; 30+ messages in thread
From: David Miller @ 2009-07-27 15:06 UTC (permalink / raw)
To: keil; +Cc: sfr, linux-next, linux-kernel
From: Karsten Keil <keil@b1-systems.de>
Date: Mon, 27 Jul 2009 11:21:33 +0200
> On Montag, 27. Juli 2009 09:53:28 you wrote:
>> Hi Dave,
>>
>> Today's linux-next build (powerpc allyesconfig) failed like this:
>>
>> drivers/isdn/hisax/built-in.o: In function `setup_w6692':
>> (.opd+0x4a28): multiple definition of `setup_w6692'
>> drivers/isdn/hardware/built-in.o:(.opd+0x4e90): first defined here
>> drivers/isdn/hisax/built-in.o: In function `.setup_w6692':
>> (.devinit.text+0x5b14): multiple definition of `.setup_w6692'
>> drivers/isdn/hardware/built-in.o:(.text+0x8b75c): first defined here
>>
>> Caused by commit 707b2ce6c1f4f1261788f2ff09ad82c35e0e6240
>> ("mISDN: Add driver for Winbond cards").
>>
>> setup_w6692 appears in drivers/isdn/hardware/mISDN/w6692.c and
>> drivers/isdn/hisax/w6692.c. I applied the patch below for today (this
>> may not be correct).
>>
>
> Sorry for that, yes this fix is correct - I really should test allyesconfig
> more times by myself :-(.
>
> ACK.
Applied.
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: linux-next: tree build failure
2009-07-27 15:06 ` David Miller
@ 2009-07-28 4:22 ` Stephen Rothwell
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2009-07-28 4:22 UTC (permalink / raw)
To: David Miller; +Cc: keil, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
Hi Dave, Karsten,
On Mon, 27 Jul 2009 08:06:17 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Karsten Keil <keil@b1-systems.de>
> Date: Mon, 27 Jul 2009 11:21:33 +0200
>
> > Sorry for that, yes this fix is correct - I really should test allyesconfig
> > more times by myself :-(.
I don't really expect people to do allyesconfig build very often.
> > ACK.
>
> Applied.
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 [flat|nested] 30+ messages in thread
* linux-next: tree build failure
@ 2008-10-21 8:30 Stephen Rothwell
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Rothwell @ 2008-10-21 8:30 UTC (permalink / raw)
To: Linus; +Cc: linux-next, LKML, Thomas Gleixner
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Hi Linus,
Today's linux-next build (i386 defconfig) failed like this:
drivers/gpu/drm/i915/i915_gem.c: In function 'fast_user_write':
drivers/gpu/drm/i915/i915_gem.c:196: error: 'o' undeclared (first use in this function)
Caused by commit 9b7530cc329eb036cfa589930c270e85031f554c ("i915: cleanup
coding horrors in i915_gem_gtt_pwrite()").
I have applied Thomas' fix since today' linux-next base precedes the fix
being added.
--
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 [flat|nested] 30+ messages in thread
end of thread, other threads:[~2009-12-16 10:11 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-01 3:19 linux-next: tree build failure Stephen Rothwell
2009-10-01 7:58 ` Jens Axboe
2009-10-01 10:41 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2009-12-16 7:21 Stephen Rothwell
2009-12-16 9:02 ` Felipe Balbi
2009-12-16 10:10 ` Liam Girdwood
2009-09-29 9:28 Jan Beulich
2009-09-29 9:51 ` roel kluin
2009-09-30 6:29 ` Jan Beulich
2009-09-29 23:39 ` Hollis Blanchard
2009-09-30 6:35 ` Jan Beulich
2009-10-02 15:48 ` Hollis Blanchard
2009-10-05 6:58 ` Jan Beulich
2009-10-09 19:14 ` Hollis Blanchard
2009-10-14 22:57 ` Hollis Blanchard
2009-10-15 7:27 ` Jan Beulich
2009-10-19 18:19 ` Hollis Blanchard
2009-10-20 1:12 ` Rusty Russell
2009-10-20 1:29 ` Hollis Blanchard
2009-09-24 5:21 Stephen Rothwell
2009-09-29 0:00 ` Hollis Blanchard
2009-08-17 8:39 Stephen Rothwell
2009-08-03 0:35 Stephen Rothwell
2009-08-03 1:01 ` NeilBrown
2009-08-03 1:30 ` Stephen Rothwell
2009-07-27 7:53 Stephen Rothwell
2009-07-27 9:21 ` Karsten Keil
2009-07-27 15:06 ` David Miller
2009-07-28 4:22 ` Stephen Rothwell
2008-10-21 8:30 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox