From owner-freebsd-hackers Mon May 31 16: 9:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id D61F51553A; Mon, 31 May 1999 16:09:22 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA04790; Mon, 31 May 1999 19:09:25 -0400 From: Bill Paul Message-Id: <199905312309.TAA04790@skynet.ctr.columbia.edu> Subject: Using newbus to hang a custom bus off a device To: hackers@freebsd.org Date: Mon, 31 May 1999 19:09:23 -0400 (EDT) Cc: dfr@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 5661 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, after a bit of head scratching, I finally think I've gotten the hang of the new bus architecture stuff (in general that is, not just the new ISA and PCI stuff). I'm trying to create an miibus framework so that I can have an miibus attached to those PCI ethernet drivers which support MII-based transceivers, to which I can attach transceiver drivers. I'm still a little confused by something though, probably because I'm trying to do the development on 3.2-RELEASE (I don't have a machine that I can clobber with -current just at the moment). Basically what I have is this: - An miibus_if.m file which describes the methods implemented by miibus drivers. There are three methodes: a readreg method, which lets you read a given register from a given PHY on the MII bus, a writereg method, which lets you write a value to a given register on a given PHY on the MII bus, and a status change method, which lets you tell the driver which implements the miibus support that the status of a PHY has changed and that the controller needs to update some state to match it. (This is mainly to deal with controllers that have speed and duplex settings that operate independently of the PHY: if the PHY negotiates 100Mbps full duplex, then the controller chip to which the PHY is attached may also need to be explicitly programmed for 100Mbps full duplex to match the PHY.) - A stub mii PHY driver, which has its own probe and attach functions, and which uses the following DRIVER_MODULE() macro: DRIVER_MODULE(miigeneric, miibus, mii_driver, mii_devclass, 0, 0); - Some stub code to be inserted into a NIC driver which implements the miibus support. The code provides a probe routine (which checks for MII support on the controller) but uses bus_generic_attach for its attach routine. This, I believe, allows all of the mii driver probes to be invoked after the bus is attached. The NIC driver also uses a DRIVER_MODULE() macro like this: DRIVER_MODULE(miibus, ax, miibus_driver, miibus_devclass, 0, 0); (Here, "ax" represents the if_ax driver, which is what I used for testing since the ASIX chipset uses an MII-based transeiver.) So, here's how I understand this: the MII driver is declared to be in the 'miibus' devclass. And the if_ax driver declares an miibus device which is attached to the ax devclass. Since this is 3.2-RELEASE, I manually attach the ax device to the root_bus devclass using device_add_child(). Then I do the following: miibus = device_add_child(sc->ax_device, "miibus", -1, NULL); if (device_probe_and_attach(miibus)) { device_delete_child(sc->ax_device, miibus); return(ENODEV); } Now, this is where I had to do some looking around: the fact that you need to use device_add_child() is not clearly spelled out in the man pages. Basically, the fact that the DRIVER_MODULE() modules declare the driver hierarchy does not mean than device instances are actually created. The DRIVER_MODULE() macros basically tell the system to expect that an miibus could be created as a child of an ax device instance, and that an miigeneric device could be created as a child of an miibus instance, but you actually need to use device_add_child() to call the device instance into existence. Similarly, in the miibus probe routine, you have to check for PHYs on the miibus and call device_add_child() to create a device node for each PHY on the bus. (I use device_add_child(dev, NULL, -1, NULL) for this, because you don't know ahead of time exactly which driver will be attached.) Then, bus_generic_attach() will call the probe routines of all the PHY drivers that are declared to be in the miibus devclass, and whichever driver supports the discovered PHY claims the device instance. Now, given all that, here are the questions that I have: - In -current, assuming that a PCI NIC driver has been properly newbus-ified, is it still necessary for the driver to manually call device_add_child() to create the miibus device instance and then call device_probe_and_attach() to get the PHY drivers into the picture? I think the answer is yes, because I don't see any other way for it to work. - Suppose that I want to probe for PHYs on the miibus in a particular order? All MII-compliant PHYs implement a standard set of registers, so in theory it's possible to write just a single generic PHY driver which will handle all PHYs. However, sometimes a given PHY will require some special handling. So, what I want to do is have expliclt PHY drivers to handle certain PHYs and have a catch-all generic driver to handle any other device that isn't handled by one of the explicit PHY drivers. This implies that the probe routine of the generic device will be invoked last. If the generic device probe is invoked first, then all PHYs will get the generic driver attached, which is not what I want. Is there some way to weight the drivers such that the specific ones will have a higher priority than the generic one, thereby forcing the specific probes to be called first? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message