From owner-freebsd-arch@FreeBSD.ORG Mon Sep 22 09:09:32 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FC3016A4B3 for ; Mon, 22 Sep 2003 09:09:32 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2079443FE9 for ; Mon, 22 Sep 2003 09:09:31 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h8MG93FH010108; Mon, 22 Sep 2003 17:09:04 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h8MG8qAc094125; Mon, 22 Sep 2003 17:09:03 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20030922.095225.85015472.imp@bsdimp.com> References: <1064221837.15078.14.camel@herring.nlsystems.com> <20030922.095225.85015472.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1064246931.26368.15.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 22 Sep 2003 17:08:52 +0100 Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: kobj multiple inheritance X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2003 16:09:32 -0000 On Mon, 2003-09-22 at 16:52, M. Warner Losh wrote: > In message: <1064221837.15078.14.camel@herring.nlsystems.com> > Doug Rabson 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);