All of lore.kernel.org
 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 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.