linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-fbdev-devel@lists.sourceforge.net, jsimmons@infradead.org
Subject: Re: [PATCH] kyrofb support
Date: Tue, 13 Jan 2004 21:28:16 -0500	[thread overview]
Message-ID: <20040114022816.GA9990@linux-sh.org> (raw)
In-Reply-To: <20040113180926.5fdb0824.akpm@osdl.org>

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Tue, Jan 13, 2004 at 06:09:26PM -0800, Andrew Morton wrote:
> Why is kyro_modedb[] and the code which touches it under #ifdef MODULE?
> 
No particular reason, really. I hadn't been following some of the recent fbdev
changes, so I wasn't sure if this was necessary or not (I was using tdfxfb as
a reference when tracking API changes, and noticed that it did the #ifdef
MODULE stuff which it never did earlier). I'll happily drop the #ifdef MODULE
bits if this isn't necessary. James?

> kyrofb_pci_tbl[] cannot be marked __devinitdata - it is linked into
> system-wide PCI tables and will be walked at various times in the kernel. 
> If it is in a discarded section the kernel oopses.
> 
Okay, I'll remove that.

> Shouldn't the module_exit(kyrofb_exit); be inside #ifdef MODULE too?
> 
Yes, I suppose.

> 
> In general, what are the fbdev drivers doing here btw?  It's very strange
> that some core file (fbmem.c) has to "know" about individual card drivers. 
> It should be sufficient for the driver to just register itself with the core
> at the drivers's module_init() time.
> 
This is done for device ordering as far as I recall. Devices listed first on
the command line are numbered first, with the rest coming up in the order that
they're listed in fb_drivers[].

I had some patches against this awhile ago that redid some of this, getting
rid of fb_drivers[], putting ordered devices in a list and logically assigning
IDs based off of that, etc. but still letting the drivers come up on their own
through module_init(). I was planning on working on this for 2.7, as I didn't
have enough time under 2.5.

> Sigh.  Too late to fix that now I guess.

I'll send you another patch for this as soon as I hear back from James or
someone else about the modedb / #ifdef MODULE stuff, I don't see any reason
why it would be required, though.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-01-14  2:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-14  1:33 [PATCH] kyrofb support Paul Mundt
2004-01-14  1:49 ` Andrew Morton
2004-01-15  0:31   ` James Simmons
2004-01-14  2:09 ` Andrew Morton
2004-01-14  2:28   ` Paul Mundt [this message]
2004-01-14 12:45     ` Geert Uytterhoeven
2004-01-15  0:34       ` James Simmons
2004-01-15  0:36     ` James Simmons
2004-01-14  4:58   ` Benjamin Herrenschmidt

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=20040114022816.GA9990@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=akpm@osdl.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).