1. 09 Jan, 2019 1 commit
  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
  16. 25 Jul, 2014 1 commit
    • Federico Vaga's avatar
      tools: include specific Makefile · 728fa03a
      Federico Vaga authored
      Sometimes (expecially in cross-compilation context) t is necessary to use
      different environments. Instead of complicate this makefile, include
      an external one with user code.
      
      Create a local file named Makefile.specific, and write here your code.
      Bear in mind that Makefile.specific will run before the Makefile.
      Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
      728fa03a
  17. 23 Jul, 2014 2 commits
    • Federico Vaga's avatar
      Merge branch 'jdgl-140206' · 5ae8bfe3
      Federico Vaga authored
          Note by Federico Vaga <federico.vaga@cern.ch>
              This is not exactly the same set of patches from
              garcialasheras <javier@garcialasheras.com>. I did few modification
              in order to:
      
              - do not introduce new dependecies. Vendor and Device ID are constant
                for life, so we can safely write them two times and avoid a file
                dependencies between kernel and userspace code.
      
              - squash FIX patches in 1d8bb157. There were consecutive patches where
                the FIX patch just fix the previous patch, so squash them. This will
                produce an useful git-blame and bit-bisect
      
              - una patch for each behavioral modification
      5ae8bfe3
    • Federico Vaga's avatar
      774e8734