From: Franck Bui-Huu <redacted>
This bug has been introduced by commit:
a536093a2f07007aa572e922752b7491b9ea8ff2
This commit fixed the big-endian case but broke the little-endian one.
This patch revert the previous change and swap the definition of
FB_BIT_NR() macro between big and little endian. It should work for
both endianess now.
Signed-off-by: Franck Bui-Huu <redacted>
---
This is the most obvious fix for me although it's a bit weird
that bit ordering depend on platform endianess. I don't know
fb code so I prefer submitting this trivial fix rather than
breaking every thing else ;)
drivers/video/cfbimgblt.c | 4 ++--
include/linux/fb.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
@@ -168,7 +168,7 @@ static inline void slow_imageblit(constwhile(j--){l--;-color=(*s&(1<<l))?fgcolor:bgcolor;+color=(*s&(1<<FB_BIT_NR(l)))?fgcolor:bgcolor;val|=FB_SHIFT_HIGH(color,shift);/* Did the bitshift spill bits to the next long? */
From: Andrew Morton <hidden> Date: 2006-11-03 18:59:14
On Fri, 03 Nov 2006 15:55:34 +0100
Franck Bui-Huu [off-list ref] wrote:
From: Franck Bui-Huu <redacted>
This bug has been introduced by commit:
a536093a2f07007aa572e922752b7491b9ea8ff2
This commit fixed the big-endian case but broke the little-endian one.
This patch revert the previous change and swap the definition of
FB_BIT_NR() macro between big and little endian. It should work for
both endianess now.
I get worried when I see the word "should" in a changelog.
quoted hunk
---
This is the most obvious fix for me although it's a bit weird
that bit ordering depend on platform endianess. I don't know
fb code so I prefer submitting this trivial fix rather than
breaking every thing else ;)
drivers/video/cfbimgblt.c | 4 ++--
include/linux/fb.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
And that swaps the little-endian and bit-endian implementations of
FB_BIT_NR(). So if it was previously broken on big-endian and was working
on little-endian then it's presumably now broken on little-endian and
working on big-endian. Or something.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
On Fri, 03 Nov 2006 15:55:34 +0100
Franck Bui-Huu [off-list ref] wrote:
quoted
From: Franck Bui-Huu <redacted>
This bug has been introduced by commit:
a536093a2f07007aa572e922752b7491b9ea8ff2
This commit fixed the big-endian case but broke the little-endian one.
This patch revert the previous change and swap the definition of
FB_BIT_NR() macro between big and little endian. It should work for
both endianess now.
I get worried when I see the word "should" in a changelog.
The change log is incorrect, sorry. I should have said:
"""
Commit a536093a2f07007aa572e922752b7491b9ea8ff2 fixed only the big
endian case but left the little endian one broken.
To fix this for both endianess, this patch reverts the previous change
and swaps the little-endian and bit-endian implementations of
FB_BIT_NR().
"""
I only tested this patch on a little endian machine only. But the code
is the same for big endian platform, so I presume that it's still
working. What make me doubt is the change log of the initial fix:
"""
This patch may deserve to go to the stable tree. The code has already been
well tested in little-endian machines. It's only in big-endian where there is
uncertainty and Herbert confirmed that this is the correct way to go.
It should not introduce regressions.
"""
It said that the code was well tested on little endian... On the other
hand if you look at the change log of commit
81d3e147ec9ffc6ef04b5f05afa4bef22487b32b, it said
"""
Fix possible endian bug(?) when bit testing in slow_imageblit(). This
function is rarely called (only if (width * bpp) % 32 != 0) thus the bug is
not triggered.
"""
Notice how it sounds unsure. Actually I don't know if it has been tested at all.
quoted
---
This is the most obvious fix for me although it's a bit weird
that bit ordering depend on platform endianess. I don't know
fb code so I prefer submitting this trivial fix rather than
breaking every thing else ;)
drivers/video/cfbimgblt.c | 4 ++--
include/linux/fb.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
And that swaps the little-endian and bit-endian implementations of
FB_BIT_NR(). So if it was previously broken on big-endian and was working
on little-endian then it's presumably now broken on little-endian and
working on big-endian. Or something.
Sorry my own fault, the change log of this patch is not correct. See
above. Please tell me if you want me to resend this patch with the
change log fixed.
Thanks
--
Franck
From: Franck Bui-Huu <redacted>
It seems that this piece of code has already been fixed twice...
The first fix has been made by the following commit:
81d3e147ec9ffc6ef04b5f05afa4bef22487b32b
by introducing FB_BIT_NR() macro to fix a 'potential' endianess
bug. It appears that change was broken for big endian platforms,
but I suspect it was for little-endian ones too.
Then a second fix has been made to fix the previous change for
big-endian platform, see commit:
a536093a2f07007aa572e922752b7491b9ea8ff2
This commit actually reverted the first fix and thus makes the
big-endian case works but leaves the little-endian case broken.
Therefore it seems that the very first state was broken only
on little-endian platform...
This patch is the third and hopefully the last attempt to fix
this bug correctly. It restores the first fix _and_ swaps the
little-endian and bit-endian implementations of FB_BIT_NR().
Now, it should work for both endianness but has been tested on
little-endian machine only.
Signed-off-by: Franck Bui-Huu <redacted>
---
Same patch with change log updated.
drivers/video/cfbimgblt.c | 4 ++--
include/linux/fb.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
@@ -168,7 +168,7 @@ static inline void slow_imageblit(constwhile(j--){l--;-color=(*s&(1<<l))?fgcolor:bgcolor;+color=(*s&(1<<FB_BIT_NR(l)))?fgcolor:bgcolor;val|=FB_SHIFT_HIGH(color,shift);/* Did the bitshift spill bits to the next long? */