[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191105134858.5d0ffc14@cakuba.netronome.com>
Date: Tue, 5 Nov 2019 13:48:58 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Ido Schimmel <idosch@...sch.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, jiri@...lanox.com,
shalomt@...lanox.com, mlxsw@...lanox.com,
Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next 0/6] mlxsw: Add extended ACK for EMADs
On Tue, 5 Nov 2019 22:48:26 +0200, Ido Schimmel wrote:
> On Tue, Nov 05, 2019 at 09:54:48AM -0800, Jakub Kicinski wrote:
> > 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.
>
> > 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".
Powered by blists - more mailing lists