mbox series

[net-next,v2,0/2] mlxsw: Add support for QSFP-DD transceiver type

Message ID 20200728102016.1960193-1-idosch@idosch.org
Headers show
Series mlxsw: Add support for QSFP-DD transceiver type | expand

Message

Ido Schimmel July 28, 2020, 10:20 a.m. UTC
From: Ido Schimmel <idosch@mellanox.com>

This patch set from Vadim adds support for Quad Small Form Factor
Pluggable Double Density (QSFP-DD) modules in mlxsw.

Patch #1 enables dumping of QSFP-DD module information through ethtool.

Patch #2 enables reading of temperature thresholds from QSFP-DD modules
for hwmon and thermal zone purposes.

Changes since v1 [1]:

Only rebase on top of net-next. After discussing with Andrew and Adrian
we agreed that current approach is OK and that in the future we can
follow Andrew's suggestion to "make a new API where user space can
request any pages it want, and specify the size of the page". This
should allow us "to work around known issues when manufactures get their
EEPROM wrong".

[1] https://lore.kernel.org/netdev/20200626144724.224372-1-idosch@idosch.org/#t

Vadim Pasternak (2):
  mlxsw: core: Add ethtool support for QSFP-DD transceivers
  mlxsw: core: Add support for temperature thresholds reading for
    QSFP-DD transceivers

 .../net/ethernet/mellanox/mlxsw/core_env.c    | 53 ++++++++++++++-----
 drivers/net/ethernet/mellanox/mlxsw/reg.h     |  3 ++
 2 files changed, 44 insertions(+), 12 deletions(-)

Comments

David Miller July 28, 2020, 8:28 p.m. UTC | #1
From: Ido Schimmel <idosch@idosch.org>
Date: Tue, 28 Jul 2020 13:20:14 +0300

> From: Ido Schimmel <idosch@mellanox.com>
> 
> This patch set from Vadim adds support for Quad Small Form Factor
> Pluggable Double Density (QSFP-DD) modules in mlxsw.
> 
> Patch #1 enables dumping of QSFP-DD module information through ethtool.
> 
> Patch #2 enables reading of temperature thresholds from QSFP-DD modules
> for hwmon and thermal zone purposes.
> 
> Changes since v1 [1]:
> 
> Only rebase on top of net-next. After discussing with Andrew and Adrian
> we agreed that current approach is OK and that in the future we can
> follow Andrew's suggestion to "make a new API where user space can
> request any pages it want, and specify the size of the page". This
> should allow us "to work around known issues when manufactures get their
> EEPROM wrong".
> 
> [1] https://lore.kernel.org/netdev/20200626144724.224372-1-idosch@idosch.org/#t

Series applied, thank you.