From owner-freebsd-current Mon Apr 19 2:42:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 87CD314EF1 for ; Mon, 19 Apr 1999 02:42:13 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elpc36.jrc.it (elpc36.jrc.it [139.191.71.36]) by mrelay.jrc.it (LMC5692) with SMTP id LAA22652; Mon, 19 Apr 1999 11:43:32 +0200 (MET DST) Date: Mon, 19 Apr 1999 11:39:44 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@elpc36.jrc.it Reply-To: Nick Hibma To: freebsd-current@freebsd.org Cc: Doug Rabson Subject: Re: newbus and modem(s) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Simple Question. > If there were 'Closed'-Host-Controller-Interface with object-only driver, > Can the vendor make the Host controller recognized without changing > usb.c code? If he exports a USB bus with the appropriate methods, he will be able to drop it in, yes. You might have noticed when installing USB support that you get a uhci0, usb0 and uhub0 device, basically all related to that one 82371AB chip that is on your motherboard. The problem currently is that, because of the porting of the NetBSD USB code, we use a mixed scheme, which makes things slightly more complicated. There is a separate method export mechanism for the UHCI/OHCI controllers. The way this is implemented currently in the NetBSD code is ugly, to say the least. > #That's what frustrated me while writing driver for smbus controller. That is more of a design issue than something caused by newbus... Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message