lkml.org 
[lkml]   [2006]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] PCI: restore 2 missing pci ids
Date
Jeff,

On Feb 1, 2006, at 12:00 PM, Jeff Garzik wrote:

> Linux Kernel Mailing List wrote:
>> tree e425ac74afc0b89f3a513290a2dd5e503d974906
>> parent 654143ee3a73b2793350b039a135d9cd3101147b
>> author Mark Rustad <MRustad@mac.com> Fri, 06 Jan 2006 14:47:29 -0800
>> committer Greg Kroah-Hartman <gregkh@suse.de> Wed, 01 Feb 2006
>> 10:00:11 -0800
>> [PATCH] PCI: restore 2 missing pci ids
>> Somewhere between 2.6.14 and 2.6.15-rc3, some PCI ids were apparently
>> removed. The ecc.c module, which is not a part of the kernel.org
>> tree, but
>> included in some distributions, fails to compile.
>> Signed-off-by: Mark Rustad <mrustad@mac.com>
>> Signed-off-by: Andrew Morton <akpm@osdl.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> include/linux/pci_ids.h | 2 ++
>> 1 files changed, 2 insertions(+)
>
> Why was this applied? We could apply these patches all day, and
> get nothing else done. If it's not in the kernel tree, we
> shouldn't be worrying about it. Let the distros patch it in.

Well, I offered the patch because I found that I suddenly needed it.
I did not know why the ids had been removed, but it looks to me like
edac is coming right along and will need the ids itself, so I sent
the patch off.

Frankly, I was surprised that the patch was so quickly accepted. I
perceive some difference of opinion on how PCI ids should be handled.
Is there a consensus on a better way to handle ids? Why were the ids
removed in the first place? THAT was worse than wasted effort.

--
Mark Rustad, MRustad@mac.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-02 06:15    [W:0.041 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site