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