public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Zwane Mwaikambo <zwane@linuxpower.ca>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Buggy PCI drivers - do not mark pci_device_id as discardable data
Date: Tue, 9 Sep 2003 22:33:47 +0100	[thread overview]
Message-ID: <20030909223347.U4216@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1063142578.30981.22.camel@dhcp23.swansea.linux.org.uk>; from alan@lxorguk.ukuu.org.uk on Tue, Sep 09, 2003 at 10:22:59PM +0100

On Tue, Sep 09, 2003 at 10:22:59PM +0100, Alan Cox wrote:
> On Maw, 2003-09-09 at 22:04, Russell King wrote:
> > I want this to be foolproof, because its me people bug when their cardbus
> > cards oops when they insert the damned things.  If people are happy to
> > ignore this issue, I'm happy to ignore the bug reports.
> > 
> > It basically isn't something I want to deal with, and we need to find a
> > way to stop these stupidities appearing in the first place.
> > 
> > Any ideas?
> 
> You've already got symbols for initdata start and end, just check the 
> pointers in the pci_register code. I guess you want a per platform
> 
> BUG_IF_INIT(x)

That would work for built-in drivers.  We could couple that with an idea
Kai came up with (in private mail) to catch them in modpost.  However,
the problem with modpost is that it gets false positives for these
drivers which explicitly want to discard their module device id tables.

As we currently stand, there seem to be only four drivers which want to
discard their driver id tables.  Is it really worth adding extra code
to the kernel to try to trap these, or just not mark the device id
tables with __initdata or __devinitdata and detect the bad guys with
a grep?

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core

  parent reply	other threads:[~2003-09-09 21:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-09 19:48 Buggy PCI drivers - do not mark pci_device_id as discardable data Russell King
2003-09-09 20:02 ` Zwane Mwaikambo
2003-09-09 20:59   ` Russell King
2003-09-09 21:04   ` Russell King
2003-09-09 21:22     ` Alan Cox
2003-09-09 21:28       ` Zwane Mwaikambo
2003-09-09 21:33       ` Russell King [this message]
2003-09-09 20:14 ` Dave Jones
2003-09-09 20:57   ` Russell King
  -- strict thread matches above, loose matches on Subject: below --
2003-09-10  3:35 agpgart support for intel SHG2 motherboard, serverworks chipset Greg KH
2003-09-09 23:12 ` Buggy PCI drivers - do not mark pci_device_id as discardable data Matt Domsch
2003-09-10  4:24   ` Greg KH
2003-09-10  9:31     ` Matt Domsch
2003-09-10 17:17       ` Matt Domsch
2003-09-11 21:20         ` Greg KH

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=20030909223347.U4216@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@linuxpower.ca \
    /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