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 1C4F7C433B4 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 E461F61350 for ; Mon, 12 Apr 2021 23:40:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239354AbhDLXlG (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: netdev@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