#
17e9157c |
| 07-Jun-2022 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
nfp: Remove kernel.h when not needed
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved.
Remove kernel.h when it i
nfp: Remove kernel.h when not needed
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved.
Remove kernel.h when it is not needed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220607125103.487801-1-simon.horman@corigine.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
96de2506 |
| 11-Oct-2018 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: replace long license headers with SPDX
Replace the repeated license text with SDPX identifiers. While at it bump the Copyright dates for files we touched this year.
Signed-off-by: Edwin Peer <
nfp: replace long license headers with SPDX
Replace the repeated license text with SDPX identifiers. While at it bump the Copyright dates for files we touched this year.
Signed-off-by: Edwin Peer <edwin.peer@netronome.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Nic Viljoen <nick.viljoen@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
f01a2161 |
| 09-Feb-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
nfp: add support for resources
Resource table is an array placed in a well defined location in device's memory which describes device resources and contains locks which have to be acquired to use th
nfp: add support for resources
Resource table is an array placed in a well defined location in device's memory which describes device resources and contains locks which have to be acquired to use them.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|