1. 02 Apr, 2015 2 commits
  2. 30 Mar, 2015 38 commits
    • Arnd Bergmann's avatar
      usb: musb: omap2plus bus glue needs USB host support · d2711f35
      Arnd Bergmann authored
      commit a8d191c8 upstream.
      
      The musb/omap2430.c bus glue driver calls usb_hcd_poll_rh_status,
      which is only available if CONFIG_USB is also set, i.e. we
      are building USB host mode and not just endpoint mode.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: linux-omap@vger.kernel.org
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d2711f35
    • Dmitry Eremin-Solenikov's avatar
      ARM: 8284/1: sa1100: clear RCSR_SMR on resume · ce9ec7bf
      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 avatarKamal Mostafa <kamal@canonical.com>
      ce9ec7bf
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix setting of pdata->clk_delay_cycles · 47e931ff
      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 avatarKamal Mostafa <kamal@canonical.com>
      47e931ff
    • Ian Abbott's avatar
      staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back · e17db245
      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 avatarKamal Mostafa <kamal@canonical.com>
      e17db245
    • Krzysztof Kozlowski's avatar
      power_supply: 88pm860x: Fix leaked power supply on probe fail · 9b1921fc
      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 avatarKamal Mostafa <kamal@canonical.com>
      9b1921fc
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix race between runtime pm and irq · dc22416d
      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>
      [ kamal: backport to 3.13-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      dc22416d
    • Sebastian Hesselbarth's avatar
      mmc: sdhci-pxav3: Remove checks for mandatory host clock · 67826881
      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>
      [ kamal: 3.13-stable prereq for:
        3bb10f60 mmc: sdhci-pxav3: fix race between runtime pm and irq ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      67826881
    • Soren Brinkmann's avatar
      clk: zynq: Force CPU_2X clock to be ungated · 22a9769f
      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 avatarKamal Mostafa <kamal@canonical.com>
      22a9769f
    • Lennart Sorensen's avatar
      USB: cp210x: add ID for RUGGEDCOM USB Serial Console · 008bba33
      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 avatarKamal Mostafa <kamal@canonical.com>
      008bba33
    • Michel Dänzer's avatar
      PCI: Fix infinite loop with ROM image of size 0 · af372b21
      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 avatarKamal Mostafa <kamal@canonical.com>
      af372b21
    • David Hildenbrand's avatar
      KVM: s390: base hrtimer on a monotonic clock · 69fc9cbb
      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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      69fc9cbb
    • David Sterba's avatar
      btrfs: set proper message level for skinny metadata · c55e2d1c
      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 avatarKamal Mostafa <kamal@canonical.com>
      c55e2d1c
    • Dave Chinner's avatar
      xfs: set superblock buffer type correctly · bc9b3c8d
      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 avatarKamal Mostafa <kamal@canonical.com>
      bc9b3c8d
    • Dave Chinner's avatar
      xfs: set buf types when converting extent formats · 81d966f9
      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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      81d966f9
    • Dave Chinner's avatar
      xfs: inode unlink does not set AGI buffer type · 4778f569
      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 avatarKamal Mostafa <kamal@canonical.com>
      4778f569
    • Dave Chinner's avatar
      xfs: ensure buffer types are set correctly · fd1edb97
      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 avatarKamal Mostafa <kamal@canonical.com>
      fd1edb97
    • Andrey Ryabinin's avatar
      smack: fix possible use after frees in task_security() callers · 42cf1a82
      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>
      [ kamal: backported to 3.13:
        - dropped changes to smk_ptrace_rule_check()
        - applied same change to smack_ptrace_traceme() ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      42cf1a82
    • Jeff Moyer's avatar
      cfq-iosched: fix incorrect filing of rt async cfqq · dbc50524
      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 avatarKamal Mostafa <kamal@canonical.com>
      dbc50524
    • Dmitry Tunin's avatar
      Bluetooth: ath3k: Add support of AR3012 bluetooth 13d3:3423 device · 17c1ab7d
      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 avatarKamal Mostafa <kamal@canonical.com>
      17c1ab7d
    • Lokesh Vutla's avatar
      ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 · 00ee6e2d
      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 avatarKamal Mostafa <kamal@canonical.com>
      00ee6e2d
    • Krzysztof Kozlowski's avatar
      power: bq24190: Fix ignored supplicants · 3a88494a
      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 avatarKamal Mostafa <kamal@canonical.com>
      3a88494a
    • Eyal Shapira's avatar
      iwlwifi: mvm: validate tid and sta_id in ba_notif · db811ab3
      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 avatarKamal Mostafa <kamal@canonical.com>
      db811ab3
    • Jisheng Zhang's avatar
      mmc: sdhci-pxav3: fix unbalanced clock issues during probe · d682ca99
      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>
      [ kamal: backport to 3.13-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      d682ca99
    • Christophe Ricard's avatar
      tpm/tpm_i2c_stm_st33: Add status check when reading data on the FIFO · 11197718
      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>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      11197718
    • Christophe Ricard's avatar
      tpm/tpm_i2c_stm_st33: Fix potential bug in tpm_stm_i2c_send · 78f9e166
      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 avatarKamal Mostafa <kamal@canonical.com>
      78f9e166
    • Hon Ching (Vicky) Lo's avatar
      tpm: Fix NULL return in tpm_ibmvtpm_get_desired_dma · 06330826
      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 avatarKamal Mostafa <kamal@canonical.com>
      06330826
    • Scot Doyle's avatar
      tpm_tis: verify interrupt during init · a117c75f
      Scot Doyle authored
      commit 448e9c55 upstream.
      
      Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
      not send IRQs while also having an ACPI TPM entry indicating that they
      will be sent. These machines freeze on resume while the tpm_tis module
      waits for an IRQ, eventually timing out.
      
      When in interrupt mode, the tpm_tis module should receive an IRQ during
      module init. Fall back to polling mode if none is received when expected.
      Signed-off-by: default avatarScot Doyle <lkml14@scotdoyle.com>
      Tested-by: default avatarMichael Mullin <masmullin@gmail.com>
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      [phuewe: minor checkpatch fixed]
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      a117c75f
    • Kiran Padwal's avatar
      char: tpm: Add missing error check for devm_kzalloc · 1daee728
      Kiran Padwal authored
      commit bb95cd34 upstream.
      
      Currently these driver are missing a check on the return value of devm_kzalloc,
      which would cause a NULL pointer dereference in a OOM situation.
      
      This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c
      Signed-off-by: default avatarKiran Padwal <kiran.padwal@smartplayin.com>
      Reviewed-By: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      1daee728
    • David Howells's avatar
      TPM: Add new TPMs to the tail of the list to prevent inadvertent change of dev · ea2f92b4
      David Howells authored
      commit 398a1e71 upstream.
      
      Add newly registered TPMs to the tail of the list, not the beginning, so that
      things that are specifying TPM_ANY_NUM don't find that the device they're
      using has inadvertently changed.  Adding a second device would break IMA, for
      instance.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      ea2f92b4
    • Calvin Owens's avatar
      ksoftirqd: Enable IRQs and call cond_resched() before poking RCU · 436955d7
      Calvin Owens authored
      commit 28423ad2 upstream.
      
      While debugging an issue with excessive softirq usage, I encountered the
      following note in commit 3e339b5d ("softirq: Use hotplug thread
      infrastructure"):
      
          [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]
      
      ...but despite this note, the patch still calls RCU with IRQs disabled.
      
      This seemingly innocuous change caused a significant regression in softirq
      CPU usage on the sending side of a large TCP transfer (~1 GB/s): when
      introducing 0.01% packet loss, the softirq usage would jump to around 25%,
      spiking as high as 50%. Before the change, the usage would never exceed 5%.
      
      Moving the call to rcu_note_context_switch() after the cond_sched() call,
      as it was originally before the hotplug patch, completely eliminated this
      problem.
      Signed-off-by: default avatarCalvin Owens <calvinowens@fb.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      436955d7
    • Matthew Wilcox's avatar
      axonram: Fix bug in direct_access · 9f3b2d00
      Matthew Wilcox authored
      commit 91117a20 upstream.
      
      The 'pfn' returned by axonram was completely bogus, and has been since
      2008.
      Signed-off-by: default avatarMatthew Wilcox <matthew.r.wilcox@intel.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9f3b2d00
    • Cyrille Pitchen's avatar
      tty/serial: at91: fix error handling in atmel_serial_probe() · 2e49aa5a
      Cyrille Pitchen authored
      commit 6fbb9bdf upstream.
      
      -EDEFER error wasn't handle properly by atmel_serial_probe().
      As an example, when atmel_serial_probe() is called for the first time, we pass
      the test_and_set_bit() test to check whether the port has already been
      initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
      returned before by clk_get(). Consequently atmel_serial_probe() used to return
      this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
      When atmel_serial_probe() was called for the second time, it used to fail on
      the test_and_set_bit() function then returning -EBUSY.
      
      When atmel_serial_probe() fails, this patch make it clear the port bit in the
      "atmel_ports_in_use" mask, if needed, before returning the error code.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      2e49aa5a
    • Cyrille Pitchen's avatar
      tty/serial: at91: enable peripheral clock before accessing I/O registers · 0f241a9b
      Cyrille Pitchen authored
      commit d4f64187 upstream.
      
      atmel_serial_probe() calls atmel_init_port(). In turn, atmel_init_port() calls
      clk_disable_unprepare() to disable the peripheral clock before returning.
      
      Later atmel_serial_probe() accesses some I/O registers such as the Mode and
      Control registers for RS485 support then the Name and Version registers, through a call to
      atmel_get_ip_name(), but at that moment the peripheral clock was still
      disabled.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0f241a9b
    • Sebastian Andrzej Siewior's avatar
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 96a1a088
      Sebastian Andrzej Siewior authored
      commit 5efd2ea8 upstream.
      
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      96a1a088
    • Ricardo Ribalda Delgado's avatar
      PCI: Generate uppercase hex for modalias var in uevent · 67907af4
      Ricardo Ribalda Delgado authored
      commit 145b3fe5 upstream.
      
      Some implementations of modprobe fail to load the driver for a PCI device
      automatically because the "interface" part of the modalias from the kernel
      is lowercase, and the modalias from file2alias is uppercase.
      
      The "interface" is the low-order byte of the Class Code, defined in PCI
      r3.0, Appendix D.  Most interface types defined in the spec do not use
      alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
      20h, etc. are unaffected.
      
      Print the "interface" byte of the Class Code in uppercase hex, as we
      already do for the Vendor ID, Device ID, Class, etc.
      
      Commit 89ec3dcf ("PCI: Generate uppercase hex for modalias interface
      class") fixed only half of the problem.  Some udev implementations rely on
      the uevent file and not the modalias file.
      
      Fixes: d1ded203 ("PCI: add MODALIAS to hotplug event for pci devices")
      Fixes: 89ec3dcf ("PCI: Generate uppercase hex for modalias interface class")
      Signed-off-by: default avatarRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      67907af4
    • Sumit.Saxena@avagotech.com's avatar
      megaraid_sas: disable interrupt_mask before enabling hardware interrupts · 909d2644
      Sumit.Saxena@avagotech.com authored
      commit c2ced171 upstream.
      
      Update driver "mask_interrupts" before enable/disable hardware interrupt
      in order to avoid missing interrupts because of "mask_interrupts" still
      set to 1 and hardware interrupts are enabled.
      Signed-off-by: default avatarSumit Saxena <sumit.saxena@avagotech.com>
      Signed-off-by: default avatarChaitra Basappa <chaitra.basappa@avagotech.com>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      909d2644
    • Jiri Kosina's avatar
      HID: fixup the conflicting keyboard mappings quirk · 24cc9001
      Jiri Kosina authored
      commit 8e7b3410 upstream.
      
      The ignore check that got added in 6ce901eb ("HID: input: fix confusion
      on conflicting mappings") needs to properly check for VARIABLE reports
      as well (ARRAY reports should be ignored), otherwise legitimate keyboards
      might break.
      
      Fixes: 6ce901eb ("HID: input: fix confusion on conflicting mappings")
      Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Reported-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      24cc9001
    • David Herrmann's avatar
      HID: input: fix confusion on conflicting mappings · 0738e7b9
      David Herrmann authored
      commit 6ce901eb upstream.
      
      On an PC-101/103/104 keyboard (American layout) the 'Enter' key and its
      neighbours look like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |   5   |
                 +---+ +---+ +-------+
                   +---+ +-----------+
                   | 3 | |     4     |
                   +---+ +-----------+
      
      On a PC-102/105 keyboard (European layout) it looks like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |       |
                 +---+ +---+ +-+  4  |
                   +---+ +---+ |     |
                   | 3 | | 5 | |     |
                   +---+ +---+ +-----+
      
      (Note that the number of keys is the same, but key '5' is moved down and
       the shape of key '4' is changed. Keys '1' to '3' are exactly the same.)
      
      The keys 1-4 report the same scan-code in HID in both layouts, even though
      the keysym they produce is usually different depending on the XKB-keymap
      used by user-space.
      However, key '5' (US 'backslash'/'pipe') reports 0x31 for the upper layout
      and 0x32 for the lower layout, as defined by the HID spec. This is highly
      confusing as the linux-input API uses a single keycode for both.
      
      So far, this was never a problem as there never has been a keyboard with
      both of those keys present at the same time. It would have to look
      something like this:
      
                 +---+ +---+ +-------+
                 | 1 | | 2 | |  x31  |
                 +---+ +---+ +-------+
                   +---+ +---+ +-----+
                   | 3 | |x32| |  4  |
                   +---+ +---+ +-----+
      
      HID can represent such a keyboard, but the linux-input API cannot.
      Furthermore, any user-space mapping would be confused by this and,
      luckily, no-one ever produced such hardware.
      
      Now, the HID input layer fixed this mess by mapping both 0x31 and 0x32 to
      the same keycode (KEY_BACKSLASH==0x2b). As only one of both physical keys
      is present on a hardware, this works just fine.
      
      Lets introduce hardware-vendors into this:
      ------------------------------------------
      
      Unfortunately, it seems way to expensive to produce a different device for
      American and European layouts. Therefore, hardware-vendors put both keys,
      (0x31 and 0x32) on the same keyboard, but only one of them is hooked up
      to the physical button, the other one is 'dead'.
      This means, they can use the same hardware, with a different button-layout
      and automatically produce the correct HID events for American *and*
      European layouts. This is unproblematic for normal keyboards, as the
      'dead' key will never report any KEY-DOWN events. But RollOver keyboards
      send the whole matrix on each key-event, allowing n-key roll-over mode.
      This means, we get a 0x31 and 0x32 event on each key-press. One of them
      will always be 0, the other reports the real state. As we map both to the
      same keycode, we will get spurious key-events, even though the real
      key-state never changed.
      
      The easiest way would be to blacklist 'dead' keys and never handle those.
      We could simply read the 'country' tag of USB devices and blacklist either
      key according to the layout. But... hardware vendors... want the same
      device for all countries and thus many of them set 'country' to 0 for all
      devices. Meh..
      
      So we have to deal with this properly. As we cannot know which of the keys
      is 'dead', we either need a heuristic and track those keys, or we simply
      make use of our value-tracking for HID fields. We simply ignore HID events
      for absolute data if the data didn't change. As HID tracks events on the
      HID level, we haven't done the keycode translation, yet. Therefore, the
      'dead' key is tracked independently of the real key, therefore, any events
      on it will be ignored.
      
      This patch simply discards any HID events for absolute data if it didn't
      change compared to the last report. We need to ignore relative and
      buffered-byte reports for obvious reasons. But those cannot be affected by
      this bug, so we're fine.
      
      Preferably, we'd do this filtering on the HID-core level. But this might
      break a lot of custom drivers, if they do not follow the HID specs.
      Therefore, we do this late in hid-input just before we inject it into the
      input layer (which does the exact same filtering, but on the keycode
      level).
      
      If this turns out to break some devices, we might have to limit filtering
      to EV_KEY events. But lets try to do the Right Thing first, and properly
      filter any absolute data that didn't change.
      
      This patch is tagged for 'stable' as it fixes a lot of n-key RollOver
      hardware. We might wanna wait with backporting for a while, before we know
      it doesn't break anything else, though.
      Reported-by: default avatarAdam Goode <adam@spicenitz.org>
      Reported-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Tested-by: default avatarFredrik Hallenberg <megahallon@gmail.com>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      0738e7b9