as we do a strcpy(smdrv_ptr->fb_struct->fix->id, name), and the name here in
sm7xxx_probe is not having any assignment, and which leads to copying of the garbage value
into the id field of the fix struct of fb interface struct. fix it by copying the name before
calling alloc_fbinfo
Signed-off-by: Devendra Naga <[email protected]>
---
Only compile tested
This patch is not tested using the hardware... if any one is having this hardware, i request them to
please test this
drivers/staging/sm7xxfb/sm7xxfb.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 1c1780c..d3957ef 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -798,16 +798,17 @@ static int __devinit smtcfb_pci_probe(struct pci_dev *pdev,
if (err)
return err;
+ sprintf(name, "sm%Xfb", ent->device);
+
sfb = smtc_alloc_fb_info(pdev, name);
+ sfb->chip_id = ent->device;
+
if (!sfb) {
err = -ENOMEM;
goto failed_free;
}
- sfb->chip_id = ent->device;
- sprintf(name, "sm%Xfb", sfb->chip_id);
-
pci_set_drvdata(pdev, sfb);
sm7xx_init_hw();
--
1.7.9.5
On Sat, Aug 04, 2012 at 11:06:12PM +0545, Devendra Naga wrote:
> as we do a strcpy(smdrv_ptr->fb_struct->fix->id, name), and the name here in
> sm7xxx_probe is not having any assignment, and which leads to copying of the garbage value
> into the id field of the fix struct of fb interface struct. fix it by copying the name before
> calling alloc_fbinfo
>
> Signed-off-by: Devendra Naga <[email protected]>
> ---
> Only compile tested
> This patch is not tested using the hardware... if any one is having this hardware, i request them to
> please test this
> drivers/staging/sm7xxfb/sm7xxfb.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
> index 1c1780c..d3957ef 100644
> --- a/drivers/staging/sm7xxfb/sm7xxfb.c
> +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
> @@ -798,16 +798,17 @@ static int __devinit smtcfb_pci_probe(struct pci_dev *pdev,
> if (err)
> return err;
>
> + sprintf(name, "sm%Xfb", ent->device);
> +
> sfb = smtc_alloc_fb_info(pdev, name);
>
> + sfb->chip_id = ent->device;
> +
> if (!sfb) {
Thanks for fixing this, and well done for spotting the bug.
There is a dereference before the check here, but I see you resent
this in another thread. Next time could you respond to the
original with a message which says to not apply it.
regards,
dan carpenter
On Mon, Aug 6, 2012 at 7:57 PM, Dan Carpenter <[email protected]> wrote:
> On Sat, Aug 04, 2012 at 11:06:12PM +0545, Devendra Naga wrote:
>> as we do a strcpy(smdrv_ptr->fb_struct->fix->id, name), and the name here in
>> sm7xxx_probe is not having any assignment, and which leads to copying of the garbage value
>> into the id field of the fix struct of fb interface struct. fix it by copying the name before
>> calling alloc_fbinfo
>>
>> Signed-off-by: Devendra Naga <[email protected]>
>> ---
>> Only compile tested
>> This patch is not tested using the hardware... if any one is having this hardware, i request them to
>> please test this
>> drivers/staging/sm7xxfb/sm7xxfb.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
>> index 1c1780c..d3957ef 100644
>> --- a/drivers/staging/sm7xxfb/sm7xxfb.c
>> +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
>> @@ -798,16 +798,17 @@ static int __devinit smtcfb_pci_probe(struct pci_dev *pdev,
>> if (err)
>> return err;
>>
>> + sprintf(name, "sm%Xfb", ent->device);
>> +
>> sfb = smtc_alloc_fb_info(pdev, name);
>>
>> + sfb->chip_id = ent->device;
>> +
>> if (!sfb) {
>
> Thanks for fixing this, and well done for spotting the bug.
>
Thanks Dan...
> There is a dereference before the check here, but I see you resent
> this in another thread. Next time could you respond to the
> original with a message which says to not apply it.
>
Sure but i have a doubt.
since we do V++ after every change to the sent patch , do we really
need to say that please dont apply this patch and there's one more
patch coming with fix?
> regards,
> dan carpenter
>
>
Thanks,
On Mon, Aug 06, 2012 at 09:57:52PM +0545, Devendra Naga wrote:
> On Mon, Aug 6, 2012 at 7:57 PM, Dan Carpenter <[email protected]> wrote:
> > On Sat, Aug 04, 2012 at 11:06:12PM +0545, Devendra Naga wrote:
> >> as we do a strcpy(smdrv_ptr->fb_struct->fix->id, name), and the name here in
> >> sm7xxx_probe is not having any assignment, and which leads to copying of the garbage value
> >> into the id field of the fix struct of fb interface struct. fix it by copying the name before
> >> calling alloc_fbinfo
> >>
> >> Signed-off-by: Devendra Naga <[email protected]>
> >> ---
> >> Only compile tested
> >> This patch is not tested using the hardware... if any one is having this hardware, i request them to
> >> please test this
> >> drivers/staging/sm7xxfb/sm7xxfb.c | 7 ++++---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
> >> index 1c1780c..d3957ef 100644
> >> --- a/drivers/staging/sm7xxfb/sm7xxfb.c
> >> +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
> >> @@ -798,16 +798,17 @@ static int __devinit smtcfb_pci_probe(struct pci_dev *pdev,
> >> if (err)
> >> return err;
> >>
> >> + sprintf(name, "sm%Xfb", ent->device);
> >> +
> >> sfb = smtc_alloc_fb_info(pdev, name);
> >>
> >> + sfb->chip_id = ent->device;
> >> +
> >> if (!sfb) {
> >
> > Thanks for fixing this, and well done for spotting the bug.
> >
> Thanks Dan...
>
> > There is a dereference before the check here, but I see you resent
> > this in another thread. Next time could you respond to the
> > original with a message which says to not apply it.
> >
> Sure but i have a doubt.
>
> since we do V++ after every change to the sent patch , do we really
> need to say that please dont apply this patch and there's one more
> patch coming with fix?
Yes. The second email very far away from the first one if you are
subscribed to a bunch of high traffic email lists.
I reviewed your patch. I saw the bug. I saw that no one else had
replied to your email. I almost didn't notice the v2 email. It's
annoying. It's not hard to just send an email. "Oops. There is
a bug here. I'll sent a v2."
regards,
dan carpenter