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 A1A36C2D0E4 for ; Tue, 24 Nov 2020 01:15:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C16A20728 for ; Tue, 24 Nov 2020 01:15:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729799AbgKXBPI (ORCPT ); Mon, 23 Nov 2020 20:15:08 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:46412 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728052AbgKXBPI (ORCPT ); Mon, 23 Nov 2020 20:15:08 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1khMv5-008ZiA-3H; Tue, 24 Nov 2020 02:14:59 +0100 Date: Tue, 24 Nov 2020 02:14:59 +0100 From: Andrew Lunn To: Moshe Shemesh Cc: "David S. Miller" , Jakub Kicinski , Adrian Pop , Michal Kubecek , netdev@vger.kernel.org, Vladyslav Tarasiuk , Moshe Shemesh Subject: Re: [PATCH net-next v2 0/2] Add support for DSFP transceiver type Message-ID: <20201124011459.GD2031446@lunn.ch> References: <1606123198-6230-1-git-send-email-moshe@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1606123198-6230-1-git-send-email-moshe@mellanox.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Nov 23, 2020 at 11:19:56AM +0200, Moshe Shemesh wrote: > Add support for new cable module type DSFP (Dual Small Form-Factor Pluggable > transceiver). DSFP EEPROM memory layout is compatible with CMIS 4.0 spec. Add > CMIS 4.0 module type to UAPI and implement DSFP EEPROM dump in mlx5. So the patches themselves look O.K. But we are yet again kicking the can down the road and not fixing the underlying inflexibility of the API. Do we want to keep kicking the can, or is now the time to do the work on this API? Andrew