From owner-freebsd-hackers Tue Aug 27 7:37:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B56DF37B400; Tue, 27 Aug 2002 07:37:18 -0700 (PDT) Received: from freebsd.dk (cpe.atm2-0-56339.0x50c6aa0a.abnxx2.customer.tele.dk [80.198.170.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8014443E72; Tue, 27 Aug 2002 07:37:17 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.12.5/8.12.5) id g7REbFUl091711; Tue, 27 Aug 2002 16:37:15 +0200 (CEST) (envelope-from sos) From: Soeren Schmidt Message-Id: <200208271437.g7REbFUl091711@freebsd.dk> Subject: Re: USB->ATA devices In-Reply-To: <20020827135110.GB24795@spc.org> To: Bruce M Simpson Date: Tue, 27 Aug 2002 16:37:15 +0200 (CEST) Cc: Ian Dowse , n_hibma@FreeBSD.ORG, joe@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL98b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Bruce M Simpson wrote: > > If you're interested, I wrote a functional but incomplete driver > > for a similar device, the Prolific Technology PL2307 bridge. I just > > This is good stuff. > > The Onspec expects a command packet containing the ATA register contents > in the order they appear in i/o space. Plus an additional byte whose > meaning I have yet to decipher. > > > implemented the conversion for a minimal set of ATA commands in the > > driver itself; it would obviously be better to have the ATA layer > > in a separate driver though. The code for that driver is at: > > How about doing ata(4) over usb? > > Support was added for PCMCIA to ata in the form of ata-card.c. This > required macro-izing the bus_space_write*() calls amongst other things. Ahem, all the bus_* stuff was done to support other platforms (alpha/sparc) not for the PCMCIA stuff which is very much straight forward... > Normally this takes place over an underlying isa/pci bus abstraction, > maybe we could re-use this abstraction in ata-usb.c to avoid changing > anything here? That way we avoid duplicating the ATA bit-banging code. It should be possible to hide the USB stuff under the ATA_* macroes or even just under bus_space_*. I need a bit more concrete details on how to call into the USB code, then it should be pretty easy to add... > > > Remember atapicam? I like the fact that it allows one to run cdrecord > with an ATAPI CDRW drive; perhaps it could be re-used and extended to > allow CAM to be used to interact with these pure ATA devices? Of course > in this case, if we make the devices on the USB->ATA bridge look like > ata-disk devices and what have you, who needs CAM? atapicam only does ATAPI, not ATA... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message