1. 10 Feb, 2016 4 commits
  2. 01 Dec, 2015 1 commit
  3. 30 Nov, 2015 1 commit
  4. 20 Nov, 2015 3 commits
  5. 13 Nov, 2015 13 commits
  6. 25 Aug, 2015 1 commit
  7. 07 May, 2015 2 commits
  8. 27 Apr, 2015 1 commit
  9. 20 Apr, 2015 3 commits
  10. 24 Feb, 2015 1 commit
    • Federico Vaga's avatar
      wr-nic-gpio: do not check on gpiochip_remove · 2b85fda2
      Federico Vaga authored
      Since kernel 3.18 the gpiochip_remove function return void and not an
      error code as before. In case the gpiochip is removed while there is a
      requested gpio, the kernel will print an error message.
      
      By applying this patch without any control on the kernel version we are
      going to loose the error message in case of trouble with old kernels
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      2b85fda2
  11. 20 Jan, 2015 1 commit
  12. 18 Sep, 2014 1 commit
  13. 13 Aug, 2014 5 commits
  14. 07 Aug, 2014 1 commit
    • Federico Vaga's avatar
      kernel: fix deadlock on fmc->irq_request(), improve comments · 9ae2ee65
      Federico Vaga authored
      With some kernel configuration the previous locking policy can
      generate a deadlock on the spec->irq_lock spinlock.
      
      For example, this will happen sistematically if the option
      CONFIG_DEBUG_SHIRQ_FIXME is enabled. In this case, the handler
      is called immediatly an it is not a separeted thread.
      
      This patch move out from the locking section what doesn't need
      protection and is 'cause' of the deadlock.
      
      The deadlock was introduced with patch d4bbcc73 by using a large
      locking section. In realty the PCI request_irq is protected
      anyway thanks to the proctection of the variable 'first_time' and
      the 'spec_vic_irq_request' function.
      
      [more explaination about patch d4bbcc73]
      The purpose of that patch was to protect the initialization of
      the first VIC handler and the release of the last one. It was
      happening that while we are releasing the last VIC handler,
      some one was registering a new one but the spec->vic is still there.
      The result was that sometimes the PCI handler was removed
      (last VIC handler) but not re-requested for the incoming request.
      Signen-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      9ae2ee65
  15. 01 Aug, 2014 2 commits