1. 31 5月, 2015 30 次提交
  2. 20 5月, 2015 1 次提交
  3. 15 5月, 2015 2 次提交
  4. 03 5月, 2015 2 次提交
  5. 27 4月, 2015 1 次提交
  6. 25 4月, 2015 2 次提交
    • D
      platform/chrome: chromeos_laptop - instantiate Atmel at primary address · 96cba9b0
      Dmitry Torokhov 提交于
      The new Atmel MXT driver expects i2c client's address contain the
      primary (main address) of the chip, and calculates the expected
      bootloader address form the primary address. Unfortunately chrome_laptop
      does probe the devices and if touchpad (or touchscreen, or both) comes
      up in bootloader mode the i2c device gets instantiated with the
      bootloader address which confuses the driver.
      
      To work around this issue let's probe the primary address first. If the
      device is not detected at the primary address we'll probe alternative
      addresses as "dummy" devices. If any of them are found, destroy the
      dummy client and instantiate client with proper name at primary address
      still.
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      96cba9b0
    • H
      toshiba_acpi: Do not register vendor backlight when acpi_video bl is available · 358d6a2c
      Hans de Goede 提交于
      commit a39f46df ("toshiba_acpi: Fix regression caused by backlight extra
      check code") causes the backlight to no longer work on the Toshiba Z30,
      reverting that commit fixes this but restores the original issue fixed
      by that commit.
      
      Looking at the toshiba_acpi backlight code for a fix for this I noticed that
      the toshiba code is the only code under platform/x86 which unconditionally
      registers a vendor acpi backlight interface, without checking for acpi_video
      backlight support first.
      
      This commit adds the necessary checks bringing toshiba_acpi in line with the
      other drivers, and fixing the Z30 regression without needing to revert the
      commit causing it.
      
      Chances are that there will be some Toshiba models which have a non working
      acpi-video implementation while the toshiba vendor backlight interface does
      work, this commit adds an empty dmi_id table where such systems can be added,
      this is identical to how other drivers handle such systems.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-and-tested-by: NAzael Avalos <coproscefalo@gmail.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      358d6a2c
  7. 24 4月, 2015 2 次提交
    • G
      crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA · 8c98ebd7
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
          drivers/built-in.o: In function `img_hash_write_via_dma_stop':
          img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg'
          drivers/built-in.o: In function `img_hash_xmit_dma':
          img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg'
          img-hash.c:(.text+0xa2b948): undefined reference to `dma_unmap_sg'
      
      Also move the "depends" section below the "tristate" line while we're at
      it.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8c98ebd7
    • R
      ACPI / scan: Add a scan handler for PRP0001 · 7d284352
      Rafael J. Wysocki 提交于
      If the special PRP0001 device ID is present in the given device's list
      of ACPI/PNP IDs and the device has a valid "compatible" property in
      the _DSD, it should be enumerated using the default mechanism,
      unless some scan handlers match the IDs preceding PRP0001 in the
      device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
      matching the IDs following PRP0001 in that list should be attached
      to the device.
      
      To make that happen, define a scan handler that will match PRP0001
      and trigger the default enumeration for the matching devices if the
      "compatible" property is present for them.
      
      Since that requires the check for platform_id and device->handler
      to be removed from acpi_default_enumeration(), move the fallback
      invocation of acpi_default_enumeration() to acpi_bus_attach()
      (after it's checked if there's a matching ACPI driver for the
      device), which is a better place to call it, and do the platform_id
      check in there too (device->handler is guaranteed to be unset at
      the point where the function is looking for a matching ACPI driver).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      7d284352