[PATCH -next 2/5] ASoC: fsl_asrc: force cast the asrc_format type

David Laight David.Laight at ACULAB.COM
Tue Jul 19 22:39:42 AEST 2022


grrr... top-posting because outluck is really stupid :-(

The definition seems to be:
typedef int __bitwise<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/__bitwise> snd_pcm_format_t<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/snd_pcm_format_t>;
#define SNDRV_PCM_FORMAT_S8<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/SNDRV_PCM_FORMAT_S8>    ((__force<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/__force> snd_pcm_format_t<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/snd_pcm_format_t>) 0)
#define SNDRV_PCM_FORMAT_U8<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/SNDRV_PCM_FORMAT_U8>    ((__force<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/__force> snd_pcm_format_t<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/snd_pcm_format_t>) 1)
#define SNDRV_PCM_FORMAT_S16_LE<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/SNDRV_PCM_FORMAT_S16_LE>        ((__force<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/__force> snd_pcm_format_t<https://elixir.bootlin.com/linux/v5.19-rc7/C/ident/snd_pcm_format_t>) 2)
...
(goes away and looks up __bitwIse)

I think I’d add:
#define snd_pcm_format(val) ((__force snd_pcm_format_t)(val))
and use that to remove most of the casts.
But the ones where you have (u32 *)&xxx are only valid because u32 and int are the same size.
That does sort of happen to be true, but someone might look at all the values and
decide that u8 is big enough.
After which the code will still compile, but the data areas get corrupted.
So you really need to use a u32 ‘temp’ variable.

It would all be slightly less problematic if the ‘force’ casts could be sparse only
(ie not seen by the compiler) – so the compiler would do the type checking.

                David

From: Shengjiu Wang <shengjiu.wang at gmail.com>
Sent: 19 July 2022 12:07
To: David Laight <David.Laight at ACULAB.COM>
Cc: Mark Brown <broonie at kernel.org>; Shengjiu Wang <shengjiu.wang at nxp.com>; Xiubo.Lee at gmail.com; festevam at gmail.com; nicoleotsuka at gmail.com; lgirdwood at gmail.com; perex at perex.cz; tiwai at suse.com; alsa-devel at alsa-project.org; linuxppc-dev at lists.ozlabs.org; linux-kernel at vger.kernel.org
Subject: Re: [PATCH -next 2/5] ASoC: fsl_asrc: force cast the asrc_format type



On Tue, Jul 19, 2022 at 6:34 PM David Laight <David.Laight at aculab.com<mailto:David.Laight at aculab.com>> wrote:
From: Mark Brown
> Sent: 19 July 2022 11:17
>
> On Tue, Jul 19, 2022 at 10:01:54AM +0000, David Laight wrote:
> > From: Shengjiu Wang
>
> > > - ret = of_property_read_u32(np, "fsl,asrc-format", &asrc->asrc_format);
> > > + ret = of_property_read_u32(np, "fsl,asrc-format", (u32 *)&asrc->asrc_format);
>
> > Ugg, you really shouldn't need to do that.
> > It means that something is badly wrong somewhere.
> > Casting pointers to integer types is just asking for a bug.
>
> That's casting one pointer type to another pointer type.

It is casting the address of some type to a 'u32 *'.
This will then be dereferenced by the called function.
So the original type better be 32 bits.

I'm also guessing that sparse was complaining about endianness?
It isn't at all clear that these casts actually fix it.
The sparse is complaining about the snd_pcm_format_t cast to u32/int type.

The code in include/sound/pcm.h also does such __force cast.
#define _SNDRV_PCM_FMTBIT(fmt)          (1ULL << (__force int)SNDRV_PCM_FORMAT_##fmt)

The change I have made does not cause an issue.

Best regards
Wang shengjiu

(Mark: You'll be glad to hear that the office aircon is
broken again - two weeks lead time on the spare part.)

        David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20220719/969651a7/attachment-0001.htm>


More information about the Linuxppc-dev mailing list