Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 14 May 2020 10:28:13 +0200
From:   Oleksij Rempel <o.rempel@pengutronix.de>
To:     Christian Herber <christian.herber@nxp.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        "David S. Miller" <davem@davemloft.net>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Michal Kubecek <mkubecek@suse.cz>,
        David Jander <david@protonic.nl>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Russell King <linux@armlinux.org.uk>,
        "mkl@pengutronix.de" <mkl@pengutronix.de>,
        Marek Vasut <marex@denx.de>
Subject: Re: [EXT] Re: signal quality and cable diagnostic
Message-ID: <20200514082813.GA1896@pengutronix.de>
References: <20200511141310.GA2543@pengutronix.de>
 <20200511143337.GC413878@lunn.ch>
 <20200512082201.GB16536@pengutronix.de>
 <AM0PR04MB7041DE18F2966573DB6E078586BC0@AM0PR04MB7041.eurprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To: <AM0PR04MB7041DE18F2966573DB6E078586BC0@AM0PR04MB7041.eurprd04.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Christian,

On Thu, May 14, 2020 at 07:13:30AM +0000, Christian Herber wrote:
> On Tue, May 12, 2020 at 10:22:01AM +0200, Oleksij Rempel wrote:
> 
> > So I think we should pass raw SQI value to user space, at least in the
> > first implementation.
> 
> > What do you think about this?
> 
> Hi Oleksij,
> 
> I had a check about the background of this SQI thing. The table you reference with concrete SNR values is informative only and not a requirement. The requirements are rather loose.
> 
> This is from OA:
> - Only for SQI=0 a link loss shall occur.
> - The indicated signal quality shall monotonic increasing /decreasing with noise level.
> - It shall be indicated in the datasheet at which level a BER<10^-10 (better than 10^-10) is achieved (e.g. "from SQI=3 to SQI=7 the link has a BER<10^-10 (better than 10^-10)")
> 
> I.e. SQI does not need to have a direct correlation with SNR. The fundamental underlying metric is the BER.
> You can report the raw SQI level and users would have to look up what it means in the respective data sheet. There is no guaranteed relation between SQI levels of different devices, i.e. SQI 5 can have lower BER than SQI 6 on another device.
> Alternatively, you could report BER < x for the different SQI levels. However, this requires the information to be available. While I could provide these for NXP, it might not be easily available for other vendors.
> If reporting raw SQI, at least the SQI level for BER<10^-10 should be presented to give any meaning to the value.

So the question is, which values to provide via KAPI to user space?

- SQI
  The PHY can probably measure the SNR quite fast and has some internal
  function or lookup table to deduct the SQI from the measured SNR.

  If I understand you correctly, we can only compare SQI values of the
  same PHY, as different PHYs give different SQIs for the same link
  characteristics (=SNR).
- SNR range
  We read the SQI from the PHY look up the SNR range for that value from
  the data sheet and provide that value to use space. This gives a
  better description of the quality of the link.
- "guestimated" BER
  The manufacturer of the PHY has probably done some extensive testing
  that a measured SNR can be correlated to some BER. This value may be
  provided in the data sheet, too.

The SNR seems to be most universal value, when it comes to comparing
different situations (different links and different PHYs). The
resolution of BER is not that detailed, for the NXP PHY is says only
"BER below 1e-10" or not.

> While I could provide these for NXP, it might not be easily available
> for other vendors.

It will be great if you can provide this information. It may force other
vendors to do the same :)

The actual procedure to measure the BER is the following testing
strategy suggested by opensig[1]:
--------------------------------------------------------------------------------
Procedure:
1. Configure the DUT as MASTER.
2. Connect the packet monitoring station to the automotive cable.
3. Connect the DUT to the automotive cable.
4. Send 2,470,000 1,518-byte packets (for a 10 -10 BER) and the monitor will
   count the number of packet errors.
5. Repeat step 4 for the remaining automotive cables.
6. Repeat steps 4-5 with the DUT configured as SLAVE.
--------------------------------------------------------------------------------

[1] http://www.opensig.org/download/document/225/Open_Alliance_100BASE-T1_PMA_Test_Suite_v1.0-dec.pdf

Regards,
Oleksij & Marc

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |