Date: Tue, 13 Jun 2000 11:39:39 +0100 (BST) From: Nick Hibma <n_hibma@calcaphon.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk>, Doug Rabson <dfr@calcaphon.com> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, Mike Smith <msmith@freebsd.org> Subject: PCI attach ordering Message-ID: <Pine.BSF.4.20.0006130936080.10103-100000@localhost> In-Reply-To: <2477.960760879@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> Right with the added twist that identification doesn't complete > until I have had a chance to poke at function 1. In other words, > I can't really claim function 0 when I see it, because I don't > know if it is part of the card I'm looking for or another card > and I will not know until I get to probe function 1. Are you saying that when you see the id 0x847x109e, you don't know whether you are looking at the multifunction card or not (I assume below that that is not the case and that the ID is sufficient). > > The card looks like this: > > > ############### func0 > # / \ > # / \ > # | \ > PCI ==# | | > # Framer0 Framer1 [...] > # | | > # | | > ### func1 ======= "ebus"=======-- ID-prom > 1) You need to claim both functions and they both represent different devices, so they should be attached to by different drivers (call them musycc-nc and musycc-eb). Assuming that there is no such thing as a card with only one of the functions your driver attaches to, you then can relate the two drivers by their unit numbering (hardwiring the device would be a bit more cumbersome). The botch you have now, musycc0 being card A function 0, musycc1 being card A function 1, musycc2 being card B function 0, etc. is really not a good idea. 2) Speaking to dfr this morning, he mentioned device_set_softc. I don't particularly like this idea as it will be abused when porting drivers from NetBSD. If you use the approach above you will not need to keep any state as you can grab the softc for either of the device with device_get_softc(device_get_device(musycc_nc_devclass, unit)); device_get_softc(device_get_device(musycc_eb_devclass, unit)); Or store the device_t and softc pointers in the other devices softc. 3) The solution you would like to see I suspect would be to connect a pci device/card (pcid, pcic is taken) driver to every pci device. pci.c would then contain a pcid driver that attaches to the pcib for every pci device/card and adds a child with a pci interface for every function that the pci card has. pcib obviously present a different interface to the pcid driver than the pci interface it does now. You could register a musyccf driver in that devclass (pcid) and when the device you want comes along return a higher priority probe for that device. Your driver not loaded, two musycc boards: pcib0 -> pcif0 -> (function 0) fxp0 -> pcif1 -> (function 0) chip0 -> (function 1) chip1 -> pcif2 -> (function 0) chip2 -> (function 1) chip3 Your driver loaded: pcib0 -> pcif0 -> (function 0) fxp0 -> musyccf0 -> (function 0) musycc-nc0 -> (function 1) musycc-eb0 -> musyccf1 -> (function 0) musycc-nc1 -> (function 1) musycc-eb1 It would not break any compatibiltity with old drivers as the interface and devclass names would stay the same. Nick -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.0006130936080.10103-100000>