Date: Tue, 13 Sep 2005 21:27:33 -0600 From: Scott Long <scottl@samsco.org> To: nsrashmi@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: PCI_MULTI FUNCTION DEVICE DRIVERS Message-ID: <432798A5.7070105@samsco.org> In-Reply-To: <9f99931605091320002845705e@mail.gmail.com> References: <9f99931605091320002845705e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
rashmi ns wrote: > Hello All, > While writing a pci-driver for hdlc controller which has two functions > 1.BRIDGE > 2.Network > Do we need to write two separate drivers for each class-code or how can a > single driver manage two different functionalites .Are there any examples on > pci-multifunction drivers .I read in the documents that we need to use mbuf > structure for multi-function devises are there any drivers which uses the > same. > Thanks in advance , > Rashmi.N.S In the FreeBSD driver model, the driver 'probe' method will get called for each PCI function in the system. The driver can either bid to claim it, or reject it. It's up to the driver author as to what criteria is used to bid/accept vs reject a function. Almost all drivers look at the pci device id set. Looking at merely the PCI class code is not recommended since it it far too ambiguous. Also, unlike Linux, the driver does not have easy access to the PCI enumeration internals of the OS. There are also no guarantees as to what order the bus will be probed or what order functions will be enumerated in. Do you actually need to program both functions of the hardware? Usually a bridge device tends to be passive from a driver standpoint. Is there something special that your bridge does? If so then you'll need to write two sets of drivers, each with a unique probe, attach, and detach method. Making the separate driver instances work together will be a bit tricky. The easy but really messy approach is to create some global variables and methods and have the drivers cheat. I'd avoid this is at all possible. Probably the more correct approach is to have each function walk the device tree and look for its sibling, then communicate via custom DEVMETHOD's. This does have performance implications though, so a combination of walking the tree then calling via direct dispatch is probably the best approach if performance is a factor. If you could provide more information about what your device is and what each function does, I can probably give better answers. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?432798A5.7070105>