1. 26 6月, 2015 1 次提交
  2. 25 6月, 2015 8 次提交
  3. 24 6月, 2015 1 次提交
  4. 19 6月, 2015 4 次提交
  5. 18 6月, 2015 4 次提交
  6. 17 6月, 2015 5 次提交
    • S
      powerpc: Make doorbell check preemption safe · 3609d819
      Shreyas B. Prabhu 提交于
      Doorbell can be used to cause ipi on cpus which are sibling threads on
      the same core. So icp_native_cause_ipi checks if the destination cpu
      is a sibling thread of the current cpu and uses doorbell in such cases.
      
      But while running with CONFIG_PREEMPT=y, since this section is
      preemtible, we can run into issues if after we check if the destination
      cpu is a sibling cpu, the task gets migrated from a sibling cpu to a
      cpu on another core.
      
      Fix this by using get_cpu()/ put_cpu()
      Signed-off-by: NShreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3609d819
    • P
      powerpc: don't use module_init for non-modular core hugetlb code · 6f114281
      Paul Gortmaker 提交于
      The hugetlbpage.o is obj-y (always built in).  It will never
      be modular, so using module_init as an alias for __initcall is
      somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of arch_initcall (which
      makes sense for arch code) will thus change this registration
      from level 6-device to level 3-arch (i.e. slightly earlier).
      However no observable impact of that small difference has
      been observed during testing, or is expected.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      6f114281
    • P
      powerpc: use subsys_initcall for Freescale Local Bus · 383d14a5
      Paul Gortmaker 提交于
      The FSL_SOC option is bool, and hence this code is either
      present or absent.  It will never be modular, so using
      module_init as an alias for __initcall is rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of subsys_initcall (which
      makes sense for bus code) will thus change this registration
      from level 6-device to level 4-subsys (i.e. slightly earlier).
      However no observable impact of that small difference has
      been observed during testing, or is expected.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Scott Wood <scottwood@freescale.com>
      Acked-by: NScott Wood <scottwood@freescale.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      383d14a5
    • P
      powerpc: don't use module_init in non-modular 83xx suspend code · a390a2f1
      Paul Gortmaker 提交于
      The suspend.o is built for SUSPEND -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      a390a2f1
    • P
      powerpc: use device_initcall for registering rtc devices · 8f6b9512
      Paul Gortmaker 提交于
      Currently these two RTC devices are in core platform code
      where it is not possible for them to be modular.  It will
      never be modular, so using module_init as an alias for
      __initcall can be somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- they will remain at level 6 in initcall ordering.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Geoff Levand <geoff@infradead.org>
      Acked-by: NGeoff Levand <geoff@infradead.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8f6b9512
  7. 15 6月, 2015 1 次提交
  8. 11 6月, 2015 16 次提交