Date: Tue, 15 Jul 2008 11:32:52 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Tino Engel <goaengel@gmx.net> Cc: freebsd-usb@freebsd.org Subject: Re: Quirks Message-ID: <200807151132.53525.hselasky@c2i.net> In-Reply-To: <20080711004223.76d17a7e@gmx.net> References: <20080709223926.142cbe5b@gmx.net> <200807101809.59532.hselasky@c2i.net> <20080711004223.76d17a7e@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807151132.53525.hselasky>