OCTEON: workaround linking failures with gcc-4.4.x 32-bits toolchains

When building with a gcc-4.4.x toolchain that is configured to produce 32-bits executables by default, we will produce __lshrti3 in sched_clock() which is never resolved so the kernel fails to link. Unconditionally use the inline assembly version as suggested by David Daney, which works around the issue.

CC David Daney<[email protected]>

Signed-off-by Florian Fainelli<[email protected]>

---

arch/mips/cavium-octeon/csrc-octeon.c +0 -8

index 0bf4bbe..36400d2 100644
@@ -53,7 +53,6 @@ static struct clocksource clocksource_mips = {
  unsigned long long notrace sched_clock(void)
  {
  	/* 64-bit arithmatic can overflow, so use 128-bit.  */
-#if (__GNUC__<  4) || ((__GNUC__ == 4)&&  (__GNUC_MINOR__<= 3))
  	u64 t1, t2, t3;
  	unsigned long long rv;
  	u64 mult = clocksource_mips.mult;

@@ -73,13 +72,6 @@ unsigned long long notrace sched_clock(void)
  		: [cnt] "r" (cnt), [mult] "r" (mult), [shift] "r" (shift)
  		: "hi", "lo");
  	return rv;
-#else
-	/* GCC>  4.3 do it the easy way.  */
-	unsigned int __attribute__((mode(TI))) t;
-	t = read_c0_cvmcount();
-	t = t * clocksource_mips.mult;
-	return (unsigned long long)(t>>  clocksource_mips.shift);
-#endif
  }
 
  void __init plat_time_init(void)

Quoted 6 lines

executables by default, we will produce __lshrti3 in sched_clock() which is never resolved so the kernel fails to link. Unconditionally use the inline assembly version as suggested by David Daney, which works around the issue.

CC David Daney<[email protected]>

Signed-off-by Florian Fainelli<[email protected]>

Acked-by David Daney <[email protected]>

Quoted 4 lines · David Daney

Quoted 4 lines

executables by default, we will produce __lshrti3 in sched_clock() which is never resolved so the kernel fails to link. Unconditionally use the inline assembly version as suggested by David Daney, which works around the issue.

Quoted 4 lines

Quoted 2 lines

CC David Daney<[email protected]>

Signed-off-by Florian Fainelli<[email protected]>

Acked-by David Daney<[email protected]>

Applied - but maybe we should just add lshrti3 instead? We already have ashldi3, ashrdi3 and lshrdi3.