Message-ID: <20210914174453.rq4iaje2ajok2fon@skbuf>
Date:   Tue, 14 Sep 2021 17:44:53 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Gerhard Engleder <gerhard@...leder-embedded.com>
CC:     Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
        netdev <netdev@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>,
        Jakub Kicinski <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net] Revert "net: phy: Uniform PHY driver access"

On Tue, Sep 14, 2021 at 07:14:12PM +0200, Gerhard Engleder wrote:
> > > I submitted it, but Michal Simek argumented that dts files of FPGA
> > > logic shall not be part of mainline. I suggested that at least one
> > > reference platform for every FPGA based IP core should be allowed,
> > > but he said that no one is able to test it.  So it seems that you
> > > will never see any dts file which contains FPGA logic in mainline. I
> > > will try to submit it again if anyone will support me?
> >
> > My opinion: If there is a real product out in the field using this,
> > the DT for the product can be in mainline.
> >
> > Reference Design Kits for ASICs are well supported in mainline. So the
> > question is, is an FPGA sufficiently different to an ASIC that is
> > should be treated differently? Do you have an off the shelf platform
> > or something custom? How easy is it to get the platform which is used
> > as an RDK? Can you make a bitstream available for anybody to use?
>
> At least in combination with the board I can see no difference between ASIC
> and FPGA. Usually a FPGA bitstream targets a specific board, so the devices
> within the FPGA can be treated like devices on the board.
>
> The reference platform is based on off the shelf stuff (Xilinx ZCU104 and Avnet
> AES-FMC-NETW1-G). At least I had no problem buying the boards.
>
> Yes, I can provide a bitstream for everybody.

My opinion is that Linux has gotten into the position of maintaining the
central repository of device tree blobs by some sort of strange accident,
and these blobs do not really have to describe "a real product out in
the field" in order to have a place in that central repository, no
matter where that might be hosted. On some platforms it is not even
possible to change the device tree (easily) since it is provided by the
firmware, nonetheless it is still valuable to be able to look at it for reference.

So I think anyone should be able to post their toy TSN driver running on
their toy bit stream described by their toy device tree, and not be too
concerned that they are littering the kernel. I would leave it upon the
device tree maintainers to figure out the scalability concern, after all
Linux took it upon itself to manage the central reference of device trees.
But I do agree that the hardware setup needs at least to be reasonably
reproducible by somebody non-you.

I think the implication of not welcoming this kind of work is marginalizing
hardware vendors such as Xilinx, and their users ending up in a worse
place than if the device trees had a place in the mainline kernel.
I am not a Xilinx engineer nor a Xilinx customer, but I am dreading each
time I get a support request for an NXP switch attached to a Zynq SoC,
just because I am always told that the person I'm helping is trapped
with some sort of odd and old SDK kernel with modifications and it is
not possible for them to move to mainline. So I am really happy to see
people getting past that barrier and submitting drivers developed on
Xilinx SoCs, it would be even nicer if they had an unimpeded path to
make forward progress with their work.

Does this invalidate my point about the GMII2RGMII converter, where I
said that it would be better for all MAC drivers to treat it like a
satellite device, instead of stowing it inside the PHY library with all
the hacks associated with that? After all, Gerhard's TSN endpoint driver
has nothing to do with Xilinx per se, it is only by chance that it runs
on Xilinx hardware, so it may seem reasonable for his driver to not need
to explicitly manage the platform's RGMII gasket. His TSN endpoint might
be ported to a different FPGA manufacturer with no such oddity. Having
this device hidden in the PHY library makes his life easier (at least
apparently, until he hits things that don't work as they should).

So while that is a valid point, there might be other places to put that
converter, which are not in the direct path of the attached PHY's driver.
For example, phylink is the melting pot of a lot of devices, on-board
PHYs, SFP modules with and without PHYs, PCSes, it may even gain support
for retimers, this was brought up a while ago. So maybe it would happily
deal with another off-label device, a standalone RGMII gasket. It could
have a structure with generic ops such as what is in place for struct
phylink_pcs, and it ensures that this will be programmed to the right
speed, put in loopback, etc etc, automatically. MAC driver uses phylink,
the device tree has a phandle to the rgmii-gasket, and it works.
Odd, and may or may not be worth it depending on how much demand there
is, but at least it's an option worth considering.

Powered by blists - more mailing lists