1. 24 3月, 2015 1 次提交
  2. 25 11月, 2014 1 次提交
    • G
      of/reconfig: Always use the same structure for notifiers · f5242e5a
      Grant Likely 提交于
      The OF_RECONFIG notifier callback uses a different structure depending
      on whether it is a node change or a property change. This is silly, and
      not very safe. Rework the code to use the same data structure regardless
      of the type of notifier.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
      Cc: <linuxppc-dev@lists.ozlabs.org>
      f5242e5a
  3. 10 11月, 2014 1 次提交
  4. 03 11月, 2014 1 次提交
    • A
      powerpc: Convert power off logic to pm_power_off · 9178ba29
      Alexander Graf 提交于
      The generic Linux framework to power off the machine is a function pointer
      called pm_power_off. The trick about this pointer is that device drivers can
      potentially implement it rather than board files.
      
      Today on powerpc we set pm_power_off to invoke our generic full machine power
      off logic which then calls ppc_md.power_off to invoke machine specific power
      off.
      
      However, when we want to add a power off GPIO via the "gpio-poweroff" driver,
      this card house falls apart. That driver only registers itself if pm_power_off
      is NULL to ensure it doesn't override board specific logic. However, since we
      always set pm_power_off to the generic power off logic (which will just not
      power off the machine if no ppc_md.power_off call is implemented), we can't
      implement power off via the generic GPIO power off driver.
      
      To fix this up, let's get rid of the ppc_md.power_off logic and just always use
      pm_power_off as was intended. Then individual drivers such as the GPIO power off
      driver can implement power off logic via that function pointer.
      
      With this patch set applied and a few patches on top of QEMU that implement a
      power off GPIO on the virt e500 machine, I can successfully turn off my virtual
      machine after halt.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      [mpe: Squash into one patch and update changelog based on cover letter]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9178ba29
  5. 25 9月, 2014 1 次提交
  6. 28 7月, 2014 1 次提交
    • M
      powerpc/pseries: Switch pseries drivers to use machine_xxx_initcall() · 8e83e905
      Michael Ellerman 提交于
      A lot of the code in platforms/pseries is using non-machine initcalls.
      That means if a kernel built with pseries support runs on another
      platform, for example powernv, the initcalls will still run.
      
      Most of these cases are OK, though sometimes only due to luck. Some were
      having more effect:
      
       * hcall_inst_init
        - Checking FW_FEATURE_LPAR which is set on ps3 & celleb.
       * mobility_sysfs_init
        - created sysfs files unconditionally
        - but no effect due to ENOSYS from rtas_ibm_suspend_me()
       * apo_pm_init
        - created sysfs, allows write
        - nothing checks the value written to though
       * alloc_dispatch_log_kmem_cache
        - creating kmem_cache on non-pseries machines
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8e83e905
  7. 27 6月, 2014 1 次提交
    • G
      of: Migrate of_find_node_by_name() users to for_each_node_by_name() · ccdb8ed3
      Grant Likely 提交于
      There are a bunch of users open coding the for_each_node_by_name() by
      calling of_find_node_by_name() directly instead of using the macro. This
      is getting in the way of some cleanups, and the possibility of removing
      of_find_node_by_name() entirely. Clean it up so that all the users are
      consistent.
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Takashi Iwai <tiwai@suse.de>
      ccdb8ed3
  8. 05 6月, 2014 1 次提交
  9. 01 5月, 2014 1 次提交
  10. 30 4月, 2014 1 次提交
  11. 11 2月, 2014 2 次提交
  12. 30 12月, 2013 1 次提交
  13. 26 11月, 2013 1 次提交
  14. 21 11月, 2013 1 次提交
  15. 11 9月, 2013 1 次提交
  16. 27 8月, 2013 1 次提交
  17. 14 8月, 2013 2 次提交
  18. 06 5月, 2013 1 次提交
  19. 26 4月, 2013 1 次提交
  20. 28 1月, 2013 1 次提交
    • F
      cputime: Generic on-demand virtual cputime accounting · abf917cd
      Frederic Weisbecker 提交于
      If we want to stop the tick further idle, we need to be
      able to account the cputime without using the tick.
      
      Virtual based cputime accounting solves that problem by
      hooking into kernel/user boundaries.
      
      However implementing CONFIG_VIRT_CPU_ACCOUNTING require
      low level hooks and involves more overhead. But we already
      have a generic context tracking subsystem that is required
      for RCU needs by archs which plan to shut down the tick
      outside idle.
      
      This patch implements a generic virtual based cputime
      accounting that relies on these generic kernel/user hooks.
      
      There are some upsides of doing this:
      
      - This requires no arch code to implement CONFIG_VIRT_CPU_ACCOUNTING
      if context tracking is already built (already necessary for RCU in full
      tickless mode).
      
      - We can rely on the generic context tracking subsystem to dynamically
      (de)activate the hooks, so that we can switch anytime between virtual
      and tick based accounting. This way we don't have the overhead
      of the virtual accounting when the tick is running periodically.
      
      And one downside:
      
      - There is probably more overhead than a native virtual based cputime
      accounting. But this relies on hooks that are already set anyway.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      abf917cd
  21. 10 1月, 2013 2 次提交
    • M
      powerpc: Add the DAWR support to the set_break() · bf99de36
      Michael Neuling 提交于
      This adds DAWR supoprt to the set_break().
      
      It does both bare metal and PAPR versions of setting the DAWR.
      
      There is still some work we can do to make full use of the watchpoint but that
      will come later.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      bf99de36
    • I
      powerpc: Disable relocation on exceptions whenever PR KVM is active · a413f474
      Ian Munsie 提交于
      For PR KVM we allow userspace to map 0xc000000000000000. Because
      transitioning from userspace to the guest kernel may use the relocated
      exception vectors we have to disable relocation on exceptions whenever
      PR KVM is active as we cannot trust that address.
      
      This issue does not apply to HV KVM, since changing from a guest to the
      hypervisor will never use the relocated exception vectors.
      
      Currently the hypervisor interface only allows us to toggle relocation
      on exceptions on a partition wide scope, so we need to globally disable
      relocation on exceptions when the first PR KVM instance is started and
      only re-enable them when all PR KVM instances have been destroyed.
      
      It's a bit heavy handed, but until the hypervisor gives us a lightweight
      way to toggle relocation on exceptions on a single thread it's only real
      option.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a413f474
  22. 15 11月, 2012 3 次提交
  23. 10 9月, 2012 3 次提交
  24. 07 9月, 2012 1 次提交
  25. 09 3月, 2012 2 次提交
    • G
      powerpc/eeh: Introduce EEH device · eb740b5f
      Gavin Shan 提交于
      Original EEH implementation depends on struct pci_dn heavily. However,
      EEH shouldn't depend on that actually because EEH needn't share much
      information with other PCI components. That's to say, EEH should have
      worked independently.
      
      The patch introduces struct eeh_dev so that EEH core components needn't
      be working based on struct pci_dn in future. Also, struct pci_dn, struct
      eeh_dev instances are created in dynamic fasion and the binding with EEH
      device, OF node, PCI device is implemented as well.
      
      The EEH devices are created after PHBs are detected and initialized, but
      PCI emunation hasn't started yet. Apart from that, PHB might be created
      dynamically through DLPAR component and the EEH devices should be creatd
      as well. Another case might be OF node is created dynamically by DR
      (Dynamic Reconfiguration), which has been defined by PAPR. For those OF
      nodes created by DR, EEH devices should be also created accordingly. The
      binding between EEH device and OF node is done while the EEH device is
      initially created.
      
      The binding between EEH device and PCI device should be done after PCI
      emunation is done. Besides, PCI hotplug also needs the binding so that
      the EEH devices could be traced from the newly coming PCI buses or PCI
      devices.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      eb740b5f
    • G
      powerpc/eeh: Platform dependent EEH operations · aa1e6374
      Gavin Shan 提交于
      EEH has been implemented on RTAS-compliant pSeries platform.
      That's to say, the EEH operations will be implemented through RTAS
      calls eventually. The situation limited feasible extension on EEH.
      In order to support EEH on multiple platforms like pseries and powernv
      simutaneously. We have to split the platform dependent EEH options
      up out of current implementation.
      
      The patch addresses supporting EEH on multiple platforms. The pseries
      platform dependent EEH operations will be abstracted by struct eeh_ops.
      EEH core components will be built based on the registered EEH operations.
      With the mechanism, what the individual platform needs to do is implement
      platform dependent EEH operations.
      
      For now, the pseries platform is covered under the mechanism. That means
      we have to think about other platforms to support EEH, like powernv.
      Besides, we only have framework for the mechanism and we have to implement
      it for pseries platform later.
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      aa1e6374
  26. 24 2月, 2012 2 次提交
  27. 23 2月, 2012 2 次提交
    • K
      powerpc/mpic: Remove duplicate MPIC_WANTS_RESET flag · e55d7f73
      Kyle Moffett 提交于
      There are two separate flags controlling whether or not the MPIC is
      reset during initialization, which is completely unnecessary, and only
      one of them can be specified in the device tree.
      
      Also, most platforms in-tree right now do actually want to reset the
      MPIC during initialization anyways, which means lots of duplicate code
      passing the MPIC_WANTS_RESET flag.
      
      Fix all of the callers which currently do not pass the MPIC_WANTS_RESET
      flag to pass the MPIC_NO_RESET flag, then remove the MPIC_WANTS_RESET
      flag and make the code reset the MPIC by default.
      Signed-off-by: NKyle Moffett <Kyle.D.Moffett@boeing.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e55d7f73
    • K
      powerpc/mpic: Remove MPIC_BROKEN_FRR_NIRQS and duplicate irq_count · 5019609f
      Kyle Moffett 提交于
      The mpic->irq_count variable is only used as a software error-checking
      limit to determine whether or not an IRQ number is valid.  In board code
      which does not manually specify an IRQ count to mpic_alloc(), i.e. 0, it
      is automatically detected from the number of ISUs and the ISU size.
      
      In practice, all hardware ends up with irq_count == num_sources, so all
      of the runtime checks on mpic->irq_count should just check the value of
      mpic->num_sources instead.
      
      When platform hardware does not correctly report the number of IRQs,
      which only happens on the MPC85xx/MPC86xx, the MPIC_BROKEN_FRR_NIRQS
      flag is used to override the detected value of num_sources with the
      manual irq_count parameter.  Since there's no need to manually specify
      the number of IRQs except in this case, the extra flag can be eliminated
      and the test changed to "irq_count != 0".
      Signed-off-by: NKyle Moffett <Kyle.D.Moffett@boeing.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5019609f
  28. 08 12月, 2011 3 次提交