/proc/pci deprecation?

It is invaluable during installation, when no lspci is installed yet. I know that I need e100/eepro100 for
'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not have even slightest idea what device 8086:2449 is, whether USB or NIC or VGA or some bridge.

Next problem is that some drivers want to print "user readable" hardware name to user, and although some have its own name database (e100), some use name from pcidev...

If you want, make it user configurable like it was during 2.2.x. But I personally prefer descriptive names and system overview I can parse without having mounted /usr to get working lspci.
Best regards,
Petr Vandrovec [email protected]

at least, the file "modules.pcimap" tells you which modules support these devices, by vendor/model codes. I once developped a little installation script which loaded all the NICs it could by listing /proc/bus/pci/devices and modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I often omit them when I need a very little image. Perhaps having a list of names only for devices supported by the kernel and modules at compile time would be an acceptable compromise ?

Regards,
Willy

I've been using the following script in my install images to find kernel modules for various PCI devices (the mechanism's not perfect, though, I know of at least one module that "doesn't put" its ids in modules.pcimap):

#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin

PCIMAP=/lib/modules/$(uname -r)/modules.pcimap
ALLDEV=$(lspci -n| sed -e 's/^.*:[[:blank:]]\+\([^[:blank:]]\+\).*$/\1/')

if [ -n "$ALLDEV" -a -r $PCIMAP ]; then
for i in $ALLDEV; do

    VENDOR="$(echo $i| cut -d':' -f1)"
    DEVICE="$(echo $i| cut -d':' -f2)"
    MODULE=$(grep "0x0000$VENDOR[[:blank:]]\+0x0000$DEVICE" $PCIMAP| \
      awk '{ print $1; }')
    echo -n "Vendor $VENDOR, dev $DEVICE: "
    if [ -n "$MODULE" ]; then
      echo $MODULE
    else
      echo "(no matching module)"
    fi

done
fi

Tomas Szepe <[email protected]>

One thing that /proc/pci gives you that 'lspci' historically didn't was the correct interrupt setup (because kernel irq routing has nothing to do with the PCI irq config byte on most "interesting" machines).

I don't know if lspci gets that right these days, and the information does exist in /sys, so there is certainly at least the _potential_ of dropping /proc/pci.

Linus

It appears to:

[mochel@tina mochel]$ lspci -v | grep -B 2 IRQ | fgrep -v Subsystem

00:07.4 USB Controller: Advanced Micro Devices [AMD] AMD-765 [Viper] USB (rev 07) (prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 16, IRQ 19
--
00:09.0 Multimedia audio controller: Creative Labs: Unknown device 0004 (rev 03)
Flags: bus master, medium devsel, latency 64, IRQ 17
--
00:09.2 FireWire (IEEE 1394): Creative Labs: Unknown device 4001 (prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 64, IRQ 18
--

00:0b.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
Flags: bus master, medium devsel, latency 64, IRQ 19
--

00:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 01)
Flags: bus master, medium devsel, latency 66, IRQ 16
--
01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5144 (prog-if 00 [VGA])
Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 18

[mochel@tina mochel]$ fgrep -B 1 IRQ /proc/pci
USB Controller: Advanced Micro Devic AMD-766 [ViperPlus] (rev 7).
IRQ 19.
--
Multimedia audio controller: Creative Labs SB Audigy (rev 3).
IRQ 17.
--
FireWire (IEEE 1394): Creative Labs SB Audigy FireWire P (rev 0).
IRQ 18.
--
Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boo (rev 0).
IRQ 19.
--

    Ethernet controller: Intel Corp. 82557/8/9 [Ethernet  (rev 1).
      IRQ 16.

--
VGA compatible controller: ATI Technologies Inc Radeon QD (rev 0).
IRQ 18.

The appended patch both make /proc/pci a compile-time option and deprecates it and the PCI names database. Text has been added to the configuration options, and the top of the file.

The /proc/pci functionality has been moved from drivers/pci/proc.c to drivers/pci/names.c, to make it closer to the PCI names interface. It ain't the prettiest, but it's simple to understand.

-pat

diffstat:

 Documentation/Changes |    4 +
 drivers/pci/Kconfig   |   38 ++++++++---
 drivers/pci/names.c   |  167 +++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/pci/proc.c    |  113 ---------------------------------
 4 files changed, 199 insertions(+), 123 deletions(-)

===== Documentation/Changes 1.28 vs edited =====

@@ -347,6 +347,10 @@
 ----------
 o  <http://powertweak.sourceforge.net/>
 
+pci-utils
+---------
+o  <ftp://ftp.kernel.org/pub/software/utils/pciutils/>
+
 Networking
 **********
 

===== drivers/pci/Kconfig 1.1 vs edited =====

@@ -1,18 +1,38 @@
 #
 # PCI configuration
 #
+
+config PCI_OLD_PROC
+	bool "/proc/pci Interface"
+	depends on PCI && PROC_FS
+	---help---
+	  This option is deprecated.
+
+	  This option provides the traditional /proc/pci interface, which lists
+	  every PCI device and some information extracted from their configuration
+	  space. 
+
+	  This option has been deprecated as of kernel version 2.5.51. The option
+	  and the /proc/pci interface will be removed at a futre date. The 
+	  preferred alternative is to use the lspci(8) utility. Please refer to
+	  Documentation/Changes for information on where to get the latest version.
+
+	  If unsure, say N and use lspci(8) instead. 
+
 config PCI_NAMES
 	bool "PCI device name database"
 	depends on PCI
 	---help---
-	  By default, the kernel contains a database of all known PCI device
-	  names to make the information in /proc/pci, /proc/ioports and
-	  similar files comprehensible to the user. This database increases
-	  size of the kernel image by about 80KB, but it gets freed after the
-	  system boots up, so it doesn't take up kernel memory. Anyway, if you
-	  are building an installation floppy or kernel for an embedded system
-	  where kernel image size really matters, you can disable this feature
-	  and you'll get device ID numbers instead of names.
+	  This option is deprecated. 
+
+	  This option adds a database of PCI device names to make the names of 
+	  PCI devices in /proc/pci and /proc/ioports more sensible. The /proc/pci
+	  interface has been deprecated, and when it is removed, the PCI names 
+	  database will also probably be removed.
+
+	  This option increases the size of the kernel by about 55KB. If 
+	  CONFIG_HOTPLUG is not set, then this memory is freed after the system
+	  boots up. 
 
-	  When in doubt, say Y.
+	  When in doubt, say N.
 

===== drivers/pci/names.c 1.5 vs edited =====

===== drivers/pci/proc.c 1.21 vs edited =====

Just out of interest, where _does_ it get the information? Does it try to do its own irq routing (bad!) or does it do it from /proc/bus/pci/devices?

Linus

It just reports what's in the PCI_INTERRUPT_LINE register.

At least on Alpha, we wrote into this register during pci configuration, so the value matches what's in /proc/interrupts. I guess I always assumed we did the same on x86, but I've never checked.

r~

That's wrong, then.

It _shouldn't_ be done. The PCI_INTERRUPT_LINE register is just a byte, which isn't even _enough_ to identify the irq "for real" on many architectures. It's also a totally different namespace at least on x86
machines: the PCI_INTERRUPT_LINE register should contain the "legacy interrupt", while the remapped interrupt will depend on whether the io-apic is enabled or not.

Writing it back is actively _bad_, since it will make it very hard to re-boot the machine without the BIOS re-enumarating the PCI bus and filling it in again (ie it would definitely screw up using things like kexec() on PC's, if the kernel we boot _from_ is an APIC kernel, but the kernel we boot _into_ is not).

So the rule should be:
- the PCI config space is _not_ the same as "pci->irq"
- we should _never_ update the PCI_INTERRUPT_LINE register, because it destroys boot loader information (the same way we need to not overwrite BIOS extended areas and ACPI areas etc in order to be able to reboot cleanly)
- we need _some_ way of getting the "kernel irq line" from /sys or /proc.

Sounds like /proc/pci still does something for us. Or is the info available in /proc/bus/pci/devices?

Linus

Actually, it doesn't. IIUC, it gets it from /proc/bus/pci/devices. That info is formatted in drivers/pci/proc.c::show_device().

I couldn't find any place that ia32 writes the PCI_INTERRUPT_LINE register during boot. And, manually reading in various places (before, during, and after enabling a device) always returned the same info.

AFAICT, lspci is getting it from /proc/bus/pci/devices. I'm getting the source now to sift through and verify. Alternatively, the data is also available in the 'irq' file in each PCI device's sysfs directory.

-pat

kernel 2.4.20 inbuilt isapp returns false data:
-----------------------------------------------
from /var/log/messages
sb creative 'vibra16',

1) non-functional with isapnp by kernel:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: sb: Creative ViBRA16X PnP detected

Dec  2 18:16:57 Lux3 kernel: sb: ISAPnP reports 'Creative ViBRA16X PnP' at 
i/o 0x220, irq 10, dma 1, 3
kernel: SB 4.16 detected OK (220)
kernel: SB16: Bad or missing 16 bit DMA channel
Dec  2 18:16:57 Lux3 kernel: sb: 1 Soundblaster PnP card(s) found.

------------------------------------------------

2) all but /dev/sndstat (which worked w. 2.4.19, same set-up) if kernel-isapnp disabled and, configured after <pnpdump> otput:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: SB 4.16 detected OK (220)
kernel: <Sound Blaster 16 (4.16)> at 0x220 irq 7 dma 1,5
kernel: <Sound Blaster 16> at 0x330 irq 7 dma 0,0
kernel: YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
kernel: <Yamaha OPL3> at 0x388
kernel: MIDI Loopback device driver

# -----------------------------------

system, <ver_linux>:
---
Linux Lux3 2.4.20 #2 Sat Dec 7 09:50:48 GMT 2002 i586 unknown
---

C compiler             2.95.4
make                   3.79.1
binutils               20020814
util-linux             v2.11n
mount                  2.11n
modutils               2.4.15
e2fsprogs              1.27
ppp                    2.4.1
isdn4k-utils           3.1pre4
C library              2.2.5
dynamic linker (ldd)   2.2.5
procps                 2.0.7
net-tools              1.60
console-tools          0.2.3
sh-utils               2.0.11
modules                isdn_bsdcomp hisax isdn ipchains bridge romfs nls_utf8 

nls_koi8-u nls_koi8-ru nls_koi8-r nls_iso8859-7 nls_iso8859-5 nls_iso8859-4 nls_iso8859-15 nls_iso8859-14 nls_iso8859-13 nls_iso8859-1 nls_gb2312 nls_cp936 nls_cp866 nls_cp865 nls_cp864 nls_cp855 nls_cp852 nls_cp850 nls_cp775 nls_cp437 nls_cp1251 nls_cp1250 nls_cp950 nls_big5 minix autofs acm usbcore v_midi opl3 sb sb_lib uart401 sound soundcore 8139too mii nbd

# -----------------------------------

statistics (after pnpdump config, only):

cat /dev/sndstat:
-----------------

	-/-

cat /proc/modules:
------------------
isdn_bsdcomp 5888 0

hisax                 131104  29 (autoclean)
isdn                  115200  30 (autoclean) [isdn_bsdcomp hisax]
ipchains               35876   0 (unused)
bridge                 15308   0 (unused)
romfs                   3584   0 (unused)
nls_utf8                 800   0 (unused)
    ...(more lang. mods)
nls_koi8-u              3872   1 (autoclean)
nls_iso8859-13          3392   0 (unused)
nls_iso8859-1           2880   2
minix                  18176   0 (unused)
autofs                  8932   0 (unused)
acm                     5024   0 (unused)
usbcore                53536   0 [acm]
v_midi                  4992   0 (unused)
opl3                   10792   0 (unused)
sb                      1792   0
sb_lib                 32288   0 [sb]
uart401                 6048   0 [sb_lib]
sound                  52588   0 [v_midi opl3 sb_lib uart401]
soundcore               3460   7 [sb_lib sound]
8139too                13376   1
mii                     2224   0 [8139too]
nbd                    14944   0 (unused)

cat /proc/interrupts:
---------------------
CPU0

  0:   44823924          XT-PIC  timer
  1:    1045591          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:    5026848          XT-PIC  HiSax
  7:        350          XT-PIC  soundblaster
  8:          3          XT-PIC  rtc
 10:          0          XT-PIC  eth0
 12:    3054844          XT-PIC  PS/2 Mouse
 14:     147687          XT-PIC  ide0
 15:    1403251          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

cat /proc/ioports:
------------------
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0220-022f : soundblaster
0240-0240 : HiSax hscx A fifo
02f8-02ff : serial(set)
0330-0333 : MPU-401 UART
0376-0376 : ide1
0378-037a : parport0
0388-038b : Yamaha OPL3
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0640-065f : HiSax hscx A
0a40-0a40 : HiSax hscx B fifo
0cf8-0cff : PCI conf1
0e40-0e5f : HiSax hscx B
1240-1240 : HiSax isac fifo
1640-165f : HiSax isac
1a40-1a47 : avm cfg
5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU d400-d40f : Acer Laboratories Inc. [ALi] M5229 IDE
d400-d407 : ide0
d408-d40f : ide1
d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
d800-d8ff : 8139too

cat /proc/dma:
1: SoundBlaster8
4: cascade
5: SoundBlaster16

I wonder if this is why we have all these problems with VIA chipset interrupt handling. According to VIA docs they _do_ use PCI_INTERRUPT_LINE on integrated devices to select the IRQ routing between APIC and PCI/ISA etc, as well as 0 meaning "IRQ disabled"

Alan

Whee.. That sounds like a load of crock in the first place, since the PCI_INTERRUPT_LINE thing should be just a scratch register as far as I know. However, it doesn't really matter - we definitely should never write to it anyway, so the VIA behaviour while strange should still be acceptable.

Anyway, to get back on the original discussion, I think we should remove the writing, and then make sure that /sbin/lspci (or some other tool) can be made to easily show either the kernel irq mapping value _or_ the "original PCI config space" value. At that point I'd agree that /proc/pci has outlived its usefulness.

(Although I still think the name database is nice to have - I certainly prefer it over having a lot of drivers having their _own_ name databases for printout purposes).

Linus

Tested and verified. If I leave it alone non apic mode works. To use APIC mode I have to write the new IRQ value into that register. I've shoved that into the driver for now, since its a demented chip specific horror.

That's definitely where it should be - the behaviour of the PCI_INTERRUPT_LINE register is clearly chip-specific, so it should be in the chip-specific drivers..

It's a kind of strange behaviour, though. What chip is this? It sounds kind of convenient, but as far as I can tell it can only work for those kinds of PCI devices that are on the same chip as the irq controller..

Linus

As a reminder of ancient times, one of the reasons I wanted to do per-PCI-device interrupt routing was due to the older incarnation of these chips, the Via 686 a/b southbridges. They have a similar method of routing interrupts, where writing to PCI_INTERRUPT_LINE directly makes internal chip magic occur. So you are correct WRT "only work ... on the same chip as the irq controller"

Jeff

VIA bridges. In my case its a CLE266 (onchip video, 5.1 audio, ide, usb, firewire, ethernet, floppy, serial, irda. parallel...) [See why I don't want to hack each driver 8)]

Oh, I didn't mean each sub-chip driver, I meant the "southbridge driver". Right now that's really only the PIRQ table mini-driver (all ten lines of it ;)

Sadly, we do _not_ have a really good generic model for setting interrupt lines. The PIRQ stuff comes closest to a driver model, but it gets disabled by the MP table parsing, and then we don't have anything good to fall back on, I'm afraid.

Linus

Think you can put in a reboot notifier/device shutdown method to restore it to it's old value, so kexec has a chance of working correctly with this hardware.

Eric

I can confirm that on most builtin VIA southbridge devices (namely USB) the register isn't just a scratch register and that indeed it is used by the interrupt router.

I guess only the irq re-routing code specific to VIA would then write those values, because it has to if the BIOS didn't set them up correctly.

It definitely made many drivers simpler.

Vojtech Pavlik
SuSE Labs

True. This applies to alpha as well because of the way how modern consoles encode IRQs routed through the ISA bridge (actual IRQ + 0xe0).

Probably we should eliminate pcibios_update_irq() call in drivers/pci/setup-irq.c and see what happens. Nothing bad, I guess.

Ivan.

A PS to this btw reading over the code - currently it seems to write it with our IRQ data if we do a suspend/resume but not initially. If so we have an inconsistency to resolve

Hi Linus!

The latter (unless you use `lspci -b' which reads the config registers directly) and it's doing it this way since the first version ;)

Have a nice fortnight

Martin `MJ' Mares   <[email protected]>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Anything is good and useful if it's made of chocolate.

Every half-decent installer autodetects all PCI devices. AND had lspci installed in the install image.

Ugh :-/ That's a reason to keep it around then.

lspci should be installed in /sbin.

Erik Hensema ([email protected])

Yes, but wait till you find yourself stuck on a weird embedded board with a small flash and a serial console and you are trying to debug the PCI device you've built.

Sure in most cases you have lspci (and its friends); but why do people want to deprecate a perfectly good tool that occasionally comes in useful? (Make it a compile time option sure, remove it - no).

Dave
---------------- Have a happy GNU millennium! ----------------------

/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Em Sat, Dec 07, 2002 at 01:15:59PM +0000, Dr. David Alan Gilbert escreveu:

In this weird embedded board with small flash it'd be lovely to save one more page (or perhaps more) in the kernel image, no? :-)

See above. And as you said lspci mostly is available. Remove it or make it a compile time option, please.

- Arnaldo

Agreed. But -=*if*=- I want to.

I would personally prefer to spend the page in the (compressed in flash!) kernel image than the nine pages or so for "lspci" (possibly compressed as well).

Roger.

** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

Em Mon, Dec 09, 2002 at 08:03:19PM +0100, Rogier Wolff escreveu:

wow, is lspci so bloated? 8) And I didn't objected to having it as a user selectable option :-)

- Arnaldo

Actually I'm inclined to insist that lspci belong in /sbin. Really. :)

Tomas Szepe <[email protected]>

Try it. At least on Debian it is useless without name database, which lives in /usr/share/misc/pci.ids... I can read numbers directly from /proc/bus/pci, if I want numbers.
Petr Vandrovec [email protected]

Hmmmm, on SuSE 8.0 too. I consider this a bug. Or at least a misfeature. Binaries in /bin and /sbin should not need anything from /usr.

Erik Hensema <[email protected]>

Originally pci.ids was in /etc/.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds