linux-kernel - Re: (subset) [PATCH v7 00/16] Add audio support for the MediaTek Genio 350-evk board

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZttucCV86ryyqIiT@finisterre.sirena.org.uk>
Date: Fri, 6 Sep 2024 22:04:48 +0100
From: Mark Brown <broonie@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Alexandre Mergnat <amergnat@...libre.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Lee Jones <lee@...nel.org>, Flora Fu <flora.fu@...iatek.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Christian König <christian.koenig@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, linux-media@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Nicolas Belin <nbelin@...libre.com>
Subject: Re: (subset) [PATCH v7 00/16] Add audio support for the MediaTek
 Genio 350-evk board

On Fri, Sep 06, 2024 at 12:23:23PM -0700, Nathan Chancellor wrote:
> On Fri, Sep 06, 2024 at 07:27:01PM +0100, Mark Brown wrote:
> > Are these just warnings introduced by recent versions of the toolchains?
> > These commits passed an x86 allmodconfig with GCC 12 at each step (I did
> > catch one warning there with another patch in the series that didn't get
> > applied) and 0day didn't say anything at any point.

> Not sure, I did not look too hard. At cursory glance, I am not sure x86
> allmodconfig would catch these, as this code depends on ARCH_MEDIATEK
> (not COMPILE_TEST), which only exists for arm and arm64.

Ah, I hadn't seen that (the other bits were building on x86).

> > > Clang 19:

> > That's relatively modern, though some of the warnings don't look
> > particularly new and exciting.

> Fair although I still see some of them on old versions too:

Yeah, like I say some of the warnings didn't look like they were new.

> https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/10738441894
> 
> > >   sound/soc/mediatek/mt8365/mt8365-dai-adda.c:93:8: error: implicit conversion from 'unsigned long' to 'unsigned int' changes value from 18446744073709551614 to 4294967294 [-Werror,-Wconstant-conversion]
> > >      91 |                 regmap_update_bits(afe->regmap, AFE_ADDA_UL_DL_CON0,
> > >         |                 ~~~~~~~~~~~~~~~~~~
> > >      92 |                                    AFE_ADDA_UL_DL_ADDA_AFE_ON,
> > >      93 |                                    ~AFE_ADDA_UL_DL_ADDA_AFE_ON);
> > >         |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >   1 error generated.
> > 
> > That's a bit surprising, regmap_update_bits() takes an unsigned long?  I
> > suspect the constants need to be defined as unsigned.

> Does it? I see it taking 'unsigned int' for all of its parameters.

Sorry, I misread the warning there (or was perhaps looking at another
one) and for some reason though it was about dropping signs but it's
rather due to BIT() being defined for longs which is a rather bad
landmine given how common a pattern negation is.  I do see that
synclink.h has some convenient BITn macros for some reason which would
do the trick but really I think it's just a case of open coding the
BIT() usage, or defining a BITI() or something but that seems ugly.
Probably just open code the definitions.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)