From: Andres Salomon <dilinger@queued.net>
To: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-fbdev-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, adaplas@gmail.com
Subject: Re: [Linux-fbdev-devel] [PATCH 5/15] skeletonfb: check fb_alloc_cmap return value and handle failure properly
Date: Mon, 9 Feb 2009 17:32:00 -0500 [thread overview]
Message-ID: <20090209173200.1122808e@ephemeral> (raw)
In-Reply-To: <20090209072929.29589e5d.krzysztof.h1@poczta.fm>
On Mon, 9 Feb 2009 07:29:29 +0100
Krzysztof Helt <krzysztof.h1@poczta.fm> wrote:
> On Sat, 7 Feb 2009 12:13:02 -0500
> Andres Salomon <dilinger@queued.net> wrote:
>
> >
> > Bad example code, no cookie!
> >
>
> It is even worse than you thought.
Maybe skeletonfb.c should simply be dropped completely? Incorrect
documentation is worse than no documentation. If it's unmaintained,
buggy, and incorrect in many places...
>
> > Signed-off-by: Andres Salomon <dilinger@debian.org>
> > ---
> > drivers/video/skeletonfb.c | 9 ++++++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/skeletonfb.c b/drivers/video/skeletonfb.c
> > index df53365..a439159 100644
> > --- a/drivers/video/skeletonfb.c
> > +++ b/drivers/video/skeletonfb.c
> > @@ -795,8 +795,9 @@ static int __devinit xxxfb_probe(struct pci_dev
> > *dev, if (!retval || retval == 4)
> > return -EINVAL;
> >
> > - /* This has to been done !!! */
> > - fb_alloc_cmap(&info->cmap, cmap_len, 0);
> > + /* This has to be done! */
> > + if (fb_alloc_cmap(&info->cmap, cmap_len, 0))
> > + return -ENOMEM;
> >
>
> The info pointer should be freed before the return here ...
>
> > /*
> > * The following is done in the case of having hardware with a
> > static @@ -820,8 +821,10 @@ static int __devinit xxxfb_probe(struct
> > pci_dev *dev, */
> > /* xxxfb_set_par(info); */
> >
> > - if (register_framebuffer(info) < 0)
> > + if (register_framebuffer(info) < 0) {
> > + fb_dealloc_cmap(&info->cmap);
>
> ... and here.
>
> > return -EINVAL;
> > + }
> > printk(KERN_INFO "fb%d: %s frame buffer device\n", info->node,
> > info->fix.id);
> > pci_set_drvdata(dev, info); /* or platform_set_drvdata(pdev,
> > info) */ --
>
>
> Kind regards,
> Krzysztof
>
>
> ----------------------------------------------------------------------
> Zostan mistrzem parkowania w Bombaju!
> Zagraj >> http://link.interia.pl/f204e
>
prev parent reply other threads:[~2009-02-09 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-07 17:13 [PATCH 5/15] skeletonfb: check fb_alloc_cmap return value and handle failure properly Andres Salomon
2009-02-07 17:13 ` Andres Salomon
2009-02-09 6:29 ` [Linux-fbdev-devel] " Krzysztof Helt
2009-02-09 22:32 ` Andres Salomon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090209173200.1122808e@ephemeral \
--to=dilinger@queued.net \
--cc=adaplas@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=krzysztof.h1@poczta.fm \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.