diff options
author | Salil Mehta <salil.mehta@huawei.com> | 2018-03-22 14:28:54 +0000 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-03-22 15:29:03 -0400 |
commit | 436667d2e1793995267915d2562f7b14f26c1f63 (patch) | |
tree | 3395a065e9bfbd4c01596aa90755603ce4063271 /arch/sparc/vdso/vdso2c.h | |
parent | 35a1e50343bdae07bffe911e2d9f7e825fafe4f1 (diff) |
net: hns3: Add VF Reset device state and its handling
This introduces the hclge device reset states of "requested" and
"pending" and also its handling in context to Reset Service Task.
Device gets into requested state because of any VF reset request
asserted from upper layers, for example due to watchdog timeout
expiration. Requested state would result in eventually forwarding
the VF reset request to PF which would actually reset the VF.
Device will get into pending state if:
1. VF receives the acknowledgement from PF for the VF reset
request it originally sent to PF.
2. Reset Service Task detects that after asserting VF reset for
certain times the data-path is not working and device then
decides to assert full VF reset(this means also resetting the
PCIe interface).
3. PF intimates the VF that it has undergone reset.
Pending state would result in VF to poll for hardware reset
completion status and then resetting the stack/enet layer, which
in turn means reinitializing the ring management/enet layer.
Note: we would be adding support of 3. later as a separate patch.
This decision should not affect VF reset as its event handling
is generic in nature.
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/sparc/vdso/vdso2c.h')
0 files changed, 0 insertions, 0 deletions