From owner-freebsd-usb@FreeBSD.ORG Thu Jul 10 22:37:22 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 E048A106566C for ; Thu, 10 Jul 2008 22:37:22 +0000 (UTC) (envelope-from goaengel@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4F2C78FC15 for ; Thu, 10 Jul 2008 22:37:22 +0000 (UTC) (envelope-from goaengel@gmx.net) Received: (qmail invoked by alias); 10 Jul 2008 22:37:20 -0000 Received: from p54988BAE.dip0.t-ipconnect.de (EHLO localhost) [84.152.139.174] by mail.gmx.net (mp038) with SMTP; 11 Jul 2008 00:37:20 +0200 X-Authenticated: #39106949 X-Provags-ID: V01U2FsdGVkX1+SWmNNf9mS1vVR0oKDeIDzGroBS2W1H0n2JpGxN5 llnbxPcKacakgm Date: Fri, 11 Jul 2008 00:42:23 +0200 From: Tino Engel To: Hans Petter Selasky Message-ID: <20080711004223.76d17a7e@gmx.net> In-Reply-To: <200807101809.59532.hselasky@c2i.net> References: <20080709223926.142cbe5b@gmx.net> <200807092344.09985.hselasky@c2i.net> <20080710135033.71c1bf21@gmx.net> <200807101809.59532.hselasky@c2i.net> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 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: Thu, 10 Jul 2008 22:37:23 -0000 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? Best regards, Tino P.S.: Maybe /etc and /var/db is not the right place for things like this, you probably know better... P.P.S.: What is an IR (from your last mail)?