On Thu, Aug 16, 2012 at 03:47:15PM +0200, Sebastian Andrzej Siewior wrote: > On 08/16/2012 03:17 PM, Andrzej Pietrasiewicz wrote: > >A lun is "opened" on storing the "file" attribute of the lun, it is in > >fsg_lun_store_file, storage_common.c. So, again, this is a configfs > >callback. > > > >On storing the connect attribute, the following happens: a composite driver > >is probed, then all the configurations are iterated over, their functions > >being bound in turn. After the gadget is set up this way, the host notices > >connecting a new mass storage device. > > The configuration has to remain unchanged until the "connect" attribute > is changed (i.e. unconnected). That means the gadget can only be > reconfigured once it is not active. Yes, that's my understanding of the driver code. What I'm trying to understand is the trigger for setting connect=1. See, all of the other configfs steps you outlined make sense to me as "part of the gadget's internal state". While I don't know what C1 and F1 are (I assume G1 is Gadget1), I don't know that it matters. What changes the state to "active"? That is, what triggers setting connect=1? Is it just part of the flow of power-up, or is there some separation between "setting myself up" and "seeing that a host wants to talk to me"? Joel -- "The trouble with being punctual is that nobody's there to appreciate it." - Franklin P. Jones http://www.jlbec.org/ jlbec@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
