Re: [PATCH 2/2] usb: gadget: convert all users to the new udc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Jun 10, 2011 at 05:49:31PM -0400, Alan Stern wrote:
> > I don't really remember that, so I might have missed. OTOH, composite.c
> > is fairly simple and the only gadget driver not using it is
> > file_storage.c, but having a f_msc.c wouldn't hurt.
> 
> We already have f_mass_storage.c.  There are two different versions of 
> the storage gadget: my original standalone driver and Michal's 
> adaptation to the composite framework.  Are you suggesting that I bite 
> the bullet and withdraw g_file_storage?

I'm suggesting that we don't need two implementations for the same
thing, see that when g_ether was converted to composite.c, its functions
were phased out to f_ecm.c, f_ether.c and f_subset.c and the old ether.c
became just a simple layer to tie things up together.

Why was g_file_storage done differently, I don't know ;-)

> > keep reading. The idea is to move the otg notifier to be a UDC notifier.
> > Most of the notifications are from the gadget anyway: Suspend, Resume,
> > Enumerated with xxx mA configuration, etc.
> 
> But what does this have to do with all the inline operations in
> gadget.h?  For example, what is the connection between otg notifiers
> and usb_ep_enable()?

Well, I'm not sure adding a notification to all those inlines will be
nice. But that's up to interpretation.

> > exactly... if removable == 1, it means we're a card-reader (or CDROM) so
> > we can connect to host even without a backing file ;-)
> 
> No, no -- consider what happens when removable == 0.  If you wait until
> a filename is echoed to the "file" sysfs attribute, you'll be waiting a
> long time because the attribute will be read-only.

Yes, that's the other side. Let me try in C (english is so difficult):

static int storage_open(...)
{
	....

	ret = filp_open();

	if (!removable && ret == 0)
		usb_function_activate(storage);
}

static int storage_bind(..)
{
	...

	if (removable)
		usb_function_activate(storage_to_function(stor));

	return 0;
}

See ? So, if we have "removable" set to one, we connect straight away,
but if we don't there's no reason to connect to host until we have the
backing file opened. So, if we fail opening the backing file, we
shouldn't even connect to host IMHO.

> > well, I though you would have gotten the point. The thing is that there
> > is a duplication there. All controllers have to "bypass" usb_ep_queue()
> > and that's always a bit tricky to get right. So, if we know every
> > controller will _have_ to start a ep0-out transfer to receive the first
> > USB Setup Packet, then we can combine that on an upper layer and free
> > all controllers from having to do that.
> 
> The gadget framework doesn't use usb_ep_queue() to start a control
> transfer on ep0.  It is used only for the data and status stages, not
> the setup stage.  Which means that _no_ controller has to start an
> ep0-out transfer to receive the first Setup packet.

ok ok, that pretty much depends on the controller. The one I'm working
now will only receive a packet if I kick ep0-out transfer to start up
the internal DMA engine ;-)

While it's a simple case, the setup stage seems always different than
the data stage.

> > Well, at least I've put 3 products on the market, all of them got USB
> > certification. Does that count ;-) ?
> 
> Hmmm...  I have a Mobile Internet Device made by some Chinese company
> that runs g_file_storage by default.  The backing file is a partition
> on an SD card -- and that partition is also mounted at the same time,
> which is strictly against the rules.  This suggests that many of the
> people using the gadget software don't have a very good idea of what
> they're doing.

Tricky comparisson you've made heh. But you can check if any of n800,
n810 or n900 do something like that ;-)

Back at Nokia we would unmount the eMMC partition in order to export via
mass storage. Many people have asked me to put something similar to what
you're describing here, never got to do it :-p

If you want simultaneous access to the media via USB and via the device
itself, you should be using something like MTP instead.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux