On 08/24/2012 11:53 PM, Michal Nazarewicz wrote:
I wouldn't duplicate the documentation. One in header file should be
enough.
I think I go for the .c file where this is implemented. If you change
the .c file most people don't care about the header file.
+int usb_gadget_controller_number(struct usb_gadget *gadget)
+{
+ if (gadget_is_net2280(gadget))
+ return 0x01;
.. snip...
+ else if (gadget_is_lpc32xx(gadget))
+ return 0x33;
+
+ return -ENOENT;
+}
How about using a table with a loop. For instance something like:
int usb_gadget_controller_number(struct usb_gadget *gadget)
{
static const char *const map[] = {
"\x01net2280",
..snip..
"\x33lpc32xx_udc",
};
const char *const *it = map, *const *end = map + ARRAY_SIZE(map);
const char *const name = gadget->name;
for (; it != end; ++it) {
if (!strcmp(name, *it + 1))
return (unsigned char)**it;
}
return -ENOENT
}
Something less fancy should also do.
I am a friend of explicit naming and less hacks. And if you sort the
map then you have less reads to get to the last entry. This can be
limited even further if make it a member of a struct.
Which brings me to: How important is this function?
- hacks / limitations should be implement differently i.e. a feature
bitmap
- do we need a unique bcd value across all udcs? Is somebody using
this? Useful?
Most of my device have either 1.00 or 2.00.
We set this to 0x200 + UDC number. Why? Why the 0x200? The spec says
"device release number" and "release number" is defined as 0xJJMN
(with J major, M minor, N sub minor minor). I don't say we have to
follow this I just for a sane reason and a use case.
Using here something like 0x305 for kernel version 3.5 would be a
little more useful. We would know that the kernel on this device is
based on v3.5 (plus a big number of patches on top).
Sebastian
--
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
