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 A5644C433ED for ; Fri, 30 Apr 2021 21:57:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A79861419 for ; Fri, 30 Apr 2021 21:57:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231268AbhD3V6a (ORCPT ); Fri, 30 Apr 2021 17:58:30 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:48680 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229915AbhD3V63 (ORCPT ); Fri, 30 Apr 2021 17:58:29 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lcb8j-001s1W-5i; Fri, 30 Apr 2021 23:57:37 +0200 Date: Fri, 30 Apr 2021 23:57:37 +0200 From: Andrew Lunn To: Don Bollinger Cc: 'Moshe Shemesh' , 'Michal Kubecek' , 'Jakub Kicinski' , netdev@vger.kernel.org, 'Vladyslav Tarasiuk' Subject: Re: [PATCH ethtool-next 0/4] Extend module EEPROM API Message-ID: References: <1619162596-23846-1-git-send-email-moshe@nvidia.com> <008301d73e03$1196abb0$34c40310$@thebollingers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008301d73e03$1196abb0$34c40310$@thebollingers.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > There are routine functions to configure the devices that require writing > appropriate values to various registers. Byte 26 allows software control of > low power mode, squelch and software reset. Page 10h is full of Lane and > Data Path Control registers. These all sounds like foot canons when in user space control. I would expect the MAC and or SFP driver to make use of these features, no need to export them to user space, at least not in a raw format. I could however imagine ethtool commands to manipulate specific features, passing the request to the MAC to perform, so it knows what is going on. > Beyond the spec, but allowed by the spec, there are vendor specific > capabilities like firmware download that require bulk write (up to 128 bytes > per write). This one is not so easy. Since it is vendor specific, we need to consider how to actually make it vendor generic from Ethtool, or maybe devlink. Maybe code in the kernel which matches on the vendor string in the SFP EEPROM, and provides a standardized API towards ethtool, and does whatever magic is needed towards the SFP. But it gets messy when you don't have direct access to the SFP, there is a layer of firmware in the middle, which is often the case. Andrew