From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
To: "'Joel Becker'" <jlbec@evilplan.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
"'Kyungmin Park'" <kyungmin.park@samsung.com>,
"'Felipe Balbi'" <balbi@ti.com>,
"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>,
"'Sebastian Andrzej Siewior'" <bigeasy@linutronix.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"'Alan Stern'" <stern@rowland.harvard.edu>
Subject: RE: [RFC 0/2] USB gadget - configfs
Date: Thu, 16 Aug 2012 15:17:12 +0200 [thread overview]
Message-ID: <000101cd7bb1$73f36050$5bda20f0$%p@samsung.com> (raw)
In-Reply-To: <20120815081331.GL31083@dhcp-172-17-9-228.mtv.corp.google.com>
Hello Joel,
Thank you for your reply. Please find comments inline.
On Wednesday, August 15, 2012 10:14 AM Joel Becker wrote:
<snip>
> > So, the config item corresponding to the lun becomes depended on during
> > the write file operation, the same with undepend. Can this be expressed
> > with configfs_depend/undepend_item()? Your code in fs/configfs/dir.c
> > contains a warning not to call the configfs_depend_item()
> > from a configfs callback.
> > In this case, is store_attribute a configfs callback?
>
<snip>
> Yes, attribute store is a callback. So what should you do?
> This is where my understanding of your setup logic fails me. At first I
> thought fsg_bind_function() was the right place, because it is where you
> expect the LUNs to already be configured. But it is, in turn, called
> underneath another configfs callback (ufg_gadget_grp_store_connect()).
> Can you help me understand the userspace steps that are used to
> set up a gadget? The way I read the code, there is some software in the
> gadget that sets up the LUN mappings; that is, the host has no idea
> "lun01" is backed by a file named "foo". So, if you had a gadget that
> just exposed a single LUN, it would have some userspace software at
> startup that sets fua=1, removable=0, ro=0, file="foo". At some future
> point, the host connects to the gadget. At this point, lun01 is
> connected to the host, and it had better not disappear. What part of
> the code reacts to the host connect? This is the "open" of the LUN
> where I think you should be locking out.
>From userspace the procedure to set up a gadget looks like this:
(please note that for testing I use _very_ short names like
G1, C1, F1; these are not mandatory and, as already pointed out
by some, more descriptive names should be used)
$ insmod g_usb_functions.ko
$ mount -t configfs none /cfg
$ mkdir -p /cfg/usb-function-gadget/G1/C1/F1
$ echo -n <some id> > /cfg/usb-function-gadget/G1/idVendor
$ echo -n <some id> > /cfg/usb-function-gadget/G1/idProduct
$ echo -n 0xff > /cfg/usb-function-gadget/G1/bcdDevice
$ echo Manufacturer > /cfg/usb-function-gadget/G1/iManufacturer
$ echo 123abc > /cfg/usb-function-gadget/G1/iSerialNumber
$ echo Gadget > /cfg/usb-function-gadget/G1/iProduct
$ echo -n f_mass_storage > /cfg/usb-function-gadget/G1/C1/F1/name
$ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage
$ echo -n 1 > /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/luns
$ mkdir /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0
$ echo -n /root/file.img >
/cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0/file
$ echo -n 1 > /cfg/usb-function-gadget/G1/connect
The mapping between luns and their backing files is maintained in
alloc_fsg_lun,
f_mass_storage.c; the function needs improvement. The intended logic is not
to
allow more than 1 lun of the same name at the same time.
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.
So it seems the only chance to call config_item_depend is in a configfs
callback. Or is it?
Thanks,
Andrzej
next prev parent reply other threads:[~2012-08-16 13:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-21 10:55 [RFC 0/2] USB gadget - configfs Andrzej Pietrasiewicz
2012-06-21 10:55 ` [RFC 1/2] fs: configfs: add check_rmdir operation Andrzej Pietrasiewicz
2012-07-02 8:49 ` Joel Becker
2012-06-21 10:55 ` [RFC 2/2] usb: gadget: Add USB Functions Gadget Andrzej Pietrasiewicz
2012-06-21 11:34 ` [RFC 0/2] USB gadget - configfs Sebastian Andrzej Siewior
2012-06-24 19:50 ` Sebastian Andrzej Siewior
2012-06-25 14:11 ` Alan Stern
2012-07-03 16:15 ` Felipe Balbi
2012-07-02 9:09 ` Joel Becker
2012-07-10 8:54 ` Andrzej Pietrasiewicz
2012-08-15 8:13 ` Joel Becker
2012-08-16 13:17 ` Andrzej Pietrasiewicz [this message]
2012-08-16 13:47 ` Sebastian Andrzej Siewior
2012-08-17 1:46 ` Joel Becker
2012-08-17 9:22 ` Sebastian Andrzej Siewior
2012-08-17 10:30 ` Andrzej Pietrasiewicz
2012-08-17 10:34 ` Sebastian Andrzej Siewior
2012-08-20 5:59 ` Joel Becker
2012-08-20 8:53 ` Andrzej Pietrasiewicz
2012-08-20 11:17 ` Joel Becker
2012-08-20 11:01 ` Sebastian Andrzej Siewior
2012-08-20 11:19 ` Joel Becker
2012-08-21 8:19 ` Andrzej Pietrasiewicz
2012-08-29 19:52 ` Sebastian Andrzej Siewior
2012-08-29 13:17 ` Andrzej Pietrasiewicz
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='000101cd7bb1$73f36050$5bda20f0$%p@samsung.com' \
--to=andrzej.p@samsung.com \
--cc=balbi@ti.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=jlbec@evilplan.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=stern@rowland.harvard.edu \
/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).