From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BDAFC43460 for ; Mon, 12 Apr 2021 23:40:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65E0F61278 for ; Mon, 12 Apr 2021 23:40:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239366AbhDLXlG (ORCPT ); Mon, 12 Apr 2021 19:41:06 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46912 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237567AbhDLXlF (ORCPT ); Mon, 12 Apr 2021 19:41:05 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lW6AS-00GNdF-QW; Tue, 13 Apr 2021 01:40:32 +0200 Date: Tue, 13 Apr 2021 01:40:32 +0200 From: Andrew Lunn To: Ivan Bornyakov Cc: system@metrotek.ru, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/2] net: phy: marvell-88x2222: check that link is operational Message-ID: References: <614b534f1661ecf1fff419e2f36eddfb0e6f066d.1618227910.git.i.bornyakov@metrotek.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <614b534f1661ecf1fff419e2f36eddfb0e6f066d.1618227910.git.i.bornyakov@metrotek.ru> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote: > Some SFP modules uses RX_LOS for link indication. In such cases link > will be always up, even without cable connected. RX_LOS changes will > trigger link_up()/link_down() upstream operations. Thus, check that SFP > link is operational before actual read link status. Sorry, but this is not making much sense to me. LOS just indicates some sort of light is coming into the device. You have no idea what sort of light. The transceiver might be able to decode that light and get sync, it might not. It is important that mv2222_read_status() returns the line side status. Has it been able to achieve sync? That should be independent of LOS. Or are you saying the transceiver is reporting sync, despite no light coming in? Andrew