Re: kobj multiple inheritance

• Previous message: M. Warner Losh: "Re: kobj multiple inheritance"
• In reply to: M. Warner Losh: "Re: kobj multiple inheritance"
• Next in thread: Justin T. Gibbs: "Re: kobj multiple inheritance"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: "M. Warner Losh" <imp@bsdimp.com>
Date: 22 Sep 2003 17:08:52 +0100

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);

_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

• Previous message: M. Warner Losh: "Re: kobj multiple inheritance"
• In reply to: M. Warner Losh: "Re: kobj multiple inheritance"
• Next in thread: Justin T. Gibbs: "Re: kobj multiple inheritance"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]