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
