17.05.2021 16:39, Krzysztof Kozlowski пишет: > On 17/05/2021 09:35, Dmitry Osipenko wrote: >> 17.05.2021 14:28, Krzysztof Kozlowski пишет: >>> On 16/05/2021 12:12, Dmitry Osipenko wrote: >>>> Fix compilation warning on 64bit platforms caused by implicit promotion >>>> of 32bit signed integer to a 64bit unsigned value which happens after >>>> enabling compile-testing of the driver. >>>> >>>> Suggested-by: Nathan Chancellor <nathan@xxxxxxxxxx> >>>> Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx> >>>> --- >>>> drivers/memory/tegra/tegra124-emc.c | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/memory/tegra/tegra124-emc.c b/drivers/memory/tegra/tegra124-emc.c >>>> index 5699d909abc2..c9eb948cf4df 100644 >>>> --- a/drivers/memory/tegra/tegra124-emc.c >>>> +++ b/drivers/memory/tegra/tegra124-emc.c >>>> @@ -272,8 +272,8 @@ >>>> #define EMC_PUTERM_ADJ 0x574 >>>> >>>> #define DRAM_DEV_SEL_ALL 0 >>>> -#define DRAM_DEV_SEL_0 (2 << 30) >>>> -#define DRAM_DEV_SEL_1 (1 << 30) >>>> +#define DRAM_DEV_SEL_0 (2u << 30) >>>> +#define DRAM_DEV_SEL_1 (1u << 30) >>> >>> Why not using BIT()? This would make even this 2<<30 less awkard... >> >> The bitfield 31:30 is a enum, 3 is a wrong value. Formally it's >> incorrect to use the BIT() macro here. > > Why "3"? BIT(31) is the same as 2<<30. By 3 I meant BIT(31)|BIT(30). This bitfield is explicitly designated as a enum in the hardware documentation. > It's common to use BIT for > register fields which do not accept all possible values. Now you > basically reimplement BIT() which is error-prone. Could you please show couple examples? The common practice today is to use FIELD_PREP helpers, but this driver was written before these helpers existed.
