From owner-freebsd-usb@FreeBSD.ORG Tue Jul 15 09:31:16 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7914F1065674 for ; Tue, 15 Jul 2008 09:31:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id CD7EA8FC15 for ; Tue, 15 Jul 2008 09:31:15 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=8kjA1I9P6a1jR4eVc-8A:9 a=v56VxE407QCbIbCNiSIA:7 a=QvqDf7CFhVlkLJ1FlQesktqmnGkA:4 a=LY0hPdMaydYA:10 Received: from [193.217.167.134] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.4b) with ESMTPA id 1007181206; Tue, 15 Jul 2008 11:31:14 +0200 From: Hans Petter Selasky To: Tino Engel Date: Tue, 15 Jul 2008 11:32:52 +0200 User-Agent: KMail/1.9.7 References: <20080709223926.142cbe5b@gmx.net> <200807101809.59532.hselasky@c2i.net> <20080711004223.76d17a7e@gmx.net> In-Reply-To: <20080711004223.76d17a7e@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807151132.53525.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Quirks X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2008 09:31:16 -0000 On Friday 11 July 2008, Tino Engel wrote: > Hi --HPS, > > > Hi Tino, > > > > Let's focus on getting the USB mass storage problems fixed first. > > There are plenty of USB Mass Storage IR's in the database. > > > > What kind of quirk strategy would you like to apply? > > > > If the device fails the Mass Storage test, then switch on all > > possible quirks ? Which means that the user might have to replug the > > USB device ? > > > > --HPS > > Here is a map of what I think would be reasonable: > > > At first there is a file (let's say /etc/ums.conf) which holds the > configuration of how to approach new devices. The file is delivered > with reasonable defaults. > > > GLOBAL OPTIONS: > =============== > If the option ALL_QUIRKS="YES" is set, a new UMS is approached with > all quirks. If something fails here, there is pretty much nothing left > to do. > > Also all other quirks can be set on by default: > Example: Q_NO_SYNC_CACHE="YES" would disable cache syncing for all msc > devices. > > So, now there more sophisticated part: > In case the all quirks option is not set, 2 cases remain in this model: > > CASE 1: > ======= > > Case 1 describes the case of a MSC device that hangs up > after receiving a command it could not be able to handle. It ends in a > unfixable state, even a bus reset cannot help. > > That leads us to the conclusion, the device has to be unplugged in > order to proceed. The only question is, how to proceed then. Also in > this case, the was is determined by configuration. > > The easiest case would be given by using the option: > STALLED_ALL_QUIRKS="YES" > > Then dmesg would tell to replug the device (and other events would be > triggered, for whatsoever), and all quirks would be applied for this > device from there on. The information would be held in /var/db/ums or > whatever appropriate place. > > Additionally one could think about enabling a chained quirk set: > For example I could set STALLED_Q_NO_SYNC_CACHE="1" and > STALLED_ALL_QUIRKS="2" which would have the effect, that for this > specific device, cache syncing would be disabled (quirked) on first > reconnect, and, if failed, all quirks would be activated on next > connect. dmesg would properly inform me to replug. > > Nice would also be an option STALLED_INTELLIGENCE="YES" which would try > same order as in case 2. > > The successful quirk combination is also stored in /var/db/ums. > > In addition, it would be nice to have a vendor/device specific config > format. (e.g. STALLED_Q_NO_SYNC_CACHE="SAMSUNG,1") > > This way would have the advantage that my device runs anyhow without > kernel recompilation (although i might have to replug a couple of times > in worst case :-( ) > > CASE 2: > ======= > In case 2, the device can recover by a usb reset. There it is a runtime > issue, if just all quirk permutations can be tested or if a > configuration similar to case 1 is appropriate. (I assume, we can live > with the runtime there, since plugging an usb device is not a > real-time-thing ^^) > Than we can have a nice logic (from most common to less common quirk > permutations order) > > Here we should definitely have a config file, containing device > specific quirk information, which can be updated. > > > Anyhow, feedback events (e.g. for graphical connection tools) > interaction with things like HAL and whatever comes up should be > considered, so it can be implemented sooner or later... > > > What do you think? Hi Tino, I think this should be all automatic. Most users will have no clue what to put in those configuration files. Any others have any opinion about this on the list? --HPS