Date: 22 Sep 2003 17:08:52 +0100 From: Doug Rabson <dfr@nlsystems.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: kobj multiple inheritance Message-ID: <1064246931.26368.15.camel@builder02.qubesoft.com> In-Reply-To: <20030922.095225.85015472.imp@bsdimp.com> References: <1064221837.15078.14.camel@herring.nlsystems.com> <20030922.095225.85015472.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003-09-22 at 16:52, M. Warner Losh wrote:
> In message: <1064221837.15078.14.camel@herring.nlsystems.com>
> Doug Rabson <dfr@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);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1064246931.26368.15.camel>