1. 14 Jul, 2016 11 commits
  2. 13 Jul, 2016 3 commits
  3. 11 Jul, 2016 2 commits
  4. 08 Jul, 2016 10 commits
  5. 06 Jul, 2016 10 commits
  6. 29 Jun, 2016 4 commits
    • Viresh Kumar's avatar
      greybus: light: Initialize mutex before using it · 957ccca0
      Viresh Kumar authored
      Light protocol driver is suffering from the same issue that was fixed in
      camera driver earlier (commit a7c3b0c3c8da).
      
      Big cleanup function is used instead of fine grained control in the
      error path, and in one of the cases the mutex was found uninitialized
      and so the oops seen in SW-6752.
      
      Initialize the mutex before any code can access it.
      
      Compile tested only.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarRui Miguel Silva <rui.silva@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      957ccca0
    • Johan Hovold's avatar
      greybus: Revert "greybus: uart: don't use spin_lock_irq()" · 2aae92bd
      Johan Hovold authored
      This reverts commit bd3c4aa99dc23449699432e0744bcb5af7afa98c.
      
      Someone decided that all use of spin_lock_irq was to be considered a bug
      and went on a search-and-replace type "bug-fixing" spree last week.
      
      This is however just plain wrong. Using spin_lock_irq is perfectly fine
      in paths were interrupts have not been disabled, and this is in fact
      even preferred over the lazy approach of always using spin_lock_irqsave
      instead of understanding the code that is being written or modified.
      
      All current uses of spin_lock_irq have already been vetted in this
      respect. Also note that it is only used in functions that may sleep,
      that is, in functions that must not be called with interrupts disabled
      in the first place.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      2aae92bd
    • Johan Hovold's avatar
      greybus: Revert "greybus: es2.c: don't use spin_lock_irq()" · 07af9340
      Johan Hovold authored
      This reverts commit b44c3b5b0307788750eb4c462ed5982236876a8b.
      
      Someone decided that all use of spin_lock_irq was to be considered a bug
      and went on a search-and-replace type "bug-fixing" spree last week.
      
      This is however just plain wrong. Using spin_lock_irq is perfectly fine
      in paths were interrupts have not been disabled, and this is in fact
      even preferred over the lazy approach of always using spin_lock_irqsave
      instead of understanding the code that is being written or modified.
      
      All current uses of spin_lock_irq have already been vetted in this
      respect. Also note that it is only used in functions that may sleep,
      that is, in functions that must not be called with interrupts disabled
      in the first place.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      07af9340
    • Johan Hovold's avatar
      greybus: Revert "greybus: gb_connections_lock: don't use spin_lock_irq()" · 0b1d2623
      Johan Hovold authored
      This reverts commit b022fd95108e8b9d202532a74d39e86152bc8f7f.
      
      Someone decided that all use of spin_lock_irq was to be considered a bug
      and went on a search-and-replace type "bug-fixing" spree last week.
      
      This is however just plain wrong. Using spin_lock_irq is perfectly fine
      in paths were interrupts have not been disabled, and this is in fact
      even preferred over the lazy approach of always using spin_lock_irqsave
      instead of understanding the code that is being written or modified.
      
      All current uses of spin_lock_irq have already been vetted in this
      respect. Also note that it is only used in functions that may sleep,
      that is, in functions that must not be called with interrupts disabled
      in the first place.
      Signed-off-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      0b1d2623