[PATCH] unset twsi option3 for gconfig as well

Signed-off-by: Roel Kluin --- drivers/pinctrl/mvebu/pinctrl-dove.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c index 29f7e4f..360b9b2 100644 --- a/drivers/pinctrl/mvebu/pinctrl-dove.c +++ b

[PATCH] set data enable logic level to low

Signed-off-by: Roel Kluin --- drivers/video/omap2/dss/display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c index fafe7c9..669a81f 100644 --- a/drivers/video/omap2/dss/display.c +++ b/drivers/video

exynos4: index out of bounds if no pixelcode found

In case no valid pixelcode is found, an i of -1 after the loop is out of bounds for the array. Signed-off-by: Roel Kluin --- diff --git a/drivers/media/platform/exynos4-is/fimc-lite-reg.c b/drivers/media/platform/exynos4-is/fimc-lite-reg.c index 72a343e3b..d0dc7ee 100644 --- a/drivers/media

exynos4: index out of bounds if no pixelcode found

In case no valid pixelcode is found, an i of -1 after the loop is out of bounds for the array. Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/drivers/media/platform/exynos4-is/fimc-lite-reg.c b/drivers/media/platform/exynos4-is/fimc-lite-reg.c index 72a343e3b..d0dc7ee 100644

[PATCH] set data enable logic level to low

Signed-off-by: Roel Kluin roel.kl...@gmail.com --- drivers/video/omap2/dss/display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c index fafe7c9..669a81f 100644 --- a/drivers/video/omap2/dss/display.c

[PATCH] unset twsi option3 for gconfig as well

Signed-off-by: Roel Kluin roel.kl...@gmail.com --- drivers/pinctrl/mvebu/pinctrl-dove.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c index 29f7e4f..360b9b2 100644 --- a/drivers/pinctrl/mvebu

lockdep: testing '0' where '\0' intended?

Not entirely sure about the assembly part, but shouldn't it... Test for the nul character rather than the '0' (== 0x30), in the __get_user_unknown() case. Signed-off-by: Roel Kluin --- diff --git a/kernel/lockdep_proc.c b/kernel/lockdep_proc.c index b2c71c5..71b3aba 100644 --- a/kernel

[PATCH] jump_label: unlikely(x) > 0

untested, but wasn't this intended instead? -- if (unlikely(x) > 0) doesn't seem to help branch prediction Signed-off-by: Roel Kluin --- diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index a507907..cf08540 100644 --- a/include/linux/jump_label.h +++ b/incl

tty: incorrect test of echo_buf() result for ECHO_OP_START

Untested, but this looks like a bug to me --- test echo_buf() result for ECHO_OP_START Signed-off-by: Roel Kluin --- diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index 7a744b6..42b6cca 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -767,7 +767,7 @@ static size_t

tty: incorrect test of echo_buf() result for ECHO_OP_START

Untested, but this looks like a bug to me --- test echo_buf() result for ECHO_OP_START Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index 7a744b6..42b6cca 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -767,7

[PATCH] jump_label: unlikely(x) 0

untested, but wasn't this intended instead? -- if (unlikely(x) 0) doesn't seem to help branch prediction Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h index a507907..cf08540 100644 --- a/include/linux

lockdep: testing '0' where '\0' intended?

Not entirely sure about the assembly part, but shouldn't it... Test for the nul character rather than the '0' (== 0x30), in the __get_user_unknown() case. Signed-off-by: Roel Kluin roel.kl...@gmail.com --- diff --git a/kernel/lockdep_proc.c b/kernel/lockdep_proc.c index b2c71c5..71b3aba

Re: Fix bug in end absolute address in drivers/mtd/devices/slram.c

devlength = simple_strtoul(szlength, , 0); >> - devlength = handle_unit(devlength, buffer) - devstart; >> + devlength = handle_unit(devlength, buffer); >> if (devlength < devstart) >> goto err_out; > &

Re: Fix bug in end absolute address in drivers/mtd/devices/slram.c

; + devlength = handle_unit(devlength, buffer); if (devlength devstart) goto err_out; ... adding the suspects to CC so that they are aware of this. Yes, that's what it should have been. FWIW, Acked-by: Roel Kluin roel.kl...@gmail.com -- To unsubscribe

Re: [PATCH] fs/ext4/mballoc.c: Convert to list_for_each_entry_rcu()

Aneesh Kumar K.V wrote: > On Tue, Feb 19, 2008 at 01:31:18AM +0100, Roel Kluin wrote: >> Please verify, this patch was not yet tested >> --- >> Convert list_for_each_rcu() to list_for_each_entry_rcu() >> >> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> >

Re: [PATCH] wireless: Convert to list_for_each_entry_rcu()

Roel Kluin wrote: > Please verify, this patch was not yet tested. > --- > Convert list_for_each_rcu() to list_for_each_entry_rcu() > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> > --- Same mistake as in other patch, please ignore the previous patch and consider the

Re: [PATCH] wireless: Convert to list_for_each_entry_rcu()

Roel Kluin wrote: Please verify, this patch was not yet tested. --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- Same mistake as in other patch, please ignore the previous patch and consider the patch below. --- Convert

Re: [PATCH] fs/ext4/mballoc.c: Convert to list_for_each_entry_rcu()

Aneesh Kumar K.V wrote: On Tue, Feb 19, 2008 at 01:31:18AM +0100, Roel Kluin wrote: Please verify, this patch was not yet tested --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin [EMAIL PROTECTED] NACK. This patch doesn't build. You have extra cur

[PATCH] wireless: Convert to list_for_each_entry_rcu()

Please verify, this patch was not yet tested. --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c index 88efe1b..c5aaab8 100644 --- a/drivers/net/wireless/s

[PATCH] fs/ext4/mballoc.c: Convert to list_for_each_entry_rcu()

Please verify, this patch was not yet tested --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index dd0fcfc..0c4dd13 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -

Re: [PATCH] ufs: [bl]e*_add_cpu conversion

Andrew Morton wrote: > On Wed, 13 Feb 2008 10:41:44 +0100 Roel Kluin <[EMAIL PROTECTED]> wrote: > >> you may also want these: >> --- >> [bl]e_add_cpu conversion in return > upsets powerpc (at least): > > fs/ufs/swab.h: In function `fs64_add': >

Re: [PATCH 1/3] Fix Unlikely(x) == y

David Howells wrote: > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > >> Hence shouldn't we ask the gcc people what's the purpose of >> __builtin_expect(), if it doesn't live up to its promise? > > __builtin_expect() is useful on FRV where you _have_ to give each branch and > conditional branch

[PATCH] arch/sh/drivers/heartbeat.c ioremap is expected to succeed

ed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/sh/drivers/heartbeat.c b/arch/sh/drivers/heartbeat.c index b76a14f..ab77b0e 100644 --- a/arch/sh/drivers/heartbeat.c +++ b/arch/sh/drivers/heartbeat.c @@ -93,7 +93,7 @@ static int heartbeat_drv_probe(struct platform_

[PATCH] arch/sh/drivers/heartbeat.c ioremap is expected to succeed

!unlikely(hd-base) is equivalent to likely(!hd-base) (for instance see comments with commit fd312561adcc90e924f35d3032d5493aeb4c3017), I think the ioremap is expected to succeed? please confirm that's right. The patch below was *not* tested. --- ioremap is expected to succeed Signed-off-by: Roel

Re: [PATCH 1/3] Fix Unlikely(x) == y

David Howells wrote: Geert Uytterhoeven [EMAIL PROTECTED] wrote: Hence shouldn't we ask the gcc people what's the purpose of __builtin_expect(), if it doesn't live up to its promise? __builtin_expect() is useful on FRV where you _have_ to give each branch and conditional branch

[PATCH] wireless: Convert to list_for_each_entry_rcu()

Please verify, this patch was not yet tested. --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/net/wireless/strip.c b/drivers/net/wireless/strip.c index 88efe1b..c5aaab8 100644 --- a/drivers/net/wireless/strip.c

[PATCH] fs/ext4/mballoc.c: Convert to list_for_each_entry_rcu()

Please verify, this patch was not yet tested --- Convert list_for_each_rcu() to list_for_each_entry_rcu() Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index dd0fcfc..0c4dd13 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -3127,6

Re: [PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Roel Kluin wrote: > Roel Kluin wrote: >> Replace !likely(x) by likely(!x) > sorry, please ignore this patch The patch below shouldn't change semantics. --- replace !likely(x) by unlikely(!x) Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/sign

Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

H. Peter Anvin wrote: > Roel Kluin wrote: >> H. Peter Anvin wrote: >>> Roel Kluin wrote: >>>> Not entirely sure who to send this to >>>> --- >>>> Replace !likely(x) by likely(!x) >>> Whoa... >>> >>> Are you sure th

[PATCH] fs/ufs/util.h 2nd parameter of fs32_to_cpu is not boolean

ter is not boolean --- Test the return value, rather than passing a boolean Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/fs/ufs/util.h b/fs/ufs/util.h index b26fc4d..23ceed8 100644 --- a/fs/ufs/util.h +++ b/fs/ufs/util.h @@ -58,7 +58,7 @@ ufs_set_fs_state(struct super_block *s

Re: [PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Roel Kluin wrote: > Replace !likely(x) by likely(!x) > > Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> > --- > diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c > index caee1f0..335872f 100644 > --- a/arch/x86/kernel/signal_32.c > +++ b/arch/x86/

Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

H. Peter Anvin wrote: > Roel Kluin wrote: >> Not entirely sure who to send this to >> --- >> Replace !likely(x) by likely(!x) > > Whoa... > > Are you sure this is correct? > > !likely(x) is equivalent to unlikely(!x), not the opposite, so this is a >

[PATCH] drivers/mtd/onenand/onenand_base.c unlikely(x) || unlikely(y) => unlikely(x || y)

Not yet tested. --- Replace unlikely(x) || unlikely(y) by unlikely(x || y) Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c index 8d7d21b..7334b4a 100644 --- a/drivers/mtd/onenand/onenand_base.c +++ b/d

[PATCH] kernel/sched.c unlikely(x) || unlikely(y) => unlikely(x || y)

Not yet tested. --- Replace unlikely(x) || unlikely(y) by unlikely(x || y) Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/kernel/sched.c b/kernel/sched.c index f28f19e..816c299 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -137,7 +137,7 @@ static inline void sg_inc_cpu

[PATCH 3/3] drivers/s390/block/dcssblk.c: Fix Unlikely(x) != y

The patch below was not yet tested. If it's correct as it is, please comment. --- Fix Unlikely(x) != y Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c index 3faf053..e6c94db 100644 --- a/drivers/s390/block/dcssblk.c

[PATCH 2/3] drivers/media/video/sn9c102/sn9c102_core.c Fix Unlikely(x) == y

The patch below was not yet tested. If it's incorrect, please comment. --- Fix Unlikely(x) == y Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/media/video/sn9c102/sn9c102_core.c b/drivers/media/video/sn9c102/sn9c102_core.c index c40ba3a..66313b1 100644 --- a/drivers

[PATCH 1/3] Fix Unlikely(x) == y

The patch below was not yet tested. If it's correct as it is, please comment. --- Fix Unlikely(x) == y Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c index 3a6db04..a14e5cd 100644 --- a/arch/p

[PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/kernel/exit.c b/kernel/exit.c index 506a957..df207fc 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -1497,7 +1497,7 @@

[PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Replace !likely(x) by likely(!x) Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index caee1f0..335872f 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -303,7 +303,7 @@ get_sigframe(

Re: + bluetooth-fix-warning-in-net-bluetooth-hci_sysfsc.patch added to -mm tree

Andrew Morton wrote: > On Sat, 16 Feb 2008 01:27:41 -0800 (PST) David Miller <[EMAIL PROTECTED]> > wrote: > >> From: [EMAIL PROTECTED] >> Date: Fri, 15 Feb 2008 20:49:33 -0800 >> >>> Subject: bluetooth: fix warning in net/bluetooth/hci_sysfs.c >>> From: Andrew Morton <[EMAIL PROTECTED]> >>> >>>

Re: + bluetooth-fix-warning-in-net-bluetooth-hci_sysfsc.patch added to -mm tree

Andrew Morton wrote: On Sat, 16 Feb 2008 01:27:41 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Date: Fri, 15 Feb 2008 20:49:33 -0800 Subject: bluetooth: fix warning in net/bluetooth/hci_sysfs.c From: Andrew Morton [EMAIL PROTECTED]

[PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Replace !likely(x) by likely(!x) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index caee1f0..335872f 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -303,7 +303,7 @@ get_sigframe(struct

[PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/kernel/exit.c b/kernel/exit.c index 506a957..df207fc 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -1497,7 +1497,7 @@ repeat

[PATCH 1/3] Fix Unlikely(x) == y

The patch below was not yet tested. If it's correct as it is, please comment. --- Fix Unlikely(x) == y Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c index 3a6db04..a14e5cd 100644 --- a/arch/powerpc

[PATCH 3/3] drivers/s390/block/dcssblk.c: Fix Unlikely(x) != y

The patch below was not yet tested. If it's correct as it is, please comment. --- Fix Unlikely(x) != y Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c index 3faf053..e6c94db 100644 --- a/drivers/s390/block/dcssblk.c +++ b

[PATCH 2/3] drivers/media/video/sn9c102/sn9c102_core.c Fix Unlikely(x) == y

The patch below was not yet tested. If it's incorrect, please comment. --- Fix Unlikely(x) == y Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/media/video/sn9c102/sn9c102_core.c b/drivers/media/video/sn9c102/sn9c102_core.c index c40ba3a..66313b1 100644 --- a/drivers/media

[PATCH] kernel/sched.c unlikely(x) || unlikely(y) = unlikely(x || y)

Not yet tested. --- Replace unlikely(x) || unlikely(y) by unlikely(x || y) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/kernel/sched.c b/kernel/sched.c index f28f19e..816c299 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -137,7 +137,7 @@ static inline void sg_inc_cpu_power

[PATCH] drivers/mtd/onenand/onenand_base.c unlikely(x) || unlikely(y) = unlikely(x || y)

Not yet tested. --- Replace unlikely(x) || unlikely(y) by unlikely(x || y) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c index 8d7d21b..7334b4a 100644 --- a/drivers/mtd/onenand/onenand_base.c +++ b/drivers/mtd

Re: [PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Roel Kluin wrote: Replace !likely(x) by likely(!x) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index caee1f0..335872f 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -303,7 +303,7

Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x), not the opposite, so this is a functional change... -hpa You are right, sorry

Re: [PATCH 2/2] kernel/{exit.c, signal.c, power/process.c}: replace !likely(x) by likely(!x)

H. Peter Anvin wrote: Roel Kluin wrote: H. Peter Anvin wrote: Roel Kluin wrote: Not entirely sure who to send this to --- Replace !likely(x) by likely(!x) Whoa... Are you sure this is correct? !likely(x) is equivalent to unlikely(!x), not the opposite, so this is a functional change

Re: [PATCH 1/2] [x86] arch/x86/kernel/signal_32.c: replace !likely(x) by likely(!x)

Roel Kluin wrote: Roel Kluin wrote: Replace !likely(x) by likely(!x) sorry, please ignore this patch The patch below shouldn't change semantics. --- replace !likely(x) by unlikely(!x) Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel

[PATCH] fs/ufs/util.h 2nd parameter of fs32_to_cpu is not boolean

is not boolean --- Test the return value, rather than passing a boolean Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/fs/ufs/util.h b/fs/ufs/util.h index b26fc4d..23ceed8 100644 --- a/fs/ufs/util.h +++ b/fs/ufs/util.h @@ -58,7 +58,7 @@ ufs_set_fs_state(struct super_block *sb, struct

Re: Announce: Linux-next (Or Andrew's dream :-))

Alan Cox wrote: >> Evolution in nature and changes in code are different because in code junk >> and bugs are constantly removed. In biology junk is allowed and may provide >> a pool for future development. Linux development is intended and not >> survival. > > I would be interested to see any

Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds wrote: > > On Wed, 13 Feb 2008, Roel Kluin wrote: >> In nature there is a lot of duplication: several copies of genes can exist >> and different copies may have a distinct evolution. > > This is true of very complex animals, but much less so when looking at

Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds wrote: On Wed, 13 Feb 2008, Roel Kluin wrote: In nature there is a lot of duplication: several copies of genes can exist and different copies may have a distinct evolution. This is true of very complex animals, but much less so when looking at things like bacteria

Re: Announce: Linux-next (Or Andrew's dream :-))

Alan Cox wrote: Evolution in nature and changes in code are different because in code junk and bugs are constantly removed. In biology junk is allowed and may provide a pool for future development. Linux development is intended and not survival. I would be interested to see any evidence

Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds wrote: > > On Tue, 12 Feb 2008, Greg KH wrote: >>> That's the point. >> Not it isn't. To quote you a number of years ago: >> "Linux is evolution, not intelligent design" > > Umm. Have you read a lot of books on evolution? > > It doesn't sound like you have. > > The fact

[drivers/video/sis/init301.c] SiS_Pr->ChipType >= SIS_661 not evaluated twice

Not sure whether this is important, but in drivers/video/sis/init301.c:1557: if((SiS_Pr->ChipType >= SIS_661) || (SiS_Pr->SiS_ROMNew)) { SiS_Pr->SiS_LCDTypeInfo = (SiS_GetReg(SiS_Pr->SiS_P3d4,0x39) & 0x7c) >> 2; } else if((SiS_Pr->ChipType < SIS_315H) || (SiS_Pr->ChipType >= SIS_661)) {

Re: [PATCH] ufs: [bl]e*_add_cpu conversion

_cpu_byteorder); you may also want these: --- [bl]e_add_cpu conversion in return Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h index 1683d2b..a1e3000 100644 --- a/fs/ufs/swab.h +++ b/fs/ufs/swab.h @@ -44,18 +44,22 @@ static __inline u32 fs64_add(s

Re: [PATCH] crypto: be*_add_cpu conversion

[EMAIL PROTECTED] wrote: > From: Marcin Slusarz <[EMAIL PROTECTED]> > > replace all: > big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + > expression_in_cpu_byteorder); > with: > beX_add_cpu(_endian_variable,

Re: [PATCH] crypto: be*_add_cpu conversion

[EMAIL PROTECTED] wrote: From: Marcin Slusarz [EMAIL PROTECTED] replace all: big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) + expression_in_cpu_byteorder); with: beX_add_cpu(big_endian_variable, expression_in_cpu_byteorder);

Re: [PATCH] ufs: [bl]e*_add_cpu conversion

also want these: --- [bl]e_add_cpu conversion in return Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/fs/ufs/swab.h b/fs/ufs/swab.h index 1683d2b..a1e3000 100644 --- a/fs/ufs/swab.h +++ b/fs/ufs/swab.h @@ -44,18 +44,22 @@ static __inline u32 fs64_add(struct super_block *sbp, u32 *n

[drivers/video/sis/init301.c] SiS_Pr-ChipType = SIS_661 not evaluated twice

Not sure whether this is important, but in drivers/video/sis/init301.c:1557: if((SiS_Pr-ChipType = SIS_661) || (SiS_Pr-SiS_ROMNew)) { SiS_Pr-SiS_LCDTypeInfo = (SiS_GetReg(SiS_Pr-SiS_P3d4,0x39) 0x7c) 2; } else if((SiS_Pr-ChipType SIS_315H) || (SiS_Pr-ChipType = SIS_661)) {

Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds wrote: On Tue, 12 Feb 2008, Greg KH wrote: That's the point. Not it isn't. To quote you a number of years ago: Linux is evolution, not intelligent design Umm. Have you read a lot of books on evolution? It doesn't sound like you have. The fact is, evolution often

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent

John David Anglin wrote: >> James Bottomley wrote: >>> On Mon, 2008-02-11 at 17:23 +0100, Roel Kluin wrote: >>>> duplicate pa11_dma_alloc_consistent; more appropriate appears >>>> pa11_dma_alloc_noncoherent here. >>>> >>>> Not t

[PATCH][fs/cifs/cifsfs.c] Make use of cifs_xquota_get

else in the kernel. The patch below makes use of the function cifs_xquota_get, As an alternative the entire function cifs_xquota_get could be removed. --- Make use of cifs_xquota_get Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index f

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

James Bottomley wrote: > On Mon, 2008-02-11 at 17:23 +0100, Roel Kluin wrote: >> duplicate pa11_dma_alloc_consistent; more appropriate appears >> pa11_dma_alloc_noncoherent here. >> >> Not tested, please confirm that this fix is correct > > No, it looks comple

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

Matthew Wilcox wrote: > On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote: >> duplicate pa11_dma_alloc_consistent; more appropriate appears >> pa11_dma_alloc_noncoherent here. >> >> Not tested, please confirm that this fix is correct > > I don't think it

[PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

duplicate pa11_dma_alloc_consistent; more appropriate appears pa11_dma_alloc_noncoherent here. Not tested, please confirm that this fix is correct --- fix noncoherent allocation Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kern

[PATCH][drivers/pnp/pnpacpi/core.c] __initdata is not an identifier

atch below these sparse complaints do not occur --- __initdata is not an identifier Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c index 662b4c2..c283a9a 100644 --- a/drivers/pnp/pnpacpi/core.c +++ b/drivers/pnp/pnpacpi

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

James Bottomley wrote: On Mon, 2008-02-11 at 17:23 +0100, Roel Kluin wrote: duplicate pa11_dma_alloc_consistent; more appropriate appears pa11_dma_alloc_noncoherent here. Not tested, please confirm that this fix is correct No, it looks completely incorrect to me. What makes you think

[PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

duplicate pa11_dma_alloc_consistent; more appropriate appears pa11_dma_alloc_noncoherent here. Not tested, please confirm that this fix is correct --- fix noncoherent allocation Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent

John David Anglin wrote: James Bottomley wrote: On Mon, 2008-02-11 at 17:23 +0100, Roel Kluin wrote: duplicate pa11_dma_alloc_consistent; more appropriate appears pa11_dma_alloc_noncoherent here. Not tested, please confirm that this fix is correct No, it looks completely incorrect to me

[PATCH][fs/cifs/cifsfs.c] Make use of cifs_xquota_get

else in the kernel. The patch below makes use of the function cifs_xquota_get, As an alternative the entire function cifs_xquota_get could be removed. --- Make use of cifs_xquota_get Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index fcc4342

Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?

Matthew Wilcox wrote: On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote: duplicate pa11_dma_alloc_consistent; more appropriate appears pa11_dma_alloc_noncoherent here. Not tested, please confirm that this fix is correct I don't think it is. The memories are fading, so I don't

[PATCH][drivers/pnp/pnpacpi/core.c] __initdata is not an identifier

these sparse complaints do not occur --- __initdata is not an identifier Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c index 662b4c2..c283a9a 100644 --- a/drivers/pnp/pnpacpi/core.c +++ b/drivers/pnp/pnpacpi/core.c @@ -36,7 +36,7

[PATCH] [arch/arm/mach-pnx4008/gpio.c] duplication in if ... else if branches

There is a duplication of code in the following section. Possibly it was copy-pasted and it was forgotten to edit these lines? otherwise consider removing the duplicate lines with the patch below. --- Different if ... else if branches do the same, remove duplication Signed-off-by: Roel Kluin

[PATCH] [arch/arm/mach-pnx4008/gpio.c] duplication in if ... else if branches

There is a duplication of code in the following section. Possibly it was copy-pasted and it was forgotten to edit these lines? otherwise consider removing the duplicate lines with the patch below. --- Different if ... else if branches do the same, remove duplication Signed-off-by: Roel Kluin

[PATCH][drivers/usb/serial/ftdi_sio.c] add missing '|'

add missing '|' Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 90dcc62..2173561 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -394,7 +394,7 @@ static const char *ftdi_chi

Re: [PATCH][drivers/misc/thinkpad_acpi.c] duplicate test if (level & TP_EC_FAN_FULLSPEED)

Greg KH wrote: > On Tue, Feb 05, 2008 at 09:34:54AM +0100, Roel Kluin wrote: >> Henrique de Moraes Holschuh wrote: >>> On Tue, 05 Feb 2008, Roel Kluin wrote: >>>> Roland Dreier wrote: >>>>> > Note the duplicate test 'if (level & TP_

Re: [PATCH][drivers/scsi/u14-34f.c] duplicate test 'SCpnt->sc_data_direction == DMA_FROM_DEVICE'

James Bottomley wrote: > On Mon, 2008-02-04 at 23:36 +0100, Roel Kluin wrote: >> Note the duplicate test 'SCpnt->sc_data_direction == DMA_FROM_DEVICE' >> - if (SCpnt->sc_data_direction == DMA_FROM_DEVICE) { >> + if (SCpnt->sc_data_direction == DMA_TO_DEVICE)

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Kristoffer Ericson wrote: > Oki, here is attempt #2 (btw, new mail or just keep thread?) > > Tested to build and checkpatch. > > diff --git a/drivers/video/backlight/jornada720_bllcd.c > b/drivers/video/backlight/jornada720_bllcd.c > +static int jornada_bl_update_status(struct backlight_device

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Roel Kluin wrote: > Kristoffer Ericson wrote: >> Greetings, >> >> Richard I've cleaned up the driver by checking with checkpatch.pl as Russell >> suggested. I would appreciate it if you could >> look through the patch again and give comments since the patch look

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Kristoffer Ericson wrote: > Greetings, > > Richard I've cleaned up the driver by checking with checkpatch.pl as Russell > suggested. I would appreciate it if you could > look through the patch again and give comments since the patch looks somewhat > different. > > I can add patch for

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Roel Kluin wrote: Kristoffer Ericson wrote: Greetings, Richard I've cleaned up the driver by checking with checkpatch.pl as Russell suggested. I would appreciate it if you could look through the patch again and give comments since the patch looks somewhat different. I can add patch

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Kristoffer Ericson wrote: Greetings, Richard I've cleaned up the driver by checking with checkpatch.pl as Russell suggested. I would appreciate it if you could look through the patch again and give comments since the patch looks somewhat different. I can add patch for Kconfig/Makefile

Re: [PATCH/HP7XX] - Add combined LCD / BL driver for platform HP Jornada 7xx handhelds

Kristoffer Ericson wrote: Oki, here is attempt #2 (btw, new mail or just keep thread?) Tested to build and checkpatch. diff --git a/drivers/video/backlight/jornada720_bllcd.c b/drivers/video/backlight/jornada720_bllcd.c +static int jornada_bl_update_status(struct backlight_device *dev)

Re: [PATCH][drivers/scsi/u14-34f.c] duplicate test 'SCpnt-sc_data_direction == DMA_FROM_DEVICE'

James Bottomley wrote: On Mon, 2008-02-04 at 23:36 +0100, Roel Kluin wrote: Note the duplicate test 'SCpnt-sc_data_direction == DMA_FROM_DEVICE' - if (SCpnt-sc_data_direction == DMA_FROM_DEVICE) { + if (SCpnt-sc_data_direction == DMA_TO_DEVICE) { cpp-xdir = DTD_IN; return

Re: [PATCH][drivers/misc/thinkpad_acpi.c] duplicate test if (level TP_EC_FAN_FULLSPEED)

Greg KH wrote: On Tue, Feb 05, 2008 at 09:34:54AM +0100, Roel Kluin wrote: Henrique de Moraes Holschuh wrote: On Tue, 05 Feb 2008, Roel Kluin wrote: Roland Dreier wrote: Note the duplicate test 'if (level TP_EC_FAN_FULLSPEED)'. should this be replaced by Actually I suspect one

[PATCH][drivers/usb/serial/ftdi_sio.c] add missing '|'

add missing '|' Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index 90dcc62..2173561 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -394,7 +394,7 @@ static const char *ftdi_chip_name

Re: [PATCH][drivers/misc/thinkpad_acpi.c] duplicate test if (level & TP_EC_FAN_FULLSPEED)

Henrique de Moraes Holschuh wrote: > On Tue, 05 Feb 2008, Roel Kluin wrote: >> Roland Dreier wrote: >>> > /* safety net should the EC not support AUTO >>> > * or FULLSPEED mode bits and just ignore them */ >>> >

Re: [PATCH][drivers/scsi/u14-34f.c] duplicate test 'SCpnt->sc_data_direction == DMA_FROM_DEVICE'

[EMAIL PROTECTED] wrote: > Good to know that somebody still uses the Ultrastor 14f board :). > Yes, this typo was introduced by somebody doing massive editing to all > scsi drivers long ago. > Cheers, > --db Actually, I do not own a Ultrastor 14f board. I found this by searching for if (test)

Re: [PATCH][drivers/scsi/u14-34f.c] duplicate test 'SCpnt-sc_data_direction == DMA_FROM_DEVICE'

[EMAIL PROTECTED] wrote: Good to know that somebody still uses the Ultrastor 14f board :). Yes, this typo was introduced by somebody doing massive editing to all scsi drivers long ago. Cheers, --db Actually, I do not own a Ultrastor 14f board. I found this by searching for if (test) ...

Re: [PATCH][drivers/misc/thinkpad_acpi.c] duplicate test if (level TP_EC_FAN_FULLSPEED)

Henrique de Moraes Holschuh wrote: On Tue, 05 Feb 2008, Roel Kluin wrote: Roland Dreier wrote: /* safety net should the EC not support AUTO * or FULLSPEED mode bits and just ignore them */ if (level TP_EC_FAN_FULLSPEED

[PATCH][drivers/misc/thinkpad_acpi.c] duplicate test if (level & TP_EC_FAN_FULLSPEED)

et the fan level. And as thinkpad-acpi was leaving these set to zero, it would stop(!) the fan, which is Not A Good Thing. So, as a safety net, we now make sure to also set the fan level part of the HFSP register to speed 7 for full-speed, and a minimum of speed 4 for auto mode. -- second TP_EC_FAN_F

[PATCH][drivers/scsi/u14-34f.c] duplicate test 'SCpnt->sc_data_direction == DMA_FROM_DEVICE'

rom the memory to the device DMA_FROM_DEVICE = PCI_DMA_FROMDEVICEdata is coming from the device to the Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/u14-34f.c b/drivers/scsi/u14-34f.c index 662c004..1e704

[PATCH][drivers/misc/thinkpad_acpi.c] duplicate test 'if (level & TP_EC_FAN_FULLSPEED)'

in drivers/misc/thinkpad_acpi.c, lines 4137-4142 it reads: /* safety net should the EC not support AUTO * or FULLSPEED mode bits and just ignore them */ if (level & TP_EC_FAN_FULLSPEED) level |= 7; /* safety min speed 7

[drivers/scsi/NCR53C9x.c] remove duplication for family_code == 0x00

(family_code == 0x00) { if ((version & 7) == 2) esp->erev = fas100a; /* NCR53C9X */ else esp->erev = espunknown; Note the duplication of test 'if(family_code == 0x00)' and lines below Signed-off-by

[drivers/misc/thinkpad_acpi.c] duplicate test if (level & TP_EC_FAN_FULLSPEED)

in drivers/misc/thinkpad_acpi.c: 4137-4142 it reads: /* safety net should the EC not support AUTO * or FULLSPEED mode bits and just ignore them */ if (level & TP_EC_FAN_FULLSPEED) level |= 7; /* safety min speed 7 */

  1   2   3   >