Date:   Thu, 7 Nov 2019 20:06:30 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Nicholas Johnson <nicholas.johnson-opensource@...look.com.au>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: Possibility of me mainlining Tehuti Networks 10GbE driver

Hi,

On 11/7/2019 6:24 PM, Nicholas Johnson wrote:
> Hi all,
> 
> To start off, if I am emailing the wrong people, please blame the output 
> of: "scripts/get_maintainer.pl drivers/net/ethernet/tehuti/" and let me 
> know who I should be contacting. Should I add in 
> "linux-kernel@...r.kernel.org"?
> 
> I just discovered that the Tehuti 10GbE networking drivers (required for 
> things such as some AKiTiO Thunderbolt to 10GbE adapters) are not in 
> mainline. I am interested in mainlining it, but need to know how much 
> work it would take and if it will force me to be the maintainer for all 
> eternity.
> 
> The driver, in tn40xx-0.3.6.15-c.tar appears to be available here:
> Link: https://www.akitio.com/faq/341-thunder3-10gbe-adapter-can-i-use-this-network-adapter-on-linux
> Also here:
> Link: https://github.com/acooks/tn40xx-driver
> 
> I see some immediate style problems and indentation issues. I can fix 
> these.
> 
> The current driver only works with Linux v4.19, I believe. There are a 
> small handful of compile errors with v5.4. I can probably fix these.
> 
> However, could somebody please comment on any technical issues that you 
> can see here? How much work do you think I would have to do to mainline 
> this? Would I have to buy such a device for testing? Would I have to buy 
> *all* of the supported devices for testing? Or can other people do that 
> for me?

This is based on roughly 5 minutes of browsing source files, but what I
see, which is typical from out of tree vendor drivers is a complete lack
of use of existing kernel APIs beyond registering a net_device which you
would have to use to seek upstream inclusion, that includes for the most
part:

- make use of the PHYLINK subsystem for supporting 10GBaseT and SFP
modules instead of doing your own, there might be existing PHY drivers
that you can use for the Aquantia and Marvell parts, see
drivers/net/phy/ to check whether the PHY models are indeed supported

- implement a proper mii_bus interface for "talking" to the PHYs,
implement a proper gpio_chip instance to register with Linux as a GPIO
controller, such that then you can use i2c-gpio to become an i2c bus
master driver, and then talk to the SFPs properly

- lots and lots of stylistic issues that must be fixed

- getting rid of private driver ioctl implementation

There are certainly many more details once we start digging of course.

> 
> I am not keen on having to buy anything without mainline support - it is 
> an instant disqualification of a hardware vendor. It results in a 
> terrible user experience for experienced people (might not be able to 
> use latest kernel which is needed for supporting other things) and is 
> debilitating for people new to Linux who do not how to use the terminal, 
> possibly enough so that they will go back to Windows.

Seems like a reasonable position to me, the grey area is when there is a
Linux driver, but its quality is not making it upstream available, then
you find yourself emailing netdev about that very situation :)

> 
> Andy, what is your relationship to Tehuti Networks? Would you be happy 
> to maintain this if I mainlined it? It says you are maintainer of 
> drivers/net/ethernet/tehuti/ directory. I will not do this if I am 
> expected to maintain it - in no small part because I do not know a lot 
> about it. I will only be modifying what is currently available to make 
> it acceptable for mainline, if possible.

Given how the driver is broken up, you can do a couple of strategies:

- try to submit it all as-is (almost) under drivers/staging/ where it
may get contributions from people to clean it up to the kernel coding
style, using coccinelle semantic patch and pretty much anything that can
be done by inspecting code visually while not really testing it. This
might make the driver stay in staging for a long time, but if there are
in-kernel API changes, they will be done and so it will continue to
build and maybe even work, for any version of Linux in which it got
included and onward. The problem with that approach is that it will
likely stay in limbo unless a dedicated set of people start working
towards moving it out of staging.

- rewrite it in smaller parts and submit it in small chunks, with basic
functionality one step at a time, e.g.: driver skeleton/entry point as a
pci_device/driver, then net_device registration without anything, then
RX path, then TX path, then control path, then ethtool interface, etc.
etc. Given the shape of the driver, but not knowing how familiar you are
with the driver or the kernel, a 3 man/month work for someone motivated
is probably an optimistic estimate of the work you have ahead of you,
6m/m sounds more realistic. There is also an expectation that you will
be maintaining this driver for a few months (maybe years) to come, and
network drivers tend to always have something that needs to be fixed, so
it is a nice side gig, but it could be time consuming.

> 
> Also, license issues - does GPLv2 permit mainlining to happen? I believe 
> the Tehuti driver is available under GPLv2 (correct me if I am wrong).

The source code on the github tree suggests this is the case, therefore
it is entirely appropriate to seek upstream inclusion given the license
allows it.

What needs to be figured out is the PHY firmware situation which appears
to be completed punted onto the user to figure out which files (and
where to download), how to extract the relevant firmware blobs (there
are scripts, okay). If you have a contact with one of the vendors
supported by the driver, or better yet, with Tehuti, that may be
something they could help with. A mainline driver with proprietary
firmware blobs is not uncommon, but having to get the blobs outside of
linux-firmware is a real pain for distributions and some might even
refuse to build your driver because of that.

> 
> Would I need to send patches for this, or for something this size, is it 
> better to send a pull request? If I am going to do patches, I will need 
> to make a gmail account or something, as Outlook messes with the 
> encoding of the things which I send.

For sending patches, you would want to use git send-email to make sure
you avoid MUA issues.

> 
> Thanks for any comments on this.

Hope all of this helps. Cheers
-- 
Florian

Powered by blists - more mailing lists