* [PATCH] video/smscufx: fix line counting in fb_write @ 2012-04-20 22:11 Alexander Holler 2012-04-21 11:26 ` Alexander Holler 0 siblings, 1 reply; 6+ messages in thread From: Alexander Holler @ 2012-04-20 22:11 UTC (permalink / raw) To: linux-kernel; +Cc: Steve Glendinning, linux-fbdev, Alexander Holler Line 0 and 1 were both written to line 0 (on the display) and all subsequent lines had an offset of -1. The result was that the last line on the display was never overwritten by writes to /dev/fbN. The origin of this bug seems to have been udlfb. Signed-off-by: Alexander Holler <holler@ahsoftware.de> --- drivers/video/smscufx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c index ccbfef5..1e1e2d2 100644 --- a/drivers/video/smscufx.c +++ b/drivers/video/smscufx.c @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info, const char __user *buf, result = fb_sys_write(info, buf, count, ppos); if (result > 0) { - int start = max((int)(offset / info->fix.line_length) - 1, 0); + int start = max((int)(offset / info->fix.line_length), 0); int lines = min((u32)((result / info->fix.line_length) + 1), (u32)info->var.yres); -- 1.7.6.5 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] video/smscufx: fix line counting in fb_write 2012-04-20 22:11 [PATCH] video/smscufx: fix line counting in fb_write Alexander Holler @ 2012-04-21 11:26 ` Alexander Holler 2012-05-13 12:47 ` Florian Tobias Schandinat 0 siblings, 1 reply; 6+ messages in thread From: Alexander Holler @ 2012-04-21 11:26 UTC (permalink / raw) To: Alexander Holler; +Cc: linux-kernel, linux-fbdev Hello, as for the patch for udlfb, I forgot to mention that this is a candidate for all stable trees 3.2 and above. Btw., the address of the maintainer doesn't seem to be valid anymore. Regards, Alexander Am 21.04.2012 00:11, schrieb Alexander Holler: > Line 0 and 1 were both written to line 0 (on the display) and all subsequent > lines had an offset of -1. The result was that the last line on the display > was never overwritten by writes to /dev/fbN. > > The origin of this bug seems to have been udlfb. > > Signed-off-by: Alexander Holler<holler@ahsoftware.de> Cc: stable@vger.kernel.org > --- > drivers/video/smscufx.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c > index ccbfef5..1e1e2d2 100644 > --- a/drivers/video/smscufx.c > +++ b/drivers/video/smscufx.c > @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info, const char __user *buf, > result = fb_sys_write(info, buf, count, ppos); > > if (result> 0) { > - int start = max((int)(offset / info->fix.line_length) - 1, 0); > + int start = max((int)(offset / info->fix.line_length), 0); > int lines = min((u32)((result / info->fix.line_length) + 1), > (u32)info->var.yres); > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] video/smscufx: fix line counting in fb_write 2012-04-21 11:26 ` Alexander Holler @ 2012-05-13 12:47 ` Florian Tobias Schandinat 2012-07-02 21:25 ` Alexander Holler 0 siblings, 1 reply; 6+ messages in thread From: Florian Tobias Schandinat @ 2012-05-13 12:47 UTC (permalink / raw) To: Alexander Holler; +Cc: linux-kernel, linux-fbdev Hi Alexander, On 04/21/2012 11:26 AM, Alexander Holler wrote: > Hello, > > as for the patch for udlfb, I forgot to mention that this is a candidate > for all stable trees 3.2 and above. > > Btw., the address of the maintainer doesn't seem to be valid anymore. it is better to cc me on patches to the framebuffer subsystem for such cases. I don't have much free time so it's rare that I come around to dig in the mailing list. > > Regards, > > Alexander > > Am 21.04.2012 00:11, schrieb Alexander Holler: >> Line 0 and 1 were both written to line 0 (on the display) and all >> subsequent >> lines had an offset of -1. The result was that the last line on the >> display >> was never overwritten by writes to /dev/fbN. >> >> The origin of this bug seems to have been udlfb. >> >> Signed-off-by: Alexander Holler<holler@ahsoftware.de> > > Cc: stable@vger.kernel.org Patch looks good to me but can be made simpler. > >> --- >> drivers/video/smscufx.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c >> index ccbfef5..1e1e2d2 100644 >> --- a/drivers/video/smscufx.c >> +++ b/drivers/video/smscufx.c >> @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info, >> const char __user *buf, >> result = fb_sys_write(info, buf, count, ppos); >> >> if (result> 0) { >> - int start = max((int)(offset / info->fix.line_length) - 1, 0); >> + int start = max((int)(offset / info->fix.line_length), 0); the cast to int as well as the max is superfluous without the -1 as the value can no longer be negative. >> int lines = min((u32)((result / info->fix.line_length) + 1), >> (u32)info->var.yres); >> > Best regards, Florian Tobias Schandinat ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] video/smscufx: fix line counting in fb_write 2012-05-13 12:47 ` Florian Tobias Schandinat @ 2012-07-02 21:25 ` Alexander Holler 2012-07-26 17:26 ` Florian Tobias Schandinat 0 siblings, 1 reply; 6+ messages in thread From: Alexander Holler @ 2012-07-02 21:25 UTC (permalink / raw) To: Florian Tobias Schandinat; +Cc: linux-kernel, linux-fbdev Hi Florian, sorry for the late answer. Am 13.05.2012 14:47, schrieb Florian Tobias Schandinat: > Hi Alexander, > > On 04/21/2012 11:26 AM, Alexander Holler wrote: >> Hello, >> >> as for the patch for udlfb, I forgot to mention that this is a candidate >> for all stable trees 3.2 and above. >> >> Btw., the address of the maintainer doesn't seem to be valid anymore. > > it is better to cc me on patches to the framebuffer subsystem for such > cases. I don't have much free time so it's rare that I come around to > dig in the mailing list. > >> >> Regards, >> >> Alexander >> >> Am 21.04.2012 00:11, schrieb Alexander Holler: >>> Line 0 and 1 were both written to line 0 (on the display) and all >>> subsequent >>> lines had an offset of -1. The result was that the last line on the >>> display >>> was never overwritten by writes to /dev/fbN. >>> >>> The origin of this bug seems to have been udlfb. >>> >>> Signed-off-by: Alexander Holler<holler@ahsoftware.de> >> >> Cc: stable@vger.kernel.org > > Patch looks good to me but can be made simpler. > >> >>> --- >>> drivers/video/smscufx.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c >>> index ccbfef5..1e1e2d2 100644 >>> --- a/drivers/video/smscufx.c >>> +++ b/drivers/video/smscufx.c >>> @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info, >>> const char __user *buf, >>> result = fb_sys_write(info, buf, count, ppos); >>> >>> if (result> 0) { >>> - int start = max((int)(offset / info->fix.line_length) - 1, 0); >>> + int start = max((int)(offset / info->fix.line_length), 0); > > the cast to int as well as the max is superfluous without the -1 as the > value can no longer be negative. I had that impression too, but I wanted to change as less as possible, so I didn't had the need to check types and (their) sizes for possible overflows or such. I was lazy and just wanted to fix that one bug. ;) > >>> int lines = min((u32)((result / info->fix.line_length) + 1), >>> (u32)info->var.yres); >>> Regards, Alexander ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] video/smscufx: fix line counting in fb_write 2012-07-02 21:25 ` Alexander Holler @ 2012-07-26 17:26 ` Florian Tobias Schandinat 2012-07-30 19:28 ` Alexander Holler 0 siblings, 1 reply; 6+ messages in thread From: Florian Tobias Schandinat @ 2012-07-26 17:26 UTC (permalink / raw) To: Alexander Holler; +Cc: linux-kernel, linux-fbdev On 07/02/2012 09:25 PM, Alexander Holler wrote: > Hi Florian, > > sorry for the late answer. > > Am 13.05.2012 14:47, schrieb Florian Tobias Schandinat: >> Hi Alexander, >> >> On 04/21/2012 11:26 AM, Alexander Holler wrote: >>> Hello, >>> >>> as for the patch for udlfb, I forgot to mention that this is a candidate >>> for all stable trees 3.2 and above. >>> >>> Btw., the address of the maintainer doesn't seem to be valid anymore. >> >> it is better to cc me on patches to the framebuffer subsystem for such >> cases. I don't have much free time so it's rare that I come around to >> dig in the mailing list. >> >>> >>> Regards, >>> >>> Alexander >>> >>> Am 21.04.2012 00:11, schrieb Alexander Holler: >>>> Line 0 and 1 were both written to line 0 (on the display) and all >>>> subsequent >>>> lines had an offset of -1. The result was that the last line on the >>>> display >>>> was never overwritten by writes to /dev/fbN. >>>> >>>> The origin of this bug seems to have been udlfb. >>>> >>>> Signed-off-by: Alexander Holler<holler@ahsoftware.de> >>> >>> Cc: stable@vger.kernel.org >> >> Patch looks good to me but can be made simpler. >> >>> >>>> --- >>>> drivers/video/smscufx.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c >>>> index ccbfef5..1e1e2d2 100644 >>>> --- a/drivers/video/smscufx.c >>>> +++ b/drivers/video/smscufx.c >>>> @@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_info *info, >>>> const char __user *buf, >>>> result = fb_sys_write(info, buf, count, ppos); >>>> >>>> if (result> 0) { >>>> - int start = max((int)(offset / info->fix.line_length) - 1, 0); >>>> + int start = max((int)(offset / info->fix.line_length), 0); >> >> the cast to int as well as the max is superfluous without the -1 as the >> value can no longer be negative. > > I had that impression too, but I wanted to change as less as possible, > so I didn't had the need to check types and (their) sizes for possible > overflows or such. I was lazy and just wanted to fix that one bug. ;) Well, as this patch fixes a bug I applied it as is. > >> >>>> int lines = min((u32)((result / info->fix.line_length) + 1), >>>> (u32)info->var.yres); >>>> Best regards, Florian Tobias Schandinat ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] video/smscufx: fix line counting in fb_write 2012-07-26 17:26 ` Florian Tobias Schandinat @ 2012-07-30 19:28 ` Alexander Holler 0 siblings, 0 replies; 6+ messages in thread From: Alexander Holler @ 2012-07-30 19:28 UTC (permalink / raw) To: Florian Tobias Schandinat; +Cc: linux-kernel, linux-fbdev Hello, Am 26.07.2012 19:26, schrieb Florian Tobias Schandinat: > Well, as this patch fixes a bug I applied it as is. Thanks a lot, actually I was more interested to get that one-line-patch for udlfb, because I've discovered that bug using one of those Mimo-LCDs. ;) Are you responsible for that too? Regards, Alexander ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-30 19:29 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-20 22:11 [PATCH] video/smscufx: fix line counting in fb_write Alexander Holler 2012-04-21 11:26 ` Alexander Holler 2012-05-13 12:47 ` Florian Tobias Schandinat 2012-07-02 21:25 ` Alexander Holler 2012-07-26 17:26 ` Florian Tobias Schandinat 2012-07-30 19:28 ` Alexander Holler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox