On 04/03/14 08:01, Daniel Mack wrote:
> Hi Damien,
> 
> Thanks for your patch! See my two comments below.
> 
> On 01/27/2014 04:02 AM, Damien Zammit wrote:
>> On 27/01/14 03:52, Clemens Ladisch wrote:
>>>>>> This patch creates a dual endpoint quirk.
>>>>>>>> The quirk interface needs a second audioformat struct for this to work
>>>>>>>> which I called ".data2".
>>>> Couldn't you just let .data point to an array of two structs?
>> Thanks Clemens, I have created a new patch using this suggestion.
> 
> [...]
> 
>> +	fp2 = kmemdup((const struct audioformat*)(quirk->data + sizeof(const struct audioformat)), sizeof(*fp2), GFP_KERNEL);
>> +	if (!fp2) {
>> +		snd_printk(KERN_ERR "cannot memdup 2\n");
>> +		return -ENOMEM;
>> +	}
>> +	if (fp1->nr_rates > MAX_NR_RATES) {
>> +		kfree(fp1);
>> +		kfree(fp2);
> 
> Please do proper error unwinding here with jump labels rather than
> open-coding the kfree() calls from multiple places.
> 
> Also, I wonder whether a more generic quirk type to set up a dynamic
> number of fixed interfaces wouldn't be nicer. IOW, add a field to struct
> snd_usb_audio_quirk to denote the number of array members in quirk->data
> and call the quirk type QUIRK_AUDIO_FIXED_MULTI_ENDPOINT or something.
> Then, rewrite the logic to iterate over the interfaces in a loop. That
> might also make the code more readable.

Hi Daniel, Clemens,
I have addressed the above issues, please find attached my new patch.
I did a proper git log message that describes my changes.  I am keen to
get this reviewed and hopefully accepted soon.
I did a clean clone of Takashi's 'sound' (for-next) and applied my
changes on top of that.

Damien