1. 12 1月, 2019 1 次提交
    • A
      mips: fix n32 compat_ipc_parse_version · 5a9372f7
      Arnd Bergmann 提交于
      While reading through the sysvipc implementation, I noticed that the n32
      semctl/shmctl/msgctl system calls behave differently based on whether
      o32 support is enabled or not: Without o32, the IPC_64 flag passed by
      user space is rejected but calls without that flag get IPC_64 behavior.
      
      As far as I can tell, this was inadvertently changed by a cleanup patch
      but never noticed by anyone, possibly nobody has tried using sysvipc
      on n32 after linux-3.19.
      
      Change it back to the old behavior now.
      
      Fixes: 78aaf956 ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # 3.19+
      5a9372f7
  2. 11 1月, 2019 1 次提交
  3. 10 1月, 2019 2 次提交
    • R
      MIPS: BCM47XX: Setup struct device for the SoC · 321c46b9
      Rafał Miłecki 提交于
      So far we never had any device registered for the SoC. This resulted in
      some small issues that we kept ignoring like:
      1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
      2) Lack of proper tree in the /sys/devices/
      3) mips_dma_alloc_coherent() silently handling empty coherent_dma_mask
      
      Kernel 4.19 came with a lot of DMA changes and caused a regression on
      bcm47xx. Starting with the commit f8c55dc6 ("MIPS: use generic dma
      noncoherent ops for simple noncoherent platforms") DMA coherent
      allocations just fail. Example:
      [    1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
      [    1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
      [    1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
      [    1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
      
      The bgmac driver also triggers a WARNING:
      [    0.959486] ------------[ cut here ]------------
      [    0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 bgmac_enet_probe+0x1b4/0x5c4
      [    0.973751] Modules linked in:
      [    0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
      [    0.982750] Stack : 804a0000 804597c4 00000000 00000000 80458fd8 8381bc2c 838282d4 80481a47
      [    0.991367]         8042e3ec 00000001 804d38f0 00000204 83980000 00000065 8381bbe0 6f55b24f
      [    0.999975]         00000000 00000000 80520000 00002018 00000000 00000075 00000007 00000000
      [    1.008583]         00000000 80480000 000ee811 00000000 00000000 00000000 80432c00 80248db8
      [    1.017196]         00000009 00000204 83980000 803ad7b0 00000000 801feeec 00000000 804d0000
      [    1.025804]         ...
      [    1.028325] Call Trace:
      [    1.030875] [<8000aef8>] show_stack+0x58/0x100
      [    1.035513] [<8001f8b4>] __warn+0xe4/0x118
      [    1.039708] [<8001f9a4>] warn_slowpath_null+0x48/0x64
      [    1.044935] [<80248db8>] bgmac_enet_probe+0x1b4/0x5c4
      [    1.050101] [<802498e0>] bgmac_probe+0x558/0x590
      [    1.054906] [<80252fd0>] bcma_device_probe+0x38/0x70
      [    1.060017] [<8020e1e8>] really_probe+0x170/0x2e8
      [    1.064891] [<8020e714>] __driver_attach+0xa4/0xec
      [    1.069784] [<8020c1e0>] bus_for_each_dev+0x58/0xb0
      [    1.074833] [<8020d590>] bus_add_driver+0xf8/0x218
      [    1.079731] [<8020ef24>] driver_register+0xcc/0x11c
      [    1.084804] [<804b54cc>] bgmac_init+0x1c/0x44
      [    1.089258] [<8000121c>] do_one_initcall+0x7c/0x1a0
      [    1.094343] [<804a1d34>] kernel_init_freeable+0x150/0x218
      [    1.099886] [<803a082c>] kernel_init+0x10/0x104
      [    1.104583] [<80005878>] ret_from_kernel_thread+0x14/0x1c
      [    1.110107] ---[ end trace f441c0d873d1fb5b ]---
      
      This patch setups a "struct device" (and passes it to the bcma) which
      allows fixing all the mentioned problems. It'll also require a tiny bcma
      patch which will follow through the wireless tree & its maintainer.
      
      Fixes: f8c55dc6 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-wireless@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.19+
      321c46b9
    • T
      MIPS: jazz: fix 64bit build · 41af167f
      Thomas Bogendoerfer 提交于
      64bit JAZZ builds failed with
      
        linux-next/arch/mips/jazz/jazzdma.c: In function `vdma_init`:
        /linux-next/arch/mips/jazz/jazzdma.c:77:30: error: implicit declaration
          of function `KSEG1ADDR`; did you mean `CKSEG1ADDR`?
          [-Werror=implicit-function-declaration]
          pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
                                      ^~~~~~~~~
                                      CKSEG1ADDR
        /linux-next/arch/mips/jazz/jazzdma.c:77:10: error: cast to pointer from
          integer of different size [-Werror=int-to-pointer-cast]
          pgtbl = (VDMA_PGTBL_ENTRY *)KSEG1ADDR(pgtbl);
                  ^
        In file included from /linux-next/arch/mips/include/asm/barrier.h:11:0,
                         from /linux-next/include/linux/compiler.h:248,
                         from /linux-next/include/linux/kernel.h:10,
                         from /linux-next/arch/mips/jazz/jazzdma.c:11:
        /linux-next/arch/mips/include/asm/addrspace.h:41:29: error: cast from
          pointer to integer of different size [-Werror=pointer-to-int-cast]
         #define _ACAST32_  (_ATYPE_)(_ATYPE32_) /* widen if necessary */
                                     ^
        /linux-next/arch/mips/include/asm/addrspace.h:53:25: note: in
          expansion of macro `_ACAST32_`
         #define CPHYSADDR(a)  ((_ACAST32_(a)) & 0x1fffffff)
                                 ^~~~~~~~~
        /linux-next/arch/mips/jazz/jazzdma.c:84:44: note: in expansion of
          macro `CPHYSADDR`
          r4030_write_reg32(JAZZ_R4030_TRSTBL_BASE, CPHYSADDR(pgtbl));
      
      Using correct casts and CKSEG1ADDR when dealing with the pgtbl setup
      fixes this.
      Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      41af167f
  4. 08 1月, 2019 3 次提交
    • A
      MIPS: ath79: Enable OF serial ports in the default config · 565dc8a4
      Alban Bedel 提交于
      CONFIG_SERIAL_OF_PLATFORM is needed to get a working console on the OF
      boards, enable it in the default config to get a working setup out of
      the box.
      Signed-off-by: NAlban Bedel <albeu@free.fr>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      565dc8a4
    • H
      MIPS: lantiq: Use CP0_LEGACY_COMPARE_IRQ · 390d1b46
      Hauke Mehrtens 提交于
      Instead of using the lantiq specific MIPS_CPU_TIMER_IRQ use the generic
      CP0_LEGACY_COMPARE_IRQ constant for the timer interrupt number.
      MIPS_CPU_TIMER_IRQ was already defined to 7 for both supported SoC
      families.
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: jhogan@kernel.org
      Cc: ralf@linux-mips.org
      Cc: john@phrozen.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-mips@vger.kernel.org
      390d1b46
    • H
      MIPS: lantiq: Fix IPI interrupt handling · 2b4dba55
      Hauke Mehrtens 提交于
      This makes SMP on the vrx200 work again, by removing all the MIPS CPU
      interrupt specific code and making it fully use the generic MIPS CPU
      interrupt controller.
      
      The mti,cpu-interrupt-controller from irq-mips-cpu.c now handles the CPU
      interrupts and also the IPI interrupts which are used to communication
      between the CPUs in a SMP system. The generic interrupt code was
      already used before but the interrupt vectors were overwritten again
      when we called set_vi_handler() in the lantiq interrupt driver and we
      also provided our own plat_irq_dispatch() function which overwrote the
      weak generic implementation. Now the code uses the generic handler for
      the MIPS CPU interrupts including the IPI interrupts and registers a
      handler for the CPU interrupts which are handled by the lantiq ICU with
      irq_set_chained_handler() which was already called before.
      
      Calling the set_c0_status() function is also not needed any more because
      the generic MIPS CPU interrupt already activates the needed bits.
      
      Fixes: 1eed4004 ("MIPS: smp-mt: Use CPU interrupt controller IPI IRQ domain support")
      Cc: stable@kernel.org # v4.12
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: jhogan@kernel.org
      Cc: ralf@linux-mips.org
      Cc: john@phrozen.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-mips@vger.kernel.org
      2b4dba55
  5. 06 1月, 2019 3 次提交
  6. 05 1月, 2019 2 次提交
    • J
      mm: treewide: remove unused address argument from pte_alloc functions · 4cf58924
      Joel Fernandes (Google) 提交于
      Patch series "Add support for fast mremap".
      
      This series speeds up the mremap(2) syscall by copying page tables at
      the PMD level even for non-THP systems.  There is concern that the extra
      'address' argument that mremap passes to pte_alloc may do something
      subtle architecture related in the future that may make the scheme not
      work.  Also we find that there is no point in passing the 'address' to
      pte_alloc since its unused.  This patch therefore removes this argument
      tree-wide resulting in a nice negative diff as well.  Also ensuring
      along the way that the enabled architectures do not do anything funky
      with the 'address' argument that goes unnoticed by the optimization.
      
      Build and boot tested on x86-64.  Build tested on arm64.  The config
      enablement patch for arm64 will be posted in the future after more
      testing.
      
      The changes were obtained by applying the following Coccinelle script.
      (thanks Julia for answering all Coccinelle questions!).
      Following fix ups were done manually:
      * Removal of address argument from  pte_fragment_alloc
      * Removal of pte_alloc_one_fast definitions from m68k and microblaze.
      
      // Options: --include-headers --no-includes
      // Note: I split the 'identifier fn' line, so if you are manually
      // running it, please unsplit it so it runs for you.
      
      virtual patch
      
      @pte_alloc_func_def depends on patch exists@
      identifier E2;
      identifier fn =~
      "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      type T2;
      @@
      
       fn(...
      - , T2 E2
       )
       { ... }
      
      @pte_alloc_func_proto_noarg depends on patch exists@
      type T1, T2, T3, T4;
      identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      @@
      
      (
      - T3 fn(T1, T2);
      + T3 fn(T1);
      |
      - T3 fn(T1, T2, T4);
      + T3 fn(T1, T2);
      )
      
      @pte_alloc_func_proto depends on patch exists@
      identifier E1, E2, E4;
      type T1, T2, T3, T4;
      identifier fn =~
      "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      @@
      
      (
      - T3 fn(T1 E1, T2 E2);
      + T3 fn(T1 E1);
      |
      - T3 fn(T1 E1, T2 E2, T4 E4);
      + T3 fn(T1 E1, T2 E2);
      )
      
      @pte_alloc_func_call depends on patch exists@
      expression E2;
      identifier fn =~
      "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      @@
      
       fn(...
      -,  E2
       )
      
      @pte_alloc_macro depends on patch exists@
      identifier fn =~
      "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
      identifier a, b, c;
      expression e;
      position p;
      @@
      
      (
      - #define fn(a, b, c) e
      + #define fn(a, b) e
      |
      - #define fn(a, b) e
      + #define fn(a) e
      )
      
      Link: http://lkml.kernel.org/r/20181108181201.88826-2-joelaf@google.comSigned-off-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Suggested-by: NKirill A. Shutemov <kirill@shutemov.name>
      Acked-by: NKirill A. Shutemov <kirill@shutemov.name>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Cc: Kirill A. Shutemov <kirill@shutemov.name>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4cf58924
    • M
      fls: change parameter to unsigned int · 3fc2579e
      Matthew Wilcox 提交于
      When testing in userspace, UBSAN pointed out that shifting into the sign
      bit is undefined behaviour.  It doesn't really make sense to ask for the
      highest set bit of a negative value, so just turn the argument type into
      an unsigned int.
      
      Some architectures (eg ppc) already had it declared as an unsigned int,
      so I don't expect too many problems.
      
      Link: http://lkml.kernel.org/r/20181105221117.31828-1-willy@infradead.orgSigned-off-by: NMatthew Wilcox <willy@infradead.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3fc2579e
  7. 04 1月, 2019 1 次提交
    • L
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds 提交于
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      
      There were a couple of notable cases:
      
       - csky still had the old "verify_area()" name as an alias.
      
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
      
       - microblaze used the type argument for a debug printout
      
      but other than those oddities this should be a total no-op patch.
      
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96d4f267
  8. 03 1月, 2019 1 次提交
    • A
      MIPS: OCTEON: mark RGMII interface disabled on OCTEON III · edefae94
      Aaro Koskinen 提交于
      Commit 885872b7 ("MIPS: Octeon: Add Octeon III CN7xxx
      interface detection") added RGMII interface detection for OCTEON III,
      but it results in the following logs:
      
      [    7.165984] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
      [    7.173017] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
      
      The current RGMII routines are valid only for older OCTEONS that
      use GMX/ASX hardware blocks. On later chips AGL should be used,
      but support for that is missing in the mainline. Until that is added,
      mark the interface as disabled.
      
      Fixes: 885872b7 ("MIPS: Octeon: Add Octeon III CN7xxx interface detection")
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # 4.7+
      edefae94
  9. 31 12月, 2018 2 次提交
    • H
      MIPS: Fix a R10000_LLSC_WAR logic in atomic.h · db1ce3f5
      Huacai Chen 提交于
      Commit 4936084c ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
      introduce a mistake in atomic64_fetch_##op##_relaxed(), because it
      forget to delete R10000_LLSC_WAR in the if-condition. So fix it.
      
      Fixes: 4936084c ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Steven J . Hill <Steven.Hill@cavium.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # 4.19+
      db1ce3f5
    • J
      MIPS: BCM63XX: drop unused and broken DSP platform device · 682fee80
      Jonas Gorski 提交于
      Trying to register the DSP platform device results in a null pointer
      access:
      
      [    0.124184] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 804e305c, ra == 804e6f20
      [    0.135208] Oops[#1]:
      [    0.137514] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.87
      ...
      [    0.197117] epc   : 804e305c bcm63xx_dsp_register+0x80/0xa4
      [    0.202838] ra    : 804e6f20 board_register_devices+0x258/0x390
      ...
      
      This happens because it tries to copy the passed platform data over the
      platform_device's unpopulated platform_data.
      
      Since this code has been broken since its submission, no driver was ever
      submitted for it, and apparently nobody was using it, just remove it
      instead of trying to fix it.
      
      Fixes: e7300d04 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.")
      Signed-off-by: NJonas Gorski <jonas.gorski@gmail.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      682fee80
  10. 30 12月, 2018 4 次提交
    • C
      kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops · cc028297
      Christophe Leroy 提交于
      checkpatch.pl reports the following:
      
        WARNING: struct kgdb_arch should normally be const
        #28: FILE: arch/mips/kernel/kgdb.c:397:
        +struct kgdb_arch arch_kgdb_ops = {
      
      This report makes sense, as all other ops struct, this
      one should also be const. This patch does the change.
      
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: x86@kernel.org
      Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      cc028297
    • C
      mips/kgdb: prepare arch_kgdb_ops for constness · 911b7afd
      Christophe Leroy 提交于
      MIPS is the only architecture modifying arch_kgdb_ops during init.
      This patch makes the init static, so that it can be changed to
      const in following patch, as recommended by checkpatch.pl
      Suggested-by: NPaul Burton <paul.burton@mips.com>
      Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      911b7afd
    • D
      kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() · 3cd99ac3
      Douglas Anderson 提交于
      When I had lockdep turned on and dropped into kgdb I got a nice splat
      on my system.  Specifically it hit:
        DEBUG_LOCKS_WARN_ON(current->hardirq_context)
      
      Specifically it looked like this:
        sysrq: SysRq : DEBUG
        ------------[ cut here ]------------
        DEBUG_LOCKS_WARN_ON(current->hardirq_context)
        WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 lockdep_hardirqs_on+0xf0/0x160
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27
        pstate: 604003c9 (nZCv DAIF +PAN -UAO)
        pc : lockdep_hardirqs_on+0xf0/0x160
        ...
        Call trace:
         lockdep_hardirqs_on+0xf0/0x160
         trace_hardirqs_on+0x188/0x1ac
         kgdb_roundup_cpus+0x14/0x3c
         kgdb_cpu_enter+0x53c/0x5cc
         kgdb_handle_exception+0x180/0x1d4
         kgdb_compiled_brk_fn+0x30/0x3c
         brk_handler+0x134/0x178
         do_debug_exception+0xfc/0x178
         el1_dbg+0x18/0x78
         kgdb_breakpoint+0x34/0x58
         sysrq_handle_dbg+0x54/0x5c
         __handle_sysrq+0x114/0x21c
         handle_sysrq+0x30/0x3c
         qcom_geni_serial_isr+0x2dc/0x30c
        ...
        ...
        irq event stamp: ...45
        hardirqs last  enabled at (...44): [...] __do_softirq+0xd8/0x4e4
        hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130
        softirqs last  enabled at (...42): [...] _local_bh_enable+0x2c/0x34
        softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100
        ---[ end trace adf21f830c46e638 ]---
      
      Looking closely at it, it seems like a really bad idea to be calling
      local_irq_enable() in kgdb_roundup_cpus().  If nothing else that seems
      like it could violate spinlock semantics and cause a deadlock.
      
      Instead, let's use a private csd alongside
      smp_call_function_single_async() to round up the other CPUs.  Using
      smp_call_function_single_async() doesn't require interrupts to be
      enabled so we can remove the offending bit of code.
      
      In order to avoid duplicating this across all the architectures that
      use the default kgdb_roundup_cpus(), we'll add a "weak" implementation
      to debug_core.c.
      
      Looking at all the people who previously had copies of this code,
      there were a few variants.  I've attempted to keep the variants
      working like they used to.  Specifically:
      * For arch/arc we passed NULL to kgdb_nmicallback() instead of
        get_irq_regs().
      * For arch/mips there was a bit of extra code around
        kgdb_nmicallback()
      
      NOTE: In this patch we will still get into trouble if we try to round
      up a CPU that failed to round up before.  We'll try to round it up
      again and potentially hang when we try to grab the csd lock.  That's
      not new behavior but we'll still try to do better in a future patch.
      Suggested-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      3cd99ac3
    • D
      kgdb: Remove irq flags from roundup · 9ef7fa50
      Douglas Anderson 提交于
      The function kgdb_roundup_cpus() was passed a parameter that was
      documented as:
      
      > the flags that will be used when restoring the interrupts. There is
      > local_irq_save() call before kgdb_roundup_cpus().
      
      Nobody used those flags.  Anyone who wanted to temporarily turn on
      interrupts just did local_irq_enable() and local_irq_disable() without
      looking at them.  So we can definitely remove the flags.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      9ef7fa50
  11. 24 12月, 2018 2 次提交
    • L
      watchdog: mtx-1: Convert to use GPIO descriptor · d2b911db
      Linus Walleij 提交于
      This converts the MTX-1 driver to grab a GPIO descriptor
      associated with the device instead of using a resource with
      a global GPIO number. Augment the driver and the boardfile.
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@linux-watchdog.org>
      d2b911db
    • S
      MIPS: ralink: Select CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 · 0b153944
      Stefan Roese 提交于
      Testing has shown, that when using mainline U-Boot on MT7688 based
      boards, the system may hang or crash while mounting the root-fs. The
      main issue here is that mainline U-Boot configures EBase to a value
      near the end of system memory. And with CONFIG_CPU_MIPSR2_IRQ_VI
      disabled, trap_init() will not allocate a new area to place the
      exception handler. The original value will be used and the handler
      will be copied to this location, which might already be used by some
      userspace application.
      
      The MT7688 supports VI - its config3 register is 0x00002420, so VInt
      (Bit 5) is set. But without setting CONFIG_CPU_MIPSR2_IRQ_VI this
      bit will not be evaluated to result in "cpu_has_vi" being set. This
      patch now selects CONFIG_CPU_MIPSR2_IRQ_VI on MT7620/8 which results
      trap_init() to allocate some memory for the exception handler.
      
      Please note that this issue was not seen with the Mediatek U-Boot
      version, as it does not touch EBase (stays at default of 0x8000.0000).
      This is strictly also not correct as the kernel (_text) resides
      here.
      Signed-off-by: NStefan Roese <sr@denx.de>
      [paul.burton@mips.com: s/beeing/being/]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      0b153944
  12. 23 12月, 2018 5 次提交
  13. 21 12月, 2018 3 次提交
  14. 18 12月, 2018 1 次提交
  15. 17 12月, 2018 2 次提交
  16. 15 12月, 2018 6 次提交
    • F
      mips: generate uapi header and system call table files · 99bf73eb
      Firoz Khan 提交于
      System call table generation script must be run to gener-
      ate unistd_(nr_)n64/n32/o32.h and syscall_table_32_o32/
      64_n64/64_n32/64-o32.h files. This patch will have changes
      which will invokes the script.
      
      This patch will generate unistd_(nr_)n64/n32/o32.h and
      syscall_table_32_o32/64_n64/64-n32/64-o32.h files by the
      syscall table generation script invoked by parisc/Make-
      file and the generated files against the removed files
      must be identical.
      
      The generated uapi header file will be included in uapi/-
      asm/unistd.h and generated system call table header file
      will be included by kernel/scall32-o32/64-n64/64-n32/-
      64-o32.Sfile.
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      99bf73eb
    • F
      mips: add system call table generation support · 9bcbf97c
      Firoz Khan 提交于
      The system call tables are in different format in all
      architecture and it will be difficult to manually add,
      modify or delete the syscall table entries in the res-
      pective files. To make it easy by keeping a script and
      which will generate the uapi header and syscall table
      file. This change will also help to unify the implemen-
      tation across all architectures.
      
      The system call table generation script is added in
      kernel/syscalls directory which contain the scripts to
      generate both uapi header file and system call table
      files. The syscall.tbl will be input for the scripts.
      
      syscall.tbl contains the list of available system calls
      along with system call number and corresponding entry
      point. Add a new system call in this architecture will
      be possible by adding new entry in the syscall.tbl file.
      
      Adding a new table entry consisting of:
        	- System call number.
      	- ABI.
      	- System call name.
      	- Entry point name.
      	- Compat entry name, if required.
      
      syscallhdr.sh, syscallnr.sh and syscalltbl.sh will gene-
      rate uapi header unistd_n64/n32/o32.h, unistd_nr_n64/n32/-
      o32.h and syscall_table_32_o32/64_n64/64-n32/64-o32.h files
      respectively. All *.sh files will parse the content sys-
      call.tbl to generate the header and table files. unistd-
      _n64/n32/o32.h and unistd_nr_n64/n32/o32.h will be included
      by uapi/asm/unistd.h and syscall_table_32_o32/64_n64/64-n32-
      /64-o32.h is included by kernel/syscall_table32_o32/64-
      _n64/64-n32/64-o32.S - the real system call table.
      
      ARM, s390 and x86 architecuture does have similar support.
      I leverage their implementation to come up with a generic
      solution.
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      [paul.burton@mips.com:
       - Change sysnr_pfx_unistd_nr_n64 to 64.]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      9bcbf97c
    • F
      mips: remove syscall table entries · 6a00cb61
      Firoz Khan 提交于
      The config flag - CONFIG_MIPS_MT_FPAFF uses to check whether which
      syscall entries need to be used in scall32-o32.S file.
      
      One of the patch in this patch series will generate syscall table
      file. But CONFIG_MIPS_MT_FPAFF flag will add more complexity in the
      script to generate the syscall table file.
      
      In order to come up with a common implementation across all archit-
      ecture, we need to remove mipsmt_sys_sched_setaffinity and mipsmt-
      _sys_sched_getaffinity from the table and define it in other way.
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      6a00cb61
    • F
      mips: add +1 to __NR_syscalls in uapi header · be856439
      Firoz Khan 提交于
      All other architectures are hold a value for __NR_syscalls will
      be equal to the last system call number +1.
      
      But in mips architecture, __NR_syscalls hold the value equal to
      total number of system exits in the architecture. One of the
      patch in this patch series will genarate uapi header files.
      
      In order to make the implementation common across all architect-
      ures, add +1 to __NR_syscalls, which will be equal to the last
      system call number +1.
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      be856439
    • F
      mips: rename scall64-64.S to scall64-n64.S · 6d92c268
      Firoz Khan 提交于
      When we get nanoMIPS support we'll be introducing the p32
      ABI, and there's a reasonable chance that the equivalent
      p64 ABI may come along in the future. Using 'n64' now would
      avoid confusion in that case where we may have 2 different
      64-bit ABIs.
      Suggested-by: NPaul Burton <paul.burton@mips.com>
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      [paul.burton@mips.com:
        - Remove UAPI macro renaming, github code search shows at least the
          chromium project uses __NR_64_Linux & __NR_64_Linux_syscalls.]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      6d92c268
    • F
      mips: remove unused macros · a5ee2be9
      Firoz Khan 提交于
      Remove __NR_Linux_syscalls from uapi/asm/unistd.h as
      there is no users to use NR_syscalls macro in mips
      kernel.
      
      MAX_SYSCALL_NO can also remove as there is commit
      2957c9e6 ("[MIPS] IRIX: Goodbye and thanks for
      all the fish"), eight years ago.
      Signed-off-by: NFiroz Khan <firoz.khan@linaro.org>
      [paul.burton@mips.com:
       - Drop the removal of NR_syscalls which is used by
         kernel/trace/trace.h.]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: y2038@lists.linaro.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: arnd@arndb.de
      Cc: deepa.kernel@gmail.com
      Cc: marcin.juszkiewicz@linaro.org
      a5ee2be9
  17. 14 12月, 2018 1 次提交
    • P
      kvm: introduce manual dirty log reprotect · 2a31b9db
      Paolo Bonzini 提交于
      There are two problems with KVM_GET_DIRTY_LOG.  First, and less important,
      it can take kvm->mmu_lock for an extended period of time.  Second, its user
      can actually see many false positives in some cases.  The latter is due
      to a benign race like this:
      
        1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
           them.
        2. The guest modifies the pages, causing them to be marked ditry.
        3. Userspace actually copies the pages.
        4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
           they were not written to since (3).
      
      This is especially a problem for large guests, where the time between
      (1) and (3) can be substantial.  This patch introduces a new
      capability which, when enabled, makes KVM_GET_DIRTY_LOG not
      write-protect the pages it returns.  Instead, userspace has to
      explicitly clear the dirty log bits just before using the content
      of the page.  The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
      64-page granularity rather than requiring to sync a full memslot;
      this way, the mmu_lock is taken for small amounts of time, and
      only a small amount of time will pass between write protection
      of pages and the sending of their content.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2a31b9db