Hello Felipe,
2017-03-10 10:15 GMT+01:00 Felipe Balbi <balbi@xxxxxxxxxx>:
>
> Hi,
>
> Romain Izard <romain.izard.pro@xxxxxxxxx> writes:
>> With commit "usb: gadget: don't couple configfs to legacy gadgets"
>> it is possible to build a modular kernel with both built-in configfs
>> support and modular legacy gadget drivers.
>>
>> But when building a kernel without modules, it is also necessary to be
>> able to build with configfs but without any legacy gadget driver.
>>
>> Mark the choice for legacy gadget drivers as optional.
>>
>> Fixes: bc49d1d17dcf ("usb: gadget: don't couple configfs to legacy gadgets")
>> Cc: <stable@xxxxxxxxxxxxxxx> # 4.9+
>
> this is *NOT* a fix since this requirement didn't exist before.
It worked in 4.1, as a non-modular kernel would only have a single entry
from the USB gadget driver choice option, and USB_CONFIGFS was one of
those.
When I moved on to 4.9, this configuration could not be selected anymore.
>
>> Signed-off-by: Romain Izard <romain.izard.pro@xxxxxxxxx>
>> ---
>> changes in v2:
>> - Reword description
>>
>> drivers/usb/gadget/Kconfig | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index 8ad203296079..e157e9aa4f3d 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -212,7 +212,7 @@ config USB_F_TCM
>> # this first set of drivers all depend on bulk-capable hardware.
>>
>> config USB_CONFIGFS
>> - tristate "USB functions configurable through configfs"
>> + tristate "USB Gadget functions configurable through configfs"
>
> unrelated change
>
>> select USB_LIBCOMPOSITE
>> help
>> A Linux USB "gadget" can be set up through configfs.
>> @@ -458,8 +458,9 @@ config USB_CONFIGFS_F_TCM
>> UAS utilizes the USB 3.0 feature called streams support.
>>
>> choice
>> - tristate "USB Gadget Drivers"
>> + tristate "USB Gadget precomposed configurations"
>
> unrelated change
>
>> default USB_ETH
>> + optional
>> help
>> A Linux "Gadget Driver" talks to the USB Peripheral Controller
>> driver through the abstract "gadget" API. Some other operating
>> @@ -476,6 +477,12 @@ choice
>> not be able work with that controller, or might need to implement
>> a less common variant of a device class protocol.
>>
>> + The available choices each represent a single precomposed USB
>> + gadget configuration. In the device model, each option contains
>> + both the device instanciation as a child for a USB gadget
>> + controller, and the relevant drivers for each function declared
>> + by the device.
>
> unrelated change
I'll split this.
Best regards,
--
Romain Izard