From: Jeff Garzik <jgarzik@pobox.com>
To: Grant Coady <grant_lkml@dodo.com.au>
Cc: Greg KH <greg@kroah.com>, Grant Coady <lkml@dodo.com.au>,
"Gaston, Jason D" <jason.d.gaston@intel.com>,
mj@ucw.cz, akpm@osdl.org, linux-kernel@vger.kernel.org,
Greg KH <gregkh@suse.de>
Subject: Re: [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R
Date: Sun, 11 Sep 2005 04:51:10 -0400 [thread overview]
Message-ID: <4323EFFE.2040102@pobox.com> (raw)
In-Reply-To: <pfn7i1ll7g5bs8sm8kq0md33f8khsujrbf@4ax.com>
Grant Coady wrote:
> Just ran the discovery script on 2.6.13.mm2, there's roughly 1609
> symbols unused in pci_ids.h, another 1030 are defined throughout the
> source tree, leaving 729 in pci_ids.h. Total unique symbols is 1030.
> Not counted are macro defined symbols:
>
> PCI_DEVICE_ID_##id
> PCI_DEVICE_ID_##v##_##d
> PCI_DEVICE_ID_BROOKTREE_##chip
> PCI_VENDOR_ID_##v
>
> from:
>
> linux-2.6.13-mm2/drivers/video/cirrusfb.c
> linux-2.6.13-mm2/sound/oss/ymfpci.c
> linux-2.6.13-mm2/sound/pci/bt87x.c
>
>
> What is the goal here? Is a comment stripped, non-duplicate pci_ids.h
> with a reference to source site okay?
Not sure what your last question is asking. The current goal is to
remove completely unused symbols from pci_ids.h, nothing more.
> Should the various distributed defines be collected to the one header
> file and that header be include'd to those files? It seems pci_ids.h
> is redundant.
pci_ids.h should be the place where PCI IDs (class, vendor, device) are
collected.
Long term, we should be able to trim a lot of device ids, since they are
usually only used in one place.
Jeff
next prev parent reply other threads:[~2005-09-11 8:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-29 21:55 [PATCH 2.6.13-rc4 1/1] pci_ids: patch for Intel ICH7R Gaston, Jason D
2005-07-29 22:21 ` Jeff Garzik
2005-07-29 22:26 ` Andrew Morton
2005-07-29 22:29 ` Jeff Garzik
2005-07-30 2:28 ` Grant Coady
2005-07-30 3:52 ` Jeff Garzik
2005-07-30 4:54 ` Grant Coady
2005-08-11 19:22 ` Jeff Garzik
2005-09-11 3:11 ` Greg KH
2005-09-11 8:00 ` Grant Coady
2005-09-11 8:51 ` Jeff Garzik [this message]
2005-09-11 20:40 ` Grant Coady
2005-09-13 6:46 ` Grant
2005-09-13 7:03 ` Greg KH
2005-09-13 8:14 ` Grant Coady
2005-11-02 5:38 ` Grant Coady
2005-07-30 9:42 ` Grant Coady
2005-08-11 19:23 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2005-07-29 16:24 Jason Gaston
2005-07-29 21:49 ` Jeff Garzik
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=4323EFFE.2040102@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=grant_lkml@dodo.com.au \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=jason.d.gaston@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@dodo.com.au \
--cc=mj@ucw.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 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.