- 17 Dec, 2019 2 commits
-
-
Federico Vaga authored
Signed-off-by:Federico Vaga <federico.vaga@cern.ch>
-
Federico Vaga authored
Signed-off-by:
-
- 17 Oct, 2019 2 commits
-
-
Federico Vaga authored
The following patch introduced a fix and a bug because I forgot to change the negation: 7b3d1da4 drv:gn412x_gpio: fix direction get/set Here we try to fix it, definitively. To check, do: cat /sys/kernel/debug/gpio Reported-by:
Dimitris Lampridis <dimitris.lampridis@cern.ch>
Signed-off-by: -
Federico Vaga authored
Signed-off-by:
-
- 16 Oct, 2019 1 commit
-
-
Federico Vaga authored
Reported-by:
Dimitris Lampridis <dimitris.lampridis@cern.ch>
Signed-off-by:
-
- 26 Sep, 2019 3 commits
-
-
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
why I added coccicheck does not need explanations install is to install the kernel, we need to do modules_install for kernel modules Signed-off-by:
-
- 23 Sep, 2019 8 commits
-
-
Federico Vaga authored
It looks like there is a bug somewhere that make the system panic on resource releasing. I can't provide any evidence that devm_* is related to the issue, but removing it seems to solve the problem (or at least is not as frequent as before: I can load/unload 100 times without problems). The problem was mitigated also by introducing delays (mdelay/printk) in the fcl/gpio remove functions. My guess is that MFD removal and devres clean up conflicts at some point. MFD uses platform_unregister() which does resource_release(), and because of devres, only after that we will release all resources that we took on probe(). The flow does not sound right, we should release resources we took **before** platform releases/remove the resource from the system (not viceversa). Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by:
-
- 11 Sep, 2019 2 commits
-
-
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by:
-
- 10 Sep, 2019 1 commit
-
-
Federico Vaga authored
Signed-off-by:
-
- 09 Sep, 2019 2 commits
-
-
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by:
-
- 04 Sep, 2019 1 commit
-
-
Federico Vaga authored
Signed-off-by:
-
- 03 Sep, 2019 1 commit
-
-
Federico Vaga authored
Signed-off-by:
-
- 02 Sep, 2019 17 commits
-
-
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Data is transfered in network order (big-endian), so we need to properly write/read TX/RX registers Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
Signed-off-by: -
Federico Vaga authored
The driver will validate this for each transfer. The Linux kernel mask is limited to 32bits transfers but actually this core is able to do upt to 128bits. Signed-off-by:
-
