Hi Prabhakar, On Mon, Jun 17, 2024 at 3:15 PM Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote: > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > Commit 13a8cae6e561 ("pinctrl: renesas: rzg2l: Drop struct > rzg2l_variable_pin_cfg") introduced a Smatch static checker warning: > > drivers/pinctrl/renesas/pinctrl-rzg2l.c:374 rzg2l_pinctrl_get_variable_pin_cfg() > warn: was expecting a 64 bit value instead of '~((((1))) << (16))' > > The function `rzg2l_pinctrl_get_variable_pin_cfg` attempts to mask out > `PIN_CFG_VARIABLE` using `BIT(16)`. However, since `pincfg` is a `u64`, > this inadvertently masks the high 32 bits as well, which is unintended > (on non 64-bit platforms). To correct this, `PIN_CFG_VARIABLE` should > be defined using `BIT_ULL(16)`, ensuring proper 64-bit masking. > > To avoid such issues, update `PIN_CFG_*` macros to use `BIT_ULL()`. > > Fixes: 13a8cae6e561 ("pinctrl: renesas: rzg2l: Drop struct rzg2l_variable_pin_cfg") > Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > Closes: https://lore.kernel.org/all/5c1bf20b-7e94-4b06-95e5-da9f99750203@moroto.mountain/ > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> Thanks for your patch! Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> I would like to brainstorm a bit about this, though. See below... > --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c > +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c > @@ -41,28 +41,28 @@ > #define MUX_FUNC_MASK GENMASK(31, 16) > > /* PIN capabilities */ > -#define PIN_CFG_IOLH_A BIT(0) > -#define PIN_CFG_IOLH_B BIT(1) > -#define PIN_CFG_SR BIT(2) > -#define PIN_CFG_IEN BIT(3) > -#define PIN_CFG_PUPD BIT(4) > -#define PIN_CFG_IO_VMC_SD0 BIT(5) > -#define PIN_CFG_IO_VMC_SD1 BIT(6) > -#define PIN_CFG_IO_VMC_QSPI BIT(7) > -#define PIN_CFG_IO_VMC_ETH0 BIT(8) > -#define PIN_CFG_IO_VMC_ETH1 BIT(9) > -#define PIN_CFG_FILONOFF BIT(10) > -#define PIN_CFG_FILNUM BIT(11) > -#define PIN_CFG_FILCLKSEL BIT(12) > -#define PIN_CFG_IOLH_C BIT(13) > -#define PIN_CFG_SOFT_PS BIT(14) > -#define PIN_CFG_OEN BIT(15) > -#define PIN_CFG_VARIABLE BIT(16) > -#define PIN_CFG_NOGPIO_INT BIT(17) > -#define PIN_CFG_NOD BIT(18) /* N-ch Open Drain */ > -#define PIN_CFG_SMT BIT(19) /* Schmitt-trigger input control */ > -#define PIN_CFG_ELC BIT(20) > -#define PIN_CFG_IOLH_RZV2H BIT(21) > +#define PIN_CFG_IOLH_A BIT_ULL(0) > +#define PIN_CFG_IOLH_B BIT_ULL(1) > +#define PIN_CFG_SR BIT_ULL(2) > +#define PIN_CFG_IEN BIT_ULL(3) > +#define PIN_CFG_PUPD BIT_ULL(4) > +#define PIN_CFG_IO_VMC_SD0 BIT_ULL(5) > +#define PIN_CFG_IO_VMC_SD1 BIT_ULL(6) > +#define PIN_CFG_IO_VMC_QSPI BIT_ULL(7) > +#define PIN_CFG_IO_VMC_ETH0 BIT_ULL(8) > +#define PIN_CFG_IO_VMC_ETH1 BIT_ULL(9) > +#define PIN_CFG_FILONOFF BIT_ULL(10) > +#define PIN_CFG_FILNUM BIT_ULL(11) > +#define PIN_CFG_FILCLKSEL BIT_ULL(12) > +#define PIN_CFG_IOLH_C BIT_ULL(13) > +#define PIN_CFG_SOFT_PS BIT_ULL(14) > +#define PIN_CFG_OEN BIT_ULL(15) > +#define PIN_CFG_VARIABLE BIT_ULL(16) PIN_CFG_VARIABLE looks a bit misplaced here, in between all the flags indicating actual capabilities of a pin. What about relocating it to the "high" half, and moving it next to RZG2L_SINGLE_PIN? Perhaps even renaming it to RZG2L_CFG_VARIABLE? > +#define PIN_CFG_NOGPIO_INT BIT_ULL(17) > +#define PIN_CFG_NOD BIT_ULL(18) /* N-ch Open Drain */ > +#define PIN_CFG_SMT BIT_ULL(19) /* Schmitt-trigger input control */ > +#define PIN_CFG_ELC BIT_ULL(20) > +#define PIN_CFG_IOLH_RZV2H BIT_ULL(21) > > #define RZG2L_MPXED_COMMON_PIN_FUNCS(group) \ > (PIN_CFG_IOLH_##group | \ Then the other PIN_CFG_* definitions can keep on using BIT(). To make that safer, PIN_CFG_MASK should be restricted to 32-bit: -#define PIN_CFG_MASK GENMASK_ULL(46, 0) +#define PIN_CFG_MASK GENMASK_ULL(31, 0) and several u64 variables can be changed to u32 again. What do you think? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds