Date: Mon, 19 Apr 1999 13:51:54 +0200 (CEST) From: Nick Hibma <nick.hibma@jrc.it> To: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp> Cc: Doug Rabson <dfr@nlsystems.com>, freebsd-current@FreeBSD.ORG Subject: Re: newbus and modem(s) Message-ID: <Pine.BSF.3.96.990419115049.83369J-100000@elpc36.jrc.it> In-Reply-To: <199904190857.RAA01297@shidahara1.planet.sci.kobe-u.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me try to post an example to see whether I understood your question: Let's assume we have a motherboard with an ISA NHCI (new host controller interface) apart from the standard PCI UHCI (Universal Host Controller Interface, Intel) available in the 82371AB chipset. We boot the system, the UHCI controller is recognised by the PCI bus driver (nexus - pci), probed by the UHCI driver (pci - usb) and this will create a driver that implements a "usb" devclass. It then starts a probe for devices on the bus it represents. The "usb" class driver was compiled into the kernel and attaches to that bus. This is the uhub driver (usb - uhub). You start websurfing and find this driver for your NHCI controller (New Host Controller Interface). After download you load the driver with kldload. The ISA bus is notified of the presence of a new driver and reprobes the ISA devices that are not attached by a driver. It probes the physical NHCI device with the NHCI driver (isa - usb) (succeeds) and attaches the loaded driver to it. This will create a new bus with device class "usb". After the attach has finished, the probe_and_attach function is called and a usb class driver will probe and attach to this new bus. You now have two USB busses (the diagram contains 2 mice, 2 keyboards, 1 Zip drive, and 2 external and 2 root hubs): pci - usb - uhub - uhub - ums \ ukbd \ umass (Zip drive) \ usb - uhub - ums \ uhub - ukbd \ trackball (The '-' and '\' represent the spots where the drivers are located. The names represent the device classes). The usb class driver is able to talk to the UHCI or NHCI driver through predefined methods, like USB_DEVICE_BULK_TRANSFER, USB_DEVICE_BULK_TRANSFER_ABORT, USB_HOST_RESET, USB_HOST_SUSPEND, etc. In later releases methods can be added by using new names. What is not possible with newbus is to attach a pci - usb driver to a bus that is not called pci, but for example pci2. But this is a logical limitation as with the change of name for the bus, the interface to the bus must have changed as well. The devclass names should therefore not contain vendor, device or type specific interfaces, only generic interfaces. I hope this serves as an explanation for your question. Kind regards, Nick P.S.: Above is a wanted situation for the USB stack not the current. The current source code contains a more complicated approach due to the fact that it is converted from newconfig in NetBSD. The UHCI driver attaches to pci and creates one child for the usb bus. This could be removed. (e.g. pci - uhci - usb - uhub - ums, for a system with only a mouse attached). Second, the uhub driver is available in two device classes, usb and uhub. > I don't mention on upstream driver such as 'ukbd' > (I think such device can be add truly dynamic),but I mention on > 'host-controller' like [ou]hci. > > What I ask is what shall I do if there is a downstream driver without > declared DRIVER_MODULE on upstream bus.Are there any way without changing > upstream bus code? > > Takanori Watanabe > <a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">; > Public Key</a> > Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990419115049.83369J-100000>