1. 14 Jul, 2016 1 commit
    • Viresh Kumar's avatar
      greybus: es2: Fix 'make check' warnings with arpc · e818027c
      Viresh Kumar authored
      This is what I got:
      
      greybus/es2.c:1130:29: warning: restricted __le16 degrades to integer
      greybus/es2.c:1140:22: warning: incorrect type in assignment (different base types)
      greybus/es2.c:1140:22:    expected restricted __le16 [usertype] id
      greybus/es2.c:1140:22:    got unsigned short [unsigned] [usertype] <noident>
      greybus/es2.c:1162:52: warning: incorrect type in argument 8 (different base types)
      greybus/es2.c:1162:52:    expected unsigned short [unsigned] [usertype] size
      greybus/es2.c:1162:52:    got restricted __le16 [usertype] size
      greybus/es2.c:1164:31: warning: restricted __le16 degrades to integer
      greybus/es2.c:1253:34: warning: incorrect type in argument 2 (different base types)
      greybus/es2.c:1253:34:    expected unsigned char [unsigned] [usertype] id
      greybus/es2.c:1253:34:    got restricted __le16 [usertype] id
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarJohan Hovold <johan@hovoldconsulting.com>
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      e818027c
  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 7 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
    • Johan Hovold's avatar
      greybus: Revert "connection: switch to using spin_lock_irqsave/spin_lock_irqrestore excluisvely" · a29bac62
      Johan Hovold authored
      This reverts commit 426237c515b42b9f06d9a2b1021a6d2c4d440c51.
      
      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>
      a29bac62
    • Sandeep Patil's avatar
      greybus: svc: remove input device handling in SVC protocol · 1beb1fae
      Sandeep Patil authored
      The input device was added before to handle the key(s) connected
      directly to SVC, which is not the case anymore. So, this change removes
      the gb_svc_key_event() operation and the corresponding input device
      code with it.
      
      Testing Done:
      Boot tested and tried module insert/removal through AraManager
      
      Change-Id: Iaa541d4aefb5c0ed16caaa39450029de35d7c228
      Signed-off-by: default avatarSandeep Patil <sspatil@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      1beb1fae
    • Viresh Kumar's avatar
      greybus: kernel_ver: Add kstrtobool() · 0ef5be18
      Viresh Kumar authored
      It was added in 4.6 and is required for one of the use case, copy it.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      0ef5be18
  7. 24 Jun, 2016 7 commits