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
