Thread (36 messages) 36 messages, 4 authors, 2023-04-03

Re: [PATCH 6/7] dsa: marvell: Correct value of max_frame_size variable after validation

From: Andrew Lunn <andrew@lunn.ch>
Date: 2023-03-09 15:42:47
Also in: lkml

quoted
If I understand this correctly, in patch 4, you add a call to the 6250
family to call mv88e6185_g1_set_max_frame_size(), which sets a bit
called MV88E6185_G1_CTL1_MAX_FRAME_1632 if the frame size is larger
than 1518.
Yes, correct.
quoted
However, you're saying that 6250 has a frame size of 2048. That's
fine, but it makes MV88E6185_G1_CTL1_MAX_FRAME_1632 rather misleading
as a definition. While the bit may increase the frame size, I think
if we're going to do this, then this definition ought to be renamed.
I thought about rename, but then I've double checked; register offset
and exact bit definition is the same as for 6185, so to avoid
unnecessary code duplication - I've reused the existing function.

Maybe comment would be just enough?
The driver takes care with its namespace in order to add per switch
family defines. So you can add MV88E6250_G1_CTL1_MAX_FRAME_2048. It
does not matter if it is the same bit. You can also add a
mv88e6250_g1_set_max_frame_size() and it also does not matter if it is
in effect the same as mv88e6185_g1_set_max_frame_size().

We should always make the driver understandably first, compact and
without redundancy second. We are then less likely to get into
situations like this again where it is not clear what MTU a device
actually supports because the code is cryptic.

	 Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help