1. 20 3月, 2018 1 次提交
  2. 27 1月, 2018 1 次提交
  3. 19 1月, 2018 1 次提交
  4. 19 12月, 2017 1 次提交
  5. 09 11月, 2017 2 次提交
  6. 30 11月, 2016 1 次提交
    • B
      PCI: Add comments about ROM BAR updating · 0b457dde
      Bjorn Helgaas 提交于
      pci_update_resource() updates a hardware BAR so its address matches the
      kernel's struct resource UNLESS it's a disabled ROM BAR.  We only update
      those when we enable the ROM.
      
      It's not obvious from the code why ROM BARs should be handled specially.
      Apparently there are Matrox devices with defective ROM BARs that read as
      zero when disabled.  That means that if pci_enable_rom() reads the disabled
      BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and
      writes it back, it would enable the ROM at address zero.
      
      Add comments and references to explain why we can't make the code look more
      rational.
      
      The code changes are from 755528c8 ("Ignore disabled ROM resources at
      setup") and 8085ce08 ("[PATCH] Fix PCI ROM mapping").
      
      Link: https://lkml.org/lkml/2005/8/30/138Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      0b457dde
  7. 12 3月, 2016 2 次提交
  8. 09 3月, 2016 2 次提交
    • B
      PCI: Set ROM shadow location in arch code, not in PCI core · 0c0e0736
      Bjorn Helgaas 提交于
      IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
      RAM.  The existence of such a copy and its location are arch-specific.
      Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
      0xC0000-0xDFFFF location was hard-coded into the PCI core.
      
      If we're using a shadow copy in RAM, disable the ROM BAR and release the
      address space it was consuming.  Move the location information from the PCI
      core to the arch code that sets IORESOURCE_ROM_SHADOW.  Save the location
      of the RAM copy in the struct resource for PCI_ROM_RESOURCE.
      
      After this change, pci_map_rom() will call pci_assign_resource() and
      pci_enable_rom() for these IORESOURCE_ROM_SHADOW resources, which we did
      not do before.  This is safe because:
      
        - pci_assign_resource() will do nothing because the resource is marked
          IORESOURCE_PCI_FIXED, which means we can't move it, and
      
        - pci_enable_rom() will not turn on the ROM BAR's enable bit because the
          resource is marked IORESOURCE_ROM_SHADOW, which means it is in RAM
          rather than in PCI memory space.
      
      Storing the location in the struct resource means "lspci" will show the
      shadow location, not the value from the ROM BAR.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      0c0e0736
    • B
      PCI: Don't enable/disable ROM BAR if we're using a RAM shadow copy · 4708f9a5
      Bjorn Helgaas 提交于
      If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
      touch the ROM BAR enable bit.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      4708f9a5
  9. 09 1月, 2016 1 次提交
  10. 11 12月, 2015 1 次提交
  11. 24 1月, 2015 1 次提交
  12. 11 6月, 2014 2 次提交
  13. 28 2月, 2014 1 次提交
  14. 22 12月, 2013 1 次提交
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      These interfaces:
      
        pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
      
      took a pci_dev, but they really depend only on the pci_bus.  And we want to
      use them in resource allocation paths where we have the bus but not a
      device, so this patch converts them to take the pci_bus instead of the
      pci_dev:
      
        pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
      
      In fact, with standard PCI-PCI bridges, they only depend on the host
      bridge, because that's the only place address translation occurs, but
      we aren't going that far yet.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  15. 27 3月, 2013 1 次提交
  16. 20 3月, 2013 1 次提交
  17. 11 12月, 2012 1 次提交
  18. 06 12月, 2012 1 次提交
  19. 23 8月, 2012 1 次提交
  20. 01 11月, 2011 1 次提交
  21. 14 2月, 2009 1 次提交
  22. 05 2月, 2009 1 次提交
  23. 04 11月, 2008 1 次提交
  24. 27 9月, 2008 1 次提交
  25. 04 3月, 2008 1 次提交
  26. 02 2月, 2008 1 次提交
  27. 10 7月, 2007 1 次提交
  28. 02 12月, 2006 1 次提交
  29. 28 10月, 2006 1 次提交
  30. 19 10月, 2006 1 次提交
  31. 01 7月, 2006 1 次提交
  32. 28 6月, 2006 1 次提交
  33. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      Tim Schmielau 提交于
      I recently picked up my older work to remove unnecessary #includes of
      sched.h, starting from a patch by Dave Jones to not include sched.h
      from module.h. This reduces the number of indirect includes of sched.h
      by ~300. Another ~400 pointless direct includes can be removed after
      this disentangling (patch to follow later).
      However, quite a few indirect includes need to be fixed up for this.
      
      In order to feed the patches through -mm with as little disturbance as
      possible, I've split out the fixes I accumulated up to now (complete for
      i386 and x86_64, more archs to follow later) and post them before the real
      patch.  This way this large part of the patch is kept simple with only
      adding #includes, and all hunks are independent of each other.  So if any
      hunk rejects or gets in the way of other patches, just drop it.  My scripts
      will pick it up again in the next round.
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  34. 02 9月, 2005 1 次提交
  35. 30 7月, 2005 1 次提交
  36. 01 5月, 2005 1 次提交
新手
引导
客服 返回
顶部