From owner-freebsd-current@FreeBSD.ORG Thu Jun 26 08:55:56 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7FBE37B401; Thu, 26 Jun 2003 08:55:56 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10E4343F85; Thu, 26 Jun 2003 08:55:56 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h5QFtpE1063234; Thu, 26 Jun 2003 09:55:53 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 26 Jun 2003 09:55:29 -0600 (MDT) Message-Id: <20030626.095529.11642254.imp@bsdimp.com> To: eaja@erols.com From: "M. Warner Losh" In-Reply-To: <20030625160525.46bcef88.eaja@erols.com> References: <20030625160525.46bcef88.eaja@erols.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: PATCH: move cardbus container to "pci" devclass X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 15:55:57 -0000 First, CardBus is not PCI. It is a derivative of PCI that has its own, weird rules for configuring cards. Our current implementation doesn't follow all the weird rules, since most cardbus hardware is the same silicon as pci hardware. However, for attachment and such there likely needs to be a distinction. In message: <20030625160525.46bcef88.eaja@erols.com> Eric Jacobs writes: : I have made a patch for -CURRENT and 5.1-RELEASE that hopefully : improves the support for Cardbus devices by changing the "cardbus" : driver to implement the "pci" devclass rather than the "cardbus" : devclass, and to make their unit numbers correspond with the : PCI secondary bus numbers that their bridges are assigned. I both like and dislike this patch. It has advantages and disadvantages :-) : This has a number of advantages: : : - User mode tools that interface with the /dev/pci interface : such as pciconf and lspci (from ports) are now able to access : Cardbus devices without modifications. This is cool. There are other ways that this could be done. : - PCI drivers no longer need an additional driver declaration : in order to support cardbus, e.g., in : : ./pci/if_xl.c:DRIVER_MODULE(xl, cardbus, xl_driver, xl_devclass, 0, 0); : ./pci/if_xl.c:DRIVER_MODULE(xl, pci, xl_driver, xl_devclass, 0, 0); : : only the second line is required. (The first is harmless though.) I'm not sure this is a good idea. Cardbus is supposed to be configured in a different way than pci. The fact that we're able to get away with just looking at the vendor/subvendor fields means we're lucky. That violates the spec. Also, I've added the cardbus line whenever I've verified that the hardware exists in cardbus form and when I have some modest reason to expect it to work. : - Because the unit numbers in the "pci" devclass now represent : the PCI bus numbers in use in the system, we now have a good : way of assigning bus numbers to the Cardbus bridges in lieu : of the PCI BIOS doing so, which is not something we can expect : all BIOSes to do. (The old code incremented a static counter : starting from 2 by 3 every time this condition occurred, : which wasn't correct because there could already be a pci2 : in the system, and the counter would eventually recycle.) This is also cool. The current kludge we have is ugly, and has the problems you describe. : And a couple of potential drawbacks: : : - Drivers that need to behave differently for Cardbus devices : can't do so by declaring another driver_t specifically for : cardbus. (No driver that I'm aware of does this, however; : they all use the same driver_t.) None currently do, but some might need to in the future. While this could be supported with kobj returning errors in the raw pci case and no errors in the cardbus case, I think that would make for some icky attachment code. I'm torn on this issue a little. : - Users that are accustomed to newbus nameunits containing : descriptive information about devices may prefer to see, : for example, "cardbus0" rather than "pci2". This is a very useful distinction. It makes it a lot easier to say 'do this when a cardbus card attaches, but do that when a non-cardbus card attaches'. devd exposes this to the user now, and i'd prefer to keep this distinction. i don't mind if it is called cardbus2 rather than cardbus0 when the cardbus has a bus number of 2. I have a laptop that has a rl0 on pci0 and a rl1 on cardbus0. I'd like to continue to have devd able to do different thing to each one based on their location, not on the rl number. : Note that : using newbus in this way defeats a good deal of its : potential for object-oriented design. I don't understand this comment at all. : The patches are at : : http://users.erols.com/eaja/cardbus51.diff : http://users.erols.com/eaja/cardbuscurrent.diff : : Any comments? I think that these are patches that I can work with. However, it assumes that the bus number and the pci unit number are the same. This may be true on some machines, but definitely isn't true on all machines. We also need to reserve, like windows does, at least one additional bus per slot to deal with cards that have bridges on them (there are a few, including nasty things like cardbus to pci bridges so you can have 5 pci slots on your laptop). Warner