From owner-freebsd-hackers Wed Apr 9 06:04:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA18060 for hackers-outgoing; Wed, 9 Apr 1997 06:04:11 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA18003; Wed, 9 Apr 1997 06:03:35 -0700 (PDT) Received: from dbws.etinc.com (dbws.etinc.com [204.141.95.130]) by etinc.com (8.8.3/8.6.9) with SMTP id JAA18681; Wed, 9 Apr 1997 09:09:29 -0400 (EDT) Message-Id: <3.0.32.19970409090212.006b8a6c@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 09 Apr 1997 09:02:13 -0400 To: Stefan Esser From: dennis Subject: Re: pci probes with multiple "units" Cc: hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:48 PM 4/9/97 +0200, Stefan Esser wrote: >On Apr 8, dennis wrote: >> >> What is the preferred method (assuming that there is more than one >> way to do it) to handle multiple multiport devices in Freebsd. It seems >> (I could be wrong) that the *first* adapter always probes/attaches as unit >> 0 (even if the declaration is... >> >> device de4 >> >> for example), the *second* as 1, etc. If you have 2 boards with 4 ports >> each, logically you would like to declare: >> >> device de0 >> device de4 > >PCI config lines are only scanned for the *name* of the device. >Everything else is automatic ... >You don't need a line per device. The drivers are all expected >to support an arbitrary number of cards ... > >> and have the device names correspond to the actual port device >> numbers, but I suspect that this won't work (I havent actually tried >> it yet). >> >> It can certainly be done manually by calling if_attach with the correct >> number, but is there a better, physical way to do it so that the probes >> are done with the root/first port on the board? > >There is no easy way to know which device is the "root" device, >since this concept is out of the scope of the PCI bus. The PCI >BIOS maps all devices into system memory (or port space), but >you have no way to know whether the BIOS scans from low to high >slot numbers or reverse, or whether it is even depths first (as >reported once), leading to a possibly very surprising scan order. > >As long as you can't assign a physical position to a PCI device, >there is no use in having multiple device lines in the config >file. But the specification of the physical position is not a >number, it is a sequence of slot numbers, arbitrarily long ... >(In fact, 8 levels of slot numbers might be sufficient.) > >A device that will be probed as de0 on pci1:0 could possibly >have to be declared as: > >device de0 at pci9.4.5.0-0 > >This could be the second slot on the mother board (if actual >slots start at PCI slot number 8) where an PCI extender box >has been installed, 4 could be the internal slot used by the >cable of that box, 5 could be a physical slot in the extender >box, 0 the number of the device behind the PCI to PCI bridge >on a multi-channel Ethernet card, and finally 0 the "function" >number of the PCI device on the PCI chip (which can be omitted >in most cases). > >And if you think this is a constructed unrealistic example, >then I can send you the probe message of a system that would >require an even longer slot sequence ;-) > > >I've been thinking about the topic of assigning PCI device >instances to physical positions, but did not yet come to any >workable result ... How does it determine the "unit" number that is passed to the pci_attach function? Is it the number of non null probe returns from a particular pci_probe? In other words, can I assume that with multiple cards, scanned in some indeterminable order, that the units will be passed as 0,1,2, etc even with only a single device entry in the config file? Dennis