lkml.org 
[lkml]   [2004]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.6.8-rc2] intel8x0.c to include CK804 audio support
At Mon, 26 Jul 2004 22:09:11 -0400,
Jeff Garzik wrote:
>
> Andrew Morton wrote:
> > "Andrew Chew" <achew@nvidia.com> wrote:
> >
> >>I sincerely apologize about the mangled patch. I'll be more careful
> >>next time (and check my mailer settings).
> >
> >
> > Is OK - you're in good company ;)
> >
> >
> >>The #ifdef was for consistency (I noticed that there were other IDs
> >>similarly defined in intel8x0.c). I don't see why we'd need it, either.
> >>We should probably remove PCI_DEVICE_ID_NVIDIA_MCP2_AUDIO and
> >>PCI_DEVICE_ID_NVIDIA_MCP3_AUDIO #defines from intel8x0.c as well, as
> >>they're similarly redundant. For that matter, why not remove all of the
> >>PCI_DEVICE_ID_* #defines from the intel8x0.c driver, and make sure the
> >>device IDs are defined in pci_ids.h.
> >>
> >>Want me to submit a patch for that?
> >
> >
> > Let's leave that up to Jeff.
>
> Jaroslav and the ALSA guys... no idea who maintains the ALSA i810 driver.

ALSA team ;)
I included the patch to ALSA tree. Thanks.
Jaroslav will submit the patchset later.

> In any case, I think the device id constants are a waste, and have
> stopped using the *_DEVICE_ID_* constants in my drivers. The vendor id
> is generally common across many drivers, but rarely does one care about
> sharing arbitrary name<->arbitrary id mappings these days, when one
> driver supports so many chips.

Well, I agree in general. It would be still reasonable to define a
const when it appears more than once, though.


Takashi
-
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: 2005-03-22 14:04    [W:0.030 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site