[PATCH 2/2] ASoC: hdmi-codec: add channel mapping control

[Arnaud Pouliquen]

On 12/12/2016 03:05 PM, Takashi Sakamoto wrote:
> On Dec 12 2016 21:55, Takashi Iwai wrote:
>> On Mon, 12 Dec 2016 13:12:16 +0100,
>> Takashi Sakamoto wrote:
>>>
>>> On Dec 12 2016 18:54, Takashi Iwai wrote:
>>>>>>> +enum hdmi_codec_cea_spk_placement {
>>>>>>> +	FL  = (1 <<  0),	/* Front Left           */
>>>>>>> +	FC  = (1 <<  1),	/* Front Center         */
>>>>>>> +	FR  = (1 <<  2),	/* Front Right          */
>>>>>>> +	FLC = (1 <<  3),	/* Front Left Center    */
>>>>>>> +	FRC = (1 <<  4),	/* Front Right Center   */
>>>>>>> +	RL  = (1 <<  5),	/* Rear Left            */
>>>>>>> +	RC  = (1 <<  6),	/* Rear Center          */
>>>>>>> +	RR  = (1 <<  7),	/* Rear Right           */
>>>>>>> +	RLC = (1 <<  8),	/* Rear Left Center     */
>>>>>>> +	RRC = (1 <<  9),	/* Rear Right Center    */
>>>>>>> +	LFE = (1 << 10),	/* Low Frequency Effect */
>>>>>>> +};
>>>>>>
>>>>>> BIT() macro in "linux/bitops.h" is available.
>>>>> will be corrected in a v2
>>>>
>>>> One slight caution: BIT() expands to an unsigned long type.
>>>
>>> Mmm, indeed. This is my wrong indication, sorry.
>>> Thanks for your correction.
>>
>> Well, it's not necessarily wrong.  My point is that it requires
>> caution sometimes, as it's not blindly convertible.
>> In short: it depends on the code.
> 
> Hm. Here, I prefer to avoiding needless type-coversions, especially 
> between 'signed' and 'unsigned'. In C semantics of enumerator 
> specifiers, these values are handled as 'int' type. On the other hand, 
> the BIT() macro has 'UL' suffix.
> 
> In short: carefulness.
I will have a look if reasonable or not to integrate use of BIT ...

Arnaud