From mboxrd@z Thu Jan  1 00:00:00 1970
From: Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH net-next v2 03/13] net: phy: sfp: warn the user when no tx_disable pin is available
Date: Sat, 05 May 2018 13:38:31 -0700
Message-ID: <44545AF4-64E3-4772-B5BA-43CCF2321025@gmail.com>
References: <20180504135643.23466-1-antoine.tenart@bootlin.com> <20180504135643.23466-4-antoine.tenart@bootlin.com> <ed267042-1a61-7fcc-13ee-3cad2c05c658@gmail.com> <20180504171425.GA17233@lunn.ch>
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Antoine Tenart <antoine.tenart@bootlin.com>, davem@davemloft.net,
        kishon@ti.com, linux@armlinux.org.uk, gregory.clement@bootlin.com,
        jason@lakedaemon.net, sebastian.hesselbarth@gmail.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        thomas.petazzoni@bootlin.com, maxime.chevallier@bootlin.com,
        miquel.raynal@bootlin.com, nadavh@marvell.com, stefanc@marvell.com,
        ymarkman@marvell.com, mw@semihalf.com,
        linux-arm-kernel@lists.infradead.org
To: Andrew Lunn <andrew@lunn.ch>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20180504171425.GA17233@lunn.ch>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

On May 4, 2018 10:14:25 AM PDT, Andrew Lunn <andrew@lunn=2Ech> wrote:
>On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
>> On 05/04/2018 06:56 AM, Antoine Tenart wrote:
>> > In case no Tx disable pin is available the SFP modules will always
>be
>> > emitting=2E This could be an issue when using modules using laser as
>their
>> > light source as we would have no way to disable it when the fiber
>is
>> > removed=2E This patch adds a warning when registering an SFP cage
>which do
>> > not have its tx_disable pin wired or available=2E
>>=20
>> Is this something that was done in a possibly earlier revision of a
>> given board design and which was finally fixed? Nothing wrong with
>the
>> patch, but this seems like a pretty serious board design mistake,
>that
>> needs to be addressed=2E
>
>Hi Florian
>
>Zii Devel B is like this=2E Only the "Signal Detect" pin is wired to a
>GPIO=2E

Good point, indeed=2E BTW what do you think about exposing the SFF's EEPRO=
M and diagnostics through the standard ethtool operations even if we have t=
o keep the description of the SFF as a fixed link in Device Tree because of=
 the unfortunate wiring?

--=20
Florian