[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200103141743.GC22988@lunn.ch>
Date: Fri, 3 Jan 2020 15:17:43 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jonathan Corbet <corbet@....net>,
Kishon Vijay Abraham I <kishon@...com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] Fix 10G PHY interface types
> Describing the actual interface at chip to chip level (RGMII, SGMII, XAUI,
> XFI, etc.). This may be incomplete for people trying to configure their HW
> that supports multiple modes (reminder - device trees describe HW, they do
> not configure SW). More details would be required and the list would be...
> eclectic.
Hi Madalin
Please forget the existing DT binding for the moment. Please describe
what values you need to program into your hardware to make it
work. Please don't use the existing DT naming when describing what you
need. Maybe use the terms from the reference manual?
Once we have a list, we can figure out what could be generic, what
could be vendor specific, and how to describe it in ACPI, DT, etc.
At LPC 2019, Claudiu and Vladimir talked about wanting to describe the
eye configuration for some hardware. It would be interesting if there
is any overlap. Aquantia also have some values used to configure the
SERDES of their PHYs. I think this is a board specific binary blob
which is loaded into the PHY as part of the firmware. That then limits
their firmware to a specific board, which is not so nice. But does
that also indicate that how the MAC is configured might also depend on
how the PHY configures its electrical properties?
Andrew
Powered by blists - more mailing lists