[EXT] Re: bnx2x: ppc64le: Unable to set message level greater than 0x7fff

Jakub Kicinski kuba at kernel.org
Thu Mar 17 06:18:25 AEDT 2022


On Wed, 16 Mar 2022 19:52:32 +0100 Michal Kubecek wrote:
> > Yup, IIUC it works for Paul on a 5.17 system, that system likely has
> > old ethtool user space tool which uses ioctls instead of netlink.
> > 
> > What makes the netlink path somewhat non-trivial is that there is 
> > an expectation that the communication can be based on names (strings)
> > as well as bit positions. I think we'd need a complete parallel
> > attribute to carry vendor specific bits :S  
> 
> Yes, that would be a way to go. However, in such case I would prefer
> separating these driver/device specific message flags completely rather
> then letting drivers grab currently unused flags (as is the case here,
> IIUC) as those are likely to collide with future global ones.

I was thinking let the driver specify which flags it is squatting on in
a mask in ethtool_ops, and then make sure the generic vs non-generic
flags are routed appropriately in the user space <> core communication.
We can also split the private vs generic on the ethtool_op level.

User space would have to jump thru extra hoops to figure the separation
out (maybe we can expose the "private mask" in get?)

I agree that the more we can separate the private and generic flags,
the better, that's just what I could come up with.


More information about the Linuxppc-dev mailing list