kernel/arch/powerpc/include/asm/cputable.h, branch linux-4.1.y

powerpc/book3s: Fix flush_tlb cpu_spec hook to take a generic argument.

2015-03-16T20:52:48Z

The flush_tlb hook in cpu_spec was introduced as a generic function hook to invalidate TLBs. But the current implementation of flush_tlb hook takes IS (invalidation selector) as an argument which is architecture dependent. Hence, It is not right to have a generic routine where caller has to pass non-generic argument. This patch fixes this and makes flush_tlb hook as high level API. Reported-by: Benjamin Herrenschmidt Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman

powerpc: Remove unused CPU_FTR_IABR

2015-01-23T03:02:50Z

We removed the last usage of CPU_FTR_IABR in commit 1ad7d70562ee "powerpc/xmon: Enable HW instruction breakpoint on POWER8". Mark it as free. Signed-off-by: Michael Ellerman

powerpc: Remove unused CPU_FTRS_A2

2014-11-09T22:59:29Z

In commit fb5a515704d7 "Remove platforms/wsp and associated pieces" we removed the last user of CPU_FTRS_A2, so we should remove it too. Signed-off-by: Michael Ellerman

powerpc: Remove CPU_FTR_HVMODE from CPU_FTRS_ALWAYS

2014-11-09T22:59:29Z

We potentially clear CPU_FTR_HVMODE at runtime in __init_hvmode_206(), so we must make sure it's not set in CPU_FTRS_ALWAYS. This doesn't hurt us in practice at the moment, because we don't support compiling only for CPUs that support CPU_FTR_HVMODE. Signed-off-by: Michael Ellerman

powerpc: Add POWER8 features to CPU_FTRS_POSSIBLE/ALWAYS

2014-08-13T05:13:43Z

We have been a bit slack about updating the CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS masks. When we added POWER8, and also POWER8E we forgot to update the ALWAYS mask. And when we added POWER8_DD1 we forgot to update both the POSSIBLE and ALWAYS masks. Luckily this hasn't caused any actual bugs AFAICS. Failing to update the ALWAYS mask just forgoes a potential optimisation opportunity. Failing to update the POSSIBLE mask for POWER8_DD1 is also OK because it only removes a bit rather than adding any. Regardless they should all be in both masks so as to avoid any future bugs when the set of ALWAYS/POSSIBLE bits changes, or the masks themselves change. Signed-off-by: Michael Ellerman Acked-by: Michael Neuling Acked-by: Joel Stanley Signed-off-by: Benjamin Herrenschmidt

Merge remote-tracking branch 'scott/next' into next

2014-08-05T04:13:41Z

Scott writes: Highlights include e6500 hardware threading support, an e6500 TLB erratum workaround, corenet error reporting, support for a new board, and some minor fixes.

powerpc/e6500: Add support for hardware threads

2014-07-30T00:26:20Z

The general idea is that each core will release all of its threads into the secondary thread startup code, which will eventually wait in the secondary core holding area, for the appropriate bit in the PACA to be set. The kick_cpu function pointer will set that bit in the PACA, and thus "release" the core/thread to boot. We also need to do a few things that U-Boot normally does for CPUs (like enable branch prediction). Signed-off-by: Andy Fleming [scottwood@freescale.com: various changes, including only enabling threads if Linux wants to kick them] Signed-off-by: Scott Wood

powerpc: Remove CLASSIC_PPC

2014-07-28T04:11:22Z

We have a strange #define in cputable.h called CLASSIC_PPC. Although it is defined for 32 & 64bit, it's only used for 32bit and it's basically a duplicate of CONFIG_PPC_BOOK3S_32, so let's use the latter. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt

powerpc: Remove CONFIG_POWER4

2014-07-28T04:10:26Z

Although the name CONFIG_POWER4 suggests that it controls support for power4 cpus, this symbol is actually misnamed. It is a historical wart from the powermac code, which used to support building a 32-bit kernel for power4. CONFIG_POWER4 was used in that context to guard code that was 64-bit only. In the powermac code we can just use CONFIG_PPC64 instead, and in other places it is a synonym for CONFIG_PPC_BOOK3S_64. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt

powerpc: Remove CONFIG_POWER3

2014-07-28T04:10:24Z

Now that we have dropped power3 support we can remove CONFIG_POWER3. The usage in pgtable_32.c was already dead code as CONFIG_POWER3 was not selectable on PPC32. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt