kernel.git/arch/m68k/coldfire, branch linux-4.10.y

clocksource: Use a plain u64 instead of cycle_t

2016-12-25T10:04:12Z

There is no point in having an extra type for extra confusion. u64 is unambiguous. Conversion was done with the following coccinelle script: @rem@ @@ -typedef u64 cycle_t; @fix@ typedef cycle_t; @@ -cycle_t +u64 Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: John Stultz

m68k: add Sysam AMCORE open board support

2016-12-04T22:53:27Z

Add support for Sysam AMCORE board, an open hardware embedded Linux board, see http://sysam.it/openzone/projects/amcore/amcore.html for any info. Signed-off-by: Angelo Dureghello Signed-off-by: Greg Ungerer

m68knommu: platform support for i2c devices on ColdFire SoC

2016-12-04T22:53:27Z

These changes based on work by Steven King to support the i2c hardware modules on ColdFire SoC family devices. This is the per SoC hardware support. Contains a common platform device setup. Each of the SoC family members tends to have some minor local setup required to initialize the module. But all ColdFire family members use the same i2c hardware module. This i2c hardware module is the same as used in the Freescale iMX ARM based family of SoC devices. Steven's original patches were based on using a new and different i2c-coldfire.c driver. But this is not neccessary as we can use the existing Linux i2c-imx.c driver with no change required to it. And this patch is now based on using the existing i2c-imx driver. This patch only contains the ColdFire platform changes. Signed-off-by: Greg Ungerer Tested-by: Angelo Dureghello

m68k: let clk_disable() return immediately if clk is NULL

2016-09-26T02:02:59Z

In many of clk_disable() implementations, it is a no-op for a NULL pointer input, but this is one of the exceptions. Making it treewide consistent will allow clock consumers to call clk_disable() without NULL pointer check. Signed-off-by: Masahiro Yamada Signed-off-by: Greg Ungerer

m68k: move ColdFire _bootmem_alloc code

2016-09-26T02:02:58Z

The early ColdFire bootmem_alloc() code is currently only included in the board support for the Coldire 54xx platforms. It will be used on all ColdFire MMU enabled platforms as others are supported. So move the mcf54xx_bootmem_alloc() function to be generally available to all MMU enabled ColdFire parts (and use a more generic name for it). Signed-off-by: Greg Ungerer

m68k: report correct FPU type on ColdFire MMU platforms

2016-09-26T02:02:58Z

Not all ColdFire SoC parts that have an MMU also have an FPU - so set an FPU type (via m68k_fputype) appropriate for the configured platform. With this set correctly /proc/cpuinfo will report FPU "none" on devices that don't have one. And kernel code paths that initialize FPU hardware will now only execute if an FPU is actually present. Signed-off-by: Greg Ungerer

m68k: set appropriate machine type for m5411x SoC platforms

2016-09-26T02:02:58Z

Create a new machine type for platforms based around the ColdFire 5441x SoC family. Set that machine type on startup when building for this platform type. Currently the ColdFire head.S hard codes a M54xx machine type at startup - since that is the only platform type currently supported with MMU enabled. The m5441x has an MMU and this change forms part of the support required to run it with the MMU enabled. Signed-off-by: Greg Ungerer

m68knommu: switch to using IO access methods in WildFire board code

2016-09-26T02:02:57Z

Most ColdFire support code has switched to using IO memory access methods (readb/writeb/etc) when reading and writing internal peripheral device registers. The WildFire board specific halt code was missed. As it is now the WildFire code is broken, since all register definitions were changed to be register addresses only some time ago. Fix the WildFire board code to use the appropriate IO access functions. Signed-off-by: Greg Ungerer

m68knommu: fix early setup to not access variables

2016-09-26T02:02:57Z

The early setup code for the ColdFire 53xx platform accesses variables before the RAM and other system initialization steps may have taken place. Currently it has 2 global variables that will end up in the bss section that are accessed during this early setup. There is a special static RAM stack setup at this time, but not necessarily the RAM where kernel data sections will end up. Even on system setups where RAM is setup by a boot loader the access to the early setup variables is before the BSS section has been initialized. This can potentially corrupt a ram loaded root filesystem that sits in that memory area before it has been moved. These 2 variables are not used at all after being set, and can just be removed. Reported-by: Christian Gieseler Signed-off-by: Greg Ungerer

m68k: Assorted spelling fixes

2016-07-03T12:05:28Z

- s/acccess/access/ - s/accoding/according/ - s/addad/added/ - s/addreess/address/ - s/allocatiom/allocation/ - s/Assember/Assembler/ - s/compactnes/compactness/ - s/conneced/connected/ - s/decending/descending/ - s/diectly/directly/ - s/diplacement/displacement/ Signed-off-by: Andrea Gelmini [geert: Squashed, fix arch/m68k/ifpsp060/src/pfpsp.S] Signed-off-by: Geert Uytterhoeven