[RFC] drm/pvr: define oversized freelist reconstruction handling

[Pengpeng Hou <pengpeng@iscas.ac.cn>]

pvr_free_list_process_reconstruct_req() receives a reconstruction count
from firmware and uses it to iterate the request ID array and populate the
response ID array. Both arrays have
ROGUE_FWIF_MAX_FREELISTS_TO_RECONSTRUCT entries, but the count is not
checked against that limit.

An oversized count would therefore make the loop and memcpy() access past
the fixed protocol objects. The bounds issue is clear, but I could not find
an ABI-defined completion for a malformed whole request.

In particular, clamping does not appear justified. It changes the response
count and silently omits IDs that firmware claims to have supplied. Dropping
the request may leave firmware waiting for the reconstruction update, while
echoing the original count cannot be represented safely in the fixed
response.

For comparison, the older Imagination host implementation also assumes a
valid count, processes that many entries and echoes the count in the update:

https://android.googlesource.com/kernel/mediatek/+/android-mtk-3.18/drivers/staging/imgtec/rogue/rgxta3d.c#710

The current ABI provides a per-freelist reconstruction-failed flag, but no
whole-request error value for an invalid count.

What is the intended recovery when firmware supplies a count above the
protocol maximum? Should the driver treat it as a firmware-fatal condition,
complete a bounded subset, or use another firmware-defined response? Once
that contract is clear, I can prepare a narrow patch without inventing new
firmware semantics.