netdev - Re: [PATCH net-next v3 0/7] net: aquantia: implement WOL and EEE support

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]

Message-Id: <20180911.234820.1747706577550366387.davem@davemloft.net>
Date:   Tue, 11 Sep 2018 23:48:20 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     igor.russkikh@...antia.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 0/7] net: aquantia: implement WOL and EEE
 support

From: Igor Russkikh <igor.russkikh@...antia.com>
Date: Mon, 10 Sep 2018 12:39:27 +0300

> This is v3 of WOL/EEE functionality patch for atlantic driver.
> 
> In this patchset Yana Esina and Nikita Danilov implemented:
> 
> - Upload function to interact with FW memory
> - Definitions and structures necessary for the correct operation of Wake ON Lan
> - The functionality Wake On Lan via ethtool (Magic packet is supported)
> - The functionality for Energy-Efficient Ethernet configuration via ethtool
> 
> Version 3:
> - use ETH_ALEN instead of raw number
> 
> Version 2 has the following fixes:
> - patchset reorganized to extract renaming and whitespace fixes into separate
>   patches
> - some of magic numbers replaced with defines
> - reverse christmas tree applied

Series applied, thanks.

> Discussion outcome regarding driver version bumps was not finished
> (here https://patchwork.ozlabs.org/patch/954905/)
> David, could you suggest the best way to proceed on this?

Having a channel for your driver that is outside of upstream and Linux
distribution packages creates lots of problems.

When a user reports a problem with an upstream kernel, that verion
dictates which driver source was being used.  There is not confusion
or ambiguity.

For a distribution kernel, the distributor hashes out which driver
they published in their kernel package when evaluating a bug reported
to them.

None of these two entities is ready to evaluate and handle properly
your custom scheme.

So generally I frown against separate distribution schemes.  It is
in the final analysis an inferior experience for the user because
you basically narrow all of their support channels for problems
down to you and you alone.  The whole idea is to make it work the
opposite way.

So in the upstream tree, really, the driver version is pretty useless.