[net-next,v3] ethtool: doc: clarify what drivers can implement in their get_drvinfo()

  Many of the drivers which implement ethtool_ops::get_drvinfo() will
prints the .driver, .version or .bus_info of struct ethtool_drvinfo.
To have a glance of current state, do:

  $ git grep -W "get_drvinfo(struct"

Printing in those three fields is useless because:

  - since [1], the driver version should be the kernel version (at
    least for upstream drivers). Arguably, out of tree drivers might
    still want to set a custom version, but out of tree is not our
    focus.

  - since [2], the core is able to provide default values for .driver
    and .bus_info.

In summary, drivers may provide .fw_version and .erom_version, the
rest is expected to be done by the core. Update the doc to reflect the
facts.

Also update the dummy driver and simply remove the callback in order
not to confuse the newcomers: most of the drivers will not need this
callback function any more.

[1] commit 6a7e25c7fb48 ("net/core: Replace driver version to be
    kernel version")
Link: https://git.kernel.org/torvalds/linux/c/6a7e25c7fb48

[2] commit edaf5df22cb8 ("ethtool: ethtool_get_drvinfo: populate
    drvinfo fields even if callback exits")
Link: https://git.kernel.org/netdev/net-next/c/edaf5df22cb8

Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
---
Arguably, dummy.c is code and not documentation, but for me, it makes
sense to treat it as documentation, thus I am putting everything in
one single patch.

* Changelog *

v2 -> v3:

  * add Reviewed-by: Leon Romanovsky <leonro@nvidia.com> tag.
  * use shorter links.

v1 -> v2:

  * forgot the net-next prefix in the patch subject... Sorry for the
    noise.
---
 drivers/net/dummy.c          | 7 -------
 include/uapi/linux/ethtool.h | 6 +++---
 2 files changed, 3 insertions(+), 10 deletions(-)
  

On Sun, 13 Nov 2022 17:34:04 +0900 Vincent Mailhol wrote:
> - * Drivers should set at most @driver, @version, @fw_version and
> - * @bus_info in their get_drvinfo() implementation.  The ethtool
> - * core fills in the other fields using other driver operations.
> + * Drivers should set at most @fw_version and @erom_version in their
> + * get_drvinfo() implementation. The ethtool core fills in the other
> + * fields using other driver operations.

Can I still nit pick the working on v3? :)

Almost half of the fields are not filled in by other operations, 
so how about we cut deeper? Even @erom_version is only filled in by 
a single driver, and pretty much deprecated (devlink is much more
flexible for all FW version reporting and flashing).

How about:

 * Majority of the drivers should no longer implement this callback.
 * Most fields are correctly filled in by the core using system
 * information, or populated using other driver operations.
  

On Tue. 15 Nov. 2022 at 14:27, Jakub Kicinski <kuba@kernel.org> wrote:
> On Sun, 13 Nov 2022 17:34:04 +0900 Vincent Mailhol wrote:
> > - * Drivers should set at most @driver, @version, @fw_version and
> > - * @bus_info in their get_drvinfo() implementation.  The ethtool
> > - * core fills in the other fields using other driver operations.
> > + * Drivers should set at most @fw_version and @erom_version in their
> > + * get_drvinfo() implementation. The ethtool core fills in the other
> > + * fields using other driver operations.
>
> Can I still nit pick the working on v3? :)

Nitpicks are welcome!

> Almost half of the fields are not filled in by other operations,
> so how about we cut deeper? Even @erom_version is only filled in by
> a single driver, and pretty much deprecated

I do not like to say that it is "pretty much deprecated". Either it is
deprecated and we can start to clean things up, or it is not and
people can continue to use it. It is good to have a clear position,
whatever it is.

> (devlink is much more flexible for all FW version reporting and flashing).

Side note, I just started to study devlink.

> How about:
>
>  * Majority of the drivers should no longer implement this callback.
>  * Most fields are correctly filled in by the core using system
>  * information, or populated using other driver operations.

> * Majority of the drivers should no longer implement this callback.
                                                       ^^^^
In this context, "this callback" is not defined (there is no prior mention in
this struct doc). I will replace it with "the drv_info() callback".

I am fine to try to discourage the developper from implementing the
callback. But I still want a small note to state the facts (c.f. above
comment, unless we explicitly deprecate the drv_info(), I do not think
we should try to completely hide its existence).

What about this:


diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index dc2aa3d75b39..fe4d8dddb0a7 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -159,8 +159,10 @@ static inline __u32 ethtool_cmd_speed(const
struct ethtool_cmd *ep)
  *     in its bus driver structure (e.g. pci_driver::name).  Must
  *     not be an empty string.
  * @version: Driver version string; may be an empty string
- * @fw_version: Firmware version string; may be an empty string
- * @erom_version: Expansion ROM version string; may be an empty string
+ * @fw_version: Firmware version string; drivers can set it; may be an
+ *     empty string
+ * @erom_version: Expansion ROM version string; drivers can set it;
+ *     may be an empty string
  * @bus_info: Device bus address.  This should match the dev_name()
  *     string for the underlying bus device, if there is one.  May be
  *     an empty string.
@@ -180,9 +182,10 @@ static inline __u32 ethtool_cmd_speed(const
struct ethtool_cmd *ep)
  * Users can use the %ETHTOOL_GSSET_INFO command to get the number of
  * strings in any string set (from Linux 2.6.34).
  *
- * Drivers should set at most @driver, @version, @fw_version and
- * @bus_info in their get_drvinfo() implementation.  The ethtool
- * core fills in the other fields using other driver operations.
+ * Majority of the drivers should no longer implement the
+ * get_drvinfo() callback.  Most fields are correctly filled in by the
+ * core using system information, or populated using other driver
+ * operations.
  */
 struct ethtool_drvinfo {
        __u32   cmd;


Yours sincerely,
Vincent Mailhol
  

On Tue, 15 Nov 2022 16:52:39 +0900 Vincent MAILHOL wrote:
> - * @fw_version: Firmware version string; may be an empty string
> - * @erom_version: Expansion ROM version string; may be an empty string
> + * @fw_version: Firmware version string; drivers can set it; may be an
> + *     empty string
> + * @erom_version: Expansion ROM version string; drivers can set it;
> + *     may be an empty string

"drivers can set it" rings a little odd to my non-native-English-
-speaker's ear. Perhaps "driver-defined;" ? Either way is fine, tho.

>   * @bus_info: Device bus address.  This should match the dev_name()
>   *     string for the underlying bus device, if there is one.  May be
>   *     an empty string.
> @@ -180,9 +182,10 @@ static inline __u32 ethtool_cmd_speed(const
> struct ethtool_cmd *ep)
>   * Users can use the %ETHTOOL_GSSET_INFO command to get the number of
>   * strings in any string set (from Linux 2.6.34).
>   *
> - * Drivers should set at most @driver, @version, @fw_version and
> - * @bus_info in their get_drvinfo() implementation.  The ethtool
> - * core fills in the other fields using other driver operations.
> + * Majority of the drivers should no longer implement the
> + * get_drvinfo() callback.  Most fields are correctly filled in by the
> + * core using system information, or populated using other driver
> + * operations.

SG! Good point on the doc being for the struct. We can make the notice
even stronger if you want by saying s/Majority of the/Modern/
  

On Tue. 16 Nov. 2022 at 01:28, Jakub Kicinski <kuba@kernel.org> wrote:
> On Tue, 15 Nov 2022 16:52:39 +0900 Vincent MAILHOL wrote:
> > - * @fw_version: Firmware version string; may be an empty string
> > - * @erom_version: Expansion ROM version string; may be an empty string
> > + * @fw_version: Firmware version string; drivers can set it; may be an
> > + *     empty string
> > + * @erom_version: Expansion ROM version string; drivers can set it;
> > + *     may be an empty string
>
> "drivers can set it" rings a little odd to my non-native-English-
> -speaker's ear. Perhaps "driver-defined;" ? Either way is fine, tho.

I am not a native speaker either so I won't argue here. Changed to
"driver defined" in v4.

> >   * @bus_info: Device bus address.  This should match the dev_name()
> >   *     string for the underlying bus device, if there is one.  May be
> >   *     an empty string.
> > @@ -180,9 +182,10 @@ static inline __u32 ethtool_cmd_speed(const
> > struct ethtool_cmd *ep)
> >   * Users can use the %ETHTOOL_GSSET_INFO command to get the number of
> >   * strings in any string set (from Linux 2.6.34).
> >   *
> > - * Drivers should set at most @driver, @version, @fw_version and
> > - * @bus_info in their get_drvinfo() implementation.  The ethtool
> > - * core fills in the other fields using other driver operations.
> > + * Majority of the drivers should no longer implement the
> > + * get_drvinfo() callback.  Most fields are correctly filled in by the
> > + * core using system information, or populated using other driver
> > + * operations.
>
> SG! Good point on the doc being for the struct. We can make the notice
> even stronger if you want by saying s/Majority of the/Modern/

"Modern drivers should no longer..." sounds like an unconditional
interdiction. I changed it to "Modern drivers no longer have to..." to
nuance the terms and suggest that they remain some edge cases.

I sent the v4 but messed up the In-Reply-To tag so it became a new thread:
https://lore.kernel.org/netdev/20221115233524.805956-1-mailhol.vincent@wanadoo.fr/T/#u


Yours sincerely,
Vincent Mailhol
  

On Wed. 16 Nov. 2022 at 09:30, Vincent MAILHOL
<mailhol.vincent@wanadoo.fr> wrote:
> On Tue. 16 Nov. 2022 at 01:28, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue, 15 Nov 2022 16:52:39 +0900 Vincent MAILHOL wrote:
> > SG! Good point on the doc being for the struct.

That comment just made me realize that actually, struct ethtool_ops is
also outdated:
https://elixir.bootlin.com/linux/latest/source/include/linux/ethtool.h#L462

Please ignore the v4, I will send another patch to also fix the struct
ethtool_ops doc.


Yours sincerely,
Vincent Mailhol