From: Guenter Roeck <linux@roeck-us.net>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Hung-Te Lin <hungte@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Anton Vasilyev <vasilyev@ispras.ru>,
Colin Ian King <colin.king@canonical.com>,
Thomas Gleixner <tglx@linutronix.de>,
Alexios Zavras <alexios.zavras@intel.com>,
Samuel Holland <samuel@sholland.org>,
Allison Randal <allison@lohutok.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firmware: google: update vpd_decode from upstream
Date: Wed, 7 Aug 2019 06:58:34 -0700 [thread overview]
Message-ID: <20190807135834.GA12853@roeck-us.net> (raw)
In-Reply-To: <5d44b8eb.1c69fb81.6d1c1.7d80@mx.google.com>
On Fri, Aug 02, 2019 at 03:27:54PM -0700, Stephen Boyd wrote:
> Quoting Hung-Te Lin (2019-08-02 01:20:31)
> > The VPD implementation from Chromium Vital Product Data project has been
> > updated so vpd_decode be easily shared by kernel, firmware and the user
> > space utility programs. Also improved value range checks to prevent
> > kernel crash due to bad VPD data.
>
> Please add a Fixes: tag here to fix the commit that introduces the
> problem. It would also be nice to get a description of the problem that
> this patch is fixing. For example, explaining why the types change from
> signed to unsigned.
>
> >
> > Signed-off-by: Hung-Te Lin <hungte@chromium.org>
> > ---
> > drivers/firmware/google/vpd.c | 38 +++++++++------
> > drivers/firmware/google/vpd_decode.c | 69 +++++++++++++++-------------
> > drivers/firmware/google/vpd_decode.h | 17 ++++---
> > 3 files changed, 71 insertions(+), 53 deletions(-)
> >
> > diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> > index 0739f3b70347..ecf217a7db39 100644
> > --- a/drivers/firmware/google/vpd.c
> > +++ b/drivers/firmware/google/vpd.c
> > @@ -73,7 +73,7 @@ static ssize_t vpd_attrib_read(struct file *filp, struct kobject *kobp,
> > * exporting them as sysfs attributes. These keys present in old firmwares are
> > * ignored.
> > *
> > - * Returns VPD_OK for a valid key name, VPD_FAIL otherwise.
> > + * Returns VPD_DECODE_OK for a valid key name, VPD_DECODE_FAIL otherwise.
>
> Maybe we should convert these things to use linux conventions instead of
> VPD error codes?
>
> > *
> > * @key: The key name to check
> > * @key_len: key name length
> > @@ -86,14 +86,14 @@ static int vpd_section_check_key_name(const u8 *key, s32 key_len)
> > c = *key++;
> >
> > if (!isalnum(c) && c != '_')
> > - return VPD_FAIL;
> > + return VPD_DECODE_FAIL;
> > }
> >
> > - return VPD_OK;
> > + return VPD_DECODE_OK;
>
> Can you split this rename out into it's own patch. That way we can
> confirm that there are no changes due to the rename of the enum.
>
> > }
> >
> > -static int vpd_section_attrib_add(const u8 *key, s32 key_len,
> > - const u8 *value, s32 value_len,
> > +static int vpd_section_attrib_add(const u8 *key, u32 key_len,
> > + const u8 *value, u32 value_len,
> > void *arg)
> > {
> > int ret;
> > @@ -246,7 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
> >
> > static int vpd_sections_init(phys_addr_t physaddr)
> > {
> > - struct vpd_cbmem *temp;
> > + struct vpd_cbmem __iomem *temp;
The change to __iomem should also be a separate patch.
Guenter
next prev parent reply other threads:[~2019-08-07 13:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 8:20 [PATCH] firmware: google: update vpd_decode from upstream Hung-Te Lin
2019-08-02 22:27 ` Stephen Boyd
2019-08-07 13:58 ` Guenter Roeck [this message]
2019-08-07 14:59 ` Stephen Boyd
2019-08-07 16:50 ` Guenter Roeck
2019-08-29 10:19 ` [PATCH v2] " Hung-Te Lin
2019-08-29 11:24 ` Greg Kroah-Hartman
2019-08-29 11:45 ` [PATCH v3] firmware: google: check if size is valid when decoding VPD data Hung-Te Lin
2019-08-29 14:51 ` Stephen Boyd
2019-08-30 2:23 ` [PATCH v4] " Hung-Te Lin
2019-08-30 5:03 ` Stephen Boyd
2019-08-30 16:54 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190807135834.GA12853@roeck-us.net \
--to=linux@roeck-us.net \
--cc=alexios.zavras@intel.com \
--cc=allison@lohutok.net \
--cc=colin.king@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=hungte@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel@sholland.org \
--cc=swboyd@chromium.org \
--cc=tglx@linutronix.de \
--cc=vasilyev@ispras.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox