[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <cover.1277972135.git.mina86@mina86.com>
Date: Thu, 01 Jul 2010 11:17:41 +0200
From: Michal Nazarewicz <m.nazarewicz@...sung.com>
To: linux-usb@...r.kernel.org
Cc: David Brownell <dbrownell@...rs.sourceforge.net>,
Kyungmin Park <kyungmin.park@...sung.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH/RFC 0/2] The Experimental Composite Gadget
Hello,
The following two patches add an “Experimental Composite Gadget”
which is “Multifunction Composite Gadget” with FunctionFS and an
“Install Mode”.
An “Install Mode” is a mode where just after the device is connected
it reports as a mass storage device (single configuration, single
interface) with first logical unit being an removable CD-ROM.
The idea is that the logical unit provides a disk image with drivers
for the main device. This way no additional data storage is needed
to make the device operational with hosts (i.e. no CD-ROM with
drivers needed).
When an eject is issued on the first logical unit the device switches
to a normal mode with all the other functionalities. When device is
disconnected and connected again it switches back to the install
mode.
The switching is done by calling usb_composite_unregister() followed
by usb_composite_register(). The same approach is used in the
FunctionFS Gadget included in the kernel.
This is the main point I'd like to discuss. What would be the best
way of switching device's configuration?
The best would be if it were possible to “reregister” the usb
composite device which would once again call the bind function.
Does that make sense? Should I go and implement such a call to the
composite device?
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
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