From: Josua Dietze <digidietze@draisberghof.de>
To: Oliver Neukum <oliver@neukum.org>
Cc: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>,
Dan Williams <dcbw@redhat.com>,
Stefan Seyfried <stefan.seyfried@googlemail.com>,
linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
usb-storage@lists.one-eyed-alien.net,
Stefan Seyfried <seife@sphairon.com>
Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage
Date: Thu, 17 Dec 2009 14:33:06 +0100 [thread overview]
Message-ID: <4B2A3312.104@draisberghof.de> (raw)
In-Reply-To: <200912171402.42168.oliver@neukum.org>
Oliver Neukum schrieb:
> Am Mittwoch, 16. Dezember 2009 20:52:58 schrieb Matthew Dharm:
>>>> If this is the case, then the only reasonable answer to is to push the
>>>> modeswitch code for both into udev and out of the kernel. It will take
>>> you mean usb_modeswitch, not udev actually.
>> That is correct; I had mis-typed. Tho, the actual implementation is udev
>> calling usb_modeswitch and/or eject.
>
> Can storage tell the devices apart so that it knows which ones to leave
> to the kernel solution and which devices to accept so that udev can
> issue an eject command?
If you are thinking about the two specific devices at hand there is
no need to tell them apart. Same IDs on plugin, same switching
procedure, different IDs on return, different drivers take care.
If you are thinking generally, there is already a case when:
same IDs on plugin, different switching procedures.
See "option_ms.c"; the solution was to check for SCSI ID strings and
only act if there's a match. I filed this patch to enable userspace
handling for a different device with the same IDs.
This is also the way usb_modeswitch (via wrapping script) is
handling ambiguities right now.
(BTW, the next version has no more compiler warnings. No big deal.)
Cheers,
Josua
next prev parent reply other threads:[~2009-12-17 13:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-15 12:06 [PATCH] move eject code from zd1211rw to usb-storage Stefan Seyfried
2009-12-15 12:31 ` Josua Dietze
2009-12-15 14:01 ` Stefan Seyfried
2009-12-15 14:59 ` Josua Dietze
2009-12-15 17:58 ` [usb-storage] " Matthew Dharm
2009-12-15 15:11 ` Oliver Neukum
2009-12-15 18:03 ` Matthew Dharm
2009-12-16 10:29 ` Oliver Neukum
2009-12-16 11:42 ` Josua Dietze
2009-12-16 18:03 ` Matthew Dharm
2009-12-16 19:50 ` Dan Williams
2009-12-16 19:52 ` Matthew Dharm
2009-12-17 13:02 ` Oliver Neukum
2009-12-17 13:33 ` Josua Dietze [this message]
2009-12-17 14:36 ` Oliver Neukum
2009-12-17 18:21 ` Matthew Dharm
2009-12-16 10:49 ` Stefan Seyfried
2009-12-16 11:22 ` Josua Dietze
2009-12-16 12:14 ` Stefan Seyfried
2009-12-16 14:05 ` John W. Linville
2009-12-16 16:47 ` Dan Williams
2009-12-16 19:12 ` Matthew Dharm
2009-12-16 11:23 ` Oliver Neukum
2009-12-17 10:41 ` [usb-storage] " Daniel Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B2A3312.104@draisberghof.de \
--to=digidietze@draisberghof.de \
--cc=dcbw@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=oliver@neukum.org \
--cc=seife@sphairon.com \
--cc=stefan.seyfried@googlemail.com \
--cc=usb-storage@lists.one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).