Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jul 2008 00:42:23 +0200
From:      Tino Engel <goaengel@gmx.net>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: Quirks
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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)?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080711004223.76d17a7e>