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

[Guenter Roeck]

On 5/26/22 09:31, Cezary Rojewski wrote:
> On 2022-05-26 6:24 PM, Guenter Roeck wrote:
>> On Mon, May 16, 2022 at 12:11:12PM +0200, Cezary Rojewski wrote:
>>> AVS driver operates with granular audio card division in mind.
>>> Super-card approach (e.g.: I2S, DMIC and HDA DAIs combined) is
>>> deprecated in favour of individual cards - one per each device. This
>>> provides necessary dynamism, especially for configurations with number
>>> of codecs present and makes it easier to survive auxiliary devices
>>> failures - one card failing to probe does not prevent others from
>>> succeeding.
>>>
>>> All boards spawned by AVS are unregistered on ->remove(). This includes
>>> dummy codecs such as DMIC.
>>>
>>> As all machine boards found in sound/soc/intel/boards are irreversibly
>>> tied to 'super-card' approach, new boards are going to be introduced.
>>> This temporarily increases number of boards available under /intel
>>> directory until skylake-driver becomes deprecated and removed.
>>>
>>> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski at linux.intel.com>
>>> Signed-off-by: Cezary Rojewski <cezary.rojewski at intel.com>
>>> ---
> 
> 
>>> +
>>> +static int avs_register_i2s_board(struct avs_dev *adev, struct snd_soc_acpi_mach *mach)
>>> +{
>>> +    struct platform_device *board;
>>> +    int num_ssps;
>>> +    char *name;
>>> +    int ret;
>>> +
>>> +    num_ssps = adev->hw_cfg.i2s_caps.ctrl_count;
>>> +    if (fls(mach->mach_params.i2s_link_mask) > num_ssps) {
>>> +        dev_err(adev->dev, "Platform supports %d SSPs but board %s requires SSP%ld\n",
>>
>>     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",
>>                                                                                                    ^^^
>>
>> Reported by 0-day but still made it into mainline.
> 
> 
> Hello,
> 
> Thanks for the report. This seems to be a false-positive and is being addressed by a separate patchset [1]. Perhaps the cover letter for the mentioned series could have looped 0-day.

No, this is not a false positive. More like a false assumption.

> If I'm wrong about this, feel free to correct me.
> 
> 
> [1]: https://lore.kernel.org/lkml/20220525144844.1571705-1-amadeuszx.slawinski@linux.intel.com/
> 
This is incomplete. It does not address all definitions of __fls() for arc, and it
does not address the build failure for sparc64 (arch/sparc/include/asm/bitops_64.h).

Guenter