Dne 31.3.2017 v 11:01 Laurent Pinchart napsal(a):
> Hi Felipe and Petr,
>
> On Tuesday 28 Mar 2017 16:48:46 Felipe Balbi wrote:
>> Petr Cvek <petr.cvek@xxxxxx> writes:
>>> Dne 7.3.2017 v 06:58 Laurent Pinchart napsal(a):
>>>> On Tuesday 07 Mar 2017 00:57:20 Petr Cvek wrote:
>>>>> Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
>>>>> methods") caused a stringification of an undefined macro argument
>>>>> "aname", so three UVC parameters (streaming_interval,
>>>>> streaming_maxpacket and streaming_maxburst) were named "aname".
>>>>>
>>>>> Add the definition of "aname" to the main macro and name the filenames
>>>>> as originaly intended.
>>>>
>>>> Why don't you just
>>>>
>>>> - UVC_ATTR(f_uvc_opts_, cname, aname)
>>>> + UVC_ATTR(f_uvc_opts_, cname, cname)
>>>>
>>>> in the definition of the UVCG_OPTS_ATTR() macro ?
>>>
>>> Hi,
>>>
>>> In a fact I did it for my first testing version. But then I realized
>>> two things. First one is that someone may want to rename these three
>>> files (now or in the future). The second one is that this bug was
>>> caused by original author, who probably assumed the UVCG_OPTS_ATTR
>>> macro had "aname" argument as others UVCG_* macros and didn't check. I
>>> assumed that too and only after I saw three "aname" files with the
>>> same path I realized where is the problem.
>>>
>>> So it's more like a human error prone type of a code. But if you think
>>> "cname" is enough I can send PATCH v2.
>
> I think it would be, otherwise we end up passing the same argument twice,
> which seems a bit useless to me. If we ever need to rename those files we can
> always change the code later.
... or if the variables, which need to be renamed (and userapi filenames to be kept).
>
> It's no big deal, but I have a preference for my proposal.
>
Any way I've sent your suggested version, you can choose whichever you like ;-).
cheers,
Petr
--
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
