> >> @@ -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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
