public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Greg KH <greg@kroah.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jaroslav Kysela <perex@suse.cz>, Adam Belay <ambx1@neo.rr.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pnp & pci structure cleanups
Date: Mon, 30 Dec 2002 18:14:36 -0500	[thread overview]
Message-ID: <20021230231436.GA20810@gtf.org> (raw)
In-Reply-To: <20021230225134.GD814@kroah.com>

On Mon, Dec 30, 2002 at 02:51:34PM -0800, Greg KH wrote:
> On Mon, Dec 30, 2002 at 05:50:12PM -0500, Jeff Garzik wrote:
> > On Mon, Dec 30, 2002 at 11:12:40PM +0000, Alan Cox wrote:
> > > On Mon, 2002-12-30 at 22:12, Greg KH wrote:
> > > > Yeah!  Thanks for taking these fields out of pci.h, I really appreciate
> > > > it.  I'll send this on to Linus in a bit.
> > > 
> > > Argh I was using those to implement a test "pci_compatible" driver so
> > > that you could feed new pci idents to old drivers. Oh well 
> > 
> > Note that we need a way to do field replacement of PCI id tables.
> > 
> > I've been harping on that to various ears for years :)
> 
> And USB id tables.  A number of usb drivers are slowly adding module
> paramater hacks to get around this, but it would be really nice to do
> this "correctly" for all drivers.  Somehow...

Surely there is a sysfs path we can devise to do

	echo "add <pci_device_id line>" > /sys/pci/driver/tulip

(or replace that with a file-oriented interface that inputs an entire
table)

and internally just refer to, and update, a kmalloc'd copy of the
original driver's pci (or usb) table.


> > <tangent>
> > I also want to add PCI revision id and mask to struct pci_device_id.
> > </tangent>
> 
> Do any drivers need that today?  It shouldn't be that hard to do it, and
> now is the time :)

Yes.  tulip driver could find this useful, but that's currently a small
case worked around in the driver.

The big and annoying case is 8139C+ (8139cp.c), which has the same
PCI id as old 8139 boards, but additionally includes dramatically new
and better functionality.  The distinguishing characteristic at the
probe phase is the PCI revision id, as the PCI id is the same as another
driver.

	Jeff



  reply	other threads:[~2002-12-30 23:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-29 11:33 [PATCH] pnp & pci structure cleanups Jaroslav Kysela
2002-12-30 22:12 ` Greg KH
2002-12-30 23:12   ` Alan Cox
2002-12-30 22:50     ` Jeff Garzik
2002-12-30 22:51       ` Greg KH
2002-12-30 23:14         ` Jeff Garzik [this message]
2002-12-30 23:59           ` Greg KH
2002-12-31  1:50           ` Alan Cox
2002-12-31  1:47             ` Jeff Garzik
2002-12-31  2:47               ` Alan Cox

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=20021230231436.GA20810@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ambx1@neo.rr.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@suse.cz \
    /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