> Because if working under ACPI4.x without param_extension support, there
> is possible that einj_param has meaning (maybe containing address info?),
> but we just ignore it under current implementation. Maybe in future we
> need it so I don't hope to return NULL so early. OTOH, my fix is just
> ignore einj_param in current logic, not very destructive.
I'm not sure that we'd ever add such extra meaning to einj_param. There
aren't going to be any more updates to ACPI 4.x.
Just from a naming point of view - if we don't have the "param" extension
enabled - why would "einj_param" need to be set at all?
Stopping early has other advantages:
1) We don't set up a mapping that we'll never use with:
v4param = acpi_os_map_memory(paddrv4, sizeof (*v4param));
2) We won't uselessly dereference that mapping:
if (v4param->reserved1 || v4param->reserved2)
-Tony
��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
