netdev - Re: [PATCH net-next 4/8] net/funeth: ethtool operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Dec 2021 12:56:09 -0800
From:   Dimitris Michailidis <d.michailidis@...gible.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>, davem@...emloft.net,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 4/8] net/funeth: ethtool operations

On Thu, Dec 30, 2021 at 12:43 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 30 Dec 2021 12:30:34 -0800 Dimitris Michailidis wrote:
> > On Thu, Dec 30, 2021 at 12:22 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > > On Thu, 30 Dec 2021 19:04:08 +0100 Andrew Lunn wrote:
> > > > > +static void fun_get_drvinfo(struct net_device *netdev,
> > > > > +                       struct ethtool_drvinfo *info)
> > > > > +{
> > > > > +   const struct funeth_priv *fp = netdev_priv(netdev);
> > > > > +
> > > > > +   strscpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
> > > > > +   strcpy(info->fw_version, "N/A");
> > > >
> > > > Don't set it, if you have nothing useful to put in it.
> > >
> > > Also, if user has no way of reading the firmware version how do they
> > > know when to update the FW in the flash? FW flashing seems pointless
> > > without knowing the current FW version.
> >
> > It will be available, but FW hasn't settled on the API for it yet.
> > There are several FW images on the devices, one will be reported here but
> > will rely on devlink for the full set.
>
> Can we defer the FW flashing to that point as well, then?
> It's always a bit risky to add support for subset of functionality
> upstream given the strict backward compat requirements.

Sure, I'll cut out the bulk of the devlink file.