Given the existing code in iwl_dbg_tlv_update_drams(), the
following can happen and cause firmware asserts, and even
the device to become unusable:

 * We set the magic so the firmware will use the data;
 * we try to fill multiple allocation IDs, with at least
   one successful, but - crucially - one failing and thus
   not touching the data;
 * we don't clear the data since there was one success.

This doesn't seem like much of a problem just yet, however,
what happens now is that the allocation ID(s) that failed
are not initialized.

There are two additional things to know:
 * we never free these allocations across FW restart or
   interface down/up etc., in fact we never free them until
   the driver is unbound from the device (e.g. unloaded)
 * the firmware uses the DRAM info structure for real debug
   data when it has used it completely

Given that, and the fact that we never initialize the data
on restart, we can be unlucky and end up with an allocation
that looks for the most part valid (valid ID, valid number
of buffers, etc.) but has bad sizes - causing the firmware
to throw an assert we can never recover from.

Fixing the code to have the entire buffers cleared (which
we should do so old debug data isn't sticking around) is a
bit more complex, so as a first step make the actual code
that fills the information more robust by clearing the
structure first, and filling the magic values only if it
actually succeeded for one, rather than doing it the other
way around.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.87cf5528f4bc.I26ac907a4162297808b33467fc7f5d8177474a34@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>