Date: Wed, 14 Sep 2005 08:49:13 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@samsco.org Cc: nsrashmi@gmail.com, freebsd-hackers@freebsd.org Subject: Re: PCI_MULTI FUNCTION DEVICE DRIVERS Message-ID: <20050914.084913.10907287.imp@bsdimp.com> In-Reply-To: <432798A5.7070105@samsco.org> References: <9f99931605091320002845705e@mail.gmail.com> <432798A5.7070105@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <432798A5.7070105@samsco.org>
Scott Long <scottl@samsco.org> writes:
: 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.
Generally speaking this is true. However, the class is available for
inspection and is used by some drivers in the tree (cardbus bridges,
pci bridge, some serial cards). Extra care has to be taken when
matching this way.
: 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.
There's also no guarantee that attach will be called after probe
without other probe routines being called. That's how it is currently
implemented, but there's no iron clad guarnatee that this will always
be the case.
: 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.
I've done this on other drivers in the past like this, and it works
relatively well. Finding siblings can be a bit of a pain, so I
usually do it once and cache the results. If your bridge function is
just a pci bridge, for example, then the standard driver will likely
do all that's required.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050914.084913.10907287.imp>