[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150106.172918.70204012105519766.davem@davemloft.net>
Date: Tue, 06 Jan 2015 17:29:18 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: amirv@...lanox.com
Cc: ddecotig@...il.com, f.fainelli@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
saeedm@...lanox.com, decot@...glers.com, jasowang@...hat.com,
mst@...hat.com, herbert@...dor.apana.org.au,
viro@...iv.linux.org.uk, ben@...adent.org.uk, yamato@...hat.com,
xii@...gle.com, nhorman@...driver.com, xiyou.wangcong@...il.com,
fbl@...hat.com, teg@...m.no, jiri@...nulli.us, vyasevic@...hat.com,
ebiederm@...ssion.com, VenkatKumar.Duvvuru@...lex.Com,
_govind@....com
Subject: Re: [PATCH net-next v2 0/8] net: extend ethtool link mode bitmaps
to 48 bits
From: Amir Vadai <amirv@...lanox.com>
Date: Tue, 6 Jan 2015 15:56:33 +0200
> Mellanox is about to release next month a driver for a new NIC, with 3
> new speeds * few link modes for each + new link modes for 10G.
> It seems that we will need to consume almost all the new bits.
This tells me that the approach to this problem needs to be rethought.
Maybe we just need to bite the bullet and make a new ETHTOOL_GSET_2
and ETHTOOL_SSET_2 or whatever you want to name them.
Then we can define a completely new structure, with 64-bit bitmaps
for link modes or whatever. The ethtool_op callbacks work using
this structure, and only the net/core/ethtool.c code knows about
the older structure and translates to/from for ETHTOOL_{GSET,SSET}.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists