[2/3] usb: gadget: configfs: Create control_config group

[Jerry Zhang <zhangjerry@google.com>]

> >> @@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(
> >>      if (!gi->composite.gadget_driver.function)
> >>              goto err;
> >>
> >> +    gi->control_config.c.label = "control_config";
> >> +    /* composite requires some value, but it doesn't matter */
> >> +    gi->control_config.c.bConfigurationValue = 42;
> >
> > If I understand correctly this is never exposed to the host, is it?
That's right. It won't be in cdev so it doesn't show up in the actual
descriptors and as such can't be enabled.

> >
> >> +    INIT_LIST_HEAD(&gi->control_config.func_list);
> >> +    config_group_init_type_name(&gi->control_config.group,
> >> +                    "control_config", &gadget_config_type);
> >> +    configfs_add_default_group(&gi->control_config.group, &gi->group);
> >
> > Since it is a config I'd rather this be put inside the "configs" group.
> > Configs created by the user must be named following the
> > <config name>.<bConfigurationValue> pattern, so there will be no
conflict
> > with any other conf. The name can be "control" then.
> >

> Answering my own doubts: this could be ok from the kernel point of view,
> but existing userspace (libusbgx) already assumes that in the configs
directory
> there are only entries of the form <config>.<number> and anything other
than that
> will cause it to report error.
Makes sense. I would be fine either way but it sounds like we're stuck
because of that library.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html