kernel/git/stable/linux.git/arch/m68k, branch linux-5.8.y

m68knommu: include SDHC support only when hardware has it

2020-10-29T09:07:53+00:00

[ Upstream commit 322c512f476f07e960cecd447ef22c15bed0e5f1 ] The mere fact that the kernel has the MMC subsystem enabled (CONFIG_MMC enabled) does not mean that the underlying hardware platform has the SDHC hardware present. Within the ColdFire hardware defines that is signified by MCFSDHC_BASE being defined with an address. The platform data for the ColdFire parts is including the SDHC hardware if CONFIG_MMC is enabled, instead of MCFSDHC_BASE. This means that if you are compiling for a ColdFire target that does not support SDHC but enable CONFIG_MMC you will fail to compile with errors like this: arch/m68k/coldfire/device.c:565:12: error: ‘MCFSDHC_BASE’ undeclared here (not in a function) .start = MCFSDHC_BASE, ^ arch/m68k/coldfire/device.c:566:25: error: ‘MCFSDHC_SIZE’ undeclared here (not in a function) .end = MCFSDHC_BASE + MCFSDHC_SIZE - 1, ^ arch/m68k/coldfire/device.c:569:12: error: ‘MCF_IRQ_SDHC’ undeclared here (not in a function) .start = MCF_IRQ_SDHC, ^ Make the SDHC platform support depend on MCFSDHC_BASE, that is only include it if the specific ColdFire SoC has that hardware module. Fixes: 991f5c4dd2422881 ("m68k: mcf5441x: add support for esdhc mmc controller") Signed-off-by: Greg Ungerer Reviewed-by: Geert Uytterhoeven Reviewed-by: Angelo Dureghello Tested-by: Angelo Dureghello Signed-off-by: Sasha Levin

m68knommu: fix overwriting of bits in ColdFire V3 cache control

2020-08-26T09:49:05+00:00

[ Upstream commit bdee0e793cea10c516ff48bf3ebb4ef1820a116b ] The Cache Control Register (CACR) of the ColdFire V3 has bits that control high level caching functions, and also enable/disable the use of the alternate stack pointer register (the EUSP bit) to provide separate supervisor and user stack pointer registers. The code as it is today will blindly clear the EUSP bit on cache actions like invalidation. So it is broken for this case - and that will result in failed booting (interrupt entry and exit processing will be completely hosed). This only affects ColdFire V3 parts that support the alternate stack register (like the 5329 for example) - generally speaking new parts do, older parts don't. It has no impact on ColdFire V3 parts with the single stack pointer, like the 5307 for example. Fix the cache bit defines used, so they maintain the EUSP bit when carrying out cache actions through the CACR register. Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin

m68k: mac: Fix IOP status/control register writes

2020-08-19T06:26:08+00:00

[ Upstream commit 931fc82a6aaf4e2e4a5490addaa6a090d78c24a7 ] When writing values to the IOP status/control register make sure those values do not have any extraneous bits that will clear interrupt flags. To place the SCC IOP into bypass mode would be desirable but this is not achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS to the control register. Drop this ineffective register write. Remove the flawed and unused iop_bypass() function. Make use of the unused iop_stop() function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Cc: Joshua Thompson Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

m68k: mac: Don't send IOP message until channel is idle

2020-08-19T06:26:07+00:00

[ Upstream commit aeb445bf2194d83e12e85bf5c65baaf1f093bd8f ] In the following sequence of calls, iop_do_send() gets called when the "send" channel is not in the IOP_MSG_IDLE state: iop_ism_irq() iop_handle_send() (msg->handler)() iop_send_message() iop_do_send() Avoid this by testing the channel state before calling iop_do_send(). When sending, and iop_send_queue is empty, call iop_do_send() because the channel is idle. If iop_send_queue is not empty, iop_do_send() will get called later by iop_handle_send(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Tested-by: Stan Johnson Cc: Joshua Thompson Link: https://lore.kernel.org/r/6d667c39e53865661fa5a48f16829d18ed8abe54.1590880333.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

m68k: mm: fix node memblock init

2020-06-29T13:58:05+00:00

After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was hanging silently. memblock_add() seems not appropriate, since using MAX_NUMNODES as node id, while memblock_add_node() sets up memory for node id 0. Signed-off-by: Angelo Dureghello Signed-off-by: Mike Rapoport Signed-off-by: Greg Ungerer

m68k: nommu: register start of the memory with memblock

2020-06-29T13:57:54+00:00

The m68k nommu setup code didn't register the beginning of the physical memory with memblock because it was anyway occupied by the kernel. However, commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than zone sizes") changed zones initialization to use memblock.memory to detect the zone extents and this caused inconsistency between zone PFNs and the actual PFNs: BUG: Bad page state in process swapper pfn:20165 page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 page dumped because: nonzero mapcount CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 Stack from 404c9ebc: 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff Call Trace: [<40088470>] 0x40088470 [<40088504>] 0x40088504 [<40088a12>] 0x40088a12 [<402ca000>] 0x402ca000 [<400a0934>] 0x400a0934 Adjust the memory registration with memblock to include the beginning of the physical memory and make sure that the area occupied by the kernel is marked as reserved. Signed-off-by: Mike Rapoport Signed-off-by: Greg Ungerer

Merge tag 'kbuild-v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2020-06-13T20:29:16+00:00

Pull more Kbuild updates from Masahiro Yamada: - fix build rules in binderfs sample - fix build errors when Kbuild recurses to the top Makefile - covert '---help---' in Kconfig to 'help' * tag 'kbuild-v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: treewide: replace '---help---' in Kconfig files with 'help' kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables samples: binderfs: really compile this sample and fix build issues

treewide: replace '---help---' in Kconfig files with 'help'

2020-06-13T16:57:21+00:00

Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over '---help---'"), the number of '---help---' has been gradually decreasing, but there are still more than 2400 instances. This commit finishes the conversion. While I touched the lines, I also fixed the indentation. There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---' In order to convert all of them to 1 tab + 'help', I ran the following commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/' Signed-off-by: Masahiro Yamada

Merge tag 'm68knommu-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu

2020-06-11T19:50:54+00:00

Pull m68knommu updates from Greg Ungerer: - casting clean up in the user access macros - memory leak on error case fix for PCI probing - update of a defconfig * tag 'm68knommu-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k,nommu: fix implicit cast from __user in __{get,put}_user_asm() m68k,nommu: add missing __user in uaccess' __ptr() macro m68k: Drop CONFIG_MTD_M25P80 in stmark2_defconfig m68k/PCI: Fix a memory leak in an error handling path

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

2020-06-11T11:14:41+00:00

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp. GZIP, BZIP2, LZOP env variables are reserved by the tools. The original attempt to redefine them internally doesn't work in makefiles/scripts intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in broken builds. There can be other broken build commands because of this, so the universal solution is to use non-reserved env variables for the compression tools. Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools") Signed-off-by: Denis Efremov Tested-by: Guenter Roeck Signed-off-by: Masahiro Yamada