Re: [net-next PATCH 2/8] octeontx2-pf: Add ethtool priv flag to control PAM4 on/off

From: Andrew Lunn
Date: Sun Mar 21 2021 - 10:28:52 EST

Next message: Eric W. Biederman: "Re: [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads"
Previous message: Oliver Hartkopp: "Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(struct canfd_frame, len) || offsetof(struct can_frame, data) != offsetof(struc..."
In reply to: Hariprasad Kelam: "[net-next PATCH 2/8] octeontx2-pf: Add ethtool priv flag to control PAM4 on/off"
Next in thread: Hariprasad Kelam: "[net-next PATCH 3/8] octeontx2-af: Support for parsing pkts with switch headers"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, Mar 21, 2021 at 05:39:52PM +0530, Hariprasad Kelam wrote:
> From: Felix Manlunas <fmanlunas@xxxxxxxxxxx>
>
> For PHYs that support changing modulation type (NRZ or PAM4), enable these
> commands:
>
> ethtool --set-priv-flags ethX pam4 on
> ethtool --set-priv-flags ethX pam4 off # means NRZ modulation
> ethtool --show-priv-flags ethX

Why is this not derived from the link mode? How do other Vendors
support this in their high speed MAC/PHY combinations.

Please stop using priv flags like this. This is not a Marvell specific
problem. Any high speed MAC/PHY combination is going to need some way
to configure this. So please think about the best generic solution.

This combined with your DSA changes give me a bad feeling. It seems
like you are just trying to dump your SDK features into the kernel,
without properly integrating the features in a vendor neutral way.

Andrew