Tue, Nov 05, 2019 at 10:48:58PM CET, jakub.kicinski@netronome.com wrote:

On Tue, 5 Nov 2019 22:48:26 +0200, Ido Schimmel wrote:

quoted

On Tue, Nov 05, 2019 at 09:54:48AM -0800, Jakub Kicinski wrote:

quoted

Hm, the firmware has no log that it keeps? Surely FW runs a lot of
periodic jobs etc which may encounter some error conditions, how do 
you deal with those?  

There are intrusive out-of-tree modules that can get this information.
It's currently not possible to retrieve this information from the
driver. We try to move away from such methods, but it can't happen
overnight. This set and the work done in the firmware team to add this
new TLV is one step towards that goal.

quoted

Bottom line is I don't like when data from FW is just blindly passed
to user space.  

The same information will be passed to user space regardless if you use
ethtool / devlink / printk.

Sure, but the additional hoop to jump through makes it clear that this
is discouraged and it keeps clear separation between the Linux
interfaces and proprietary custom FW.. "stuff".

Hmm, let me try to understand. So you basically have problem with
passing random FW generated data and putting it to user (via dmesg,
extack). However, ethtool dump is fine. Devlink health reporter is also
fine.

That is completely sufficient for async events/errors.
However in this case, we have MSG sent to fw which generates an ERROR
and this error is sent from FW back, as a reaction to this particular
message.

What do you suggest we should use in order to maintain the MSG-ERROR
pairing? Perhaps a separate devlink health reporter just for this?

What do you think?