From: Vineet Gupta <vgupta@kernel.org>
To: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"kernel test robot" <lkp@intel.com>,
"Cezary Rojewski" <cezary.rojewski@intel.com>,
alsa-devel@alsa-project.org, broonie@kernel.org
Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com,
pierre-louis.bossart@linux.intel.com, tiwai@suse.com,
hdegoede@redhat.com, Geert Uytterhoeven <geert@linux-m68k.org>,
Vineet Gupta <vgupta@kernel.org>,
kbuild-all@lists.01.org, cujomalainey@chromium.org,
lma@semihalf.com
Subject: Re: [PATCH v2 11/15] ASoC: Intel: avs: Machine board registration
Date: Fri, 13 May 2022 19:49:54 -0700 [thread overview]
Message-ID: <c8875143-87b7-9ece-8613-b8d90acb4526@kernel.org> (raw)
In-Reply-To: <bb6e1945-df7e-f339-ea69-05248d480af3@linux.intel.com>
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
>> base:
>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>> for-next
>> config: arc-allyesconfig
>> (https://download.01.org/0day-ci/archive/20220509/202205091954.7hT2TBhd-lkp@intel.com/config)
>> compiler: arceb-elf-gcc (GCC) 11.3.0
>> reproduce (this is a W=1 build):
>> wget
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>> -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> #
>> https://github.com/intel-lab-lkp/linux/commit/2ef25400a7aee5a8e75c2ccdb5618be31c9f6809
>> git remote add linux-review
>> https://github.com/intel-lab-lkp/linux
>> git fetch --no-tags linux-review
>> Cezary-Rojewski/ASoC-Intel-avs-Driver-core-and-PCM-operations/20220509-165656
>> git checkout 2ef25400a7aee5a8e75c2ccdb5618be31c9f6809
>> # save the config file
>> mkdir build_dir && cp config build_dir/.config
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0
>> make.cross W=1 O=build_dir ARCH=arc SHELL=/bin/bash sound/soc/intel/avs/
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>> All warnings (new ones prefixed by >>):
>>
>> In file included from include/linux/device.h:15,
>> from include/linux/acpi.h:15,
>> from sound/soc/intel/avs/board_selection.c:9:
>> sound/soc/intel/avs/board_selection.c: In function
>> 'avs_register_i2s_board':
>>>> sound/soc/intel/avs/board_selection.c:328:36: warning: format '%ld'
>>>> expects argument of type 'long int', but argument 5 has type 'int'
>>>> [-Wformat=]
>> 328 | dev_err(adev->dev, "Platform supports %d
>> SSPs but board %s requires SSP%ld\n",
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> include/linux/dev_printk.h:110:30: note: in definition of macro
>> 'dev_printk_index_wrap'
>> 110 | _p_func(dev, fmt,
>> ##__VA_ARGS__); \
>> | ^~~
>> include/linux/dev_printk.h:144:56: note: in expansion of macro
>> 'dev_fmt'
>> 144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev,
>> dev_fmt(fmt), ##__VA_ARGS__)
>> | ^~~~~~~
>> sound/soc/intel/avs/board_selection.c:328:17: note: in expansion
>> of macro 'dev_err'
>> 328 | dev_err(adev->dev, "Platform supports %d
>> SSPs but board %s requires SSP%ld\n",
>> | ^~~~~~~
>> sound/soc/intel/avs/board_selection.c:328:90: note: format string
>> is defined here
>> 328 | dev_err(adev->dev, "Platform supports %d
>> SSPs but board %s requires SSP%ld\n",
>> | ~~^
>> | |
>> | long int
>> | %d
>>
>>
>> vim +328 sound/soc/intel/avs/board_selection.c
>>
>> 318
>> 319 static int avs_register_i2s_board(struct avs_dev *adev,
>> struct snd_soc_acpi_mach *mach)
>> 320 {
>> 321 struct platform_device *board;
>> 322 int num_ssps;
>> 323 char *name;
>> 324 int ret;
>> 325
>> 326 num_ssps = adev->hw_cfg.i2s_caps.ctrl_count;
>> 327 if (fls(mach->mach_params.i2s_link_mask) > num_ssps) {
>> > 328 dev_err(adev->dev, "Platform supports %d SSPs but
>> board %s requires SSP%ld\n",
>> 329 num_ssps, mach->drv_name,
>> __fls(mach->mach_params.i2s_link_mask));
>> 330 return -ENODEV;
>> 331 }
>> 332
>> 333 name = devm_kasprintf(adev->dev, GFP_KERNEL,
>> "%s.%d-platform", mach->drv_name,
>> 334 mach->mach_params.i2s_link_mask);
>> 335 if (!name)
>> 336 return -ENOMEM;
>> 337
>> 338 ret = avs_i2s_platform_register(adev, name,
>> mach->mach_params.i2s_link_mask, mach->pdata);
>> 339 if (ret < 0)
>> 340 return ret;
>> 341
>> 342 mach->mach_params.platform = name;
>> 343
>> 344 board = platform_device_register_data(NULL,
>> mach->drv_name, mach->mach_params.i2s_link_mask,
>> 345 (const void *)mach, sizeof(*mach));
>> 346 if (IS_ERR(board)) {
>> 347 dev_err(adev->dev, "ssp board register failed\n");
>> 348 return PTR_ERR(board);
>> 349 }
>> 350
>> 351 ret = devm_add_action(adev->dev,
>> board_pdev_unregister, board);
>> 352 if (ret < 0) {
>> 353 platform_device_unregister(board);
>> 354 return ret;
>> 355 }
>> 356
>> 357 return 0;
>> 358 }
>> 359
>>
>
> 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 ?
Thx,
-Vineet
next prev parent reply other threads:[~2022-05-16 8:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 8:58 [PATCH v2 00/15] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 01/15] ASoC: Intel: avs: Account for libraries when booting basefw Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 02/15] ASoC: Intel: avs: Generic soc component driver Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 03/15] ASoC: Intel: avs: Generic PCM FE operations Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 04/15] ASoC: Intel: avs: non-HDA PCM BE operations Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 05/15] ASoC: Intel: avs: HDA " Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 06/15] ASoC: Intel: avs: Coredump and recovery flow Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 07/15] ASoC: Intel: avs: Prepare for firmware tracing Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 08/15] ASoC: Intel: avs: D0ix power state support Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 09/15] ASoC: Intel: avs: Event tracing Cezary Rojewski
2022-05-09 14:42 ` kernel test robot
2022-05-09 8:58 ` [PATCH v2 10/15] ASoC: Intel: avs: Replace link_mask usage with i2s_link_mask Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 11/15] ASoC: Intel: avs: Machine board registration Cezary Rojewski
2022-05-09 11:58 ` kernel test robot
2022-05-09 12:38 ` Amadeusz Sławiński
2022-05-14 2:49 ` Vineet Gupta [this message]
2022-05-14 13:20 ` Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 12/15] ASoC: Intel: avs: PCI driver implementation Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 13/15] ASoC: Intel: avs: Power management Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 14/15] ASoC: Intel: avs: SKL-based platforms support Cezary Rojewski
2022-05-09 8:58 ` [PATCH v2 15/15] ASoC: Intel: avs: APL-based " Cezary Rojewski
2022-05-17 17:21 ` [PATCH v2 00/15] ASoC: Intel: avs: Driver core and PCM operations Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8875143-87b7-9ece-8613-b8d90acb4526@kernel.org \
--to=vgupta@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=cujomalainey@chromium.org \
--cc=geert@linux-m68k.org \
--cc=harshapriya.n@intel.com \
--cc=hdegoede@redhat.com \
--cc=kbuild-all@lists.01.org \
--cc=lkp@intel.com \
--cc=lma@semihalf.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rad@semihalf.com \
--cc=tiwai@suse.com \
--cc=upstream@semihalf.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox