Dear All,
this is the fourth version of RFC regarding configfs integration
into the usb gadget. This is still a work in progress.
It is rebased onto 3.7-rc5 merged with Greg's latest usb-next
and Felipe's latest gadget branches.
It is not meant for merging yet, but rather to be discussed.
The USB Functions Gadget serves as a place to store the code
which can be summarized as "configfs-based binding". This kind of code
must be stored somewhere anyway. composite.c could be just as good
a place for that but for the moment I chose not to mess with it.
My intention is not to add new gadgets, but to promote the use of
usb function modules, e.g. f_mass_storage.ko.
Speaking about function modules, I use Sebastian's framework for
registering the functions:
69bc7b6346e032ade2a7aca022ec9c0e282e5f0b usb/gadget: add some
infracture to register/unregister functions
I don't use the usbf_option stuff, though, for the reasons I would
like to state below.
The usbf_opt has, in my opinion, the following features:
- assumes that usb functions remain as they are and are not aware
of being configured through configfs (which at a first glance
looks attractive, but there are problems, see below) and are totally
configfs-independent
- good only for a flat structure of configfs directories, i.e.
a function has only its one-level configfs directory with
no subdirectories
- good only for a static structure of configfs directories, i.e.
if, during function's lifetime, some subdirectories should
appear under its configfs directory, there's no way to pass this
information to the configfs part
- no possibility to pass an event from inside the function,
e.g. eject in mass storage
- easy to ensure backwards compatibility.
These featues in my opinion turn out to be unsatisfactory.
The very example is mass storage gadget which I ported to
the new framework.
The mass storage function requires a hierarchy of subdirectories,
not just one directory in configfs. With usbf_opt there is no
way to convey the information about this hierarchy from the
function to the configfs part. Of course Sebastian's proposal
could be extended to include the way of passing this kind
of information, but then it would make it overly complicated.
And this kind of hierarchy would be represented in two places:
one place would be the usb function and the other would be
the configfs part, so this effectively means doing the same
thing twice with the overhead of translating one hierarchy
representation to another.
The mass storage function needs a hierarchy of directories
to represent the function itself and its luns. It could be
configured the old way, with a comma-separated list of
values but this is ugly and a step backwards. A directories
hierarchy is thus required.
During its lifetime, the mass storage can require creating
lunX directories for its luns. And again, with usbf_option
there is no way to pass this event to the configfs part.
All in all, I think it is better not to force complete separation
of functions from their configfs parts. Instead, I propose
to extend the struct usb_function with 2 operations and extend
the functions with a configfs part dedicated to them.
I also show how to write an adapter module, which provides
the old sysfs-based interface to mass storage with module parameters,
but internally operates on configfs.
The patches 03 throuth 12 are not squashed in order to show the
steps involved in porting mass storage to the new framework,
but, ATTENTION, this means that if only some of them are applied,
the code may or may not compile. The patches may need checkpach.
v4:
Changes since v3:
- use Sebastian's function registration framework
- code cleanup and small improvements
- differently squashed commits in order to show the steps
v3:
Changes since v2:
- improved ufg_gadget_bind
- some attributes have real values instead of dummy values
- added interfaces and endpoints directories in configfs
- added a local header file in drivers/usb/gadget
Andrzej Pietrasiewicz (13):
usb: composite: add make_group and add_function operations
usb: gadget: Add USB Functions Gadget
usb: gadget: example port of mass storage to UFG: create
storage_common.h and factor out code from storage_common.c
usb: gadget: example port of mass storage to UFG: storage common:
change struct device to configfs entities
usb: gadget: example port of mass storage to UFG: storage common: add
configfs type
usb: gadget: example port of mass storage to UFG: create
f_mass_storage.h and factor out code from f_mass_storage.c
usb: gadget: example port of mass storage to UFG: f_mass_storage:
remove sysfs handling
usb: gadget: example port of mass storage to UFG: f_mass_storage:
remove unused operations
usb: gadget: example port of mass storage to UFG: f_mass_storage:
change array of fsg_lun to config_group
usb: gadget: example port of mass storage to UFG: f_mass_storage:
split fsg_common_init
usb: gadget: example port of mass storage to UFG: f_mass_storage: add
configfs type
usb: gadget: example port of mass storage to UFG: f_mass_storage: use
new function registration framework
usb: gadget: ufg: add Mass Storage Gadget adapter to UFG
drivers/usb/gadget/Kconfig | 25 +
drivers/usb/gadget/Makefile | 9 +
drivers/usb/gadget/f_mass_storage.c | 828 ++++++++++++-------------
drivers/usb/gadget/f_mass_storage.h | 96 +++
drivers/usb/gadget/storage_common.c | 173 ++++---
drivers/usb/gadget/storage_common.h | 43 ++
drivers/usb/gadget/ufg_mass_storage.c | 608 +++++++++++++++++++
drivers/usb/gadget/usb_functions.c | 1067 +++++++++++++++++++++++++++++++++
drivers/usb/gadget/usb_functions.h | 100 +++
include/linux/usb/composite.h | 6 +
10 files changed, 2456 insertions(+), 499 deletions(-)
create mode 100644 drivers/usb/gadget/f_mass_storage.h
create mode 100644 drivers/usb/gadget/storage_common.h
create mode 100644 drivers/usb/gadget/ufg_mass_storage.c
create mode 100644 drivers/usb/gadget/usb_functions.c
create mode 100644 drivers/usb/gadget/usb_functions.h
--
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
