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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 C033CC43331 for ; Sun, 10 Nov 2019 17:52:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EB9E2080F for ; Sun, 10 Nov 2019 17:52:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="NDnXBLOF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfKJRwX (ORCPT ); Sun, 10 Nov 2019 12:52:23 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:59236 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726684AbfKJRwX (ORCPT ); Sun, 10 Nov 2019 12:52:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iVKl+3MMYgW162rXUWMshk45wYB5ADLH3+fA5rA43Ws=; b=NDnXBLOFHBkULdVZQ94lWJrXQb DFYUW7/8/Nm8cHJxT8P9nnWt1mq96ESYWHpa1wMrh+MyQ8n56kFJWABU3w3EaMq2KEW1Pn+/Rn1Ry V7b5nqNn3Hp7xjZBFf0CEYu5YKzqlJ8YJvLydxN3+oGXhXJKoHB1w/hVBCzV3pNMFPag=; Received: from andrew by vps0.lunn.ch with local (Exim 4.92.2) (envelope-from ) id 1iTrNp-0007Am-NZ; Sun, 10 Nov 2019 18:52:17 +0100 Date: Sun, 10 Nov 2019 18:52:17 +0100 From: Andrew Lunn To: Russell King - ARM Linux admin Cc: Florian Fainelli , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next 00/17] Allow slow to initialise GPON modules to work Message-ID: <20191110175217.GL25889@lunn.ch> References: <20191110140530.GA25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191110140530.GA25745@shell.armlinux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Nov 10, 2019 at 02:05:30PM +0000, Russell King - ARM Linux admin wrote: > Some GPON modules take longer than the SFF MSA specified time to > initialise and respond to transactions on the I2C bus for either > both 0x50 and 0x51, or 0x51 bus addresses. Technically these modules > are non-compliant with the SFP Multi-Source Agreement, they have > been around for some time, so are difficult to just ignore. Hi Russell We are seeing quite a few SFP/SFF which violate the spec. Do you think there is any value in naming and shaming in the kernel logs SFP which don't conform to the standard? If you need to wait longer than 1 second for the EEPROM to become readable, print the vendor name from the EEPROM and warn it is not conforment. If the diagnostic page is not immediately available, again, print the vendor name warn it is not conforment? Andrew