1. 30 1月, 2008 2 次提交
  2. 20 10月, 2007 1 次提交
  3. 13 10月, 2007 1 次提交
  4. 11 10月, 2007 1 次提交
  5. 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
  6. 11 9月, 2007 1 次提交
  7. 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
  8. 07 12月, 2006 1 次提交
  9. 02 12月, 2006 1 次提交
  10. 15 11月, 2006 1 次提交
  11. 09 10月, 2006 1 次提交
  12. 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
  13. 03 7月, 2006 1 次提交
  14. 01 7月, 2006 1 次提交
  15. 23 6月, 2006 2 次提交
  16. 28 4月, 2006 1 次提交
  17. 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
  18. 01 2月, 2006 1 次提交
  19. 10 1月, 2006 1 次提交
  20. 07 1月, 2006 1 次提交
  21. 31 10月, 2005 1 次提交
  22. 01 10月, 2005 1 次提交
  23. 27 9月, 2005 1 次提交
  24. 26 8月, 2005 1 次提交
  25. 30 7月, 2005 1 次提交
  26. 28 7月, 2005 1 次提交
  27. 12 7月, 2005 1 次提交
  28. 28 6月, 2005 1 次提交
    • J
      [PATCH] PCI Allow OutOfRange PIRQ table address · 120bb424
      jayalk@intworks.biz 提交于
      I updated this to remove unnecessary variable initialization, make
      check_routing be inline only and not __init, switch to strtoul, and
      formatting fixes as per Randy Dunlap's recommendations.
      
      I updated this to change pirq_table_addr to a long, and to add a warning
      msg if the PIRQ table wasn't found at the specified address, as per thread
      with Matthew Wilcox.
      
      In our hardware situation, the BIOS is unable to store or generate it's PIRQ
      table in the F0000h-100000h standard range. This patch adds a pci kernel
      parameter, pirqaddr to allow the bootloader (or BIOS based loader) to inform
      the kernel where the PIRQ table got stored. A beneficial side-effect is that,
      if one's BIOS uses a static address each time for it's PIRQ table, then
      pirqaddr can be used to avoid the $pirq search through that address block each
      time at boot for normal PIRQ BIOSes.
      Signed-off-by: NJaya Kumar <jayalk@intworks.biz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      120bb424
  29. 24 6月, 2005 1 次提交
  30. 27 5月, 2005 1 次提交
  31. 01 5月, 2005 1 次提交
  32. 17 4月, 2005 2 次提交