[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B2A3312.104@draisberghof.de>
Date: Thu, 17 Dec 2009 14:33:06 +0100
From: Josua Dietze <digidietze@...isberghof.de>
To: Oliver Neukum <oliver@...kum.org>
CC: Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
Dan Williams <dcbw@...hat.com>,
Stefan Seyfried <stefan.seyfried@...glemail.com>,
linux-usb@...r.kernel.org, linux-wireless@...r.kernel.org,
linux-kernel@...r.kernel.org, usb-storage@...ts.one-eyed-alien.net,
Stefan Seyfried <seife@...airon.com>
Subject: Re: [PATCH] move eject code from zd1211rw to usb-storage
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists