1. 03 Jun, 2017 7 commits
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: clear the latched status of the interrupt · cee0fad7
      Abhijeet Dharmapurikar authored
      PMIC interrupts each have an internal latched status bit which is
      not visible from any register.  This status bit is set as soon as
      the conditions specified in the interrupt type and polarity
      registers are met even if the interrupt is not enabled.  When it
      is set, nothing else changes within the PMIC and no interrupt
      notification packets are sent.  If the internal latched status
      bit is set when an interrupt is enabled, then the value is
      immediately propagated into the interrupt latched status register
      and an interrupt notification packet is sent out from the PMIC
      over SPMI.
      
      This PMIC hardware behavior can lead to a situation where the
      handler for a level triggered interrupt is called immediately
      after enable_irq() is called even though the interrupt physically
      triggered while it was disabled within the genirq framework.
      This situation takes place if the the interrupt fires twice after
      calling disable_irq().  The first time it fires, the level flow
      handler will mask and disregard it.  Unfortunately, the second
      time it fires, the internal latched status bit is set within the
      PMIC and no further notification is received.  When enable_irq()
      is called later, the interrupt is unmasked (enabled in the PMIC)
      which results in the PMIC immediately sending an interrupt
      notification packet out over SPMI.  This breaks the semantics
      of level triggered interrupts within the genirq framework since
      they should be completely ignored while disabled.
      
      The PMIC internal latched status behavior also affects how
      interrupts are treated during suspend.  While entering suspend,
      all interrupts not specified as wakeup mode are masked.  Upon
      resume, these interrupts are unmasked.  Thus if any of the
      non-wakeup PMIC interrupts fired while the system was suspended,
      then the PMIC will send interrupt notification packets out via
      SPMI as soon as they are unmasked during resume.  This behavior
      violates genirq semantics as well since non-wakeup interrupts
      should be completely ignored during suspend.
      
      Modify the qpnpint_irq_unmask() function so that the interrupt
      latched status clear register is written immediately before the
      interrupt enable register.  This clears the internal latched
      status bit of the interrupt so that it cannot trigger spuriously
      immediately upon being enabled.
      
      Also, while resuming an irq, an unmask could be called even if it
      was not previously masked.  So, before writing these registers,
      check if the interrupt is already enabled within the PMIC. If it
      is, then no further register writes are required.  This
      condition check ensures that a valid latched status register bit
      is not cleared until it is properly handled.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cee0fad7
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: fix missing interrupts · f6dda8e2
      Abhijeet Dharmapurikar authored
      irq_enable is called when the device resumes. Note that the
      irq_enable is called regardless of whether the interrupt was
      marked enabled/disabled in the descriptor or whether it was
      masked/unmasked at the controller while resuming.
      
      The current driver unconditionally clears the interrupt in its
      irq_enable callback. This is dangerous as any interrupts that
      happen right before the resume could be missed.
      Remove the irq_enable callback and use mask/unmask instead.
      
      Also remove struct pmic_arb_irq_spec as it serves no real purpose.
      It is used only in the translate function and the code is much
      cleaner without it.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6dda8e2
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: cleanup unrequested irqs · 6bc546e7
      Abhijeet Dharmapurikar authored
      We see a unmapped irqs trigger right around bootup. This could
      likely be because the bootloader exited leaving the interrupts
      in an unknown or unhandled state.  Ack and mask the interrupt
      if one is found. A request_irq later will unmask it and also
      setup proper mapping structures.
      
      Also the current driver ensures that no read/write transaction
      is in progress while it makes changes to the interrupt regions.
      This is not necessary because read/writes over spmi and arbiter
      interrupt control are independent operations. Hence, remove the
      synchronized accesses to interrupt region.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bc546e7
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: optimize table lookups · 7f1d4e58
      Abhijeet Dharmapurikar authored
      The current driver uses a mix of radix tree and a fwd lookup
      table to translate between apid and ppid. It is buggy and confusing.
      
      Instead simply use a radix tree for v1 hardware and use the
      forward lookup table for v2.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f1d4e58
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: fix inconsistent use of apid and chan · 1ef1ce4e
      Abhijeet Dharmapurikar authored
      The driver currently uses "apid" and "chan" to mean apid. Remove
      the use of chan and use only apid.
      
      On a SPMI bus there is allocation to manage up to 4K peripherals.
      However, in practice only few peripherals are instantiated
      and only few among the instantiated ones actually interrupt.
      
      APID is CPU's way of keeping track of peripherals that could interrupt.
      There is a table that maps the 256 interrupting peripherals to
      a number between 0 and 255. This number is called APID. Information about
      that interrupting peripheral is stored in registers offset by its
      corresponding apid.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ef1ce4e
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic-arb: rename spmi_pmic_arb_dev to spmi_pmic_arb · 111a10bf
      Abhijeet Dharmapurikar authored
      Usually *_dev best used for structures that embed a struct device in
      them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data
      structure. Use an appropriate name for it.
      
      Also there are many places in the driver that left shift the bit to
      generate a bit mask. Replace it with the BIT() macro.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      111a10bf
    • Abhijeet Dharmapurikar's avatar
      spmi: pmic_arb: block access of invalid read and writes · 57102ad7
      Abhijeet Dharmapurikar authored
      The system crashes due to bad access when reading from an non configured
      peripheral and when writing to peripheral which is not owned by current
      ee. This patch verifies ownership to avoid crashing on
      write.
      For reads, since the forward mapping table, data_channel->ppid, is
      towards the end of the block, we use the core size to figure the
      max number of ppids supported. The table starts at an offset of 0x800
      within the block, so size - 0x800 will give us the area used by the
      table. Since each table is 4 bytes long (core_size - 0x800) / 4 will
      gives us the number of data_channel supported.
      This new protection is functional on hw v2.
      Signed-off-by: default avatarAbhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: default avatarKiran Gunda <kgunda@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      57102ad7
  2. 27 May, 2017 1 commit
  3. 25 May, 2017 18 commits
  4. 22 May, 2017 3 commits
    • Greg Kroah-Hartman's avatar
      Merge 4.12-rc2 into char-misc-next · b4a338d2
      Greg Kroah-Hartman authored
      We want the fixes in here as well to handle merge issues.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4a338d2
    • Linus Torvalds's avatar
      Linux 4.12-rc2 · 08332893
      Linus Torvalds authored
      08332893
    • Linus Torvalds's avatar
      x86: fix 32-bit case of __get_user_asm_u64() · 33c9e972
      Linus Torvalds authored
      The code to fetch a 64-bit value from user space was entirely buggered,
      and has been since the code was merged in early 2016 in commit
      b2f68038 ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit
      kernels").
      
      Happily the buggered routine is almost certainly entirely unused, since
      the normal way to access user space memory is just with the non-inlined
      "get_user()", and the inlined version didn't even historically exist.
      
      The normal "get_user()" case is handled by external hand-written asm in
      arch/x86/lib/getuser.S that doesn't have either of these issues.
      
      There were two independent bugs in __get_user_asm_u64():
      
       - it still did the STAC/CLAC user space access marking, even though
         that is now done by the wrapper macros, see commit 11f1a4b9
         ("x86: reorganize SMAP handling in user space accesses").
      
         This didn't result in a semantic error, it just means that the
         inlined optimized version was hugely less efficient than the
         allegedly slower standard version, since the CLAC/STAC overhead is
         quite high on modern Intel CPU's.
      
       - the double register %eax/%edx was marked as an output, but the %eax
         part of it was touched early in the asm, and could thus clobber other
         inputs to the asm that gcc didn't expect it to touch.
      
         In particular, that meant that the generated code could look like
         this:
      
              mov    (%eax),%eax
              mov    0x4(%eax),%edx
      
         where the load of %edx obviously was _supposed_ to be from the 32-bit
         word that followed the source of %eax, but because %eax was
         overwritten by the first instruction, the source of %edx was
         basically random garbage.
      
      The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark
      the 64-bit output as early-clobber to let gcc know that no inputs should
      alias with the output register.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@kernel.org   # v4.8+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      33c9e972
  5. 21 May, 2017 7 commits
    • Linus Torvalds's avatar
      Clean up x86 unsafe_get/put_user() type handling · 334a023e
      Linus Torvalds authored
      Al noticed that unsafe_put_user() had type problems, and fixed them in
      commit a7cc722f ("fix unsafe_put_user()"), which made me look more
      at those functions.
      
      It turns out that unsafe_get_user() had a type issue too: it limited the
      largest size of the type it could handle to "unsigned long".  Which is
      fine with the current users, but doesn't match our existing normal
      get_user() semantics, which can also handle "u64" even when that does
      not fit in a long.
      
      While at it, also clean up the type cast in unsafe_put_user().  We
      actually want to just make it an assignment to the expected type of the
      pointer, because we actually do want warnings from types that don't
      convert silently.  And it makes the code more readable by not having
      that one very long and complex line.
      
      [ This patch might become stable material if we ever end up back-porting
        any new users of the unsafe uaccess code, but as things stand now this
        doesn't matter for any current existing uses. ]
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      334a023e
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · f3926e4c
      Linus Torvalds authored
      Pull misc uaccess fixes from Al Viro:
       "Fix for unsafe_put_user() (no callers currently in mainline, but
        anyone starting to use it will step into that) + alpha osf_wait4()
        infoleak fix"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        osf_wait4(): fix infoleak
        fix unsafe_put_user()
      f3926e4c
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 970c305a
      Linus Torvalds authored
      Pull scheduler fix from Thomas Gleixner:
       "A single scheduler fix:
      
        Prevent idle task from ever being preempted. That makes sure that
        synchronize_rcu_tasks() which is ignoring idle task does not pretend
        that no task is stuck in preempted state. If that happens and idle was
        preempted on a ftrace trampoline the machine crashes due to
        inconsistent state"
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/core: Call __schedule() from do_idle() without enabling preemption
      970c305a
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e7a3d627
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A set of small fixes for the irq subsystem:
      
         - Cure a data ordering problem with chained interrupts
      
         - Three small fixlets for the mbigen irq chip"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        genirq: Fix chained interrupt data ordering
        irqchip/mbigen: Fix the clear register offset calculation
        irqchip/mbigen: Fix potential NULL dereferencing
        irqchip/mbigen: Fix memory mapping code
      e7a3d627
    • Al Viro's avatar
      osf_wait4(): fix infoleak · a8c39544
      Al Viro authored
      failing sys_wait4() won't fill struct rusage...
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a8c39544
    • Al Viro's avatar
      fix unsafe_put_user() · a7cc722f
      Al Viro authored
      __put_user_size() relies upon its first argument having the same type as what
      the second one points to; the only other user makes sure of that and
      unsafe_put_user() should do the same.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a7cc722f
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 56f410cf
      Linus Torvalds authored
      Pull tracing fixes from Steven Rostedt:
      
       - Fix a bug caused by not cleaning up the new instance unique triggers
         when deleting an instance. It also creates a selftest that triggers
         that bug.
      
       - Fix the delayed optimization happening after kprobes boot up self
         tests being removed by freeing of init memory.
      
       - Comment kprobes on why the delay optimization is not a problem for
         removal of modules, to keep other developers from searching that
         riddle.
      
       - Fix another case of rcu not watching in stack trace tracing.
      
      * tag 'trace-v4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Make sure RCU is watching before calling a stack trace
        kprobes: Document how optimized kprobes are removed from module unload
        selftests/ftrace: Add test to remove instance with active event triggers
        selftests/ftrace: Fix bashisms
        ftrace: Remove #ifdef from code and add clear_ftrace_function_probes() stub
        ftrace/instances: Clear function triggers when removing instances
        ftrace: Simplify glob handling in unregister_ftrace_function_probe_func()
        tracing/kprobes: Enforce kprobes teardown after testing
        tracing: Move postpone selftests to core from early_initcall
      56f410cf
  6. 20 May, 2017 4 commits