On Mon, 12 Apr 2021 15:26:00 -0500 Lijun Pan wrote: > On Mon, Apr 12, 2021 at 1:23 PM Jakub Kicinski <k...@kernel.org> wrote: > > On Mon, 12 Apr 2021 02:43:30 -0500 Lijun Pan wrote: > > > Add timeout and fatal reset sysfs entries so that both functions > > > can be triggered manually the tested. Otherwise, you have to run > > > the program for enough time and check both randomly generated > > > resets in the long long log. > > > > This looks more suitable for debugfs. > > > > But can't you use ethtool or devlink reset functionality somehow? > > ethtool and devlink reset seem better to be implemented by a FAILVOER reset > for > this driver. ethtool/devlink reset are not implemented in this driver, > which will be a todo list for me.
ethtool isn't really much to implement, its basically a bunch of ops the driver implements. You can pick and choose which ones you implement. It'd be better to use ethtool or devlink, but I guess debugfs could be acceptable too. sysfs is a stable API, so it's definitely a no-go. > This timeout reset can be triggered by tx watchdog, > .ndo_tx_timeout->ibmvnic_tx_timeout->ibmvnic_reset(adapter, > VNIC_RESET_TIMEOUT); > Do you know is there a way to trigger that ndo_tx_timeout from some > user space tool? > > The FATAL reset is triggered by Firmware, quite specific for this driver. > So in order to verify that, I put it in sysfs entry. Good question, I don't think we have a way to trigger the timeout in a generic way. My first instinct would be to use ethtool self test (ethtool_ops->self_test) to call the same function within the driver.
