1. 14 Dec, 2015 9 commits
    • Petr Štetiar's avatar
      USB: qcserial: Add support for Quectel EC20 Mini PCIe module · b3d49c5a
      Petr Štetiar authored
      commit 9d5b5ed7 upstream.
      
      It seems like this device has same vendor and product IDs as G2K
      devices, but it has different number of interfaces(4 vs 5) and also
      different interface layout which makes it currently unusable:
      
      	usbcore: registered new interface driver qcserial
      	usbserial: USB Serial support registered for Qualcomm USB modem
      	usb 2-1.2: unknown number of interfaces: 5
      
      lsusb output:
      
      	Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless
      	Device Descriptor:
      	  bLength                18
      	  bDescriptorType         1
      	  bcdUSB               2.00
      	  bDeviceClass            0 (Defined at Interface level)
      	  bDeviceSubClass         0
      	  bDeviceProtocol         0
      	  bMaxPacketSize0        64
      	  idVendor           0x05c6 Qualcomm, Inc.
      	  idProduct          0x9215 Acer Gobi 2000 Wireless Modem
      	  bcdDevice            2.32
      	  iManufacturer           1 Quectel
      	  iProduct                2 Quectel LTE Module
      	  iSerial                 0
      	  bNumConfigurations      1
      	  Configuration Descriptor:
      	    bLength                 9
      	    bDescriptorType         2
      	    wTotalLength          209
      	    bNumInterfaces          5
      	    bConfigurationValue     1
      	    iConfiguration          0
      	    bmAttributes         0xa0
      	      (Bus Powered)
      	      Remote Wakeup
      	    MaxPower              500mA
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      [johan: rename define and add comment ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b3d49c5a
    • Jani Nikula's avatar
      drm/i915: quirk backlight present on Macbook 4, 1 · cb7b74a7
      Jani Nikula authored
      commit 1b9448b0 upstream.
      
      Unsurprisingly macbooks have backlights, just the VBT doesn't seem to
      know it in this case.
      Reported-and-tested-by: default avatarDaniel Nicoletti <dantti12@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325
      Fixes: c675949e ("drm/i915: do not setup backlight if not available according to VBT")
      Reviewed-by: default avatarAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1446716999-1796-1-git-send-email-jani.nikula@intel.comSigned-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cb7b74a7
    • Thomas Betker's avatar
      iio: adc: xilinx: Fix VREFN scale · 150fa5c1
      Thomas Betker authored
      commit a57f8dac upstream.
      
      The scaling factor for VREFN is 3.0/4096 (not 1.0/4096), just as for
      VREFP. This is not immediately obvious from the specification (Xilinx
      UG480), but has been confirmed by Xilinx support.
      Suggested-by: default avatarHartmut Knaack <knaack.h@gmx.de>
      Signed-off-by: default avatarThomas Betker <thomas.betker@rohde-schwarz.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      150fa5c1
    • Dave Hansen's avatar
      x86/fpu: Fix 32-bit signal frame handling · 09a75205
      Dave Hansen authored
      commit ab6b5294 upstream.
      
      (This should have gone to LKML originally. Sorry for the extra
       noise, folks on the cc.)
      
      Background:
      
      Signal frames on x86 have two formats:
      
        1. For 32-bit executables (whether on a real 32-bit kernel or
           under 32-bit emulation on a 64-bit kernel) we have a
          'fpregset_t' that includes the "FSAVE" registers.
      
        2. For 64-bit executables (on 64-bit kernels obviously), the
           'fpregset_t' is smaller and does not contain the "FSAVE"
           state.
      
      When creating the signal frame, we have to be aware of whether
      we are running a 32 or 64-bit executable so we create the
      correct format signal frame.
      
      Problem:
      
      save_xstate_epilog() uses 'fx_sw_reserved_ia32' whenever it is
      called for a 32-bit executable.  This is for real 32-bit and
      ia32 emulation.
      
      But, fpu__init_prepare_fx_sw_frame() only initializes
      'fx_sw_reserved_ia32' when emulation is enabled, *NOT* for real
      32-bit kernels.
      
      This leads to really wierd situations where 32-bit programs
      lose their extended state when returning from a signal handler.
      The kernel copies the uninitialized (zero) 'fx_sw_reserved_ia32'
      out to userspace in save_xstate_epilog().  But when returning
      from the signal, the kernel errors out in check_for_xstate()
      when it does not see FP_XSTATE_MAGIC1 present (because it was
      zeroed).  This leads to the FPU/XSAVE state being initialized.
      
      For MPX, this leads to the most permissive state and means we
      silently lose bounds violations.  I think this would also mean
      that we could lose *ANY* FPU/SSE/AVX state.  I'm not sure why
      no one has spotted this bug.
      
      I believe this was broken by:
      
      	72a671ce ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels")
      
      way back in 2012.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: dave@sr71.net
      Cc: fenghua.yu@intel.com
      Cc: yu-cheng.yu@intel.com
      Link: http://lkml.kernel.org/r/20151111002354.A0799571@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [ luis: backported to 3.16:
        - file and function rename:
          * arch/x86/kernel/fpu/signal.c -> arch/x86/kernel/xsave.c
          * fpu__init_prepare_fx_sw_frame() -> prepare_fx_sw_frame()
        - use 'i387_fsave_struct' instead of 'fregs_state'
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      09a75205
    • Lars-Peter Clausen's avatar
      iio:ad7793: Fix ad7785 product ID · 2459e20b
      Lars-Peter Clausen authored
      commit 785171fd upstream.
      
      While the datasheet for the AD7785 lists 0xXB as the product ID the actual
      product ID is 0xX3.
      
      Fix the product ID otherwise the driver will reject the device due to non
      matching IDs.
      
      Fixes: e786cc26 ("staging:iio:ad7793: Implement stricter id checking")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2459e20b
    • Lars-Peter Clausen's avatar
      iio: ad5064: Fix ad5629/ad5669 shift · 76c727f1
      Lars-Peter Clausen authored
      commit 5dcbe97b upstream.
      
      The ad5629/ad5669 are the I2C variant of the ad5628/ad5668, which has a SPI
      interface. They are mostly identical with the exception that the shift
      factor is different. Currently the driver does not take care of this
      difference which leads to incorrect DAC output values.
      
      Fix this by introducing a custom channel spec for the ad5629/ad5669 with
      the correct shift factor.
      
      Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r")
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      76c727f1
    • Michael Hennerich's avatar
      iio:ad5064: Make sure ad5064_i2c_write() returns 0 on success · d42be560
      Michael Hennerich authored
      commit 03fe472e upstream.
      
      i2c_master_send() returns the number of bytes transferred on success while
      the ad5064 driver expects that the write() callback returns 0 on success.
      Fix that by translating any non negative return value of i2c_master_send()
      to 0.
      
      Fixes: commit 6a17a076 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r")
      Signed-off-by: default avatarMichael Hennerich <michael.hennerich@analog.com>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d42be560
    • Vladimir Zapolskiy's avatar
      iio: lpc32xx_adc: fix warnings caused by enabling unprepared clock · 2f26036a
      Vladimir Zapolskiy authored
      commit 01bb70ae upstream.
      
      If common clock framework is configured, the driver generates a warning,
      which is fixed by this change:
      
          root@devkit3250:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw
          ------------[ cut here ]------------
          WARNING: CPU: 0 PID: 724 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
          Modules linked in: sc16is7xx snd_soc_uda1380
          CPU: 0 PID: 724 Comm: cat Not tainted 4.3.0-rc2+ #198
          Hardware name: LPC32XX SoC (Flattened Device Tree)
          Backtrace:
          [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
          [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
          [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
          [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
          [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
          [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
          [<>] (clk_enable) from [<>] (lpc32xx_read_raw+0x38/0x80)
          [<>] (lpc32xx_read_raw) from [<>] (iio_read_channel_info+0x70/0x94)
          [<>] (iio_read_channel_info) from [<>] (dev_attr_show+0x28/0x4c)
          [<>] (dev_attr_show) from [<>] (sysfs_kf_seq_show+0x8c/0xf0)
          [<>] (sysfs_kf_seq_show) from [<>] (kernfs_seq_show+0x2c/0x30)
          [<>] (kernfs_seq_show) from [<>] (seq_read+0x1c8/0x440)
          [<>] (seq_read) from [<>] (kernfs_fop_read+0x38/0x170)
          [<>] (kernfs_fop_read) from [<>] (do_readv_writev+0x16c/0x238)
          [<>] (do_readv_writev) from [<>] (vfs_readv+0x50/0x58)
          [<>] (vfs_readv) from [<>] (default_file_splice_read+0x1a4/0x308)
          [<>] (default_file_splice_read) from [<>] (do_splice_to+0x78/0x84)
          [<>] (do_splice_to) from [<>] (splice_direct_to_actor+0xc8/0x1cc)
          [<>] (splice_direct_to_actor) from [<>] (do_splice_direct+0xa0/0xb8)
          [<>] (do_splice_direct) from [<>] (do_sendfile+0x1a8/0x30c)
          [<>] (do_sendfile) from [<>] (SyS_sendfile64+0x104/0x10c)
          [<>] (SyS_sendfile64) from [<>] (ret_fast_syscall+0x0/0x38)
      Signed-off-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2f26036a
    • Luis Henriques's avatar
      Linux 3.16.7-ckt21 · 70a95b3e
      Luis Henriques authored
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      70a95b3e
  2. 13 Dec, 2015 31 commits