1. 30 8月, 2017 1 次提交
  2. 29 8月, 2017 1 次提交
    • M
      MIPS: SMP: Constify smp ops · ff2c8252
      Matt Redfearn 提交于
      smp_ops providers do not modify their ops structures, so they should be
      made const for robustness. Since currently the MIPS kernel is not mapped
      with memory protection, this does not in itself provide any security
      benefit, but it still makes sense to make this change.
      
      There are also slight code size efficincies from the structure being
      made read-only, saving 128 bytes of kernel text on a
      pistachio_defconfig.
      Before:
         text	   data	    bss	    dec	    hex	filename
      7187239	1772752	 470224	9430215	 8fe4c7	vmlinux
      After:
         text	   data	    bss	    dec	    hex	filename
      7187111	1772752	 470224	9430087	 8fe447	vmlinux
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Bart Van Assche <bart.vanassche@sandisk.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Steven J. Hill <steven.hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16784/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ff2c8252
  3. 08 3月, 2017 1 次提交
  4. 02 3月, 2017 1 次提交
  5. 14 2月, 2017 1 次提交
    • P
      MIPS: Audit and remove any unnecessary uses of module.h · 26dd3e4f
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  In the case of
      some code where it is modular, we can extend that to also include
      files that are building basic support functionality but not related
      to loading or registering the final module; such files also have
      no need whatsoever for module.h
      
      The advantage in removing such instances is that module.h itself
      sources about 15 other headers; adding significantly to what we feed
      cpp, and it can obscure what headers we are effectively using.
      
      Since module.h might have been the implicit source for init.h
      (for __init) and for export.h (for EXPORT_SYMBOL) we consider each
      instance for the presence of either and replace/add as needed.
      
      Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
      
      Build coverage of all the mips defconfigs revealed the module.h
      header was masking a couple of implicit include instances, so
      we add the appropriate headers there.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "Steven J. Hill" <steven.hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15131/
      [james.hogan@imgtec.com: Preserve sort order where it already exists]
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      26dd3e4f
  6. 03 1月, 2017 2 次提交
    • M
      MIPS: SMP: Remove cpu_callin_map · 5892d6a6
      Matt Redfearn 提交于
      The previous commit made cpu_callin_map redundant, since it is no longer
      used to signal secondary CPUs starting, or going offline. Remove it now.
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Qais Yousef <qsyousef@gmail.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Yang Shi <yang.shi@windriver.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14503/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5892d6a6
    • S
      MIPS: Octeon: Enable KASLR · 3ff72be4
      Steven J. Hill 提交于
      This patch enables KASLR for Octeon systems. The SMP startup code is
      such that the secondaries monitor the volatile variable
      'octeon_processor_relocated_kernel_entry' for any non-zero value.
      The 'plat_post_relocation hook' is used to set that value to the
      kernel entry point of the relocated kernel. The secondary CPUs will
      then jusmp to the new kernel, perform their initialization again
      and begin waiting for the boot CPU to start them via the relocated
      loop 'octeon_spin_wait_boot'. Inspired by Steven's code from Cavium.
      Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Signed-off-by: NSteven J. Hill <steven.hill@cavium.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14669/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3ff72be4
  7. 20 9月, 2016 1 次提交
  8. 29 7月, 2016 1 次提交
    • J
      MIPS: SMP: Update cpu_foreign_map on CPU disable · 826e99be
      James Hogan 提交于
      When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated.
      This could result in cache management SMP calls being sent to offline
      CPUs instead of online siblings in the same core.
      
      Add a call to calculate_cpu_foreign_map() in the various MIPS cpu
      disable callbacks after set_cpu_online(). All cases are updated for
      consistency and to keep cpu_foreign_map strictly up to date, not just
      those which may support hardware multithreading.
      
      Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Hongliang Tao <taohl@lemote.com>
      Cc: Hua Yan <yanh@lemote.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13799/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      826e99be
  9. 28 5月, 2016 1 次提交
  10. 13 5月, 2016 4 次提交
  11. 03 4月, 2016 1 次提交
  12. 03 8月, 2015 1 次提交
    • A
      MIPS: SMP: Don't increment irq_count multiple times for call function IPIs · 4ace6139
      Alex Smith 提交于
      The majority of SMP platforms handle their IPIs through do_IRQ()
      which calls irq_{enter/exit}(). When a call function IPI is received,
      smp_call_function_interrupt() is called which also calls
      irq_{enter,exit}(), meaning irq_count is raised twice.
      
      When tick broadcasting is used (which is implemented via a call
      function IPI), this incorrectly causes all CPU idle time on the core
      receiving broadcast ticks to be accounted as time spent servicing
      IRQs, as account_process_tick() will account as such if irq_count is
      greater than 1. This results in 100% CPU usage being reported on a
      core which receives its ticks via broadcast.
      
      This patch removes the SMP smp_call_function_interrupt() wrapper which
      calls irq_{enter,exit}(). Platforms which handle their IPIs through
      do_IRQ() now call generic_smp_call_function_interrupt() directly to
      avoid incrementing irq_count a second time. Platforms which don't
      (loongson, sgi-ip27, sibyte) call generic_smp_call_function_interrupt()
      wrapped in irq_{enter,exit}().
      Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10770/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4ace6139
  13. 05 3月, 2015 1 次提交
  14. 30 1月, 2015 1 次提交
    • A
      MIPS: OCTEON: fix kernel crash when offlining a CPU · 63a87fe0
      Aaro Koskinen 提交于
      octeon_cpu_disable() will unconditionally enable interrupts when called.
      We can assume that the routine is always called with interrupts disabled,
      so just delete the incorrect local_irq_disable/enable().
      
      The patch fixes the following crash when offlining a CPU:
      
      [   93.818785] ------------[ cut here ]------------
      [   93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 flush_smp_call_function_queue+0x1c4/0x1d0()
      [   93.836215] Modules linked in:
      [   93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.19.0-rc4-octeon-los_b5f0 #1
      [   93.847212] Stack : 0000000000000001 ffffffff81b2cf90 0000000000000004 ffffffff81630000
      	  0000000000000000 0000000000000000 0000000000000000 000000000000004a
      	  0000000000000006 ffffffff8117e550 0000000000000000 0000000000000000
      	  ffffffff81b30000 ffffffff81b26808 8000000032c77748 ffffffff81627e07
      	  ffffffff81595ec8 ffffffff81b26808 000000000000000a 0000000000000001
      	  0000000000000001 0000000000000003 0000000010008ce1 ffffffff815030c8
      	  8000000032cbbb38 ffffffff8113d42c 0000000010008ce1 ffffffff8117f36c
      	  8000000032c77300 8000000032cbba50 0000000000000001 ffffffff81503984
      	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      	  0000000000000000 ffffffff81121668 0000000000000000 0000000000000000
      	  ...
      [   93.912819] Call Trace:
      [   93.915273] [<ffffffff81121668>] show_stack+0x68/0x80
      [   93.920335] [<ffffffff81503984>] dump_stack+0x6c/0x90
      [   93.925395] [<ffffffff8113d58c>] warn_slowpath_common+0x94/0xd8
      [   93.931324] [<ffffffff811a402c>] flush_smp_call_function_queue+0x1c4/0x1d0
      [   93.938208] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108
      [   93.943444] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8
      [   93.949286] [<ffffffff8113d704>] cpu_notify+0x24/0x60
      [   93.954348] [<ffffffff81501738>] take_cpu_down+0x38/0x58
      [   93.959670] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180
      [   93.965250] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160
      [   93.971093] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8
      [   93.976936] [<ffffffff8115ab04>] kthread+0xd4/0xf0
      [   93.981735] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c
      [   93.987835]
      [   93.989326] ---[ end trace c9e3815ee655bda9 ]---
      [   93.993951] Kernel bug detected[#1]:
      [   93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: G        W      3.19.0-rc4-octeon-los_b5f0 #1
      [   94.006591] task: 8000000032c77300 ti: 8000000032cb8000 task.ti: 8000000032cb8000
      [   94.014081] $ 0   : 0000000000000000 0000000010000ce1 0000000000000001 ffffffff81620000
      [   94.022146] $ 4   : 8000000002c72ac0 0000000000000000 00000000000001a7 ffffffff813b06f0
      [   94.030210] $ 8   : ffffffff813b20d8 0000000000000000 0000000000000000 ffffffff81630000
      [   94.038275] $12   : 0000000000000087 0000000000000000 0000000000000086 0000000000000000
      [   94.046339] $16   : ffffffff81623168 0000000000000001 0000000000000000 0000000000000008
      [   94.054405] $20   : 0000000000000001 0000000000000001 0000000000000001 0000000000000003
      [   94.062470] $24   : 0000000000000038 ffffffff813b7f10
      [   94.070536] $28   : 8000000032cb8000 8000000032cbbc20 0000000010008ce1 ffffffff811bcaf4
      [   94.078601] Hi    : 0000000000f188e8
      [   94.082179] Lo    : d4fdf3b646c09d55
      [   94.085760] epc   : ffffffff811bc9d0 irq_work_run_list+0x8/0xf8
      [   94.091686]     Tainted: G        W
      [   94.095613] ra    : ffffffff811bcaf4 irq_work_run+0x34/0x60
      [   94.101192] Status: 10000ce3	KX SX UX KERNEL EXL IE
      [   94.106235] Cause : 40808034
      [   94.109119] PrId  : 000d9301 (Cavium Octeon II)
      [   94.113653] Modules linked in:
      [   94.116721] Process migration/1 (pid: 10, threadinfo=8000000032cb8000, task=8000000032c77300, tls=0000000000000000)
      [   94.127168] Stack : 8000000002c74c80 ffffffff811a4128 0000000000000001 ffffffff81635720
      	  fffffffffffffff2 ffffffff8115bacc 80000000320fbce0 80000000320fbca4
      	  80000000320fbc80 0000000000000002 0000000000000004 ffffffff8113d704
      	  80000000320fbce0 ffffffff81501738 0000000000000003 ffffffff811b343c
      	  8000000002c72aa0 8000000002c72aa8 ffffffff8159cae8 ffffffff8159caa0
      	  ffffffff81650000 80000000320fbbf0 80000000320fbc80 ffffffff811b32e8
      	  0000000000000000 ffffffff811b3768 ffffffff81622b80 ffffffff815148a8
      	  8000000032c77300 8000000002c73e80 ffffffff815148a8 8000000032c77300
      	  ffffffff81622b80 ffffffff815148a8 8000000032c77300 ffffffff81503f48
      	  ffffffff8115ea0c ffffffff81620000 0000000000000000 ffffffff81174d64
      	  ...
      [   94.192771] Call Trace:
      [   94.195222] [<ffffffff811bc9d0>] irq_work_run_list+0x8/0xf8
      [   94.200802] [<ffffffff811bcaf4>] irq_work_run+0x34/0x60
      [   94.206036] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108
      [   94.211269] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8
      [   94.217111] [<ffffffff8113d704>] cpu_notify+0x24/0x60
      [   94.222171] [<ffffffff81501738>] take_cpu_down+0x38/0x58
      [   94.227491] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180
      [   94.233072] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160
      [   94.238914] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8
      [   94.244757] [<ffffffff8115ab04>] kthread+0xd4/0xf0
      [   94.249555] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c
      [   94.255654]
      [   94.257146]
      Code: a2423c40  40026000  30420001 <00020336> dc820000  10400037  00000000  0000010f  0000010f
      [   94.267183] ---[ end trace c9e3815ee655bdaa ]---
      [   94.271804] Fatal exception: panic in 5 seconds
      Reported-by: NHemmo Nieminen <hemmo.nieminen@iki.fi>
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: stable@vger.kernel.org # v3.18+
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/8952/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      63a87fe0
  15. 02 8月, 2014 3 次提交
  16. 27 5月, 2014 1 次提交
  17. 23 5月, 2014 1 次提交
  18. 25 1月, 2014 1 次提交
  19. 04 9月, 2013 1 次提交
  20. 15 7月, 2013 1 次提交
    • P
      MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code · 078a55fc
      Paul Gortmaker 提交于
      commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.
      
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
      from asm files.  MIPS is interesting in this respect, because there
      are also uasm users hiding behind their own renamed versions of the
      __cpuinit macros.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [ralf@linux-mips.org: Folded in Paul's followup fix.]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5494/
      Patchwork: https://patchwork.linux-mips.org/patch/5495/
      Patchwork: https://patchwork.linux-mips.org/patch/5509/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      078a55fc
  21. 01 2月, 2013 1 次提交
  22. 19 7月, 2012 1 次提交
  23. 18 5月, 2012 1 次提交
  24. 29 3月, 2012 3 次提交
  25. 08 12月, 2011 1 次提交
  26. 08 11月, 2011 1 次提交
  27. 19 5月, 2011 1 次提交
  28. 14 4月, 2011 1 次提交
  29. 29 3月, 2011 1 次提交
    • D
      MIPS: Octeon: Rewrite interrupt handling code. · 0c326387
      David Daney 提交于
      This includes conversion to new style irq_chip functions, and
      correctly enabling/disabling per-CPU interrupts.
      
      The hardware interrupt bit to irq number mapping is now done with a
      flexible map, instead of by bit twiddling the irq number.
      
      [ tglx: Adjusted to new irq_cpu_on/offline callbacks and
              __irq_set_affinity_lock ]
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Cc: ralf@linux-mips.org
      LKML-Reference: <1301081931-11240-5-git-send-email-ddaney@caviumnetworks.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      0c326387
  30. 05 8月, 2010 3 次提交