1. 23 7月, 2011 1 次提交
  2. 19 6月, 2011 1 次提交
  3. 27 5月, 2011 1 次提交
  4. 15 5月, 2011 1 次提交
    • J
      pata_cm64x: fix boot crash on parisc · 9281b16c
      James Bottomley 提交于
      The old IDE cmd64x checks the status of the CNTRL register to see if
      the ports are enabled before probing them.  pata_cmd64x doesn't do
      this, which causes a HPMC on parisc when it tries to poke at the
      secondary port because apparently the BAR isn't wired up (and a
      non-responding piece of memory causes a HPMC).
      
      Fix this by porting the CNTRL register port detection logic from IDE
      cmd64x.  In addition, following converns from Alan Cox, add a check to
      see if a mobility electronics bridge is the immediate parent and forgo
      the check if it is (prevents problems on hotplug controllers).
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      9281b16c
  5. 11 5月, 2011 1 次提交
  6. 02 5月, 2011 1 次提交
    • J
      i2c-i801: Move device ID definitions to driver · a6e5e2be
      Jean Delvare 提交于
      Move the SMBus device ID definitions of recent devices from pci_ids.h
      to the i2c-i801.c driver file. They don't have to be shared, as they
      are clearly identified and only used in this driver. In the future,
      such IDs will go to i2c-i801 directly. This will make adding support
      for new devices much faster and easier, as it will avoid cross-
      subsystem patch sets and merge conflicts.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: Seth Heasley <seth.heasley@intel.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      a6e5e2be
  7. 31 3月, 2011 1 次提交
  8. 23 3月, 2011 1 次提交
  9. 17 3月, 2011 1 次提交
  10. 25 2月, 2011 1 次提交
  11. 09 2月, 2011 1 次提交
  12. 26 1月, 2011 1 次提交
  13. 14 1月, 2011 1 次提交
  14. 09 1月, 2011 2 次提交
  15. 07 1月, 2011 1 次提交
  16. 24 12月, 2010 1 次提交
  17. 23 11月, 2010 1 次提交
  18. 09 11月, 2010 1 次提交
  19. 01 11月, 2010 1 次提交
  20. 23 10月, 2010 1 次提交
  21. 19 10月, 2010 1 次提交
  22. 18 10月, 2010 1 次提交
  23. 16 10月, 2010 3 次提交
  24. 14 10月, 2010 1 次提交
  25. 02 10月, 2010 1 次提交
  26. 23 9月, 2010 1 次提交
    • J
      x86/amd-iommu: Work around S3 BIOS bug · 4c894f47
      Joerg Roedel 提交于
      This patch adds a workaround for an IOMMU BIOS problem to
      the AMD IOMMU driver. The result of the bug is that the
      IOMMU does not execute commands anymore when the system
      comes out of the S3 state resulting in system failure. The
      bug in the BIOS is that is does not restore certain hardware
      specific registers correctly. This workaround reads out the
      contents of these registers at boot time and restores them
      on resume from S3. The workaround is limited to the specific
      IOMMU chipset where this problem occurs.
      
      Cc: stable@kernel.org
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      4c894f47
  27. 20 9月, 2010 1 次提交
  28. 01 9月, 2010 1 次提交
  29. 31 8月, 2010 1 次提交
  30. 24 8月, 2010 1 次提交
  31. 09 8月, 2010 1 次提交
  32. 05 8月, 2010 1 次提交
  33. 03 8月, 2010 2 次提交
  34. 02 8月, 2010 1 次提交
  35. 23 7月, 2010 1 次提交
    • S
      xen: Xen PCI platform device driver. · 183d03cc
      Stefano Stabellini 提交于
      Add the xen pci platform device driver that is responsible
      for initializing the grant table and xenbus in PV on HVM mode.
      Few changes to xenbus and grant table are necessary to allow the delayed
      initialization in HVM mode.
      Grant table needs few additional modifications to work in HVM mode.
      
      The Xen PCI platform device raises an irq every time an event has been
      delivered to us. However these interrupts are only delivered to vcpu 0.
      The Xen PCI platform interrupt handler calls xen_hvm_evtchn_do_upcall
      that is a little wrapper around __xen_evtchn_do_upcall, the traditional
      Xen upcall handler, the very same used with traditional PV guests.
      
      When running on HVM the event channel upcall is never called while in
      progress because it is a normal Linux irq handler (and we cannot switch
      the irq chip wholesale to the Xen PV ones as we are running QEMU and
      might have passed in PCI devices), therefore we cannot be sure that
      evtchn_upcall_pending is 0 when returning.
      For this reason if evtchn_upcall_pending is set by Xen we need to loop
      again on the event channels set pending otherwise we might loose some
      event channel deliveries.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: NSheng Yang <sheng@linux.intel.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      183d03cc
  36. 02 7月, 2010 1 次提交