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.
Attachment:
signature.asc
Description: PGP signature