1. 21 12月, 2006 3 次提交
    • D
      PCI quirks: remove redundant check · 0c875c28
      David Rientjes 提交于
      Removes redundant check for dev->subordinate; if it is NULL, the function
      returns before the patch-affected code region.
      Signed-off-by: NDavid Rientjes <rientjes@cs.washington.edu>
      Acked-by: NBrice Goglin <brice@myri.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0c875c28
    • I
      pci: add class codes for Wireless RF controllers · 42a0ee32
      Inaky Perez-Gonzalez 提交于
      pci: add class codes for Wireless RF controllers
      
      Add PCI codes to include/linux/pci_ids.h for RF controllers; first
      batch of these devices seem to be the Ultra-Wide-Band and Wireless USB
      controllers (WHCI spec).
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      42a0ee32
    • R
      PCI: use /sys/bus/pci/drivers/<driver>/new_id first · 7461b60a
      Russell King 提交于
      Unfortunately, the .../new_id feature does not work with the 8250_pci
      driver.
      
      The reason for this comes down to the way .../new_id is implemented.
      When PCI tries to match a driver to a device, it checks the modules
      static device ID tables _before_ checking the dynamic new_id tables.
      
      When a driver is capable of matching by ID, and falls back to matching
      by class (as 8250_pci does), this makes it absolutely impossible to
      specify a board by ID, and as such the correct driver_data value to
      use with it.
      
      Let's say you have a serial board with vendor 0x1234 and device 0x5678.
      It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.
      
      On boot, this card is matched to the 8250_pci driver, which tries to
      probe it because it matched using the class entry.  The driver finds
      that it is unable to automatically detect the correct settings to use,
      so it returns -ENODEV.
      
      You know that the information the driver needs is to match this card
      using a device_data value of '7'.  So you echo 1234 5678 0 0 0 0 7
      into new_id.
      
      The kernel attempts to re-bind 8250_pci to this device.  However,
      because it scans the PCI driver tables, it _again_ matches the class
      entry which has the wrong device_data.  It fails.
      
      End of story.  You can't support the card without rebuilding the
      kernel (or writing a specific PCI probe module to support it.)
      
      So, can we make new_id override the driver-internal PCI ID tables?
      IOW, like this:
      
      
      From: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7461b60a
  2. 20 12月, 2006 1 次提交
  3. 18 12月, 2006 35 次提交
  4. 17 12月, 2006 1 次提交
    • L
      Fix up mm/mincore.c error value cases · 4fb23e43
      Linus Torvalds 提交于
      Hugh Dickins correctly points out that mincore() is actually _supposed_
      to fail on an unmapped hole in the user address space, rather than
      return valid ("empty") information about the hole.  This just simplifies
      the problem further (I had been misled by our previous confusing and
      complicated way of doing mincore()).
      
      Also, in the unlikely situation that we can't allocate a temporary
      kernel buffer, we should actually return EAGAIN, not ENOMEM, to keep the
      "unmapped hole" and "allocation failure" error cases separate.
      
      Finally, add a comment about our stupid historical lack of support for
      anonymous mappings.  I'll fix that if somebody reminds me after 2.6.20
      is out.
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4fb23e43