From: Russell King <rmk+lkml@arm.linux.org.uk>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: New FBDev patch
Date: Sun, 11 Jan 2004 12:09:03 +0000 [thread overview]
Message-ID: <20040111120903.D1931@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.44.0401090035270.17957-100000@phoenix.infradead.org>; from jsimmons@infradead.org on Fri, Jan 09, 2004 at 07:54:50PM +0000
On Fri, Jan 09, 2004 at 07:54:50PM +0000, James Simmons wrote:
> > sizeof(u32) != 32. Proper fix is to place the pseudopalette array
> > inside cfb_info, and dispense with this addition here.
>
> You have to make sure the struct fb_info pseudopalette points to the data
> in cfb_info. Actually only drivers should allocate the pseudopalette at
> boot time if the hardware doesn't support mode change. In the other case
> the pseudopalette should be allocated in set_par.
I respectfully disagree. It is not possible to error out of the set_par()
function - for instance, fb_set_var() contains this code:
if (info->fbops->fb_set_par)
info->fbops->fb_set_par(info);
There isn't any error return checking (so why does fb_set_par return an
int when it isn't used? It's fairly misleading.)
This all means that if the allocation of the pseudo_palette in set_par
fails, there's no way to abort the mode change - you _will_ oops in the
other fbcon layers due to a NULL pseudo_palette pointer.
Plus, we're only talking about an array of 16 32-bit words or 64 bytes.
That's hardly worth the extra code complexity to separately dynamically
allocate.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
WARNING: multiple messages have this Message-ID (diff)
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: New FBDev patch
Date: Sun, 11 Jan 2004 12:09:03 +0000 [thread overview]
Message-ID: <20040111120903.D1931@flint.arm.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.44.0401090035270.17957-100000@phoenix.infradead.org>; from jsimmons@infradead.org on Fri, Jan 09, 2004 at 07:54:50PM +0000
On Fri, Jan 09, 2004 at 07:54:50PM +0000, James Simmons wrote:
> > sizeof(u32) != 32. Proper fix is to place the pseudopalette array
> > inside cfb_info, and dispense with this addition here.
>
> You have to make sure the struct fb_info pseudopalette points to the data
> in cfb_info. Actually only drivers should allocate the pseudopalette at
> boot time if the hardware doesn't support mode change. In the other case
> the pseudopalette should be allocated in set_par.
I respectfully disagree. It is not possible to error out of the set_par()
function - for instance, fb_set_var() contains this code:
if (info->fbops->fb_set_par)
info->fbops->fb_set_par(info);
There isn't any error return checking (so why does fb_set_par return an
int when it isn't used? It's fairly misleading.)
This all means that if the allocation of the pseudo_palette in set_par
fails, there's no way to abort the mode change - you _will_ oops in the
other fbcon layers due to a NULL pseudo_palette pointer.
Plus, we're only talking about an array of 16 32-bit words or 64 bytes.
That's hardly worth the extra code complexity to separately dynamically
allocate.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-01-11 12:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-08 22:03 New FBDev patch James Simmons
2004-01-08 22:03 ` James Simmons
2004-01-08 22:56 ` Moritz Muehlenhoff
2004-01-08 23:05 ` Paul Mundt
2004-01-08 23:12 ` Tomas Szepe
2004-01-08 23:12 ` Tomas Szepe
2004-01-09 0:35 ` James Simmons
2004-01-09 0:35 ` James Simmons
2004-01-10 17:15 ` Re: New FBDev patch (a little report) Javier Villavicencio
2004-01-11 7:35 ` Benjamin Herrenschmidt
2004-01-11 7:42 ` Benjamin Herrenschmidt
2004-01-08 23:26 ` New FBDev patch Russell King
2004-01-08 23:26 ` Russell King
2004-01-09 19:54 ` James Simmons
2004-01-09 19:54 ` James Simmons
2004-01-11 12:09 ` Russell King [this message]
2004-01-11 12:09 ` Russell King
2004-01-09 17:17 ` [Linux-fbdev-devel] " Kronos
2004-01-09 20:06 ` James Simmons
2004-01-09 20:06 ` [Linux-fbdev-devel] " James Simmons
[not found] <1bRBM-5lD-13@gated-at.bofh.it>
[not found] ` <1bSRe-19C-21@gated-at.bofh.it>
2004-01-09 11:27 ` Andreas Theofilu
2004-01-09 14:10 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2004-06-23 18:04 New fbdev patch jsimmons
2004-06-25 14:11 ` Richard Smith
[not found] ` <20040629214850.GC2871@mercury.jahnsnet.de>
2004-06-29 22:27 ` Richard Smith
2004-06-30 16:57 ` jsimmons
2004-07-02 11:01 ` Thomas Jahns
2004-07-05 10:17 ` Thomas Jahns
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=20040111120903.D1931@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=jsimmons@infradead.org \
--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.