Hi Ben,

Le Wednesday 10 July 2013 à 15:32 +0100, Ben Hutchings a écrit :
> My previous refactoring in commit 79bae42d51a5 resulted in slightly
> tricky code (though I think it's more elegant).  Explain what it's
> doing.

You are being very nice to me, not sure I deserve it ;-)

> Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
> ---
>  drivers/firmware/dmi_scan.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index b95159b..4fdb377 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -419,6 +419,13 @@ static void __init dmi_format_ids(char *buf, size_t len)
>                           dmi_get_system_info(DMI_BIOS_DATE));
>  }
>  
> +/*
> + * Check for DMI/SMBIOS headers in the system firmware image.  Any
> + * SMBIOS header must start 16 bytes before the DMI header, so take a
> + * 32 byte buffer and check for DMI at offset 16 and SMBIOS at offset
> + * 0.  If the DMI header is present, set dmi_ver accordingly (SMBIOS
> + * takes precedence) and return 0.  Otherwise return 1.
> + */
>  static int __init dmi_present(const u8 *buf)
>  {
>       int smbios_ver;
> @@ -506,6 +513,13 @@ void __init dmi_scan_machine(void)
>               if (p == NULL)
>                       goto error;
>  
> +             /*
> +              * Iterate over all possible DMI header addresses q.
> +              * Maintain the 32 bytes around q in buf.  On the
> +              * first iteration, substitute zero for the
> +              * out-of-range bytes so there is no chance of falsely
> +              * detecting an SMBIOS header.
> +              */
>               memset(buf, 0, 16);
>               for (q = p; q < p + 0x10000; q += 16) {
>                       memcpy_fromio(buf + 16, q, 16);
> 

Yes, I like it, good idea.

Reviewed-by: Jean Delvare <jdelv...@suse.de>

-- 
Jean Delvare
Suse L3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to