Date: Fri, 18 Apr 1997 18:43:37 +0200 From: Stefan Esser <se@freebsd.org> To: dennis <dennis@etinc.com> Cc: "Daniel O'Callaghan" <danny@panda.hilink.com.au>, hackers@freebsd.org Subject: Re: Probing deflugalty Message-ID: <19970418184337.39801@x14.mi.uni-koeln.de> In-Reply-To: <3.0.32.19970417185458.00b2d590@etinc.com>; from dennis on Thu, Apr 17, 1997 at 06:55:00PM -0400 References: <3.0.32.19970417185458.00b2d590@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 17, dennis <dennis@etinc.com> wrote: > >On Thu, 17 Apr 1997, dennis wrote: > >> With the following configuration: > >> > >> device dev0 > >> device dev0 at isa? port 0x300 > >> > >> If a PCI device is found, the ISA dev0 really shouldn't be probed, but > >> it is. > My point here was that if ed0 is already attached that additional ed0 > probes should not be done.... Sorry, but I still don't understand what you actually dislike about the current situation ... Is it: 1) Only ed0 is specified in the kernel config file, and you do not want an additional PCI card to be attched as ed1 ? 2) You have a PCI card at some address assigned by the PCI BIOS, and have also specified the attach address in the kernel config file (or in userconfig), and now both the PCI and the ISA attach code find the card and try to attach it ? The first one is a feature, actually :) You need only have some driver included in the kernel (or loaded as an LKM), and it will attach all cards that it knows about. The second one is the result of the PCI code and the ISA code not having a common ressource list. There is no way to detect the conflict, in that case. (The current ressource registration code is ISA specific, and will have to be generalized to support multiple port and memory ranges, for example.) I plan to fix both these points in the PCI code. Some recent discussion with Jörg Wunsch made me rethink the PCI attach procedure, and I want to implement changes, that allow you to: 1) wire driver names to cards in specified PCI slots 2) allow "userconfig" to attach a unit number to a PCI device 3) allow "userconfig" to disable a PCI device 4) check for ressource conflicts with cards on other bus types (and protect against an ISA driver trying to attach a PCI card, that has already been found by its PCI driver ...) The config file format would be: # PCI bus tree controller pci0 controller pci1 at pci0 slot 5 controller pci2 at pci0 slot 6 # Adaptec 3940 in slot 5 device ahc0 at pci1 slot 0 device ahc1 at pci1 slot 1 # AMD Combo chip on motherboard device lnc0 at pci0 slot 7 func 0 device amd0 at pci0 slot 7 func 0 This does of course require changes to "config", but they are not hard to implement. The semantics of the above definitions would be, that an Adaptec 3940 in slot 5 would actually get the ahc0 and ahc1 driver instances assigned. If there was no such card, but an 2940 in slot 5, then that would come out as ahc2, since ahc0 and ahc1 are reserved for the 3940 and will only be used for such a card in slot 5. There is one problem left, but I'm going to ignore that: The PCI bus numbers used in the config file are only used as labels, they don't have to match what the PCI BIOS assigns. It is well possible, that the PCI BIOS chooses to assign PCI bus 2 to the secondary side of the PCI bridge in slot 5, and thus "pci1" in the config file is just a label for the "at pci1" clause ... (In other words: pci99 substituted for all occurances of pci1 in the config file would give indistinguishable behaviour, and would not imply, that the card will really be found on a PCI bus with a bus number of 99.) I'll implement this as time permits, together with other necessary PCI bus driver changes. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970418184337.39801>