[PATCH v2 11/15] ASoC: Intel: avs: Machine board registration

[Cezary Rojewski]

On 2022-05-14 4:49 AM, Vineet Gupta wrote:
> On 5/9/22 18:08, Amadeusz Sławiński wrote:
>> On 5/9/2022 1:58 PM, kernel test robot wrote:
>>> Hi Cezary,
>>>
>>> I love your patch! Perhaps something to improve:
>>>
>>> [auto build test WARNING on broonie-sound/for-next]
>>> [also build test WARNING on next-20220506]
>>> [cannot apply to tiwai-sound/for-next v5.18-rc6]
>>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>>> And when submitting patch, we suggest to use '--base' as documented in
>>> https://git-scm.com/docs/git-format-patch]
>>>
>>> url: 
>>> https://github.com/intel-lab-lkp/linux/commits/Cezary-Rojewski/ASoC-Intel-avs-Driver-core-and-PCM-operations/20220509-165656 


...

>> Kernel test robot warns us about __fls and it is right, as __fls 
>> depending on architecture returns either unsigned int or unsigned long.
>> But I would say that this seems questionable, as I would expect 
>> consistent return value between arches, especially for functions where 
>> we operate on bits and probably don't want inconsistent results.
>>
>> Generic asm header [1] seems to suggest that it should accept unsigned 
>> long as parameter and return unsigned long. It seems however that arc 
>> accepts unsigned long as argument and returns int, while m68k uses int 
>> for argument and return value...
>>
>> Adding relevant architecture maintainers to CC.
>>
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/bitops/__fls.h 
>>
> 
> In generic code __fls() returns long, while fls() return int, which is 
> weird as well. Anyhow for this error, ARC indeed needs fixing.
> Do u want to send a patch ?


Thanks for your input, Vineet. Yes, either me or Amadeo will address the 
problem with a separate change. Consequently, this means we won't be 
addressing the warning reported here by the kernel test bot.

Regards,
Czarek