On Tue, Apr 11, 2017 at 11:14:30AM +0200, Thierry Escande wrote: > From: Wei-Ning Huang <[email protected]> > > This patch imports lib_vpd.h and vpd_decode.c from the Chromium Vital > Product Data project. > > This library is used to parse VPD sections obtained from coreboot table > entries describing Chromebook devices product data. Only the sections of > type VPD_TYPE_STRING are decoded. > > The VPD string sections in the coreboot tables contain the type (1 byte > set to 0x01 for strings), the key length, the key ascii array, the value > length, and the value ascii array. The key and value arrays are not null > terminated. > > Signed-off-by: Wei-Ning Huang <[email protected]> > Signed-off-by: Thierry Escande <[email protected]> > --- > drivers/firmware/google/vpd_decode.c | 99 > ++++++++++++++++++++++++++++++++++++ > drivers/firmware/google/vpd_decode.h | 59 +++++++++++++++++++++ > 2 files changed, 158 insertions(+) > create mode 100644 drivers/firmware/google/vpd_decode.c > create mode 100644 drivers/firmware/google/vpd_decode.h > > diff --git a/drivers/firmware/google/vpd_decode.c > b/drivers/firmware/google/vpd_decode.c > new file mode 100644 > index 0000000..75e4027 > --- /dev/null > +++ b/drivers/firmware/google/vpd_decode.c > @@ -0,0 +1,99 @@ > +/* > + * vpd_decode.c > + * > + * Google VPD decoding routines. > + * > + * Copyright 2017 Google Inc. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License v2.0 as published by > + * the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include <linux/export.h> > + > +#include "vpd_decode.h" > + > +static int decode_len(const int32_t max_len, const uint8_t *in, > + int32_t *length, int32_t *decoded_len) > +{ > + uint8_t more;
Care to use "real" kernel variable types please? u8, u16, and others are you friend, uint8_t really isn't what we prefer, and checkpatch should tell you that... thanks, greg k-h
