1. 21 10月, 2008 2 次提交
  2. 21 8月, 2008 1 次提交
  3. 16 8月, 2008 1 次提交
  4. 29 7月, 2008 1 次提交
  5. 09 7月, 2008 1 次提交
    • R
      x86/pci: removing subsys_initcall ordering dependencies · 8dd779b1
      Robert Richter 提交于
      So far subsys_initcalls has been executed in this order depending on
      the object order in the Makefile:
      
      arch/x86/pci/visws.c:subsys_initcall(pcibios_init);
      arch/x86/pci/numa.c:subsys_initcall(pci_numa_init);
      arch/x86/pci/acpi.c:subsys_initcall(pci_acpi_init);
      arch/x86/pci/legacy.c:subsys_initcall(pci_legacy_init);
      arch/x86/pci/irq.c:subsys_initcall(pcibios_irq_init);
      arch/x86/pci/common.c:subsys_initcall(pcibios_init);
      
      This patch removes the ordering dependency. There is now only one
      subsys_initcall function that contains subsystem initialization code
      with a defined order.
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8dd779b1
  6. 11 6月, 2008 1 次提交
  7. 10 6月, 2008 1 次提交
  8. 06 6月, 2008 1 次提交
    • B
      x86/PCI: add workaround for bug in ASUS A7V600 BIOS (rev 1005) · 9f67fd5d
      Bertram Felgenhauer 提交于
      This BIOS claims the VIA 8237 south bridge to be compatible with VIA 586,
      which it is not.
      
      Without this patch, I get the following warning while booting,
      among others,
      
      | PCI: Using IRQ router VIA [1106/3227] at 0000:00:11.0
      | ------------[ cut here ]------------
      | WARNING: at arch/x86/pci/irq.c:265 pirq_via586_get+0x4a/0x60()
      | Modules linked in:
      | Pid: 1, comm: swapper Not tainted 2.6.26-rc4-00015-g1ec7d99c #1
      |  [<c0119fd4>] warn_on_slowpath+0x54/0x70
      |  [<c02246e0>] ? vt_console_print+0x210/0x2b0
      |  [<c02244d0>] ? vt_console_print+0x0/0x2b0
      |  [<c011a413>] ? __call_console_drivers+0x43/0x60
      |  [<c011a482>] ? _call_console_drivers+0x52/0x80
      |  [<c011aa89>] ? release_console_sem+0x1c9/0x200
      |  [<c0291d21>] ? raw_pci_read+0x41/0x70
      |  [<c0291e8f>] ? pci_read+0x2f/0x40
      |  [<c029151a>] pirq_via586_get+0x4a/0x60
      |  [<c02914d0>] ? pirq_via586_get+0x0/0x60
      |  [<c029178d>] pcibios_lookup_irq+0x15d/0x430
      |  [<c03b895a>] pcibios_irq_init+0x17a/0x3e0
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a6763>] kernel_init+0x73/0x250
      |  [<c03b87e0>] ? pcibios_irq_init+0x0/0x3e0
      |  [<c0114d00>] ? schedule_tail+0x10/0x40
      |  [<c0102dee>] ? ret_from_fork+0x6/0x1c
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c010324b>] kernel_thread_helper+0x7/0x1c
      |  =======================
      | ---[ end trace 4eaa2a86a8e2da22 ]---
      
      and IRQ trouble later,
      
      | irq 10: nobody cared (try booting with the "irqpoll" option)
      
      Now that's an VIA 8237 chip, so pirq_via586_get shouldn't be called
      at all; adding this workaround to via_router_probe() fixes the
      problem for me.
      
      Amazingly I have a 2.6.23.8 kernel that somehow works fine ... I'll
      never understand why.
      Signed-off-by: NBertram Felgenhauer <int-e@gmx.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9f67fd5d
  9. 02 6月, 2008 1 次提交
    • B
      pci, x86: add workaround for bug in ASUS A7V600 BIOS (rev 1005) · 75b19b79
      Bertram Felgenhauer 提交于
      This BIOS claims the VIA 8237 south bridge to be compatible with VIA 586,
      which it is not.
      
      Without this patch, I get the following warning while booting,
      among others,
      
      | PCI: Using IRQ router VIA [1106/3227] at 0000:00:11.0
      | ------------[ cut here ]------------
      | WARNING: at arch/x86/pci/irq.c:265 pirq_via586_get+0x4a/0x60()
      | Modules linked in:
      | Pid: 1, comm: swapper Not tainted 2.6.26-rc4-00015-g1ec7d99c #1
      |  [<c0119fd4>] warn_on_slowpath+0x54/0x70
      |  [<c02246e0>] ? vt_console_print+0x210/0x2b0
      |  [<c02244d0>] ? vt_console_print+0x0/0x2b0
      |  [<c011a413>] ? __call_console_drivers+0x43/0x60
      |  [<c011a482>] ? _call_console_drivers+0x52/0x80
      |  [<c011aa89>] ? release_console_sem+0x1c9/0x200
      |  [<c0291d21>] ? raw_pci_read+0x41/0x70
      |  [<c0291e8f>] ? pci_read+0x2f/0x40
      |  [<c029151a>] pirq_via586_get+0x4a/0x60
      |  [<c02914d0>] ? pirq_via586_get+0x0/0x60
      |  [<c029178d>] pcibios_lookup_irq+0x15d/0x430
      |  [<c03b895a>] pcibios_irq_init+0x17a/0x3e0
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a6763>] kernel_init+0x73/0x250
      |  [<c03b87e0>] ? pcibios_irq_init+0x0/0x3e0
      |  [<c0114d00>] ? schedule_tail+0x10/0x40
      |  [<c0102dee>] ? ret_from_fork+0x6/0x1c
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c03a66f0>] ? kernel_init+0x0/0x250
      |  [<c010324b>] kernel_thread_helper+0x7/0x1c
      |  =======================
      | ---[ end trace 4eaa2a86a8e2da22 ]---
      
      and IRQ trouble later,
      
      | irq 10: nobody cared (try booting with the "irqpoll" option)
      
      Now that's an VIA 8237 chip, so pirq_via586_get shouldn't be called
      at all; adding this workaround to via_router_probe() fixes the
      problem for me.
      
      Amazingly I have a 2.6.23.8 kernel that somehow works fine ... I'll
      never understand why.
      Signed-off-by: NBertram Felgenhauer <int-e@gmx.de>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      75b19b79
  10. 27 4月, 2008 1 次提交
    • Y
      x86: get mp_bus_to_node early · 871d5f8d
      Yinghai Lu 提交于
      Currently, on an amd k8 system with multi ht chains, the numa_node of
      pci devices under /sys/devices/pci0000:80/* is always 0, even if that
      chain is on node 1 or 2 or 3.
      
      Workaround: pcibus_to_node(bus) is used when we want to get the node that
      pci_device is on.
      
      In struct device, we already have numa_node member, and we could use
      dev_to_node()/set_dev_node() to get and set numa_node in the device.
      set_dev_node is called in pci_device_add() with pcibus_to_node(bus),
      and pcibus_to_node uses bus->sysdata for nodeid.
      
      The problem is when pci_add_device is called, bus->sysdata is not assigned
      correct nodeid yet. The result is that numa_node will always be 0.
      
      pcibios_scan_root and pci_scan_root could take sysdata. So we need to get
      mp_bus_to_node mapping before these two are called, and thus
      get_mp_bus_to_node could get correct node for sysdata in root bus.
      
      In scanning of the root bus, all child busses will take parent bus sysdata.
      So all pci_device->dev.numa_node will be assigned correctly and automatically.
      
      Later we could use dev_to_node(&pci_dev->dev) to get numa_node, and we
      could also could make other bus specific device get the correct numa_node
      too.
      
      This is an updated version of pci_sysdata and Jeff's pci_domain patch.
      
      [ mingo@elte.hu: build fix ]
      Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      871d5f8d
  11. 17 4月, 2008 1 次提交
  12. 22 2月, 2008 1 次提交
  13. 30 1月, 2008 2 次提交
  14. 20 10月, 2007 1 次提交
  15. 13 10月, 2007 1 次提交
  16. 11 10月, 2007 1 次提交
  17. 10 10月, 2007 1 次提交
    • J
      drivers/firmware: const-ify DMI API and internals · 1855256c
      Jeff Garzik 提交于
      Three main sets of changes:
      
      1) dmi_get_system_info() return value should have been marked const,
         since callers should not be changing that data.
      
      2) const-ify DMI internals, since DMI firmware tables should,
         whenever possible, be marked const to ensure we never ever write to
         that data area.
      
      3) const-ify DMI API, to enable marking tables const where possible
         in low-level drivers.
      
      And if we're really lucky, this might enable some additional
      optimizations on the part of the compiler.
      
      The bulk of the changes are #2 and #3, which are interrelated.  #1 could
      have been a separate patch, but it was so small compared to the others,
      it was easier to roll it into this changeset.
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      1855256c
  18. 11 9月, 2007 1 次提交
  19. 12 8月, 2007 1 次提交
    • M
      finish i386 and x86-64 sysdata conversion · 73c59afc
      Muli Ben-Yehuda 提交于
      This patch finishes the i386 and x86-64 ->sysdata conversion and hopefully
      also fixes Riku's and Andy's observed bugs.  It is based on Yinghai Lu's
      and Andy Whitcroft's patches (thanks!) with some changes:
      
      - introduce pci_scan_bus_with_sysdata() and use it instead of
        pci_scan_bus() where appropriate. pci_scan_bus_with_sysdata() will
        allocate the sysdata structure and then call pci_scan_bus().
      - always allocate pci_sysdata dynamically. The whole point of this
        sysdata work is to make it easy to do root-bus specific things
        (e.g., support PCI domains and IOMMU's). I dislike using a default
        struct pci_sysdata in some places and a dynamically allocated
        pci_sysdata elsewhere - the potential for someone indavertantly
        changing the default structure is too high.
      - this patch only makes the minimal changes necessary, i.e., the NUMA node is
        always initialized to -1. Patches to do the right thing with regards
        to the NUMA node can build on top of this (either add a 'node'
        parameter to pci_scan_bus_with_sysdata() or just update the node
        when it becomes known).
      
      The patch was compile tested with various configurations (e.g., NUMAQ,
      VISWS) and run-time tested on i386 and x86-64.  Unfortunately none of my
      machines exhibited the bugs so caveat emptor.
      
      Andy, could you please see if this fixes the NUMA issues you've seen?
      Riku, does this fix "pci=noacpi" on your laptop?
      Signed-off-by: NMuli Ben-Yehuda <muli@il.ibm.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Cc: <riku.seppala@kymp.net>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      73c59afc
  20. 07 12月, 2006 1 次提交
  21. 02 12月, 2006 1 次提交
  22. 15 11月, 2006 1 次提交
  23. 09 10月, 2006 1 次提交
  24. 04 10月, 2006 2 次提交
    • E
      [PATCH] genirq: i386 irq: Remove the msi assumption that irq == vector · ace80ab7
      Eric W. Biederman 提交于
      This patch removes the change in behavior of the irq allocation code when
      CONFIG_PCI_MSI is defined.  Removing all instances of the assumption that irq
      == vector.
      
      create_irq is rewritten to first allocate a free irq and then to assign that
      irq a vector.
      
      assign_irq_vector is made static and the AUTO_ASSIGN case which allocates an
      vector not bound to an irq is removed.
      
      The ioapic vector methods are removed, and everything now works with irqs.
      
      The definition of NR_IRQS no longer depends on CONFIG_PCI_MSI
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ace80ab7
    • E
      [PATCH] genirq: msi: simplify the msi irq limit policy · 92db6d10
      Eric W. Biederman 提交于
      Currently we attempt to predict how many irqs we will be able to allocate with
      msi using pci_vector_resources and some complicated accounting, and then we
      only allow each device as many irqs as we think are available on average.
      
      Only the s2io driver even takes advantage of this feature all other drivers
      have a fixed number of irqs they need and bail if they can't get them.
      
      pci_vector_resources is inaccurate if anyone ever frees an irq.  The whole
      implmentation is racy.  The current irq limit policy does not appear to make
      sense with current drivers.  So I have simplified things.  We can revisit this
      we we need a more sophisticated policy.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      92db6d10
  25. 03 7月, 2006 1 次提交
  26. 01 7月, 2006 1 次提交
  27. 23 6月, 2006 2 次提交
  28. 28 4月, 2006 1 次提交
  29. 15 4月, 2006 1 次提交
    • G
      [PATCH] arch/i386/pci/irq.c - new VIA chipsets (fwd) · 40d8b89b
      Grzegorz Janoszka 提交于
      I use 2.6.15.6 Linux kernel and found some problems. I have about 100
      Linux boxes (all with the same (binary the same) kernel). Last time I have
      upgraded all those boxes from 2.4.32 to 2.6.15.6 (first 2.6.15.1, next .2,
      .4 and .6) and I have found some problems on VIA based PC's. Probably the
      reason of this is that some VIA chipsets are unrecognized by IRQ router.
      
      In line 586 there is: /* FIXME: add new ones for 8233/5 */
      
      There were only a few of chipsets ID's there, some of my VIA chipsets were
      not present and kernel used default IRQ router.
      
      I have added three entries, so that the code looks like:
      
              case PCI_DEVICE_ID_VIA_82C596:
              case PCI_DEVICE_ID_VIA_82C686:
              case PCI_DEVICE_ID_VIA_8231:
              case PCI_DEVICE_ID_VIA_8233A:
              case PCI_DEVICE_ID_VIA_8235:
              case PCI_DEVICE_ID_VIA_8237:
              case PCI_DEVICE_ID_VIA_8237_SATA:
                      /* FIXME: add new ones for 8233/5 */
                      r->name = "VIA";
                      r->get = pirq_via_get;
                      r->set = pirq_via_set;
                      return 1;
              }
      
      The kernel goes fine but I haven't testes it for weeks, I'm just a moment
      after reboot :)
      One thing is different (better?):
      Using previus kernel I had:
      PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0
      now I have:
      PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 11
      
      Maybe it is good idea to add there some more VIA chipsets?
      The ones I have added seem to be OK.
      
      From: Grzegorz Janoszka <Grzegorz@Janoszka.pl>
      Acked-by: NMartin Mares <mj@ucw.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      40d8b89b
  30. 01 2月, 2006 1 次提交
  31. 10 1月, 2006 1 次提交
  32. 07 1月, 2006 1 次提交
  33. 31 10月, 2005 1 次提交
  34. 01 10月, 2005 1 次提交
  35. 27 9月, 2005 1 次提交
  36. 26 8月, 2005 1 次提交