Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-26 Thread Geert Uytterhoeven 
On Sun, 17 Jul 2005, Jon Smirl wrote:
> On 7/17/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > >
> > > struct fb_super_cmap {
> > >struct fb_cmap cmap;
> > >__u16 red[255];
> > >__u16 blue[255];
> > >__u16 green[255];
> > >__u16 transp[255];
> >   ^^^
> > I assume you meant 256?
> > 
> > > }
> > >
> > > Then adjust the code as need. Have the embedded cmap struct point to
> > > the fields in the super_cmap and the drivers don't have to be changed.
> > 
> > What if your colormap has more than 256 entries?
> 
> I meant 256. Does any hardware exist that takes more that 256 entries? 

1024 was quite common on high-end graphics hardware.

> They are __u16 values but I have never seen hardware that take more
> that __u8 either.

10 bit was quite common on high-end graphics hardware.

IIRC, DEC TGA can do at least one of them.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-17 Thread Jon Smirl 
On 7/17/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> >
> > struct fb_super_cmap {
> >struct fb_cmap cmap;
> >__u16 red[255];
> >__u16 blue[255];
> >__u16 green[255];
> >__u16 transp[255];
>   ^^^
> I assume you meant 256?
> 
> > }
> >
> > Then adjust the code as need. Have the embedded cmap struct point to
> > the fields in the super_cmap and the drivers don't have to be changed.
> 
> What if your colormap has more than 256 entries?

I meant 256. Does any hardware exist that takes more that 256 entries? 
They are __u16 values but I have never seen hardware that take more
that __u8 either.

-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-17 Thread Jan Engelhardt 
>> struct fb_super_cmap {
>>struct fb_cmap cmap;
>>__u16 red[255];
>>__u16 blue[255];
>>__u16 green[255];
>>__u16 transp[255];
>  ^^^
>I assume you meant 256?

Even if it really was 255, it should probably be made 256 to have things 
aligned <-- if that matters.


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-17 Thread Geert Uytterhoeven 
On Sun, 17 Jul 2005, Jon Smirl wrote:
> On 7/17/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > Resource freeing functions should generally be safe to call with NULL 
> > pointers.
> > Why?
> >  - there is some precedence in the kernel for this for deallocation 
> > functions.
> >  - removes the need for callers to check pointers for NULL.
> >  - space is saved overall by less code to test pointers for NULL all over 
> > the place.
> >  - removes possible NULL pointer dereferences when a caller forgot to check.
> > 
> > This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer 
> > argument.
> 
> The fb cmap copde would be a lot simpler if it did everything with a
> single allocation instead of five. Make a super cmap struct:
> 
> struct fb_super_cmap {
>struct fb_cmap cmap;
>__u16 red[255];
>__u16 blue[255];
>__u16 green[255];
>__u16 transp[255];
  ^^^
I assume you meant 256?

> }
> 
> Then adjust the code as need. Have the embedded cmap struct point to
> the fields in the super_cmap and the drivers don't have to be changed.

What if your colormap has more than 256 entries?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-17 Thread Jon Smirl 
On 7/17/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Resource freeing functions should generally be safe to call with NULL 
> pointers.
> Why?
>  - there is some precedence in the kernel for this for deallocation functions.
>  - removes the need for callers to check pointers for NULL.
>  - space is saved overall by less code to test pointers for NULL all over the 
> place.
>  - removes possible NULL pointer dereferences when a caller forgot to check.
> 
> This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer 
> argument.

The fb cmap copde would be a lot simpler if it did everything with a
single allocation instead of five. Make a super cmap struct:

struct fb_super_cmap {
   struct fb_cmap cmap;
   __u16 red[255];
   __u16 blue[255];
   __u16 green[255];
   __u16 transp[255];
}

Then adjust the code as need. Have the embedded cmap struct point to
the fields in the super_cmap and the drivers don't have to be changed.




-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-17 Thread Jesper Juhl 
Resource freeing functions should generally be safe to call with NULL pointers.
Why?
 - there is some precedence in the kernel for this for deallocation functions.
 - removes the need for callers to check pointers for NULL.
 - space is saved overall by less code to test pointers for NULL all over the 
place.
 - removes possible NULL pointer dereferences when a caller forgot to check.

This patch makes  fb_dealloc_cmap()  safe to call with a NULL pointer argument.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 drivers/video/fbcmap.c |3 +++
 1 files changed, 3 insertions(+)

--- linux-2.6.13-rc3-orig/drivers/video/fbcmap.c2005-06-17 
21:48:29.0 +0200
+++ linux-2.6.13-rc3/drivers/video/fbcmap.c 2005-07-17 20:33:43.0 
+0200
@@ -130,6 +130,9 @@ fail:
 
 void fb_dealloc_cmap(struct fb_cmap *cmap)
 {
+   if (unlikely(!cmap))
+   return;
+
kfree(cmap->red);
kfree(cmap->green);
kfree(cmap->blue);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/