kobj multiple inheritance
Doug Rabson
dfr at nlsystems.com
Mon Sep 22 09:09:32 PDT 2003
On Mon, 2003-09-22 at 16:52, M. Warner Losh wrote:
> In message: <1064221837.15078.14.camel at herring.nlsystems.com>
> Doug Rabson <dfr at nlsystems.com> writes:
> : This effectively allows all pci
> : drivers to get into the cardbus probe. If a particular driver needs to
> : treat its cardbus attachment specially, it can still do this by adding a
> : special cardbus driver (e.g. with a cardbus specific probe or attach
> : method) to the cardbus devclass (exactly as it does now).
>
> So if there's devices that can only be "base" pci, and have issues
> with all other types of pci-like buses, is there a way to say "only
> on pci bus, but none of the derived buses"? Or is it better to list
> those derived buses that are known to cause problems? I'd imagine
> that these devices would be rare, but I've worked on one....
If there is a device which only ever appears in base pci physically,
then, trivially, the driver for that hardware will never match to a
cardbus device (since there is no physical manifestation of a cardbus
version of the hardware).
If there is cardbus hardware which we have a base pci driver for and
which causes real problems when it attaches to cardbus hardware, then I
guess you could always include a dummy 'do nothing' cardbus attachment
which would match first. Remember that cardbus-specific drivers are
searched before we fall back to pci-generic drivers so you can always
win the driver election with a cardbus-specific driver.
>
> Also, we're violating the PC Card spec by not matching the CIS values,
> but reading the vendor/device instead. Technically, this is a
> violation and those registers aren't reqiured to be defined. So far,
> nobody has showed up with devices that don't have them, but I thought
> I'd point this out. It has been theorized that this is because so
> many designs share silicon with PCI.
If any hardware which doesn't support vendor/device ever appears, then a
driver for it would need a cardbus-specific attachment. This can be
pretty simple:
static device_method_t foo_pci_methods[] {
DEVMETHOD(device_probe, foo_pci_probe),
DEVMETHOD(device_attach, foo_pci_attach),
...
{ 0, 0 }
};
DEFINE_CLASS(foo, foo_pci_driver, foo_pci_methods,
sizeof(struct foo_softc));
/* override just the probe for cardbus */
static device_method_t foo_cardbus_methods[] {
DEVMETHOD(device_probe, foo_cardbus_probe),
{ 0, 0 }
}
DEFINE_CLASS_INHERITS1(foo, foo_cardbus_driver,
foo_cardbus_methods, sizeof(struct foo_softc),
foo_pci_driver);
More information about the freebsd-arch
mailing list