aboutsummaryrefslogtreecommitdiff
path: root/arch/m68k
AgeCommit message (Collapse)AuthorFilesLines
2020-05-28m68k: coldfire/clk.c: move m5441x specific codeAngelo Dureghello2-15/+15
Moving specific m5441x clk-related code in more appropriate location, since breaking compilation for other targets. Signed-off-by: Angelo Dureghello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-05-28m68k: mcf5441x: add support for esdhc mmc controllerAngelo Dureghello5-3/+74
Add support for sdhci-edshc mmc controller. Signed-off-by: Angelo Dureghello <[email protected]> Acked-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-05-25m68k: tools: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20200521185707.GA3661@embeddedor Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-05-25m68k: Add missing __user annotation in get_user()Jason Wang1-1/+1
The ptr is a pointer to userspace memory. So we need annotate it with __user otherwise we may get sparse warnings like: drivers/vhost/vhost.c:1603:13: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void const *__gu_ptr @@ got unsigned int [noderef] [usertypvoid const *__gu_ptr @@ drivers/vhost/vhost.c:1603:13: sparse: expected void const *__gu_ptr drivers/vhost/vhost.c:1603:13: sparse: got unsigned int [noderef] [usertype] <asn:1> *idxp Reported-by: kbuild test robot <[email protected]> Signed-off-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 7124330dabe5b3cb ("m68k/uaccess: Revive 64-bit get_user()") Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-05-25m68k: mac: Avoid stuck ISM IOP interrupt on Quadra 900/950Finn Thain1-22/+28
On a Quadra 900/950, the ISM IOP IRQ output pin is connected to an edge-triggered input on VIA2. It is theoretically possible that this signal could fail to produce the expected VIA2 interrupt. The two IOP interrupt flags can be asserted in any order but the logic in iop_ism_irq() does not allow for that. In particular, INT0 can be asserted right after INT0 is checked and before INT1 is cleared. Such an interrupt would produce no new edge and VIA2 would detect no further interrupts from the IOP. Avoid this by looping over the INT0/1 handlers so an edge can be produced. Signed-off-by: Finn Thain <[email protected]> Tested-by: Stan Johnson <[email protected]> Cc: Joshua Thompson <[email protected]> Link: https://lore.kernel.org/r/bfbb71db52c5e162d3afa25a28fc5d535ca87138.1589949122.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-05-25m68k: mac: Remove misleading commentFinn Thain1-1/+0
This code path was tested on a Quadra 950 a long time ago and the comment isn't needed. Signed-off-by: Finn Thain <[email protected]> Cc: Joshua Thompson <[email protected]> Link: https://lore.kernel.org/r/10dff3e7c17d363a4b239aae7b3ebab32bef3547.1589949122.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-05-25m68k: mac: Don't call via_flush_cache() on Mac IIfxFinn Thain3-20/+8
There is no VIA2 chip on the Mac IIfx, so don't call via_flush_cache(). This avoids a boot crash which appeared in v5.4. printk: console [ttyS0] enabled printk: bootconsole [debug0] disabled printk: bootconsole [debug0] disabled Calibrating delay loop... 9.61 BogoMIPS (lpj=48064) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) devtmpfs: initialized random: get_random_u32 called from bucket_table_alloc.isra.27+0x68/0x194 with crng_init=0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: -1, 3072 bytes, linear) NET: Registered protocol family 16 Data read fault at 0x00000000 in Super Data (pc=0x8a6a) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<00008a6a>] via_flush_cache+0x12/0x2c SR: 2700 SP: 01c1fe3c a2: 01c24000 d0: 00001119 d1: 0000000c d2: 00012000 d3: 0000000f d4: 01c06840 d5: 00033b92 a0: 00000000 a1: 00000000 Process swapper (pid: 1, task=01c24000) Frame format=B ssw=0755 isc=0200 isb=fff7 daddr=00000000 dobuf=01c1fed0 baddr=00008a6e dibuf=0000004e ver=f Stack from 01c1fec4: 01c1fed0 00007d7e 00010080 01c1fedc 0000792e 00000001 01c1fef4 00006b40 01c80000 00040000 00000006 00000003 01c1ff1c 004a545e 004ff200 00040000 00000000 00000003 01c06840 00033b92 004a5410 004b6c88 01c1ff84 000021e2 00000073 00000003 01c06840 00033b92 0038507a 004bb094 004b6ca8 004b6c88 004b6ca4 004b6c88 000021ae 00020002 00000000 01c0685d 00000000 01c1ffb4 0049f938 00409c85 01c06840 0045bd40 00000073 00000002 00000002 00000000 Call Trace: [<00007d7e>] mac_cache_card_flush+0x12/0x1c [<00010080>] fix_dnrm+0x2/0x18 [<0000792e>] cache_push+0x46/0x5a [<00006b40>] arch_dma_prep_coherent+0x60/0x6e [<00040000>] switched_to_dl+0x76/0xd0 [<004a545e>] dma_atomic_pool_init+0x4e/0x188 [<00040000>] switched_to_dl+0x76/0xd0 [<00033b92>] parse_args+0x0/0x370 [<004a5410>] dma_atomic_pool_init+0x0/0x188 [<000021e2>] do_one_initcall+0x34/0x1be [<00033b92>] parse_args+0x0/0x370 [<0038507a>] strcpy+0x0/0x1e [<000021ae>] do_one_initcall+0x0/0x1be [<00020002>] do_proc_dointvec_conv+0x54/0x74 [<0049f938>] kernel_init_freeable+0x126/0x190 [<0049f94c>] kernel_init_freeable+0x13a/0x190 [<004a5410>] dma_atomic_pool_init+0x0/0x188 [<00041798>] complete+0x0/0x3c [<000b9b0c>] kfree+0x0/0x20a [<0038df98>] schedule+0x0/0xd0 [<0038d604>] kernel_init+0x0/0xda [<0038d610>] kernel_init+0xc/0xda [<0038d604>] kernel_init+0x0/0xda [<00002d38>] ret_from_kernel_thread+0xc/0x14 Code: 0000 2079 0048 10da 2279 0048 10c8 d3c8 <1011> 0200 fff7 1280 d1f9 0048 10c8 1010 0000 0008 1080 4e5e 4e75 4e56 0000 2039 Disabling lock debugging due to kernel taint Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Thanks to Stan Johnson for capturing the console log and running git bisect. Git bisect said commit 8e3a68fb55e0 ("dma-mapping: make dma_atomic_pool_init self-contained") is the first "bad" commit. I don't know why. Perhaps mach_l2_flush first became reachable with that commit. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Cc: Joshua Thompson <[email protected]> Link: https://lore.kernel.org/r/b8bbeef197d6b3898e82ed0d231ad08f575a4b34.1589949122.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-05-25m68k/PCI: Fix a memory leak in an error handling pathChristophe JAILLET1-1/+3
If 'ioremap' fails, we must free 'bridge', as done in other error handling path bellow. Fixes: 19cc4c843f40 ("m68k/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Greg Ungerer <[email protected]>
2020-05-14vfs: add faccessat2 syscallMiklos Szeredi1-0/+1
POSIX defines faccessat() as having a fourth "flags" argument, while the linux syscall doesn't have it. Glibc tries to emulate AT_EACCESS and AT_SYMLINK_NOFOLLOW, but AT_EACCESS emulation is broken. Add a new faccessat(2) syscall with the added flags argument and implement both flags. The value of AT_EACCESS is defined in glibc headers to be the same as AT_REMOVEDIR. Use this value for the kernel interface as well, together with the explanatory comment. Also add AT_EMPTY_PATH support, which is not documented by POSIX, but can be useful and is trivial to implement. Signed-off-by: Miklos Szeredi <[email protected]>
2020-05-12floppy: use symbolic register names in the m68k portWilly Tarreau1-7/+8
Now we can use FD_STATUS and FD_DATA instead of 4 or 5, let's do this, and also use STATUS_DMA and STATUS_READY for the status bits. Link: https://lore.kernel.org/r/[email protected] Cc: Geert Uytterhoeven <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Denis Efremov <[email protected]>
2020-05-12floppy: split the base port from the register in I/O accessesWilly Tarreau1-6/+6
Currently we have architecture-specific fd_inb() and fd_outb() functions or macros, taking just a port which is in fact made of a base address and a register. The base address is FDC-specific and derived from the local or global "fdc" variable through the FD_IOPORT macro used in the base address calculation. This change splits this by explicitly passing the FDC's base address and the register separately to fd_outb() and fd_inb(). It affects the following archs: - x86, alpha, mips, powerpc, parisc, arm, m68k: simple remap of port -> base+reg - sparc32: use of reg only, since the base address was already masked out and the FDC controller is known from a static struct. - sparc64: like x86 for PCI, like sparc32 for 82077 Some archs use inline functions and others macros. This was not unified in order to minimize the number of changes to review. For the same reason checkpatch still spews a few warnings about things that were already there before. The parisc still uses hard-coded register values and could be cleaned up by taking the register definitions. The sparc per-controller inb/outb functions could further be refined to explicitly take an FDC register instead of a port in argument but it was not needed yet and may be cleaned later. Link: https://lore.kernel.org/r/[email protected] Cc: Ivan Kokshaysky <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Matt Turner <[email protected]> Cc: Ian Molton <[email protected]> Cc: Russell King <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: Helge Deller <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: [email protected] Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Denis Efremov <[email protected]>
2020-05-11m68k: defconfig: Update defconfigs for v5.7-rc1Geert Uytterhoeven12-12/+60
- Enable modular build of Bare UDP Encapsulation, exFAT filesystem support, and lockup and min heap test modules, - Remove CONFIG_NF_TABLES_SET=m (removed in commit e32a4dc6512ce3c1 ("netfilter: nf_tables: make sets built-in")), - Disable CONFIG_VHOST_MENU (should default to n). Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-05-05clk: Allow the common clk framework to be selectableStephen Boyd1-1/+1
Enable build testing and configuration control of the common clk framework so that more code coverage and testing can be done on the common clk framework across various architectures. This also nicely removes the requirement that architectures must select the framework when they don't use it in architecture code. There's one snag with doing this, and that's making sure that randconfig builds don't select this option when some architecture or platform implements 'struct clk' outside of the common clk framework. Introduce a new config option 'HAVE_LEGACY_CLK' to indicate those platforms that haven't migrated to the common clk framework and therefore shouldn't be allowed to select this new config option. Also add a note that we hope one day to remove this config entirely. Based on a patch by Mark Brown <[email protected]>. Cc: Mark Brown <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Mark Salter <[email protected]> Cc: Aurelien Jacquiot <[email protected]> Cc: Jiaxun Yang <[email protected]> Cc: Guan Xuetao <[email protected]> Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Reviewed-by: Mark Brown <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]>
2020-04-27m68k: amiga: config: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20200420181401.GA32172@embeddedor Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-04-20m68k: amiga: config: Mark expected switch fall-throughGustavo A. R. Silva1-2/+3
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: allmodconfig m68k): arch/m68k/amiga/config.c: In function ‘amiga_identify’: ./arch/m68k/include/asm/amigahw.h:42:50: warning: this statement may fall through [-Wimplicit-fallthrough=] #define AMIGAHW_SET(name) (amiga_hw_present.name = 1) ~~~~~~~~~~~~~~~~~~~~~~~^~~~ arch/m68k/amiga/config.c:223:3: note: in expansion of macro ‘AMIGAHW_SET’ AMIGAHW_SET(PCMCIA); ^~~~~~~~~~~ arch/m68k/amiga/config.c:224:2: note: here case AMI_500: ^~~~ Replace the existing /* fall through */ comments and fix the issue above by using the new pseudo-keyword fallthrough; Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/14ff577604d25243c8a897f851b436ba87ae87cb.1585264062.git.gustavo@embeddedor.com Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-04-13m68k: Drop redundant generic-y += hardirq.hGeert Uytterhoeven1-1/+0
The cleanup in commit 630f289b7114c0e6 ("asm-generic: make more kernel-space headers mandatory") did not take into account the recently added line for hardirq.h in commit acc45648b9aefa90 ("m68k: Switch to asm-generic/hardirq.h"), leading to the following message during the build: scripts/Makefile.asm-generic:25: redundant generic-y found in arch/m68k/include/asm/Kbuild: hardirq.h Fix this by dropping the now redundant line. Fixes: 630f289b7114c0e6 ("asm-generic: make more kernel-space headers mandatory") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-04-10mm/special: create generic fallbacks for pte_special() and pte_mkspecial()Anshuman Khandual3-14/+0
Currently there are many platforms that dont enable ARCH_HAS_PTE_SPECIAL but required to define quite similar fallback stubs for special page table entry helpers such as pte_special() and pte_mkspecial(), as they get build in generic MM without a config check. This creates two generic fallback stub definitions for these helpers, eliminating much code duplication. mips platform has a special case where pte_special() and pte_mkspecial() visibility is wider than what ARCH_HAS_PTE_SPECIAL enablement requires. This restricts those symbol visibility in order to avoid redefinitions which is now exposed through this new generic stubs and subsequent build failure. arm platform set_pte_at() definition needs to be moved into a C file just to prevent a build failure. [[email protected]: use defined(CONFIG_ARCH_HAS_PTE_SPECIAL) in mips per Thomas] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Guo Ren <[email protected]> [csky] Acked-by: Geert Uytterhoeven <[email protected]> [m68k] Acked-by: Stafford Horne <[email protected]> [openrisc] Acked-by: Helge Deller <[email protected]> [parisc] Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Cc: Matt Turner <[email protected]> Cc: Russell King <[email protected]> Cc: Brian Cain <[email protected]> Cc: Tony Luck <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: Sam Creasey <[email protected]> Cc: Michal Simek <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Paul Burton <[email protected]> Cc: Nick Hu <[email protected]> Cc: Greentime Hu <[email protected]> Cc: Vincent Chen <[email protected]> Cc: Ley Foon Tan <[email protected]> Cc: Jonas Bonn <[email protected]> Cc: Stefan Kristiansson <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: Guan Xuetao <[email protected]> Cc: Chris Zankel <[email protected]> Cc: Max Filippov <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-10mm/vma: define a default value for VM_DATA_DEFAULT_FLAGSAnshuman Khandual1-3/+0
There are many platforms with exact same value for VM_DATA_DEFAULT_FLAGS This creates a default value for VM_DATA_DEFAULT_FLAGS in line with the existing VM_STACK_DEFAULT_FLAGS. While here, also define some more macros with standard VMA access flag combinations that are used frequently across many platforms. Apart from simplification, this reduces code duplication as well. Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Vlastimil Babka <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Vineet Gupta <[email protected]> Cc: Russell King <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Mark Salter <[email protected]> Cc: Guo Ren <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Brian Cain <[email protected]> Cc: Tony Luck <[email protected]> Cc: Michal Simek <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Paul Burton <[email protected]> Cc: Nick Hu <[email protected]> Cc: Ley Foon Tan <[email protected]> Cc: Jonas Bonn <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Rich Felker <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Guan Xuetao <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Jeff Dike <[email protected]> Cc: Chris Zankel <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-09Merge branch 'for-next' of ↵Linus Torvalds4-48/+44
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu update from Greg Ungerer: "Only a single commit, to remove all use of the obsolete setup_irq() calls within the m68knommu architecture code" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: Replace setup_irq() by request_irq()
2020-04-07mm/vma: append unlikely() while testing VMA access permissionsAnshuman Khandual1-1/+1
It is unlikely that an inaccessible VMA without required permission flags will get a page fault. Hence lets just append unlikely() directive to such checks in order to improve performance while also standardizing it across various platforms. Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Guo Ren <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Paul Burton <[email protected]> Cc: Mike Rapoport <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-07mm/vma: make vma_is_accessible() available for general useAnshuman Khandual1-1/+1
Lets move vma_is_accessible() helper to include/linux/mm.h which makes it available for general use. While here, this replaces all remaining open encodings for VMA access check with vma_is_accessible(). Signed-off-by: Anshuman Khandual <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Guo Ren <[email protected]> Acked-by: Vlastimil Babka <[email protected]> Cc: Guo Ren <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Paul Burton <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Alexander Viro <[email protected]> Cc: "Aneesh Kumar K.V" <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Nick Piggin <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Will Deacon <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-03Merge tag 'spdx-5.7-rc1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx Pull SPDX updates from Greg KH: "Here are three SPDX patches for 5.7-rc1. One fixes up the SPDX tag for a single driver, while the other two go through the tree and add SPDX tags for all of the .gitignore files as needed. Nothing too complex, but you will get a merge conflict with your current tree, that should be trivial to handle (one file modified by two things, one file deleted.) All three of these have been in linux-next for a while, with no reported issues other than the merge conflict" * tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: ASoC: MT6660: make spdxcheck.py happy .gitignore: add SPDX License Identifier .gitignore: remove too obvious comments
2020-04-02Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds12-12/+0
Pull SCSI updates from James Bottomley: "This series has a huge amount of churn because it pulls in Mauro's doc update changing all our txt files to rst ones. Excluding that, we have the usual driver updates (qla2xxx, ufs, lpfc, zfcp, ibmvfc, pm80xx, aacraid), a treewide update for scnprintf and some other minor updates. The major core change is Hannes moving functions out of the aacraid driver and into the core" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (223 commits) scsi: aic7xxx: aic97xx: Remove FreeBSD-specific code scsi: ufs: Do not rely on prefetched data scsi: dc395x: remove dc395x_bios_param scsi: libiscsi: Fix error count for active session scsi: hpsa: correct race condition in offload enabled scsi: message: fusion: Replace zero-length array with flexible-array member scsi: qedi: Add PCI shutdown handler support scsi: qedi: Add MFW error recovery process scsi: ufs: Enable block layer runtime PM for well-known logical units scsi: ufs-qcom: Override devfreq parameters scsi: ufshcd: Let vendor override devfreq parameters scsi: ufshcd: Update the set frequency to devfreq scsi: ufs: Resume ufs host before accessing ufs device scsi: ufs-mediatek: customize the delay for enabling host scsi: ufs: make HCE polling more compact to improve initialization latency scsi: ufs: allow custom delay prior to host enabling scsi: ufs-mediatek: use common delay function scsi: ufs: introduce common and flexible delay function scsi: ufs: use an enum for host capabilities scsi: ufs: fix uninitialized tx_lanes in ufshcd_disable_tx_lcc() ...
2020-04-02mm: allow VM_FAULT_RETRY for multiple timesPeter Xu1-3/+0
The idea comes from a discussion between Linus and Andrea [1]. Before this patch we only allow a page fault to retry once. We achieved this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing handle_mm_fault() the second time. This was majorly used to avoid unexpected starvation of the system by looping over forever to handle the page fault on a single page. However that should hardly happen, and after all for each code path to return a VM_FAULT_RETRY we'll first wait for a condition (during which time we should possibly yield the cpu) to happen before VM_FAULT_RETRY is really returned. This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY flag when we receive VM_FAULT_RETRY. It means that the page fault handler now can retry the page fault for multiple times if necessary without the need to generate another page fault event. Meanwhile we still keep the FAULT_FLAG_TRIED flag so page fault handler can still identify whether a page fault is the first attempt or not. Then we'll have these combinations of fault flags (only considering ALLOW_RETRY flag and TRIED flag): - ALLOW_RETRY and !TRIED: this means the page fault allows to retry, and this is the first try - ALLOW_RETRY and TRIED: this means the page fault allows to retry, and this is not the first try - !ALLOW_RETRY and !TRIED: this means the page fault does not allow to retry at all - !ALLOW_RETRY and TRIED: this is forbidden and should never be used In existing code we have multiple places that has taken special care of the first condition above by checking against (fault_flags & FAULT_FLAG_ALLOW_RETRY). This patch introduces a simple helper to detect the first retry of a page fault by checking against both (fault_flags & FAULT_FLAG_ALLOW_RETRY) and !(fault_flag & FAULT_FLAG_TRIED) because now even the 2nd try will have the ALLOW_RETRY set, then use that helper in all existing special paths. One example is in __lock_page_or_retry(), now we'll drop the mmap_sem only in the first attempt of page fault and we'll keep it in follow up retries, so old locking behavior will be retained. This will be a nice enhancement for current code [2] at the same time a supporting material for the future userfaultfd-writeprotect work, since in that work there will always be an explicit userfault writeprotect retry for protected pages, and if that cannot resolve the page fault (e.g., when userfaultfd-writeprotect is used in conjunction with swapped pages) then we'll possibly need a 3rd retry of the page fault. It might also benefit other potential users who will have similar requirement like userfault write-protection. GUP code is not touched yet and will be covered in follow up patch. Please read the thread below for more information. [1] https://lore.kernel.org/lkml/[email protected]/ [2] https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Linus Torvalds <[email protected]> Suggested-by: Andrea Arcangeli <[email protected]> Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Brian Geffon <[email protected]> Cc: Bobby Powers <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Denis Plotnikov <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: "Kirill A . Shutemov" <[email protected]> Cc: Martin Cracauer <[email protected]> Cc: Marty McFadden <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Maya Gokhale <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Pavel Emelyanov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-02mm: introduce FAULT_FLAG_DEFAULTPeter Xu1-1/+1
Although there're tons of arch-specific page fault handlers, most of them are still sharing the same initial value of the page fault flags. Say, merely all of the page fault handlers would allow the fault to be retried, and they also allow the fault to respond to SIGKILL. Let's define a default value for the fault flags to replace those initial page fault flags that were copied over. With this, it'll be far easier to introduce new fault flag that can be used by all the architectures instead of touching all the archs. Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Brian Geffon <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Bobby Powers <[email protected]> Cc: Denis Plotnikov <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: "Kirill A . Shutemov" <[email protected]> Cc: Martin Cracauer <[email protected]> Cc: Marty McFadden <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Maya Gokhale <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Pavel Emelyanov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-02mm: introduce fault_signal_pending()Peter Xu1-1/+1
For most architectures, we've got a quick path to detect fatal signal after a handle_mm_fault(). Introduce a helper for that quick path. It cleans the current codes a bit so we don't need to duplicate the same check across archs. More importantly, this will be an unified place that we handle the signal immediately right after an interrupted page fault, so it'll be much easier for us if we want to change the behavior of handling signals later on for all the archs. Note that currently only part of the archs are using this new helper, because some archs have their own way to handle signals. In the follow up patches, we'll try to apply this helper to all the rest of archs. Another note is that the "regs" parameter in the new helper is not used yet. It'll be used very soon. Now we kept it in this patch only to avoid touching all the archs again in the follow up patches. [[email protected]: fix sparse warnings] Link: http://lkml.kernel.org/r/20200311145921.GD479302@xz-x1 Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Brian Geffon <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Bobby Powers <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Denis Plotnikov <[email protected]> Cc: "Dr . David Alan Gilbert" <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: "Kirill A . Shutemov" <[email protected]> Cc: Martin Cracauer <[email protected]> Cc: Marty McFadden <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Maya Gokhale <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: Pavel Emelyanov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-04-02asm-generic: make more kernel-space headers mandatoryMasahiro Yamada1-24/+0
Change a header to mandatory-y if both of the following are met: [1] At least one architecture (except um) specifies it as generic-y in arch/*/include/asm/Kbuild [2] Every architecture (except um) either has its own implementation (arch/*/include/asm/*.h) or specifies it as generic-y in arch/*/include/asm/Kbuild This commit was generated by the following shell script. ----------------------------------->8----------------------------------- arches=$(cd arch; ls -1 | sed -e '/Kconfig/d' -e '/um/d') tmpfile=$(mktemp) grep "^mandatory-y +=" include/asm-generic/Kbuild > $tmpfile find arch -path 'arch/*/include/asm/Kbuild' | xargs sed -n 's/^generic-y += \(.*\)/\1/p' | sort -u | while read header do mandatory=yes for arch in $arches do if ! grep -q "generic-y += $header" arch/$arch/include/asm/Kbuild && ! [ -f arch/$arch/include/asm/$header ]; then mandatory=no break fi done if [ "$mandatory" = yes ]; then echo "mandatory-y += $header" >> $tmpfile for arch in $arches do sed -i "/generic-y += $header/d" arch/$arch/include/asm/Kbuild done fi done sed -i '/^mandatory-y +=/d' include/asm-generic/Kbuild LANG=C sort $tmpfile >> include/asm-generic/Kbuild ----------------------------------->8----------------------------------- One obvious benefit is the diff stat: 25 files changed, 52 insertions(+), 557 deletions(-) It is tedious to list generic-y for each arch that needs it. So, mandatory-y works like a fallback default (by just wrapping asm-generic one) when arch does not have a specific header implementation. See the following commits: def3f7cefe4e81c296090e1722a76551142c227c a1b39bae16a62ce4aae02d958224f19316d98b24 It is tedious to convert headers one by one, so I processed by a shell script. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Michal Simek <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Arnd Bergmann <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-03-31Merge tag 'm68k-for-v5.7-tag1' of ↵Linus Torvalds26-356/+328
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k updates from Geert Uytterhoeven: - pagetable layout rewrite, to facilitate global READ_ONCE() rework - Zorro (Amiga) and DIO (HP 9000/300) bus cleanups - defconfig updates - minor cleanups and fixes * tag 'm68k-for-v5.7-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: (23 commits) m68k: defconfig: Update defconfigs for v5.6-rc4 zorro: Replace zero-length array with flexible-array member m68k: Switch to asm-generic/hardirq.h fbdev: c2p: Use BUILD_BUG() instead of custom solution dio: Remove unused dio_dev_driver() dio: Fix dio_bus_match() kerneldoc dio: Make dio_match_device() static zorro: Move zorro_bus_type to bus-private header file zorro: Remove unused zorro_dev_driver() zorro: Use zorro_match_device() helper in zorro_bus_match() zorro: Fix zorro_bus_match() kerneldoc zorro: Make zorro_match_device() static m68k: Fix Kconfig indentation m68k: mm: Change ColdFire pgtable_t m68k: mm: Fully initialize the page-table allocator m68k: mm: Extend table allocator for multiple sizes m68k: mm: Use table allocator for pgtables m68k: mm: Improve kernel_page_table() m68k: mm: Restructure Motorola MMU page-table layout m68k: mm: Move the pointer table allocator to motorola.c ...
2020-03-30Merge branch 'locking-core-for-linus' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking updates from Ingo Molnar: "The main changes in this cycle were: - Continued user-access cleanups in the futex code. - percpu-rwsem rewrite that uses its own waitqueue and atomic_t instead of an embedded rwsem. This addresses a couple of weaknesses, but the primary motivation was complications on the -rt kernel. - Introduce raw lock nesting detection on lockdep (CONFIG_PROVE_RAW_LOCK_NESTING=y), document the raw_lock vs. normal lock differences. This too originates from -rt. - Reuse lockdep zapped chain_hlocks entries, to conserve RAM footprint on distro-ish kernels running into the "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!" depletion of the lockdep chain-entries pool. - Misc cleanups, smaller fixes and enhancements - see the changelog for details" * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (55 commits) fs/buffer: Make BH_Uptodate_Lock bit_spin_lock a regular spinlock_t thermal/x86_pkg_temp: Make pkg_temp_lock a raw_spinlock_t Documentation/locking/locktypes: Minor copy editor fixes Documentation/locking/locktypes: Further clarifications and wordsmithing m68knommu: Remove mm.h include from uaccess_no.h x86: get rid of user_atomic_cmpxchg_inatomic() generic arch_futex_atomic_op_inuser() doesn't need access_ok() x86: don't reload after cmpxchg in unsafe_atomic_op2() loop x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end() objtool: whitelist __sanitizer_cov_trace_switch() [parisc, s390, sparc64] no need for access_ok() in futex handling sh: no need of access_ok() in arch_futex_atomic_op_inuser() futex: arch_futex_atomic_op_inuser() calling conventions change completion: Use lockdep_assert_RT_in_threaded_ctx() in complete_all() lockdep: Add posixtimer context tracing bits lockdep: Annotate irq_work lockdep: Add hrtimer context tracing bits lockdep: Introduce wait-type checks completion: Use simple wait queues sched/swait: Prepare usage in completions ...
2020-03-28m68knommu: Remove mm.h include from uaccess_no.hThomas Gleixner1-1/+0
In file included from include/linux/huge_mm.h:8, from include/linux/mm.h:567, from arch/m68k/include/asm/uaccess_no.h:8, from arch/m68k/include/asm/uaccess.h:3, from include/linux/uaccess.h:11, from include/linux/sched/task.h:11, from include/linux/sched/signal.h:9, from include/linux/rcuwait.h:6, from include/linux/percpu-rwsem.h:7, from kernel/locking/percpu-rwsem.c:6: include/linux/fs.h:1422:29: error: array type has incomplete element type 'struct percpu_rw_semaphore' 1422 | struct percpu_rw_semaphore rw_sem[SB_FREEZE_LEVELS]; Removing the include of linux/mm.h from the uaccess header solves the problem and various build tests of nommu configurations still work. Fixes: 80fbaf1c3f29 ("rcuwait: Add @state argument to rcuwait_wait_event()") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-27block: simplify queue allocationChristoph Hellwig1-2/+1
Current make_request based drivers use either blk_alloc_queue_node or blk_alloc_queue to allocate a queue, and then set up the make_request_fn function pointer and a few parameters using the blk_queue_make_request helper. Simplify this by passing the make_request pointer to blk_alloc_queue, and while at it merge the _node variant into the main helper by always passing a node_id, and remove the superfluous gfp_mask parameter. A lower-level __blk_alloc_queue is kept for the blk-mq case. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-03-25.gitignore: add SPDX License IdentifierMasahiro Yamada1-0/+1
Add SPDX License Identifier to all .gitignore files. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-23m68k: Replace setup_irq() by request_irq()afzal mohammed4-48/+44
request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed <[email protected]> Tested-by: Greg Ungerer <[email protected]> Signed-off-by: Greg Ungerer <[email protected]>
2020-03-09m68k: defconfig: Update defconfigs for v5.6-rc4Geert Uytterhoeven12-48/+12
- Drop CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m (depends on BRIDGE_NETFILTER, which is disabled by default since commit 98bda63e20daab95 ("net: disable BRIDGE_NETFILTER by default")), - Enable modular build of the WireGuard secure network tunnel, - Drop CONFIG_CRYPTO_LIB_{BLAKE2S,CHACHA20POLY1305,CURVE25519}=m (auto-enabled by CONFIG_WIREGUARD). Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-03-09m68k: Switch to asm-generic/hardirq.hGeert Uytterhoeven2-29/+1
Classic m68k with MMU was converted to generic hardirqs a long time ago, and there are no longer include dependency issues preventing the direct use of asm-generic/hardirq.h. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-03-09m68k: Fix Kconfig indentationKrzysztof Kozlowski3-13/+13
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-24scsi: sr: remove references to BLK_DEV_SR_VENDOR, leave it enabledDiego Elio Pettenò12-12/+0
This kernel configuration is basically enabling/disabling sr driver quirks detection. While these quirks are for fairly rare devices (very old CD burners, and a glucometer), the additional detection of these models is a very minimal amount of code. The logic behind the quirks is always built into the sr driver. This also removes the config from all the defconfig files that are enabling this already. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Jens Axboe <[email protected]> Signed-off-by: Diego Elio Pettenò <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-02-10m68k: mm: Change ColdFire pgtable_tWill Deacon2-13/+19
To match what we did to the Motorola MMU routines, change the ColdFire pgalloc. The result is that ColdFire and Sun3 pgalloc are actually very similar and could conceivably be unified. Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Fully initialize the page-table allocatorPeter Zijlstra1-1/+12
Also iterate the PMD tables to populate the PTE table allocator. This also fully replaces the previous zero_pgtable hack. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Extend table allocator for multiple sizesPeter Zijlstra3-42/+70
In addition to the PGD/PMD table size (128*4) add a PTE table size (64*4) to the table allocator. This completely removes the pte-table overhead compared to the old code, even for dense tables. Notes: - the allocator gained a list_empty() check to deal with there not being any pages at all. - the free mask is extended to cover more than the 8 bits required for the (512 byte) PGD/PMD tables. - NR_PAGETABLE accounting is restored. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Use table allocator for pgtablesPeter Zijlstra3-36/+21
With the new page-table layout, using full (4k) pages for (256 byte) pte-tables is immensely wastefull. Move the pte-tables over to the same allocator already used for the (512 byte) higher level tables (pgd/pmd). This reduces the pte-table waste from 15x to 2x. Due to no longer being bound to 16 consecutive tables, this might actually already be more efficient than the old code for sparse tables. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Improve kernel_page_table()Peter Zijlstra3-28/+41
With the PTE-tables now only being 256 bytes, allocating a full page for them is a giant waste. Start by improving the boot time allocator such that init_mm initialization will at least have optimal memory density. Much thanks to Will Deacon in help with debugging and ferreting out lost information on these dusty MMUs. Notes: - _TABLE_MASK is reduced to account for the shorter (256 byte) alignment of pte-tables, per the manual, table entries should only ever have state in the low 4 bits (Used,WrProt,Desc1,Desc0) so it is still longer than strictly required. (Thanks Will!!!) - Also use kernel_page_table() for the 020/030 zero_pgtable case and consequently remove the zero_pgtable init hack (will fix up later). Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Restructure Motorola MMU page-table layoutPeter Zijlstra5-56/+39
The Motorola 68xxx MMUs, 040 (and later) have a fixed 7,7,{5,6} page-table setup, where the last depends on the page-size selected (8k vs 4k resp.), and head.S selects 4K pages. For 030 (and earlier) we explicitly program 7,7,6 and 4K pages in %tc. However, the current code implements this mightily weird. What it does is group 16 of those (6 bit) pte tables into one 4k page to not waste space. The down-side is that that forces pmd_t to be a 16-tuple pointing to consecutive pte tables. This breaks the generic code which assumes READ_ONCE(*pmd) will be word sized. Therefore implement a straight forward 7,7,6 3 level page-table setup, with the addition (for 020/030) of (partial) large-page support. For now this increases the memory footprint for pte-tables 15 fold. Tested with ARAnyM/68040 emulation. Suggested-by: Will Deacon <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Move the pointer table allocator to motorola.cPeter Zijlstra2-102/+102
Only the Motorola MMU makes use of this allocator, it is a waste of .text to include it for Sun3/ColdFire. Also, this is going to avoid build issues when we're going to make it more Motorola specific. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Unify Motorola MMU page setupPeter Zijlstra3-22/+36
Seeing how there are 5 copies of this magic code, one of which is unexplainably different, unify and document things. Suggested-by: Will Deacon <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Fix ColdFire pgd_alloc()Will Deacon1-1/+1
I also notice that building for m5475evb_defconfig with vanilla v5.5 triggers this scary looking warning due to a mismatch between the pgd size and the (8k!) page size: | In function 'pgd_alloc.isra.111', | inlined from 'mm_alloc_pgd' at kernel/fork.c:634:12, | inlined from 'mm_init.isra.112' at kernel/fork.c:1043:6: | ./arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset [4097, 8192] is out of the bounds [0, 4096] of object 'kernel_pg_dir' with type 'pgd_t[1024]' {aka 'struct <anonymous>[1024]'} [-Warray-bounds] | #define memcpy(d, s, n) __builtin_memcpy(d, s, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ | ./arch/m68k/include/asm/mcf_pgalloc.h:93:2: note: in expansion of macro 'memcpy' | memcpy(new_pgd, swapper_pg_dir, PAGE_SIZE); | ^~~~~~ Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-10m68k: mm: Remove stray nocache in ColdFire pgallocPeter Zijlstra1-5/+1
Since ColdFire V4e is a software TLB-miss architecture, there is no need for page-tables to be mapped uncached. Remove this stray nocache_page() dance, which isn't paired with a cache_page() and looks like a copy/paste/edit fail. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Michael Schmitz <[email protected]> Tested-by: Greg Ungerer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2020-02-06Merge branch 'for-next' of ↵Linus Torvalds9-23/+11
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu Pull m68knommu updates from Greg Ungerer: "A couple of changes: - remove old CONFIG options from the m68knommu defconfig files - fix a warning in the m68k non-MMU get_user() macro" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68knommu: fix memcpy() out of bounds warning in get_user() m68k: configs: Cleanup old Kconfig IO scheduler options
2020-02-04proc: convert everything to "struct proc_ops"Alexey Dobriyan1-4/+4
The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in seq_file.h. Conversion rule is: llseek => proc_lseek unlocked_ioctl => proc_ioctl xxx => proc_xxx delete ".owner = THIS_MODULE" line [[email protected]: fix drivers/isdn/capi/kcapi_proc.c] [[email protected]: fix kernel/sched/psi.c] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-02-03m68knommu: fix memcpy() out of bounds warning in get_user()Greg Ungerer1-8/+11
Newer versions of gcc are giving warnings in the non-MMU m68k version of the get_user() macro: ./arch/m68k/include/asm/string.h:72:25: warning: ‘__builtin_memcpy’ forming offset [3, 4] is out of the bounds [0, 2] of object ‘__gu_val’ with type ‘short unsigned int’ [-Warray-bounds] The warnings are generated when smaller sized variables are used as the result of user space pointers to larger values. For example a short/2-byte variable stores the result of a user space int (4-byte) pointer. The warning is in the 8-byte branch of get_user() - even though that branch is not the taken branch in the warning cases. Refactor the 8-byte branch of get_user() so that it uses a correctly formed union type to read and write the source and destination objects. Keep using the memcpy() just in case the user space pointer is not naturaly aligned (not required for ColdFire, but needed for early 68000). Signed-off-by: Greg Ungerer <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.