* RE: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
@ 2001-05-30 19:34 Khachaturov, Vassilii
2001-05-31 2:36 ` Keith Owens
0 siblings, 1 reply; 5+ messages in thread
From: Khachaturov, Vassilii @ 2001-05-30 19:34 UTC (permalink / raw)
To: 'Mark Hahn', 'Martin Mares'
Cc: 'Alan Cox', 'Linus Torvalds', 'lkml'
[Updated patch is in the end of this mail]
Thanks, Mark!
> submit patches as text in your message, since people want
> to read them, and not waste time saving to a file, etc.
> also, explain patches: who is vid 0x12d4, how did you get
> the information, what does it effect, etc.
BTW I noticed a funny thing: the file devlist.h I tried to
patch doesn't always exist - as it gets built from the file
pci.ids in the same directory. Noone complained on that :)
What I don't understand is why pci_ids.h doesn't get
generated from pci.ids as well.
So, here's the new patch, sent along also to the pci.ids
maintainer, along with the required info.
12d4 was DGM&S. Then DGM&S was aquired by Comverse, and
later the corresponding activities (and the same PCI boards
manufacturing) went to Comverse spinoff Ulticom. So, in fact,
Ulticom is just DGM&S under a different name and controlled
by Comverse. I guess the PCI vendor registry should get
updated at some point, but I thought it could be a great
thing if Linux knew it ahead. (Currently reported by the
PCI driver "DGM&S" is obsolete - such entity doesn't exist
any more). Naturally, I have got this info being a
Comverse employee.
This patch only has effect on kernel PCI driver reporting
on the 12d4 vendor ID. There is no Linux kernel code which
supports the corresponding SS7 signalling boards.
Kind regards,
Vassilii
--- /usr/src/linux-2.4.5/include/linux/pci_ids.h Wed May 16 13:25:39
2001
+++ pci_ids.h Wed May 30 14:55:01 2001
@@ -1199,6 +1199,8 @@
#define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2
#define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018
+#define PCI_VENDOR_ID_ULTICOM 0x12d4 /* Formerly DGM&S */
+
#define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST4 0x0031
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST8 0x0021
--- /usr/src/linux-2.4.5/drivers/pci/pci.ids Sat May 19 20:49:14 2001
+++ pci.ids Wed May 30 14:54:50 2001
@@ -3204,7 +3204,7 @@
002c VTNT2
00a0 ITNT2
12d3 Vingmed Sound A/S
-12d4 DGM&S
+12d4 Ulticom (Formerly DGM&S)
12d5 Equator Technologies
12d6 Analogic Corp
12d7 Biotronic SRL
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
2001-05-30 19:34 [PATCH] 2.4.x: update for PCI vendor id 0x12d4 Khachaturov, Vassilii
@ 2001-05-31 2:36 ` Keith Owens
2001-05-31 2:55 ` Jeff Garzik
0 siblings, 1 reply; 5+ messages in thread
From: Keith Owens @ 2001-05-31 2:36 UTC (permalink / raw)
To: Khachaturov, Vassilii; +Cc: 'Martin Mares', 'lkml'
On Wed, 30 May 2001 15:34:17 -0400,
"Khachaturov, Vassilii" <Vassilii.Khachaturov@comverse.com> wrote:
>BTW I noticed a funny thing: the file devlist.h I tried to
>patch doesn't always exist - as it gets built from the file
>pci.ids in the same directory. Noone complained on that :)
drivers/pci/ devlist.h, classlist.h and gen-devlist are the generated
files. Add them to your "don't diff" list when generating patches.
>What I don't understand is why pci_ids.h doesn't get
>generated from pci.ids as well.
Leave that question for Martin.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
2001-05-31 2:36 ` Keith Owens
@ 2001-05-31 2:55 ` Jeff Garzik
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2001-05-31 2:55 UTC (permalink / raw)
To: Keith Owens; +Cc: Khachaturov, Vassilii, 'Martin Mares', 'lkml'
> "Khachaturov, Vassilii" <Vassilii.Khachaturov@comverse.com> wrote:
> >What I don't understand is why pci_ids.h doesn't get
> >generated from pci.ids as well.
Although they are similar, you cannot reliably generate useable C
constants from english words in the PCI id list...
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024 |
MandrakeSoft |
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH] 2.4.x: update for PCI vendor id 0x12d4
@ 2001-05-31 15:31 Khachaturov, Vassilii
0 siblings, 0 replies; 5+ messages in thread
From: Khachaturov, Vassilii @ 2001-05-31 15:31 UTC (permalink / raw)
To: 'Jeff Garzik', 'Martin Mares', Keith Owens
Cc: 'Alan Cox', 'Linus Torvalds', 'lkml'
> From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]
>
> > "Khachaturov, Vassilii" <Vassilii.Khachaturov@comverse.com> wrote:
> > >What I don't understand is why pci_ids.h doesn't get
> > >generated from pci.ids as well.
>
> Although they are similar, you cannot reliably generate useable C
> constants from english words in the PCI id list...
I agree. Still, right now the update of the 2 is independant. Do you think
that
merging the C constant names (with the common prefix stripped)
into the PCI id list so that there's a single source to control it would be
better?
It's also possible to apply an heuristic to only store "exception" C names
there - just take the 1st word and make it uppercase:
pci.ids:
1043 Asustek Computer, Inc.
would automatically map into what it is now:
pci_ids.h
#define PCI_VENDOR_ID_ASUSTEK 0x1043
whereas for 0x1042 one would have to change in the pci.ids:
1042 Micron
1000 FDC 37C665
1001 37C922
3000 Samurai_0
3010 Samurai_1
3020 Samurai_IDE
into
1042{PCTECH} Micron
1000{RZ1000} FDC 37C665
1001{RZ1001} 37C922
3000 Samurai_0
3010 Samurai_1
3020 Samurai_IDE
to generate in the .h
#define PCI_VENDOR_ID_PCTECH 0x1042
#define PCI_DEVICE_ID_PCTECH_RZ1000 0x1000
#define PCI_DEVICE_ID_PCTECH_RZ1001 0x1001
#define PCI_DEVICE_ID_PCTECH_SAMURAI_0 0x3000
#define PCI_DEVICE_ID_PCTECH_SAMURAI_1 0x3010
#define PCI_DEVICE_ID_PCTECH_SAMURAI_IDE 0x3020
You get the idea... This way it is also very easy to look up the .ids file
and see instantly where the names mismatch severely.
Does this make sense? If you think it does (say so), I can easily make this
into the tree of your choice in a backward-compatible way. There'll be an
option to generate the older .ids, too, for easier merge back into the 2.2
series.
Vassilii
P.S. Even if you don't think the merge of the 2 files is worth it, don't
forget to apply the 12d4 patch...
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] 2.4.x: update for PCI vendor id 0x12d4
@ 2001-05-25 18:03 Khachaturov, Vassilii
0 siblings, 0 replies; 5+ messages in thread
From: Khachaturov, Vassilii @ 2001-05-25 18:03 UTC (permalink / raw)
To: linux-kernel; +Cc: 'torvalds@transmeta.com', alan
[-- Attachment #1: Type: text/plain, Size: 209 bytes --]
This is my 1st attempt to submit a patch here - flames welcome if I did smth
wrong...
It was done across 2.4.2, but it works safely against 2.4.4 as well.
<<pci_vendor_12d4.patch>>
Kind regards,
Vassilii
[-- Attachment #2: pci_vendor_12d4.patch --]
[-- Type: application/octet-stream, Size: 753 bytes --]
--- /usr/src/linux-2.4.2/include/linux/pci_ids.h Sat Feb 3 15:48:00 2001
+++ pci_ids.h Fri May 25 13:15:51 2001
@@ -1110,6 +1110,8 @@
#define PCI_VENDOR_ID_NVIDIA_SGS 0x12d2
#define PCI_DEVICE_ID_NVIDIA_SGS_RIVA128 0x0018
+#define PCI_VENDOR_ID_ULTICOM 0x12d4 /* Formerly DGM&S */
+
#define PCI_SUBVENDOR_ID_CHASE_PCIFAST 0x12E0
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST4 0x0031
#define PCI_SUBDEVICE_ID_CHASE_PCIFAST8 0x0021
--- /usr/src/linux-2.4.2/drivers/pci/devlist.h Tue Mar 27 16:10:22 2001
+++ devlist.h Fri May 25 13:35:50 2001
@@ -3733,7 +3733,7 @@
VENDOR(12d3,"Vingmed Sound A/S")
ENDVENDOR()
-VENDOR(12d4,"DGM&S")
+VENDOR(12d4,"Ulticom (formerly DGM&S)")
ENDVENDOR()
VENDOR(12d5,"Equator Technologies")
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-05-31 15:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-05-30 19:34 [PATCH] 2.4.x: update for PCI vendor id 0x12d4 Khachaturov, Vassilii
2001-05-31 2:36 ` Keith Owens
2001-05-31 2:55 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2001-05-31 15:31 Khachaturov, Vassilii
2001-05-25 18:03 Khachaturov, Vassilii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox