All of lore.kernel.org
 help / color / mirror / Atom feed
* [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
@ 2026-05-19  6:43 kernel test robot
  2026-05-19  8:57 ` Heiko Stuebner
  0 siblings, 1 reply; 4+ messages in thread
From: kernel test robot @ 2026-05-19  6:43 UTC (permalink / raw)
  To: Rosen Penev; +Cc: oe-kbuild-all, Heiko Stuebner, Brian Masney

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   80dd246accce631c328ea43294e53b2b2dd2aa32
commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8 [4652/6115] clk: rockchip: allow COMPILE_TEST builds
config: m68k-randconfig-r133-20260519 (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 8.5.0
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
   drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
>> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
>> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)

vim +57 arch/m68k/include/asm/hash.h

14c44b95b3dcb8f George Spelvin 2016-05-26   4  
14c44b95b3dcb8f George Spelvin 2016-05-26   5  /*
14c44b95b3dcb8f George Spelvin 2016-05-26   6   * If CONFIG_M68000=y (original mc68000/010), this file is #included
14c44b95b3dcb8f George Spelvin 2016-05-26   7   * to work around the lack of a MULU.L instruction.
14c44b95b3dcb8f George Spelvin 2016-05-26   8   */
14c44b95b3dcb8f George Spelvin 2016-05-26   9  
14c44b95b3dcb8f George Spelvin 2016-05-26  10  #define HAVE_ARCH__HASH_32 1
14c44b95b3dcb8f George Spelvin 2016-05-26  11  /*
14c44b95b3dcb8f George Spelvin 2016-05-26  12   * While it would be legal to substitute a different hash operation
14c44b95b3dcb8f George Spelvin 2016-05-26  13   * entirely, let's keep it simple and just use an optimized multiply
14c44b95b3dcb8f George Spelvin 2016-05-26  14   * by GOLDEN_RATIO_32 = 0x61C88647.
14c44b95b3dcb8f George Spelvin 2016-05-26  15   *
14c44b95b3dcb8f George Spelvin 2016-05-26  16   * The best way to do that appears to be to multiply by 0x8647 with
14c44b95b3dcb8f George Spelvin 2016-05-26  17   * shifts and adds, and use mulu.w to multiply the high half by 0x61C8.
14c44b95b3dcb8f George Spelvin 2016-05-26  18   *
14c44b95b3dcb8f George Spelvin 2016-05-26  19   * Because the 68000 has multi-cycle shifts, this addition chain is
14c44b95b3dcb8f George Spelvin 2016-05-26  20   * chosen to minimise the shift distances.
14c44b95b3dcb8f George Spelvin 2016-05-26  21   *
14c44b95b3dcb8f George Spelvin 2016-05-26  22   * Despite every attempt to spoon-feed it simple operations, GCC
14c44b95b3dcb8f George Spelvin 2016-05-26  23   * 6.1.1 doggedly insists on doing annoying things like converting
14c44b95b3dcb8f George Spelvin 2016-05-26  24   * "lsl.l #2,<reg>" (12 cycles) to two adds (8+8 cycles).
14c44b95b3dcb8f George Spelvin 2016-05-26  25   *
14c44b95b3dcb8f George Spelvin 2016-05-26  26   * It also likes to notice two shifts in a row, like "a = x << 2" and
14c44b95b3dcb8f George Spelvin 2016-05-26  27   * "a <<= 7", and convert that to "a = x << 9".  But shifts longer
14c44b95b3dcb8f George Spelvin 2016-05-26  28   * than 8 bits are extra-slow on m68k, so that's a lose.
14c44b95b3dcb8f George Spelvin 2016-05-26  29   *
14c44b95b3dcb8f George Spelvin 2016-05-26  30   * Since the 68000 is a very simple in-order processor with no
14c44b95b3dcb8f George Spelvin 2016-05-26  31   * instruction scheduling effects on execution time, we can safely
14c44b95b3dcb8f George Spelvin 2016-05-26  32   * take it out of GCC's hands and write one big asm() block.
14c44b95b3dcb8f George Spelvin 2016-05-26  33   *
14c44b95b3dcb8f George Spelvin 2016-05-26  34   * Without calling overhead, this operation is 30 bytes (14 instructions
14c44b95b3dcb8f George Spelvin 2016-05-26  35   * plus one immediate constant) and 166 cycles.
14c44b95b3dcb8f George Spelvin 2016-05-26  36   *
14c44b95b3dcb8f George Spelvin 2016-05-26  37   * (Because %2 is fetched twice, it can't be postincrement, and thus it
14c44b95b3dcb8f George Spelvin 2016-05-26  38   * can't be a fully general "g" or "m".  Register is preferred, but
14c44b95b3dcb8f George Spelvin 2016-05-26  39   * offsettable memory or immediate will work.)
14c44b95b3dcb8f George Spelvin 2016-05-26  40   */
14c44b95b3dcb8f George Spelvin 2016-05-26  41  static inline u32 __attribute_const__ __hash_32(u32 x)
14c44b95b3dcb8f George Spelvin 2016-05-26  42  {
14c44b95b3dcb8f George Spelvin 2016-05-26  43  	u32 a, b;
14c44b95b3dcb8f George Spelvin 2016-05-26  44  
14c44b95b3dcb8f George Spelvin 2016-05-26  45  	asm(   "move.l %2,%0"	/* a = x * 0x0001 */
14c44b95b3dcb8f George Spelvin 2016-05-26  46  	"\n	lsl.l #2,%0"	/* a = x * 0x0004 */
14c44b95b3dcb8f George Spelvin 2016-05-26  47  	"\n	move.l %0,%1"
14c44b95b3dcb8f George Spelvin 2016-05-26  48  	"\n	lsl.l #7,%0"	/* a = x * 0x0200 */
14c44b95b3dcb8f George Spelvin 2016-05-26  49  	"\n	add.l %2,%0"	/* a = x * 0x0201 */
14c44b95b3dcb8f George Spelvin 2016-05-26  50  	"\n	add.l %0,%1"	/* b = x * 0x0205 */
14c44b95b3dcb8f George Spelvin 2016-05-26  51  	"\n	add.l %0,%0"	/* a = x * 0x0402 */
14c44b95b3dcb8f George Spelvin 2016-05-26  52  	"\n	add.l %0,%1"	/* b = x * 0x0607 */
14c44b95b3dcb8f George Spelvin 2016-05-26  53  	"\n	lsl.l #5,%0"	/* a = x * 0x8040 */
14c44b95b3dcb8f George Spelvin 2016-05-26  54  	: "=&d,d" (a), "=&r,r" (b)
14c44b95b3dcb8f George Spelvin 2016-05-26  55  	: "r,roi?" (x));	/* a+b = x*0x8647 */
14c44b95b3dcb8f George Spelvin 2016-05-26  56  
14c44b95b3dcb8f George Spelvin 2016-05-26 @57  	return ((u16)(x*0x61c8) << 16) + a + b;
14c44b95b3dcb8f George Spelvin 2016-05-26  58  }
14c44b95b3dcb8f George Spelvin 2016-05-26  59  

:::::: The code at line 57 was first introduced by commit
:::::: 14c44b95b3dcb8ff1d627e6b78f57c4373d375cb m68k: Add <asm/hash.h>

:::::: TO: George Spelvin <linux@sciencehorizons.net>
:::::: CC: George Spelvin <linux@sciencehorizons.net>

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
  2026-05-19  6:43 [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720) kernel test robot
@ 2026-05-19  8:57 ` Heiko Stuebner
  2026-05-19  8:57   ` Heiko Stuebner
  2026-05-19 23:06   ` Rosen Penev
  0 siblings, 2 replies; 4+ messages in thread
From: Heiko Stuebner @ 2026-05-19  8:57 UTC (permalink / raw)
  To: Rosen Penev, kernel test robot; +Cc: oe-kbuild-all, Brian Masney

Am Dienstag, 19. Mai 2026, 08:43:20 Mitteleuropäische Sommerzeit schrieb kernel test robot:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   80dd246accce631c328ea43294e53b2b2dd2aa32
> commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8 [4652/6115] clk: rockchip: allow COMPILE_TEST builds
> config: m68k-randconfig-r133-20260519 (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/config)
> compiler: m68k-linux-gcc (GCC) 8.5.0
> sparse: v0.6.5-rc1
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
> 
> sparse warnings: (new ones prefixed by >>)
>    drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
> >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
> >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)
> 
> vim +57 arch/m68k/include/asm/hash.h
> 
> 14c44b95b3dcb8f George Spelvin 2016-05-26   4  
> 14c44b95b3dcb8f George Spelvin 2016-05-26   5  /*
> 14c44b95b3dcb8f George Spelvin 2016-05-26   6   * If CONFIG_M68000=y (original mc68000/010), this file is #included
> 14c44b95b3dcb8f George Spelvin 2016-05-26   7   * to work around the lack of a MULU.L instruction.
> 14c44b95b3dcb8f George Spelvin 2016-05-26   8   */
> 14c44b95b3dcb8f George Spelvin 2016-05-26   9  
> 14c44b95b3dcb8f George Spelvin 2016-05-26  10  #define HAVE_ARCH__HASH_32 1
> 14c44b95b3dcb8f George Spelvin 2016-05-26  11  /*
> 14c44b95b3dcb8f George Spelvin 2016-05-26  12   * While it would be legal to substitute a different hash operation
> 14c44b95b3dcb8f George Spelvin 2016-05-26  13   * entirely, let's keep it simple and just use an optimized multiply
> 14c44b95b3dcb8f George Spelvin 2016-05-26  14   * by GOLDEN_RATIO_32 = 0x61C88647.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  15   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  16   * The best way to do that appears to be to multiply by 0x8647 with
> 14c44b95b3dcb8f George Spelvin 2016-05-26  17   * shifts and adds, and use mulu.w to multiply the high half by 0x61C8.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  18   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  19   * Because the 68000 has multi-cycle shifts, this addition chain is
> 14c44b95b3dcb8f George Spelvin 2016-05-26  20   * chosen to minimise the shift distances.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  21   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  22   * Despite every attempt to spoon-feed it simple operations, GCC
> 14c44b95b3dcb8f George Spelvin 2016-05-26  23   * 6.1.1 doggedly insists on doing annoying things like converting
> 14c44b95b3dcb8f George Spelvin 2016-05-26  24   * "lsl.l #2,<reg>" (12 cycles) to two adds (8+8 cycles).
> 14c44b95b3dcb8f George Spelvin 2016-05-26  25   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  26   * It also likes to notice two shifts in a row, like "a = x << 2" and
> 14c44b95b3dcb8f George Spelvin 2016-05-26  27   * "a <<= 7", and convert that to "a = x << 9".  But shifts longer
> 14c44b95b3dcb8f George Spelvin 2016-05-26  28   * than 8 bits are extra-slow on m68k, so that's a lose.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  29   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  30   * Since the 68000 is a very simple in-order processor with no
> 14c44b95b3dcb8f George Spelvin 2016-05-26  31   * instruction scheduling effects on execution time, we can safely
> 14c44b95b3dcb8f George Spelvin 2016-05-26  32   * take it out of GCC's hands and write one big asm() block.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  33   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  34   * Without calling overhead, this operation is 30 bytes (14 instructions
> 14c44b95b3dcb8f George Spelvin 2016-05-26  35   * plus one immediate constant) and 166 cycles.
> 14c44b95b3dcb8f George Spelvin 2016-05-26  36   *
> 14c44b95b3dcb8f George Spelvin 2016-05-26  37   * (Because %2 is fetched twice, it can't be postincrement, and thus it
> 14c44b95b3dcb8f George Spelvin 2016-05-26  38   * can't be a fully general "g" or "m".  Register is preferred, but
> 14c44b95b3dcb8f George Spelvin 2016-05-26  39   * offsettable memory or immediate will work.)
> 14c44b95b3dcb8f George Spelvin 2016-05-26  40   */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  41  static inline u32 __attribute_const__ __hash_32(u32 x)
> 14c44b95b3dcb8f George Spelvin 2016-05-26  42  {
> 14c44b95b3dcb8f George Spelvin 2016-05-26  43  	u32 a, b;
> 14c44b95b3dcb8f George Spelvin 2016-05-26  44  
> 14c44b95b3dcb8f George Spelvin 2016-05-26  45  	asm(   "move.l %2,%0"	/* a = x * 0x0001 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  46  	"\n	lsl.l #2,%0"	/* a = x * 0x0004 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  47  	"\n	move.l %0,%1"
> 14c44b95b3dcb8f George Spelvin 2016-05-26  48  	"\n	lsl.l #7,%0"	/* a = x * 0x0200 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  49  	"\n	add.l %2,%0"	/* a = x * 0x0201 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  50  	"\n	add.l %0,%1"	/* b = x * 0x0205 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  51  	"\n	add.l %0,%0"	/* a = x * 0x0402 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  52  	"\n	add.l %0,%1"	/* b = x * 0x0607 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  53  	"\n	lsl.l #5,%0"	/* a = x * 0x8040 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  54  	: "=&d,d" (a), "=&r,r" (b)
> 14c44b95b3dcb8f George Spelvin 2016-05-26  55  	: "r,roi?" (x));	/* a+b = x*0x8647 */
> 14c44b95b3dcb8f George Spelvin 2016-05-26  56  
> 14c44b95b3dcb8f George Spelvin 2016-05-26 @57  	return ((u16)(x*0x61c8) << 16) + a + b;

I'm not really sure what the correct course of action is for this.

The code calling into the hash is the
	hash_add(ctx->aux_grf_table, &vo_grf_e->node, grf_type_vo); [0]
with grf_type_vo being part of an enum [1].

So everything 32bits as the function expects, but the m68k hash32 then
doing that u16 cast.

I guess adding a 
	depends on !M68K
to the Kconfig?

Other options?

Thanks
Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk-rk3528.c#n1147
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk.h#n575

> 14c44b95b3dcb8f George Spelvin 2016-05-26  58  }
> 14c44b95b3dcb8f George Spelvin 2016-05-26  59  
> 
> :::::: The code at line 57 was first introduced by commit
> :::::: 14c44b95b3dcb8ff1d627e6b78f57c4373d375cb m68k: Add <asm/hash.h>
> 
> :::::: TO: George Spelvin <linux@sciencehorizons.net>
> :::::: CC: George Spelvin <linux@sciencehorizons.net>
> 
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
> 





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
  2026-05-19  8:57 ` Heiko Stuebner
@ 2026-05-19  8:57   ` Heiko Stuebner
  2026-05-19 23:06   ` Rosen Penev
  1 sibling, 0 replies; 4+ messages in thread
From: Heiko Stuebner @ 2026-05-19  8:57 UTC (permalink / raw)
  To: Rosen Penev, kernel test robot; +Cc: oe-kbuild-all, Brian Masney

Am Dienstag, 19. Mai 2026, 10:57:01 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:
> Am Dienstag, 19. Mai 2026, 08:43:20 Mitteleuropäische Sommerzeit schrieb kernel test robot:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   80dd246accce631c328ea43294e53b2b2dd2aa32
> > commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8 [4652/6115] clk: rockchip: allow COMPILE_TEST builds
> > config: m68k-randconfig-r133-20260519 (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/config)
> > compiler: m68k-linux-gcc (GCC) 8.5.0
> > sparse: v0.6.5-rc1
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/reproduce)
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
> > 
> > sparse warnings: (new ones prefixed by >>)
> >    drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
> > >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
> > >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)
> > 
> > vim +57 arch/m68k/include/asm/hash.h
> > 
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   4  
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   5  /*
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   6   * If CONFIG_M68000=y (original mc68000/010), this file is #included
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   7   * to work around the lack of a MULU.L instruction.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   8   */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   9  
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  10  #define HAVE_ARCH__HASH_32 1
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  11  /*
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  12   * While it would be legal to substitute a different hash operation
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  13   * entirely, let's keep it simple and just use an optimized multiply
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  14   * by GOLDEN_RATIO_32 = 0x61C88647.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  15   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  16   * The best way to do that appears to be to multiply by 0x8647 with
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  17   * shifts and adds, and use mulu.w to multiply the high half by 0x61C8.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  18   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  19   * Because the 68000 has multi-cycle shifts, this addition chain is
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  20   * chosen to minimise the shift distances.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  21   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  22   * Despite every attempt to spoon-feed it simple operations, GCC
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  23   * 6.1.1 doggedly insists on doing annoying things like converting
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  24   * "lsl.l #2,<reg>" (12 cycles) to two adds (8+8 cycles).
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  25   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  26   * It also likes to notice two shifts in a row, like "a = x << 2" and
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  27   * "a <<= 7", and convert that to "a = x << 9".  But shifts longer
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  28   * than 8 bits are extra-slow on m68k, so that's a lose.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  29   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  30   * Since the 68000 is a very simple in-order processor with no
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  31   * instruction scheduling effects on execution time, we can safely
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  32   * take it out of GCC's hands and write one big asm() block.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  33   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  34   * Without calling overhead, this operation is 30 bytes (14 instructions
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  35   * plus one immediate constant) and 166 cycles.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  36   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  37   * (Because %2 is fetched twice, it can't be postincrement, and thus it
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  38   * can't be a fully general "g" or "m".  Register is preferred, but
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  39   * offsettable memory or immediate will work.)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  40   */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  41  static inline u32 __attribute_const__ __hash_32(u32 x)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  42  {
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  43  	u32 a, b;
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  44  
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  45  	asm(   "move.l %2,%0"	/* a = x * 0x0001 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  46  	"\n	lsl.l #2,%0"	/* a = x * 0x0004 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  47  	"\n	move.l %0,%1"
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  48  	"\n	lsl.l #7,%0"	/* a = x * 0x0200 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  49  	"\n	add.l %2,%0"	/* a = x * 0x0201 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  50  	"\n	add.l %0,%1"	/* b = x * 0x0205 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  51  	"\n	add.l %0,%0"	/* a = x * 0x0402 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  52  	"\n	add.l %0,%1"	/* b = x * 0x0607 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  53  	"\n	lsl.l #5,%0"	/* a = x * 0x8040 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  54  	: "=&d,d" (a), "=&r,r" (b)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  55  	: "r,roi?" (x));	/* a+b = x*0x8647 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  56  
> > 14c44b95b3dcb8f George Spelvin 2016-05-26 @57  	return ((u16)(x*0x61c8) << 16) + a + b;
> 
> I'm not really sure what the correct course of action is for this.
> 
> The code calling into the hash is the
> 	hash_add(ctx->aux_grf_table, &vo_grf_e->node, grf_type_vo); [0]
> with grf_type_vo being part of an enum [1].
> 
> So everything 32bits as the function expects, but the m68k hash32 then
> doing that u16 cast.
> 
> I guess adding a 
> 	depends on !M68K
> to the Kconfig?

^^ "...of the clock driver" of course :-)

> 
> Other options?
> 
> Thanks
> Heiko
> 
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk-rk3528.c#n1147
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk.h#n575
> 
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  58  }
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  59  
> > 
> > :::::: The code at line 57 was first introduced by commit
> > :::::: 14c44b95b3dcb8ff1d627e6b78f57c4373d375cb m68k: Add <asm/hash.h>
> > 
> > :::::: TO: George Spelvin <linux@sciencehorizons.net>
> > :::::: CC: George Spelvin <linux@sciencehorizons.net>
> > 
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
> > 
> 
> 





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
  2026-05-19  8:57 ` Heiko Stuebner
  2026-05-19  8:57   ` Heiko Stuebner
@ 2026-05-19 23:06   ` Rosen Penev
  1 sibling, 0 replies; 4+ messages in thread
From: Rosen Penev @ 2026-05-19 23:06 UTC (permalink / raw)
  To: Heiko Stuebner; +Cc: kernel test robot, oe-kbuild-all, Brian Masney

On Tue, May 19, 2026 at 1:57 AM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Dienstag, 19. Mai 2026, 08:43:20 Mitteleuropäische Sommerzeit schrieb kernel test robot:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > head:   80dd246accce631c328ea43294e53b2b2dd2aa32
> > commit: 7edfb7fb58ee058298e18fde76a6077ef17d19d8 [4652/6115] clk: rockchip: allow COMPILE_TEST builds
> > config: m68k-randconfig-r133-20260519 (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/config)
> > compiler: m68k-linux-gcc (GCC) 8.5.0
> > sparse: v0.6.5-rc1
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605191434.PQkj2Rki-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202605191434.PQkj2Rki-lkp@intel.com/
> >
> > sparse warnings: (new ones prefixed by >>)
> >    drivers/clk/rockchip/clk-rk3528.c: note: in included file (through include/linux/hash.h, include/linux/slab.h):
> > >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720)
> > >> arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (1e8e8 becomes e8e8)
> >
> > vim +57 arch/m68k/include/asm/hash.h
> >
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   4
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   5  /*
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   6   * If CONFIG_M68000=y (original mc68000/010), this file is #included
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   7   * to work around the lack of a MULU.L instruction.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   8   */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26   9
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  10  #define HAVE_ARCH__HASH_32 1
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  11  /*
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  12   * While it would be legal to substitute a different hash operation
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  13   * entirely, let's keep it simple and just use an optimized multiply
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  14   * by GOLDEN_RATIO_32 = 0x61C88647.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  15   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  16   * The best way to do that appears to be to multiply by 0x8647 with
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  17   * shifts and adds, and use mulu.w to multiply the high half by 0x61C8.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  18   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  19   * Because the 68000 has multi-cycle shifts, this addition chain is
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  20   * chosen to minimise the shift distances.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  21   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  22   * Despite every attempt to spoon-feed it simple operations, GCC
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  23   * 6.1.1 doggedly insists on doing annoying things like converting
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  24   * "lsl.l #2,<reg>" (12 cycles) to two adds (8+8 cycles).
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  25   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  26   * It also likes to notice two shifts in a row, like "a = x << 2" and
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  27   * "a <<= 7", and convert that to "a = x << 9".  But shifts longer
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  28   * than 8 bits are extra-slow on m68k, so that's a lose.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  29   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  30   * Since the 68000 is a very simple in-order processor with no
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  31   * instruction scheduling effects on execution time, we can safely
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  32   * take it out of GCC's hands and write one big asm() block.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  33   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  34   * Without calling overhead, this operation is 30 bytes (14 instructions
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  35   * plus one immediate constant) and 166 cycles.
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  36   *
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  37   * (Because %2 is fetched twice, it can't be postincrement, and thus it
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  38   * can't be a fully general "g" or "m".  Register is preferred, but
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  39   * offsettable memory or immediate will work.)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  40   */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  41  static inline u32 __attribute_const__ __hash_32(u32 x)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  42  {
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  43         u32 a, b;
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  44
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  45         asm(   "move.l %2,%0"   /* a = x * 0x0001 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  46         "\n     lsl.l #2,%0"    /* a = x * 0x0004 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  47         "\n     move.l %0,%1"
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  48         "\n     lsl.l #7,%0"    /* a = x * 0x0200 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  49         "\n     add.l %2,%0"    /* a = x * 0x0201 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  50         "\n     add.l %0,%1"    /* b = x * 0x0205 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  51         "\n     add.l %0,%0"    /* a = x * 0x0402 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  52         "\n     add.l %0,%1"    /* b = x * 0x0607 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  53         "\n     lsl.l #5,%0"    /* a = x * 0x8040 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  54         : "=&d,d" (a), "=&r,r" (b)
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  55         : "r,roi?" (x));        /* a+b = x*0x8647 */
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  56
> > 14c44b95b3dcb8f George Spelvin 2016-05-26 @57         return ((u16)(x*0x61c8) << 16) + a + b;
>
> I'm not really sure what the correct course of action is for this.
>
> The code calling into the hash is the
>         hash_add(ctx->aux_grf_table, &vo_grf_e->node, grf_type_vo); [0]
> with grf_type_vo being part of an enum [1].
>
> So everything 32bits as the function expects, but the m68k hash32 then
> doing that u16 cast.
This AI suggests

--- a/arch/m68k/include/asm/hash.h
+++ b/arch/m68k/include/asm/hash.h
@@ -54,7 +54,7 @@ static inline u32 __attribute_const__ __hash_32(u32 x)
        : "=&d,d" (a), "=&r,r" (b)
        : "r,roi?" (x));        /* a+b = x*0x8647 */

-       return ((u16)(x*0x61c8) << 16) + a + b;
+       return ((x * 0x61c8u & 0xffffu) << 16) + a + b;
 }

 #endif /* _ASM_HASH_H */

Not my call to touch m68k includes.
>
> I guess adding a
>         depends on !M68K
> to the Kconfig?
>
> Other options?
>
> Thanks
> Heiko
>
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk-rk3528.c#n1147
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/clk/rockchip/clk.h#n575
>
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  58  }
> > 14c44b95b3dcb8f George Spelvin 2016-05-26  59
> >
> > :::::: The code at line 57 was first introduced by commit
> > :::::: 14c44b95b3dcb8ff1d627e6b78f57c4373d375cb m68k: Add <asm/hash.h>
> >
> > :::::: TO: George Spelvin <linux@sciencehorizons.net>
> > :::::: CC: George Spelvin <linux@sciencehorizons.net>
> >
> > --
> > 0-DAY CI Kernel Test Service
> > https://github.com/intel/lkp-tests/wiki
> >
>
>
>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-05-19 23:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-19  6:43 [linux-next:master 4652/6115] arch/m68k/include/asm/hash.h:57:24: sparse: sparse: cast truncates bits from constant value (18720 becomes 8720) kernel test robot
2026-05-19  8:57 ` Heiko Stuebner
2026-05-19  8:57   ` Heiko Stuebner
2026-05-19 23:06   ` Rosen Penev

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.