1. 02 Mar, 2015 6 commits
    • Luciano Coelho's avatar
      iwlwifi: mvm: always use mac color zero · a19b04a5
      Luciano Coelho authored
      commit 5523d11c upstream.
      
      We don't really need to use different mac colors when adding mac
      contexts, because they're not used anywhere.  In fact, the firmware
      doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401
      when we reach that.
      
      Remove the color increment to use always zero and avoid reaching 255.
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a19b04a5
    • Alan Stern's avatar
      USB: fix use-after-free bug in usb_hcd_unlink_urb() · 1886b1ae
      Alan Stern authored
      commit c9919790 upstream.
      
      The usb_hcd_unlink_urb() routine in hcd.c contains two possible
      use-after-free errors.  The dev_dbg() statement at the end of the
      routine dereferences urb and urb->dev even though both structures may
      have been deallocated.
      
      This patch fixes the problem by storing urb->dev in a local variable
      (avoiding the dereference of urb) and moving the dev_dbg() up before
      the usb_put_dev() call.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1886b1ae
    • Alan Stern's avatar
      USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd) · cca1efc9
      Alan Stern authored
      commit 074f9dd5 upstream.
      
      Currently the USB stack assumes that all host controller drivers are
      capable of receiving wakeup requests from downstream devices.
      However, this isn't true for the isp1760-hcd driver, which means that
      it isn't safe to do a runtime suspend of any device attached to a
      root-hub port if the device requires wakeup.
      
      This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
      and sets the flag in isp1760-hcd.  The core is modified to prevent a
      direct child of the root hub from being put into runtime suspend with
      wakeup enabled if the flag is set.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cca1efc9
    • Oliver Neukum's avatar
      cdc-acm: add sanity checks · 27e636e8
      Oliver Neukum authored
      commit 7e860a6e upstream.
      
      Check the special CDC headers for a plausible minimum length.
      Another big operating systems ignores such garbage.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Reviewed-by: default avatarAdam Lee <adam8157@gmail.com>
      Tested-by: default avatarAdam Lee <adam8157@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      27e636e8
    • Jeff Layton's avatar
      nfs: don't call blocking operations while !TASK_RUNNING · 574a940f
      Jeff Layton authored
      commit 6ffa30d3 upstream.
      
      Bruce reported seeing this warning pop when mounting using v4.1:
      
           ------------[ cut here ]------------
           WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
          do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810ff58f>] prepare_to_wait+0x2f/0x90
          Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
          CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
           0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
           0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
           ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
          Call Trace:
           [<ffffffff8186ac78>] dump_stack+0x4c/0x65
           [<ffffffff810ac9da>] warn_slowpath_common+0x8a/0xc0
           [<ffffffff810aca65>] warn_slowpath_fmt+0x55/0x70
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810ff58f>] ? prepare_to_wait+0x2f/0x90
           [<ffffffff810dd2ad>] __might_sleep+0xbd/0xd0
           [<ffffffff8124c973>] kmem_cache_alloc_trace+0x243/0x430
           [<ffffffff810d941e>] ? groups_alloc+0x3e/0x130
           [<ffffffff810d941e>] groups_alloc+0x3e/0x130
           [<ffffffffa0301b1e>] svcauth_unix_accept+0x16e/0x290 [sunrpc]
           [<ffffffffa0300571>] svc_authenticate+0xe1/0xf0 [sunrpc]
           [<ffffffffa02fc564>] svc_process_common+0x244/0x6a0 [sunrpc]
           [<ffffffffa02fd044>] bc_svc_process+0x1c4/0x260 [sunrpc]
           [<ffffffffa03d5478>] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
           [<ffffffff810ff970>] ? wait_woken+0xc0/0xc0
           [<ffffffffa03d5350>] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
           [<ffffffff810d45bf>] kthread+0x11f/0x140
           [<ffffffff810ea815>] ? local_clock+0x15/0x30
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
           [<ffffffff81874bfc>] ret_from_fork+0x7c/0xb0
           [<ffffffff810d44a0>] ? kthread_create_on_node+0x250/0x250
          ---[ end trace 675220a11e30f4f2 ]---
      
      nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
      which is just wrong. Fix that by finishing the wait immediately if we've
      found that the list has something on it.
      
      Also, we don't expect this kthread to accept signals, so we should be
      using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
      hung task warnings from the watchdog, so have the schedule_timeout
      wake up every 60s if there's no callback activity.
      Reported-by: default avatar"J. Bruce Fields" <bfields@fieldses.org>
      Signed-off-by: default avatarJeff Layton <jlayton@primarydata.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      574a940f
    • Antti Palosaari's avatar
      [media] si2168: define symbol rate limits · 987d1daa
      Antti Palosaari authored
      commit f1ecc5d1 upstream.
      
      w_scan complains about missing symbol rate limits:
      This dvb driver is *buggy*: the symbol rate limits are undefined - please report to linuxtv.org
      
      Chip supports 1 to 7.2 MSymbol/s on DVB-C.
      Signed-off-by: default avatarAntti Palosaari <crope@iki.fi>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      987d1daa
  2. 24 Feb, 2015 34 commits
    • Dmitry Eremin-Solenikov's avatar
      ARM: 8284/1: sa1100: clear RCSR_SMR on resume · f38e1da0
      Dmitry Eremin-Solenikov authored
      commit e461894d upstream.
      
      StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
      by entering the sleep mode. After we have resumed, there is little point
      in having that bit enabled. Moreover, if this bit is set before reboot,
      the bootloader can become confused. Thus clear the SMR bit on resume
      just before clearing the scratchpad (resume address) register.
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f38e1da0
    • Marcin Wojtas's avatar
      mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951 · a66664cc
      Marcin Wojtas authored
      commit a39128bc upstream.
      
      According to erratum 'ERR-7878951' Armada 38x SDHCI controller has
      different capabilities than the ones shown in its registers:
      
      - it doesn't support the voltage switching: it can work either with
        3.3V or 1.8V supply
      - it doesn't support the SDR104 mode
      - SDR50 mode doesn't need tuning
      
      The SDHCI_QUIRK_MISSING_CAPS quirk is used for updating the
      capabilities accordingly.
      
      [gregory.clement@free-electrons.com: port from 3.10]
      
      Fixes: 5491ce3f ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a66664cc
    • Gregory CLEMENT's avatar
      mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor · c930c075
      Gregory CLEMENT authored
      commit d4b803c5 upstream.
      
      According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
      specific clock adjustments in SDIO3 Configuration register. However,
      this register was not part of the device tree binding. Even if the
      binding can (and will) be extended we still need handling the case
      where this register was not available. In this case we use the
      SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities.
      
      This commit is based on the work done by Marcin Wojtas<mw@semihalf.com>
      
      Fixes: 5491ce3f ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller")
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarMarcin Wojtas <mw@semihalf.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c930c075
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix setting of pdata->clk_delay_cycles · 2234e863
      Jisheng Zhang authored
      commit 14460dba upstream.
      
      Current code checks "clk_delay_cycles > 0" to know whether the optional
      "mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't
      touch clk_delay_cycles if the property is not set. And type of
      clk_delay_cycles is u32, so we may always set pdata->clk_delay_cycles as a
      random value.
      
      This patch fix this problem by check the return value of of_property_read_u32()
      to know whether the optional clk-delay-cycles is set or not.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2234e863
    • Ian Abbott's avatar
      staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back · 22d1120b
      Ian Abbott authored
      commit 42b8ce6f upstream.
      
      `do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
      This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
      back to user-space.  (This occurs when the low-level Comedi driver's
      `do_cmdtest()` handler returns non-zero to indicate a problem with the
      contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
      the `CMDF_BOGUS` flag set.)
      
      `compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
      version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
      compatible version of `struct comedi_cmd` back to user-space, which is
      at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
      it, change `compat_cmd()` to copy a 32-bit compatible version of the
      `struct comedi_cmd` back to user-space when the main ioctl handler
      returns `-EAGAIN`.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Reviewed-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      22d1120b
    • Krzysztof Kozlowski's avatar
      power_supply: 88pm860x: Fix leaked power supply on probe fail · 6d3e3b47
      Krzysztof Kozlowski authored
      commit 24727b45 upstream.
      
      Driver forgot to unregister power supply if request_threaded_irq()
      failed in probe(). In such case the memory associated with power supply
      leaked.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: a830d28b ("power_supply: Enable battery-charger for 88pm860x")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6d3e3b47
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix race between runtime pm and irq · 44baa458
      Jisheng Zhang authored
      commit 3bb10f60 upstream.
      
      This patch is to fix a race condition that may cause an unhandled irq,
      which results in big sdhci interrupt numbers and endless "mmc1: got irq
      while runtime suspended" msgs before v3.15.
      
      Consider following scenario:
      
            CPU0                            CPU1
                                    sdhci_pxav3_runtime_suspend()
                                     spin_lock_irqsave(&host->lock, flags);
       sdhci_irq()
        spining on the &host->lock
                                     host->runtime_suspended = true;
                                     spin_unlock_irqrestore(&host->lock, flags);
        get the &host->lock
        runtime_suspended is true now
        return IRQ_NONE;
      
      Fix this race by using the core sdhci.c supplied sdhci_runtime_suspend_host()
      in runtime suspend hook which will disable card interrupts. We also use the
      sdhci_runtime_resume_host() in the runtime resume hook accordingly.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      44baa458
    • Sebastian Hesselbarth's avatar
      mmc: sdhci-pxav3: Remove checks for mandatory host clock · 8aaf3727
      Sebastian Hesselbarth authored
      commit 20d5a703 upstream.
      
      NULL-checking a struct clk it not only wrong but also not required as
      for PXAv3 driver the corresponding clock is mandatory. Remove the
      checks from sdhci_pxav3_runtime_{suspend,resume}.
      Signed-off-by: default avatarSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8aaf3727
    • Soren Brinkmann's avatar
      clk: zynq: Force CPU_2X clock to be ungated · 533e84ba
      Soren Brinkmann authored
      commit 3dccfecd upstream.
      
      The CPU_2X clock does not have a classical in-kernel user, but is,
      amongst other things, required for OCM and debug access. Make sure this
      clock is not mistakenly disabled during boot up by enabling it in the
      platform's clock driver.
      
      Fixes: 0ee52b15 'clk: zynq: Add clock controller driver'
      Signed-off-by: default avatarSoren Brinkmann <soren.brinkmann@xilinx.com>
      Signed-off-by: default avatarMichael Turquette <mturquette@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      533e84ba
    • Marcel Holtmann's avatar
      Bluetooth: btusb: Add support for Dynex/Insignia USB dongles · 92c3e24e
      Marcel Holtmann authored
      commit d049f4e5 upstream.
      
      The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require
      firmware update before operation.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=19ff ProdID=0239 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      Since this is an unsual USB vendor ID (0x19ff), these dongles are added
      via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for
      mainstream Broadcom based dongles.
      
      The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex
      which needs to be converted using hex2hcd utility and then installed
      as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully
      operational.
      
      Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e
      Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e
      
      With this firmware the device reports support for connectionless slave
      broadcast (master and slave) feature used by 3D Glasses and TVs.
      
        < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1
                Page: 2
        > HCI Event: Command Complete (0x0e) plen 14
              Read Local Extended Features (0x04|0x0004) ncmd 1
                Status: Success (0x00)
                Page: 2/2
                Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
                  Connectionless Slave Broadcast - Master
                  Connectionless Slave Broadcast - Slave
                  Synchronization Train
                  Synchronization Scan
      
      However there are some flaws with this feature. The Set Event Mask Page 2
      command is actually not supported and with that all connectionless slave
      broadcast events are always enabled.
      
        < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8
                Mask: 0x00000000000f0000
                  Synchronization Train Received
                  Connectionless Slave Broadcast Receive
                  Connectionless Slave Broadcast Timeout
                  Truncated Page Complete
        > HCI Event: Command Complete (0x0e) plen 4
              Set Event Mask Page 2 (0x03|0x0063) ncmd 1
                Status: Unknown HCI Command (0x01)
      
      In addition the Synchronization Train Received event is actually broken
      on this controller. It mixes up the order of parameters. According to the
      Bluetooth Core specification the fields are like this:
      
        struct hci_ev_sync_train_received {
                __u8     status;
                bdaddr_t bdaddr;
                __le32   offset;
                __u8     map[10];
                __u8     lt_addr;
                __le32   instant;
                __le16   interval;
                __u8     service_data;
        } __packed;
      
      This controller however sends the service_data as 5th parameter instead
      of having it as last parameter.
      
        struct hci_ev_sync_train_received {
                __u8     status;
                bdaddr_t bdaddr;
                __le32   offset;
                __u8     map[10];
                __u8     service_data;
                __u8     lt_addr;
                __le32   instant;
                __le16   interval;
        } __packed;
      
      So anybody trying to use this hardware for utilizing connectionless slave
      broadcast receivers (aka 3D Glasses), be warned about this shortcoming.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      92c3e24e
    • Heinrich Siebmanns's avatar
      Bluetooth: Add support for Broadcom BCM20702A0 variants firmware download · 7f5a4fb4
      Heinrich Siebmanns authored
      commit 6029ddc2 upstream.
      
      This requires the flag BTUSB_BCM_PATCHRAM to work.
      
      Relevant details from /sys/kernel/debug/usb/devices for my device:
      
      T:  Bus=03 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0489 ProdID=e031 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=3859F9CD2AEE
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      The firmware was extracted from a Windows 7 32-bit installation
      and converted from 'hex' to 'hcd' for use in Linux.
      
      The firmware is named "BCM20702A0_001.001.024.0156.0204.hex"
      and is located in "%SYSTEMROOT%\system32\drivers\"
      (md5 d126e6c4e0e669d76c38cf9377f76b7f)
      (sha1 145d1850b2785a953233b409e7ff77786927c7d2)
      
      The firmware file is also available as a download at
      http://support.ts.fujitsu.com/Download/
      contained in "FTS_WIDCOMMBluetoothSoftware_6309000_1072149.zip"
      
      Search for the file Win32/bcbtums-win7x86-brcm.inf in the archive,
      look for the vendor and product ID of your adapter, see the section
      'devices' in that file to find out what device name it uses. See
      the device entry in the inf file (in my case it was 'RAMUSBE031')
      to find out which hex file you need to convert to hcd for upload
      
      'hcd' file should be placed at "brcm/BCM20702A0-0489-e031.hcd"
      inside the firmware directory (e.g. "/lib/firmware")
      Signed-off-by: default avatarHeinrich Siebmanns <harv@gmx.de>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      7f5a4fb4
    • Fabio K's avatar
      Bluetooth: Add support for Broadcom BCM20702A1 variant · ff8a2068
      Fabio K authored
      commit a86c02ea upstream.
      
      This variant requires the flag BTUSB_BCM_PATCHRAM to work.
      
      Relevant details from /sys/kernel/debug/usb/devices:
      
      T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=13d3 ProdID=3404 Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=240A646F1XXX
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      The firmware was extracted from a Windows 8.1 64-bit installation
      and converted from 'hex' to 'hcd' for use in Linux.
      
      Under Windows it also identifies itself as BCM20702A0,
      but the firmware is named "BCM20702A1_001.002.014.1315.1356.hex"
      and is located in "%SYSTEMROOT%\system32\drivers\"
      (md5 67cf6bfdae61c4bb819a66da984f7913)
      (sha1 5f74cc6a9a3bf19ee0f8c3d01e4be34c609b188f)
      
      The same firmware file is also available as a download at
      http://www.asrock.com/mb/Intel/Z87E-ITX/?cat=Download&os=All
      marked as "Bluetooth driver ver:12.0.0.7820"
      
      'hcd' file should be placed at "brcm/BCM20702A0-13d3-3404.hcd"
      inside the firmware directory (e.g. "/lib/firmware")
      Signed-off-by: default avatarFabio K <healthkit@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ff8a2068
    • Lennart Sorensen's avatar
      USB: cp210x: add ID for RUGGEDCOM USB Serial Console · faa71dde
      Lennart Sorensen authored
      commit a6f03312 upstream.
      
      Added the USB serial console device ID for Siemens Ruggedcom devices
      which have a USB port for their serial console.
      Signed-off-by: default avatarLen Sorensen <lsorense@csclub.uwaterloo.ca>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      faa71dde
    • Michel Dänzer's avatar
      PCI: Fix infinite loop with ROM image of size 0 · 9b17c1c8
      Michel Dänzer authored
      commit 16b036af upstream.
      
      If the image size would ever read as 0, pci_get_rom_size() could keep
      processing the same image over and over again.  Exit the loop if we ever
      read a length of zero.
      
      This fixes a soft lockup on boot when the radeon driver calls
      pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
      
      [bhelgaas: changelog, reference]
      Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973Reported-by: default avatarFederico <federicotg@gmail.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9b17c1c8
    • Hans de Goede's avatar
      samsung-laptop: Add use_native_backlight quirk, and enable it on some models · 2fe5afe7
      Hans de Goede authored
      commit 4690555e upstream.
      
      Since kernel 3.14 the backlight control has been broken on various Samsung
      Atom based netbooks. This has been bisected and this problem happens since
      commit b35684b8 ("drm/i915: do full backlight setup at enable time")
      
      This has been reported and discussed in detail here:
      http://lists.freedesktop.org/archives/intel-gfx/2014-July/049395.html
      
      Unfortunately no-one has been able to fix this. This only affects Samsung
      Atom netbooks, and the Linux kernel and the BIOS of those laptops have never
      worked well together. All affected laptops already have a quirk to avoid using
      the standard acpi-video interface and instead use the samsung specific SABI
      interface which samsung-laptop uses. It seems that recent fixes to the i915
      driver have also broken backlight control through the SABI interface.
      
      The intel_backlight driver OTOH works fine, and also allows for finer grained
      backlight control. So add a new use_native_backlight quirk, and replace the
      broken_acpi_video quirk with this quirk for affected models. This new quirk
      disables acpi-video as before and also stops samsung-laptop from registering
      the SABI based samsung_laptop backlight interface, leaving only the working
      intel_backlight interface.
      
      This commit enables this new quirk for 3 models which are known to be affected,
      chances are that it needs to be used on other models too.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1094948 # N145P
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1115713 # N250P
      Reported-by: Bertrik Sikken <bertrik@sikken.nl> # N150P
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      2fe5afe7
    • David Hildenbrand's avatar
      KVM: s390: avoid memory leaks if __inject_vm() fails · 0aba2a81
      David Hildenbrand authored
      commit 428d53be upstream.
      
      We have to delete the allocated interrupt info if __inject_vm() fails.
      
      Otherwise user space can keep flooding kvm with floating interrupts and
      provoke more and more memory leaks.
      Reported-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Reviewed-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0aba2a81
    • David Hildenbrand's avatar
      KVM: s390: base hrtimer on a monotonic clock · 36c99ba9
      David Hildenbrand authored
      commit 0ac96caf upstream.
      
      The hrtimer that handles the wait with enabled timer interrupts
      should not be disturbed by changes of the host time.
      
      This patch changes our hrtimer to be based on a monotonic clock.
      Signed-off-by: default avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Acked-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      36c99ba9
    • David Sterba's avatar
      btrfs: set proper message level for skinny metadata · 433ee525
      David Sterba authored
      commit 5efa0490 upstream.
      
      This has been confusing people for too long, the message is really just
      informative.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      433ee525
    • Dave Chinner's avatar
      xfs: set superblock buffer type correctly · 60f2d594
      Dave Chinner authored
      commit 3443a3bc upstream.
      
      When the superblock is modified in a transaction, the commonly
      modified fields are not actually copied to the superblock buffer to
      avoid the buffer lock becoming a serialisation point. However, there
      are some other operations that modify the superblock fields within
      the transaction that don't directly log to the superblock but rely
      on the changes to be applied during the transaction commit (to
      minimise the buffer lock hold time).
      
      When we do this, we fail to mark the buffer log item as being a
      superblock buffer and that can lead to the buffer not being marked
      with the corect type in the log and hence causing recovery issues.
      Fix it by setting the type correctly, similar to xfs_mod_sb()...
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      60f2d594
    • Dave Chinner's avatar
      xfs: set buf types when converting extent formats · 3ccfacd7
      Dave Chinner authored
      commit fe22d552 upstream.
      
      Conversion from local to extent format does not set the buffer type
      correctly on the new extent buffer when a symlink data is moved out
      of line.
      
      Fix the symlink code and leave a comment in the generic bmap code
      reminding us that the format-specific data copy needs to set the
      destination buffer type appropriately.
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      [ luis: backported to 3.16: libxfs infrastructure not available in 3.16 kernel ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3ccfacd7
    • Dave Chinner's avatar
      xfs: inode unlink does not set AGI buffer type · 4cf82111
      Dave Chinner authored
      commit f19b872b upstream.
      
      This leads to log recovery throwing errors like:
      
      XFS (md0): Mounting V5 Filesystem
      XFS (md0): Starting recovery (logdev: internal)
      XFS (md0): Unknown buffer type 0!
      XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      ffff8800ffc53800: 58 41 47 49 .....
      
      Which is the AGI buffer magic number.
      
      Ensure that we set the type appropriately in both unlink list
      addition and removal.
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4cf82111
    • Dave Chinner's avatar
      xfs: ensure buffer types are set correctly · 8da34e21
      Dave Chinner authored
      commit 0d612fb5 upstream.
      
      Jan Kara reported that log recovery was finding buffers with invalid
      types in them. This should not happen, and indicates a bug in the
      logging of buffers. To catch this, add asserts to the buffer
      formatting code to ensure that the buffer type is in range when the
      transaction is committed.
      
      We don't set a type on buffers being marked stale - they are not
      going to get replayed, the format item exists only for recovery to
      be able to prevent replay of the buffer, so the type does not
      matter. Hence that needs special casing here.
      Reported-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      8da34e21
    • Andrey Ryabinin's avatar
      smack: fix possible use after frees in task_security() callers · 168f0b12
      Andrey Ryabinin authored
      commit 6d1cff2a upstream.
      
      We hit use after free on dereferncing pointer to task_smack struct in
      smk_of_task() called from smack_task_to_inode().
      
      task_security() macro uses task_cred_xxx() to get pointer to the task_smack.
      task_cred_xxx() could be used only for non-pointer members of task's
      credentials. It cannot be used for pointer members since what they point
      to may disapper after dropping RCU read lock.
      
      Mainly task_security() used this way:
      	smk_of_task(task_security(p))
      
      Intead of this introduce function smk_of_task_struct() which
      takes task_struct as argument and returns pointer to smk_known struct
      and do this under RCU read lock.
      Bogus task_security() macro is not used anymore, so remove it.
      
      KASan's report for this:
      
      	AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600
      	=============================================================================
      	BUG kmalloc-64 (Tainted: PO): kasan error
      	-----------------------------------------------------------------------------
      
      	Disabling lock debugging due to kernel taint
      	INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866
      		kmem_cache_alloc_trace+0x88/0x1bc
      		new_task_smack+0x44/0xd8
      		smack_cred_prepare+0x48/0x21c
      		security_prepare_creds+0x44/0x4c
      		prepare_creds+0xdc/0x110
      		smack_setprocattr+0x104/0x150
      		security_setprocattr+0x4c/0x54
      		proc_pid_attr_write+0x12c/0x194
      		vfs_write+0x1b0/0x370
      		SyS_write+0x5c/0x94
      		ret_fast_syscall+0x0/0x48
      	INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564
      		kfree+0x270/0x290
      		smack_cred_free+0xc4/0xd0
      		security_cred_free+0x34/0x3c
      		put_cred_rcu+0x58/0xcc
      		rcu_process_callbacks+0x738/0x998
      		__do_softirq+0x264/0x4cc
      		do_softirq+0x94/0xf4
      		irq_exit+0xbc/0x120
      		handle_IRQ+0x104/0x134
      		gic_handle_irq+0x70/0xac
      		__irq_svc+0x44/0x78
      		_raw_spin_unlock+0x18/0x48
      		sync_inodes_sb+0x17c/0x1d8
      		sync_filesystem+0xac/0xfc
      		vdfs_file_fsync+0x90/0xc0
      		vfs_fsync_range+0x74/0x7c
      	INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080
      	INFO: Object 0xc4635600 @offset=5632 fp=0x  (null)
      
      	Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      	Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
      	Redzone c4635640: bb bb bb bb                                      ....
      	Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      	Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
      	CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1
      	Backtrace:
      	[<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24)
      	 r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140
      	[<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28)
      	[<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144)
      	[<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44)
      	 r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600
      	[<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538)
      	 r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7
      	[<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8)
      	[<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70)
      	 r5:c4635600 r4:ca9da000
      	[<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44)
      	 r5:cca25e80 r4:c0ba9780
      	[<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178)
      	 r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124
      	[<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4)
      	 r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148
      	[<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108)
      	[<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648)
      	[<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88)
      	[<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198)
      	 r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000
      	[<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34)
      	[<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48)
      	Read of size 4 by thread T834:
      	Memory state around the buggy address:
      	 c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      	 c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	>c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	           ^
      	 c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      	 c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc
      	 c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	 c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
      	 c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      	==================================================================
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      [ luis: backported to 3.16:
        - dropped changes to smk_bu_task()
        - adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      168f0b12
    • Jeff Moyer's avatar
      cfq-iosched: fix incorrect filing of rt async cfqq · bb05b966
      Jeff Moyer authored
      commit c6ce1943 upstream.
      
      Hi,
      
      If you can manage to submit an async write as the first async I/O from
      the context of a process with realtime scheduling priority, then a
      cfq_queue is allocated, but filed into the wrong async_cfqq bucket.  It
      ends up in the best effort array, but actually has realtime I/O
      scheduling priority set in cfqq->ioprio.
      
      The reason is that cfq_get_queue assumes the default scheduling class and
      priority when there is no information present (i.e. when the async cfqq
      is created):
      
      static struct cfq_queue *
      cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
      	      struct bio *bio, gfp_t gfp_mask)
      {
      	const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
      	const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);
      
      cic->ioprio starts out as 0, which is "invalid".  So, class of 0
      (IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:
      
      		async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
      
      static struct cfq_queue **
      cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
      {
              switch (ioprio_class) {
              case IOPRIO_CLASS_RT:
                      return &cfqd->async_cfqq[0][ioprio];
              case IOPRIO_CLASS_NONE:
                      ioprio = IOPRIO_NORM;
                      /* fall through */
              case IOPRIO_CLASS_BE:
                      return &cfqd->async_cfqq[1][ioprio];
              case IOPRIO_CLASS_IDLE:
                      return &cfqd->async_idle_cfqq;
              default:
                      BUG();
              }
      }
      
      Here, instead of returning a class mapped from the process' scheduling
      priority, we get back the bucket associated with IOPRIO_CLASS_BE.
      
      Now, there is no queue allocated there yet, so we create it:
      
      		cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
      
      That function ends up doing this:
      
      			cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
      			cfq_init_prio_data(cfqq, cic);
      
      cfq_init_cfqq marks the priority as having changed.  Then, cfq_init_prio
      data does this:
      
      	ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
      	switch (ioprio_class) {
      	default:
      		printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
      	case IOPRIO_CLASS_NONE:
      		/*
      		 * no prio set, inherit CPU scheduling settings
      		 */
      		cfqq->ioprio = task_nice_ioprio(tsk);
      		cfqq->ioprio_class = task_nice_ioclass(tsk);
      		break;
      
      So we basically have two code paths that treat IOPRIO_CLASS_NONE
      differently, which results in an RT async cfqq filed into a best effort
      bucket.
      
      Attached is a patch which fixes the problem.  I'm not sure how to make
      it cleaner.  Suggestions would be welcome.
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Tested-by: default avatarHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bb05b966
    • Rick Dunn's avatar
      Bluetooth: btusb: Add Broadcom patchram support for ASUSTek devices · 30802ebf
      Rick Dunn authored
      commit 9a5abdaa upstream.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0b05 ProdID=17cf Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=54271E3298CD
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      
      Firmware is extracted from the latest Broadcom BCM4352 Windows driver
      by extracting the zip and searching the .hex file names for '17cf'.
      
      The hex file must then be converted to hcd format using the hex2hcd
      utility and then moved to /lib/firmware/brcm/.
      Signed-off-by: default avatarRick Dunn <rick@rickdunn.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      30802ebf
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device · bfee8060
      Dmitry Tunin authored
      commit 033efa92 upstream.
      
      Add support of 13d3:3423 device.
      
      BugLink: https://bugs.launchpad.net/bugs/1411193
      
      T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
      D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
      P: Vendor=13d3 ProdID=3423 Rev= 0.01
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
      E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
      E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
      I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
      I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
      I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
      I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
      I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
      E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bfee8060
    • Lokesh Vutla's avatar
      ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 · 3ed8ad62
      Lokesh Vutla authored
      commit 1c7e36bf upstream.
      
      With commit '7dedd346: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
      with DEBUG_LL' we moved from parsing cmdline to identify uart used
      for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
      
      On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
      BeagleBoard-X15, where we use UART3 for console, boot fails with
      DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.
      
      For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
      
      Fixes: 90020c7b ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
      Reviewed-by: default avatarFelipe Balbi <balbi@ti.com>
      Acked-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      3ed8ad62
    • Krzysztof Kozlowski's avatar
      power: bq24190: Fix ignored supplicants · 440880ae
      Krzysztof Kozlowski authored
      commit 478913fd upstream.
      
      The driver mismatched 'num_supplicants' with 'num_supplies' of
      power_supply structure.
      
      It provided list of supplicants (power_supply.supplied_to) but did
      not set the number of supplicants. Instead it set the num_supplies which
      is used when iterating over number of supplies (power_supply.supplied_from).
      
      As a result the list of supplicants was ignored by core because its size
      was 0.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: d7bf353f ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      440880ae
    • Dmitry Eremin-Solenikov's avatar
      power: gpio-charger: balance enable/disable_irq_wake calls · 831296d3
      Dmitry Eremin-Solenikov authored
      commit faeed51b upstream.
      
      enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to
      generate the wakeup event (and thus resume should call disable_irq_wake).
      Currently gpio-charger driver has this logic inverted. Correct that thus
      correcting enable/disable_irq_wake() calls balance.
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      831296d3
    • Eyal Shapira's avatar
      iwlwifi: mvm: validate tid and sta_id in ba_notif · c34294fc
      Eyal Shapira authored
      commit 2cee4762 upstream.
      
      These are coming from the FW and are used to access arrays.
      Bad values can cause an out of bounds access so discard
      such ba_notifs and warn.
      Signed-off-by: default avatarEyal Shapira <eyalx.shapira@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c34294fc
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix unbalanced clock issues during probe · a5c11323
      Jisheng Zhang authored
      commit 62cf983a upstream.
      
      Commit 0dcaa249 ("sdhci-pxav3: Fix runtime PM initialization") tries
      to fix one hang issue caused by calling sdhci_add_host() on a suspended
      device. The fix enables the clock twice, once by clk_prepare_enable() and
      another by pm_runtime_get_sync(), meaning that the clock will never be
      gated at runtime PM suspend. I observed the power consumption regression on
      Marvell BG2Q SoCs.
      
      In fact, the fix is not correct. There still be a very small window
      during which a runtime suspend might somehow occur after pm_runtime_enable()
      but before pm_runtime_get_sync().
      
      This patch fixes all of the two problems by just incrementing the usage
      counter before pm_runtime_enable(). It also adjust the order of disabling
      runtime pm and storing the usage count in the error path to handle clock
      gating properly.
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a5c11323
    • Christophe Ricard's avatar
      tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO · 35af27a3
      Christophe Ricard authored
      commit c4eadfaf upstream.
      
      Add a return value check when reading data from the FIFO register.
      Reviewed-by: default avatarJason Gunthorpe <jason.gunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Reviewed-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      35af27a3
    • Christophe Ricard's avatar
      tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send · 5117c89f
      Christophe Ricard authored
      commit 1ba3b0b6 upstream.
      
      When sending data in tpm_stm_i2c_send, each loop iteration send buf.
      Send buf + i instead as the goal of this for loop is to send a number
      of byte from buf that fit in burstcnt. Once those byte are sent, we are
      supposed to send the next ones.
      
      The driver was working because the burstcount value returns always the maximum size for a TPM
      command or response. (0x800 for a command and 0x400 for a response).
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5117c89f
    • Hon Ching (Vicky) Lo's avatar
      tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma · 55412678
      Hon Ching (Vicky) Lo authored
      commit 84eb186b upstream.
      
      There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
      kernel panic during boot when vTPM is enabled in Power partition
      configured in AMS mode.
      
      vio_bus_probe calls vio_cmo_bus_probe which calls
      tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
      The problem is, vio_cmo_bus_probe is called before calling probe, which
      for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
      and sets up vtpm's CRQ and gets required data values.  Therefore,
      since this has not yet been done, NULL is returned in attempt to get
      the size for DMA allocation.
      
      We added a NULL check.  In addition, a default buffer size will
      be set when NULL is returned.
      Signed-off-by: default avatarHon Ching (Vicky) Lo <honclo@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      55412678