[PATCH v1 1/5] net/ark: update mpu code to match current hardware version

[Kevin Traynor]

On 18/05/2022 13:54, Ferruh Yigit wrote:
> On 5/6/2022 10:27 PM, Ed Czeck wrote:
>> new version code
>> remove device-level global operations
>> remove ark_mpu_reset_stats function
>>
> 
> Hi Ed, please find a few comments inline.
> 
> Also I assume 'mpu' is an abbreviation, can you please document what it
> stands for in the commit log, like MPU (M.. P.. U..)?
> And can you please make it uppercase in the commit title, also if you
> can add them to 'devtools/words-case.txt' (in a separate patch), it will
> be checked next time by './devtools/check-git-log.sh' script.
> Same for all patches.
> 
>> Signed-off-by: Ed Czeck <ed.czeck at atomicrules.com>
>> ---
>>    drivers/net/ark/ark_ethdev.c    |  2 --
>>    drivers/net/ark/ark_ethdev_rx.c |  4 ----
>>    drivers/net/ark/ark_mpu.c       | 21 ++++-----------------
>>    drivers/net/ark/ark_mpu.h       | 29 ++---------------------------
>>    4 files changed, 6 insertions(+), 50 deletions(-)
>>
> 
> <...>
> 
>> @@ -24,10 +24,10 @@ ark_mpu_verify(struct ark_mpu_t *mpu, uint32_t obj_size)
>>    {
>>    	uint32_t version;
>>    
>> -	version = mpu->id.vernum & 0x0000fF00;
>> -	if ((mpu->id.idnum != 0x2055504d) ||
>> -	    (mpu->hw.obj_size != obj_size) ||
>> -	    (version != 0x00003100)) {
>> +	version = mpu->id.vernum;
>> +	if (mpu->id.idnum != ARK_MPU_MODID ||
>> +	    version != ARK_MPU_MODVER ||
>> +	    mpu->hw.obj_size != obj_size) {
> 
> The driver will work with a specific version of the 'MPU'. So a device
> previously working with previous version of the driver, won't work
> anymore after this patch, and will be forced to a (FW/bitstream/?) update.
> I am not sure how problematic is this from the stable release
> perspective. cc'ed maintainers.
> 

While it is nice-to-have, stable releases are not guaranteed to work 
with future HW/FW/3rd party software etc.

More importantly, a user should not *have* to make updates outside DPDK 
when moving along a single DPDK LTS stream. e.g. 21.11.1 -> 21.11.2.

> But at least won't it be good to document this in release notes, and
> perhaps having a table in the driver documentation to list which DPDK
> version requires which HW version can be good, what do you think?
> 

I agree documenting the matching versions is good for usability. e.g. 
http://doc.dpdk.org/guides/nics/ice.html#recommended-matching-list