Hello Chris,
W dniu 22.01.2015 o 15:37, Chris McClimans pisze:
The devices in embedded space accept kernel updates at various speeds.
The raspberry pi is at 3.18, and the Intel Edison is bit lagging at 3.10.
I thought it would probably be useful to the embedded community if I at
least took a stab at back porting the hid gadgetfs function to 3.18 for use
There is no gadgetfs hid implementation, at least there are none
that I am aware of.
These days instead of gadgetfs one should probably use FunctionFS.
The purpose of the two is delegating actual usb function implementation
to userspace with some filesystem being the interface to the kernel.
And ConfigFS is a totally different thing: in the context of usb gadgets
it serves the purpose of composing gadgets of different usb functions
at runtime. The kernel versions and function names you mention below
suggest that you mean ConfigFS.
on the raspberry pi. Going farther back with more modules if there is interest.
I searched through the kernel source and I think I've found the definitive
list of gadget functions (grepping for DECLARE_USB_FUNCTION_INIT),
You should also grep for DECLARE_USB_FUNCTION
and then you would find:
SourceSink
Loopback
which, in legacy gadgets, are components of gadget zero (g_zero),
the "first" gadget by David Brownell.
The two functions serve testing purposes and their names suggest
their use. They are also available for composing gadgets with configfs.
and noted when they were introduced.
It is likely that uvc will land in 3.20, so you might also be preparing for
3.20 uvc
3.19 midi, hid
3.18 uvc, uac2, uac1
3.14 fs
3.13 mass_storage
3.11 subset, rndis, phonet, ncm, eem, ecm
3.10 serial, obex, acm
I figured this list was probably the best place to ask if there were any
caveats to taking usb/gadget/function/f_hid.c back one kernel rev.
With hid specifically it is likely you will just cherry pick a couple
of commits and solve some trivial conflicts (like in Makefile or Kconfig).
On Tue, Jan 13, 2015 at 11:49 AM, Felipe Balbi <balbi@xxxxxx> wrote:
then you need to backport patches yourself. The community can't really
support older kernels :-)
I guess you don't have other way but keep in mind you'll, essentially,
be on your own
Any obvious dragons be aware of before I head out on my own?
If you decide to backport anything to 3.10, you must take this into
consideration:
Apart from some changes in the usb functions themselves,
at some point in time there happended refactoring of the gadget
directory. I guess it was sometime between 3.14 and 3.18.
Before the refactoring all the source code files related to gadgets
implementation had resided in drivers/usb/gadget. Since the refactoring
there are dedicated directories: functions, udc and legacy.
"functions" dir contains actual usb function implementations, "udc" dir
contains USB Device Controller implementations (except dual role devices
like dwc2 or dwc3) and "legacy" dir contains traditional gadgets,
composed at compilation time. The change also affected Makefiles
and Kconfigs. That said, git might be smart enough to treat most of the
refactoring changes merely as "renames".
Is there a better list to or talk/discuss backporting of usb gadget functions?
I guess there is no other list where people know more
about usb gadgets in Linux.
But when it comes to backporting you are on your own,
as Felipe said. If I were you, I would be targeting 3.18.
By the time you will have been done at least the 3.20 (or newer)
will be the state-of-the art kernel. My personal view is
that supporting 3.10 at that time makes no sense.
AP
--
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
