Mailbox Client HAL API: Erroneous behavior in flash erase boundary checks (Agilex 3 / Nios V)

Hi,

I am currently working on an Agilex 3 platform using the Nios V in Quartus Prime Pro 25.3. I discovered unexpected behavior in the Mailbox Client HAL API when trying to erase 32K blocks of flash.

In the file intel_mailbox_client_flash.c in function mailbox_client_flash_erase_block:

The function receives a dynamic block_size as an argument but ignores it during the boundary check, relying instead on the global dev_info->region_info.block_size.
Because it checks against the maximum hardware block_size (i.e., 64K) instead of the actual block_size parameter passed to the function, it mistakenly blocks legitimate erase commands at the final sectors of the region. Below is the code snippet:

int mailbox_client_flash_erase_block(intel_mailbox_client* fd, int block_offset, int block_size)
{

 if(block_offset < 0 ||
   block_offset > dev_info->region_info.region_size - dev_info->region_info.block_size ||
   (block_offset & (SZ_4K - 1)) != 0)
 {
   return -EINVAL;
 }
}

I suggest changing the boundary check to use the local block_size parameter that was explicitly passed to the function:

if(block_offset < 0 ||
  block_offset > dev_info->region_info.region_size - block_size ||
  (block_offset & (SZ_4K - 1)) != 0)
{
  return -EINVAL;
}

A similar logic flaw exists in the caller function mailbox_client_flash_erase.
The input validation check uses the static hardware block size (dev_info->region_info.block_size) instead of taking the requested length into account.
I suppose this check should prevent out-of-bounds erases in the first place, so checking if there is one 64K block left in the flash is actually pointless. 

int mailbox_client_flash_erase(intel_mailbox_client* fd, int offset, int length)
{

   if(offset < 0 || offset > dev_info->region_info.region_size - dev_info->region_info.block_size)
   {
        return -EINVAL;
   }
}

I suggest using:

if(offset < 0 || offset > dev_info->region_info.region_size - length)
{
   return -EINVAL;
}

Any feedback on this behavior would be appreciated.

Thanks!