1. 23 5月, 2011 4 次提交
  2. 21 5月, 2011 3 次提交
  3. 20 5月, 2011 4 次提交
  4. 19 5月, 2011 25 次提交
  5. 18 5月, 2011 4 次提交
    • J
      irq: Export functions to allow modular irq drivers · edf76f83
      Jonathan Cameron 提交于
      Export handle_simple_irq, irq_modify_status, irq_alloc_descs,
      irq_free_descs and generic_handle_irq to allow their usage in
      modules. First user is IIO, which wants to be built modular, but needs
      to be able to create irq chips, allocate and configure interrupt
      descriptors and handle demultiplexing interrupts.
      
      [ tglx: Moved the uninlinig of generic_handle_irq to a separate patch ]
      Signed-off-by: NJonathan Cameron <jic23@cam.ac.uk>
      Link: http://lkml.kernel.org/r/%3C1305711544-505-1-git-send-email-jic23%40cam.ac.uk%3ESigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      edf76f83
    • T
      genirq: Uninline and sanity check generic_handle_irq() · fe12bc2c
      Thomas Gleixner 提交于
      generic_handle_irq() is missing a NULL pointer check for the result of
      irq_to_desc. This was a not a big problem, but we want to expose it to
      drivers, so we better have sanity checks in place. Add a return value
      as well, which indicates that the irq number was valid and the handler
      was invoked.
      
      Based on the pure code move from Jonathan Cameron.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      fe12bc2c
    • T
      genirq: Remove pointless ifdefs · fe051434
      Thomas Gleixner 提交于
      kernel/irq/ is only built when CONFIG_GENERIC_HARDIRQS=y. So making
      code inside of kernel/irq/ conditional on CONFIG_GENERIC_HARDIRQS is
      pointless.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      fe051434
    • R
      PM: Allow drivers to allocate memory from .prepare() callbacks safely · 91e7c75b
      Rafael J. Wysocki 提交于
      If device drivers allocate substantial amounts of memory (above 1 MB)
      in their hibernate .freeze() callbacks (or in their legacy suspend
      callbcks during hibernation), the subsequent creation of hibernate
      image may fail due to the lack of memory.  This is the case, because
      the drivers' .freeze() callbacks are executed after the hibernate
      memory preallocation has been carried out and the preallocated amount
      of memory may be too small to cover the new driver allocations.
      Unfortunately, the drivers' .prepare() callbacks also are executed
      after the hibernate memory preallocation has completed, so they are
      not suitable for allocating additional memory either.  Thus the only
      way a driver can safely allocate memory during hibernation is to use
      a hibernate/suspend notifier.  However, the notifiers are called
      before the freezing of user space and the drivers wanting to use them
      for allocating additional memory may not know how much memory needs
      to be allocated at that point.
      
      To let device drivers overcome this difficulty rework the hibernation
      sequence so that the memory preallocation is carried out after the
      drivers' .prepare() callbacks have been executed, so that the
      .prepare() callbacks can be used for allocating additional memory
      to be used by the drivers' .freeze() callbacks.  Update documentation
      to match the new behavior of the code.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      91e7c75b