1. 28 4月, 2011 1 次提交
    • S
      x86: devicetree: Configure IOAPIC pin only once · 20443598
      Sebastian Andrzej Siewior 提交于
      We use io_apic_setup_irq_pin() in order to configure pin's interrupt
      number polarity and type. This is done on every irq_create_of_mapping()
      which happens for instance during pci enable calls. Level typed
      interrupts are masked by default, edge are unmasked.
      
      On the first ->xlate() call the level interrupt is configured and
      masked. The driver calls request_irq() and the line is unmasked. Lets
      assume the interrupt line is shared with another device and we call
      pci_enable_device() for this device. The ->xlate() configures the pin
      again and it is masked. request_irq() does not unmask the line because
      it _is_ already unmasked according to its internal state. So the
      interrupt will never be unmasked again.
      
      This patch is based on an earlier work by Torben Hohn and solves the
      problem by configuring the pin only once. Since all devices must agree
      on the same type and polarity there is no point in configuring the pin
      more than once.
      
      [ tglx: Split out the ce4100 part into a separate patch ]
      
      Cc: Torben Hohn <torbenh@linutronix.de>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Link: http://lkml.kernel.org/r/%3C20110427143052.GA15211%40linutronix.de%3ESigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      20443598
  2. 24 3月, 2011 1 次提交
    • R
      x86: Use syscore_ops instead of sysdev classes and sysdevs · f3c6ea1b
      Rafael J. Wysocki 提交于
      Some subsystems in the x86 tree need to carry out suspend/resume and
      shutdown operations with one CPU on-line and interrupts disabled and
      they define sysdev classes and sysdevs or sysdev drivers for this
      purpose.  This leads to unnecessarily complicated code and excessive
      memory usage, so switch them to using struct syscore_ops objects for
      this purpose instead.
      
      Generally, there are three categories of subsystems that use
      sysdevs for implementing PM operations: (1) subsystems whose
      suspend/resume callbacks ignore their arguments entirely (the
      majority), (2) subsystems whose suspend/resume callbacks use their
      struct sys_device argument, but don't really need to do that,
      because they can be implemented differently in an arguably simpler
      way (io_apic.c), and (3) subsystems whose suspend/resume callbacks
      use their struct sys_device argument, but the value of that argument
      is always the same and could be ignored (microcode_core.c).  In all
      of these cases the subsystems in question may be readily converted to
      using struct syscore_ops objects for power management and shutdown.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      f3c6ea1b
  3. 18 3月, 2011 1 次提交
  4. 12 3月, 2011 5 次提交
  5. 24 2月, 2011 11 次提交
  6. 23 2月, 2011 1 次提交
    • H
      x86: Rework arch_disable_smp_support() for x86 · 7167d08e
      Henrik Kretzschmar 提交于
      Currently arch_disable_smp_support() on x86 disables only the
      support for the IOAPIC and is also compiled in if SMP-support is
      not.
      
      Therefore this function is renamed to disable_ioapic_support(),
      which meets its purpose and is only compiled in the kernel
      when IOAPIC support is also.
      
      A new arch_disable_smp_support() is created in smpboot.c,
      which calls disable_ioapic_support() and gets only compiled
      in the kernel when SMP support is also.
      Signed-off-by: NHenrik Kretzschmar <henne@nachtwindheim.de>
      LKML-Reference: <1298385487-4708-3-git-send-email-henne@nachtwindheim.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7167d08e
  7. 15 2月, 2011 1 次提交
    • P
      x86, ioapic: Don't warn about non-existing IOAPICs if we have none · 678301ec
      Paul Bolle 提交于
      mp_find_ioapic() prints errors like:
      
          ERROR: Unable to locate IOAPIC for GSI 13
      
      if it can't find the IOAPIC that manages that specific GSI. I
      see errors like that at every boot of a laptop that apparently
      doesn't have any IOAPICs.
      
      But if there are no IOAPICs it doesn't seem to be an error that
      none can be found. A solution that gets rid of this message is
      to directly return if nr_ioapics (still) is zero. (But keep
      returning -1 in that case, so nothing breaks from this change.)
      
      The call chain that generates this error is:
      
      pnpacpi_allocated_resource()
          case ACPI_RESOURCE_TYPE_IRQ:
              pnpacpi_parse_allocated_irqresource()
                  acpi_get_override_irq()
                       mp_find_ioapic()
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      678301ec
  8. 11 2月, 2011 1 次提交
  9. 05 1月, 2011 1 次提交
    • Y
      x86: Fix APIC ID sizing bug on larger systems, clean up MAX_APICS confusion · cb2ded37
      Yinghai Lu 提交于
      Found one x2apic pre-enabled system, x2apic_mode suddenly get
      corrupted after register some cpus, when compiled
      CONFIG_NR_CPUS=255 instead of 512.
      
      It turns out that generic_processor_info() ==> phyid_set(apicid,
      phys_cpu_present_map) causes the problem.
      
      phys_cpu_present_map is sized by MAX_APICS bits, and pre-enabled
      system some cpus have an apic id > 255.
      
      The variable after phys_cpu_present_map may get corrupted
      silently:
      
       ffffffff828e8420 B phys_cpu_present_map
       ffffffff828e8440 B apic_verbosity
       ffffffff828e8444 B local_apic_timer_c2_ok
       ffffffff828e8448 B disable_apic
       ffffffff828e844c B x2apic_mode
       ffffffff828e8450 B x2apic_disabled
       ffffffff828e8454 B num_processors
       ...
      
      Actually phys_cpu_present_map is referenced via apic id, instead
      index. We should use MAX_LOCAL_APIC instead MAX_APICS.
      
      For 64-bit it will be 32768 in all cases. BSS will increase by 4k bytes
      on 64-bit:
      
      	text		data		bss		dec		filename
      	21696943	4193748		12787712	38678403	vmlinux.before
      	21696943	4193748		12791808	38682499	vmlinux.after
      
      No change on 32bit.
      
      Finally we can remove MAX_APCIS that was rather confusing.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      LKML-Reference: <4D23BD9C.3070102@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cb2ded37
  10. 30 12月, 2010 1 次提交
  11. 14 12月, 2010 1 次提交
  12. 10 12月, 2010 4 次提交
  13. 06 12月, 2010 1 次提交
  14. 18 11月, 2010 1 次提交
    • D
      x86, nmi_watchdog: Remove all stub function calls from old nmi_watchdog · 072b198a
      Don Zickus 提交于
      Now that the bulk of the old nmi_watchdog is gone, remove all
      the stub variables and hooks associated with it.
      
      This touches lots of files mainly because of how the io_apic
      nmi_watchdog was implemented.  Now that the io_apic nmi_watchdog
      is forever gone, remove all its fingers.
      
      Most of this code was not being exercised by virtue of
      nmi_watchdog != NMI_IO_APIC, so there shouldn't be anything to
      risky here.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: fweisbec@gmail.com
      Cc: gorcunov@openvz.org
      LKML-Reference: <1289578944-28564-3-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      072b198a
  15. 30 10月, 2010 1 次提交
    • Y
      x86: Check irq_remapped instead of remapping_enabled in destroy_irq() · 7b79462a
      Yinghai Lu 提交于
      Russ Anderson reported:
      | There is a regression that is causing a NULL pointer dereference
      | in free_irte when shutting down xpc. git bisect narrowed it down
      | to git commit d585d060(intr_remap: Simplify the code further), which
      | changed free_irte(). Reverse applying the patch fixes the problem.
      
      We need to use irq_remapped() for each irq instead of checking only
      intr_remapping_enabled as there might be non remapped irqs even when
      remapping is enabled.
      
      [ tglx: use cfg instead of retrieving it again. Massaged changelog ]
      Reported-bisected-and-tested-by: NRuss Anderson <rja@sgi.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      LKML-Reference: <4CCBD511.40607@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7b79462a
  16. 23 10月, 2010 1 次提交
  17. 19 10月, 2010 1 次提交
    • Y
      x86: ioapic: Call free_irte only if interrupt remapping enabled · 9717967c
      Yinghai Lu 提交于
      On a system that support intr-rempping when booting with "intremap=off"
      
      [  177.895501] BUG: unable to handle kernel NULL pointer dereference at 00000000000000f8
      [  177.913316] IP: [<ffffffff8145fc18>] free_irte+0x47/0xc0
      ...
      [  178.173326] Call Trace:
      [  178.173574]  [<ffffffff810515b4>] destroy_irq+0x3a/0x75
      [  178.192934]  [<ffffffff81051834>] arch_teardown_msi_irq+0xe/0x10
      [  178.193418]  [<ffffffff81458dc3>] arch_teardown_msi_irqs+0x56/0x7f
      [  178.213021]  [<ffffffff81458e79>] free_msi_irqs+0x8d/0xeb
      
      Call free_irte only when interrupt remapping is enabled.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4CBCB274.7010108@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9717967c
  18. 18 10月, 2010 2 次提交
  19. 12 10月, 2010 4 次提交