mlx4_core: num reserved eqs presented as log and
Quoted 9 lines · On Sunday -10,January,-28163 09:59 PM, Roland Dreier…
Follow Up Flag: Warning: May contain useful information Due By: Sunday, February 21, 2010 3:00 PM
Flag Status: RedQuoted 4 lines
Multifunctional firmware should present number of reserved EQs as > an actual number (number of reserved eqs is not necessarily a power > of 2).
Older drivers treat this field as log, so when there are relatively big > number of reserved eqs, they would fail.
The firmware would present the number of EQs as log in a single function mode > (which would also work for older driver versions) and as actual number (in other field) > in multifunctional mode. The new code would check both fields. Fixes commitbe504b0b9fbe9ba447c93ef0f5789f377102d555
Quoted 5 lines
I can't really follow this changelog. The (very old) ConnextX PRM I have states that the field returned by the firmware is the actual number, so the old driver behavior was wrong. Or was the PRM wrong?
Are you changing the firmware behavior to make that field into a log?
Is this really the best way to clean this up, having the same information twice in two different formats?
The old driver behavior was wrong. The bug was hidden because the firmware was showing small number of reserved EQs, so even when it was treated as log, there was not an issue.
New firmware versions use bigger number of reserved EQs, and using the same field would break older drivers, that treat this field as log, So the firmware needs to write the log to this field.
Another issue is that in multifunctional case (SRIOV) the number of reserved EQs is not power of 2, so using the log field is not possible. In this case the firmware would use the new field, which is visible by new drivers.
The firmware algorithm would be:
if multifunctional :
new_field = num_multifunctional_eqs
else:
old_field = log2(num_singlefunctional_eqs)
--Yevgeny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html