[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201124131608.1b884063@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 24 Nov 2020 13:16:08 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Moshe Shemesh <moshe@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Adrian Pop <pop.adrian61@...il.com>,
Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org,
Vladyslav Tarasiuk <vladyslavt@...dia.com>,
Moshe Shemesh <moshe@...dia.com>
Subject: Re: [PATCH net-next v2 0/2] Add support for DSFP transceiver type
On Tue, 24 Nov 2020 02:14:59 +0100 Andrew Lunn wrote:
> 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?
This is hardly rocket science. Let's do it right.
Powered by blists - more mailing lists