1. 03 6月, 2015 4 次提交
  2. 31 5月, 2015 2 次提交
  3. 30 5月, 2015 1 次提交
  4. 29 5月, 2015 1 次提交
  5. 28 5月, 2015 1 次提交
    • B
      EDAC: Cleanup atomic_scrub mess · b01aec9b
      Borislav Petkov 提交于
      So first of all, this atomic_scrub() function's naming is bad. It looks
      like an atomic_t helper. Change it to edac_atomic_scrub().
      
      The bigger problem is that this function is arch-specific and every new
      arch which doesn't necessarily need that functionality still needs to
      define it, otherwise EDAC doesn't compile.
      
      So instead of doing that and including arch-specific headers, have each
      arch define an EDAC_ATOMIC_SCRUB symbol which can be used in edac_mc.c
      for ifdeffery. Much cleaner.
      
      And we already are doing this with another symbol - EDAC_SUPPORT. This
      is also much cleaner than having CONFIG_EDAC enumerate all the arches
      which need/have EDAC support and drivers.
      
      This way I can kill the useless edac.h header in tile too.
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: NChris Metcalf <cmetcalf@ezchip.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-edac@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: "Maciej W. Rozycki" <macro@codesourcery.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "Steven J. Hill" <Steven.Hill@imgtec.com>
      Cc: x86@kernel.org
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      b01aec9b
  6. 03 5月, 2015 1 次提交
  7. 27 4月, 2015 1 次提交
  8. 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
  9. 24 4月, 2015 13 次提交
  10. 23 4月, 2015 2 次提交
  11. 22 4月, 2015 12 次提交