Skip to content
Snippets Groups Projects
Select Git revision
12 results
Search by author
  • Any Author
  • Projects Projects orson_admin
  • Vasco Guita Vasco Guita vasco.guita
2 authors
  1. Oct 10, 2017
  3. Jun 27, 2017
  5. Feb 28, 2017
  7. Jul 17, 2016
    • Dimitris Lampridis's avatar
      kernel: fix kernel >4.4 compatibility · 4fb9a54c
      Dimitris Lampridis authored 
      
Compiling on kernel >=4.5 produces the following error:

  CC [M]  spec-sw/kernel/wr-nic-gpio.o
spec-sw/kernel/wr-nic-gpio.c: In function ‘gc_to_fmc’:
spec-sw/kernel/wr-nic-gpio.c:20:25: error: ‘struct gpio_chip’ has no member named ‘dev’
  struct device *dev = gc->dev;
                         ^
spec-sw/kernel/wr-nic-gpio.c: In function ‘wrn_gpio_init’:
spec-sw/kernel/wr-nic-gpio.c:75:4: error: ‘struct gpio_chip’ has no member named ‘dev’
  gc->dev = &fmc->dev;
    ^

This is due to a change in struct gpio_chip introduced in 4.5,
where the "dev" field was renamed to "parent".

58383c7 gpio: change member .dev to .parent

This patch makes our code compatible with modern kernel versions

Signed-off-by: default avatarFederico Vaga <federico.vaga@cern.ch>
Signed-off-by: default avatarDimitris Lampridis <Dimitris.Lampridis@cern.ch>
      4fb9a54c
  9. Mar 03, 2016
  11. Feb 10, 2016
  13. Nov 20, 2015
  15. Nov 13, 2015
  17. Aug 25, 2015
  19. May 07, 2015
  21. Feb 24, 2015
    • 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: default avatarFederico Vaga <federico.vaga@cern.ch>
      2b85fda2
  23. Jan 20, 2015
  25. Sep 18, 2014
  27. Aug 13, 2014
  29. Aug 07, 2014
    • 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: default avatarFederico Vaga <federico.vaga@cern.ch>
      9ae2ee65
  31. Aug 01, 2014
  33. Jul 14, 2014
  35. Jul 08, 2014