Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid
board:
Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200
pgd = ddecc000
[e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453
Internal error: : 1008 [#1] SMP ARM
...
Reason of OOPS is that fec_enet_get_ethtool_stats() accesses fec
registers while IPG clock is stopped by PM.
Fix that by wrapping statistics extraction into pm_runtime_get_sync()
... pm_runtime_put_autosuspend() braces.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec_main.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
+ int i, ret;
+
+ ret = pm_runtime_get_sync(&fep->pdev->dev);
+ if (IS_ERR_VALUE(ret)) {
+ memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats));
+ return;
+ }
This really isn't the way to do this.
When the device is suspended and the clocks are going to be stopped,
you must fetch the statistic values into a software copy and provide
those if the device is suspended when statistics are requested.
+ int i, ret;
+
+ ret = pm_runtime_get_sync(&fep->pdev->dev);
+ if (IS_ERR_VALUE(ret)) {
+ memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats));
+ return;
+ }
This really isn't the way to do this.
When the device is suspended and the clocks are going to be stopped,
you must fetch the statistic values into a software copy and provide
those if the device is suspended when statistics are requested.
Ok, can do that, although can't see what's wrong with waking device
here. The situation of requesting stats on down device isn't something
widely used, thus keeping handling of that as local as possible looks
better for me.
+ int i, ret;
+
+ ret = pm_runtime_get_sync(&fep->pdev->dev);
+ if (IS_ERR_VALUE(ret)) {
+ memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats));
+ return;
+ }
This really isn't the way to do this.
When the device is suspended and the clocks are going to be stopped,
you must fetch the statistic values into a software copy and provide
those if the device is suspended when statistics are requested.
Ok, can do that, although can't see what's wrong with waking device
here. The situation of requesting stats on down device isn't something
widely used, thus keeping handling of that as local as possible looks
better for me.
The issue is the fact that you need error handling at all and might
therefore provide a set of zero stats to the user when that entire
possibility could have been avoided in the first place by recording
the stats at suspend time.