Message ID | 20230801191629.45942-1-jorge.lopez2@hp.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f41:0:b0:3e4:2afc:c1 with SMTP id v1csp68099vqx; Tue, 1 Aug 2023 16:05:21 -0700 (PDT) X-Google-Smtp-Source: APBJJlE8hN/zRO5eqrbARSsjlQFeW9ttG5hn1kvDD0nJibILLgUcWRmA75ccZKDEQnRtPt/DyHEr X-Received: by 2002:a17:902:ec82:b0:1bb:9c45:130f with SMTP id x2-20020a170902ec8200b001bb9c45130fmr16737732plg.69.1690931121242; Tue, 01 Aug 2023 16:05:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690931121; cv=none; d=google.com; s=arc-20160816; b=0CAZlxf/g3zucJ5nAxp5XUxjl5Y2ldl9BNdlwdM269+J3SajnX6VHFtY/sALO/r5eh 60fMj/TtMp+uDhO2yV0DtWA+Isx5rIL88Av+mWPRLi4G/xLn29gUTm8PApVY/YZBmlPn 4BVyML/AQUURj8dtJ1tkmE4Dz2/pfKp4dYGKHsyplOGJgvA+JUe92rc3x9ZsALq3TRgE pYf0Kewtce3WD+3lim892oVLfT8WC0lTNOp+XYKLLoe4hPowzpphx9Z/Yw88J/LPqDs3 g7f8bmh/Jo0+hZtgYm6axjB4th3vrAFU9UBKk7SBEIvKRzL4+RvXlySDqNbQoiAKX+HA 0c6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=P/DiicnH3axzr7iqL00fOt/VCKsU/0ZbCcF8W8UmQHQ=; fh=SFEyBxM5WJZP1+1LTwWXXaFsrJtJ4d+K809teYU5Sxk=; b=b9I3J0YYgahYX+ffWnqM7KFJVNkdZX0XV5PFktWLTSmhha+rQzdTk+3G1BEge4eJbE AY00wRpPytdyWGAQ+ekWa+5Y33dB7ooRmYZsezAxwJ/Ear9KL+tCLd6WTlyWa8Uz3KiR slxY7az16SmLh9Sww4KcdhgO/4a3pQom44wXHPD0EuGLDbxOTDxTE5ZgMJgGduHWlKaL YXLwxNE8b7+4okZQbRa7o93VYCoWUIXYvXA7P+qVQDOf3Ew4dnmJSQAFgmrdM+bIPBMW /I673joIb4Ah9APqkT3NoDmp9g1s64StH8eywxfcAowApfbsd2Xw7fDjbmqi8c7S0ReN 5kxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=m26xAZ8i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b3-20020a170902650300b001bb97f19c0fsi9443961plk.248.2023.08.01.16.05.07; Tue, 01 Aug 2023 16:05:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=m26xAZ8i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230189AbjHATQd (ORCPT <rfc822;dengxinlin2429@gmail.com> + 99 others); Tue, 1 Aug 2023 15:16:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229650AbjHATQc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 1 Aug 2023 15:16:32 -0400 Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A55218B; Tue, 1 Aug 2023 12:16:31 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id 006d021491bc7-56ca4d7079aso2152632eaf.0; Tue, 01 Aug 2023 12:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690917391; x=1691522191; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=P/DiicnH3axzr7iqL00fOt/VCKsU/0ZbCcF8W8UmQHQ=; b=m26xAZ8i6jKtz/Yl/N5ClIAyAQgUcpy7TFLFCe8Ub5OEYhRIri93peDqRzKZcp7CEJ 7Nu+k1nszqz8kyp6IV95lJKs7kDqq9wkSPccrR8OUraCw5RfelGnD6ttAYu92hhS1cb6 I3tzvphXvZkV/IuqU/TD9FD3wY75ATeC9EzpO7Q1o8VDySTmfwQqqp7+Vb56fdQWFRNe AozoTFe4OoOwEgJZtod8nMD6qUOWLc3SVuQ+M+u/CLaNxGP34scGKsCEwiJUzJ/rP41p d6AzxVBggpb1Svog5c/c2ZSnvZ9lPdbVzLwtN5/YOJEzJGCXpDc8cclAlY/eflicC7Jj BmUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690917391; x=1691522191; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P/DiicnH3axzr7iqL00fOt/VCKsU/0ZbCcF8W8UmQHQ=; b=Xd02G1ln0aQ1HoIT/Gz9CYqC5egm3h+hsgTClp8ylK9yAwmVUas1sIBpxVFnM86kpp qw3sQMrIVWvx8hKJBlu6+mKnddgeVaerwpzYlWxKz5MSEqp+h75WdBML3RLNAm2HZQld aMUwG3t95OAv3BL2PUGtNm9YvReVJO3/+fgxg1s9bjgCuhkWSwJwjJ9qHTifYsihwj1f rmlgdvnTx4dh3qb7tsNkI+CCxGaytlyZKvWrQQqm51lBEXWnWjMkKd5+A9qnh50E4Aj+ NZEXTJci4d8Dqk/uiiOvDKmUBSp+O182hSA5fU1XXOz1aKR6JzKZhd7khTcd377hd3YQ PeIA== X-Gm-Message-State: ABy/qLaeY1XNn4nOw0bQ3Cgj6WWiZUTD3bZ3cX/e+DgN/mDb6rMqcqXA RpRAggU6ZID0EmJFrkEruA8= X-Received: by 2002:a05:6808:93:b0:3a7:5075:b0b8 with SMTP id s19-20020a056808009300b003a75075b0b8mr1985197oic.4.1690917390865; Tue, 01 Aug 2023 12:16:30 -0700 (PDT) Received: from grumpy-VECTOR.hsd1.tx.comcast.net ([2601:2c3:480:7390:2bee:a481:ab2e:3ea2]) by smtp.gmail.com with ESMTPSA id p64-20020acaf143000000b003a414415693sm5860738oih.44.2023.08.01.12.16.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 12:16:30 -0700 (PDT) From: Jorge Lopez <jorgealtxwork@gmail.com> X-Google-Original-From: Jorge Lopez <jorge.lopez2@hp.com> To: hdegoede@redhat.com, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, thomas@t-8ch.de, ilpo.jarvinen@linux.intel.com, dan.carpenter@linaro.org Subject: [PATCH] hp-bioscfg: Update string length calculation Date: Tue, 1 Aug 2023 14:16:29 -0500 Message-Id: <20230801191629.45942-1-jorge.lopez2@hp.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773069791504588441 X-GMAIL-MSGID: 1773069791504588441 |
Series |
hp-bioscfg: Update string length calculation
|
|
Commit Message
Jorge Lopez
Aug. 1, 2023, 7:16 p.m. UTC
Replace method how the string length is calculated.
Removed unused variable 'size'
Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com>
---
Based on the latest platform-drivers-x86.git/for-next
---
drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Comments
Hi Jorge, On 8/1/23 21:16, Jorge Lopez wrote: > Replace method how the string length is calculated. > Removed unused variable 'size' > > Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com> While reviewing this I have noticed that the parsing of ORD_LIST_ELEMENTS in hp_populate_ordered_list_elements_from_package() seems to be quite buggy: 1. Normally str_value and value_len get set for string type package elements by: case ACPI_TYPE_STRING: if (elem != PREREQUISITES && elem != ORD_LIST_ELEMENTS) { ret = hp_convert_hexstr_to_str(order_obj[elem].string.pointer, order_obj[elem].string.length, &str_value, &value_len); if (ret) continue; } break; But notice how the hp_convert_hexstr_to_str() call gets stepped when elem == ORD_LIST_ELEMENTS . Yes when next dealing with ORD_LIST_ELEMENTS the never updated str_value and value_len get used: switch (eloc) { ... case ORD_LIST_ELEMENTS: /* * Ordered list data is stored in hex and comma separated format * Convert the data and split it to show each element */ ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); if (ret) goto exit_list; So that does not seem right. 2. ordered_list_data->elements[0] never gets filled when there actually is a comma in the ordered-list, iow when there is more then 1 element: part_tmp = tmpstr; part = strsep(&part_tmp, COMMA_SEP); if (!part) strscpy(ordered_list_data->elements[0], tmpstr, sizeof(ordered_list_data->elements[0])); for (elem = 1; elem < MAX_ELEMENTS_SIZE && part; elem++) { strscpy(ordered_list_data->elements[elem], part, sizeof(ordered_list_data->elements[elem])); part = strsep(&part_tmp, SEMICOLON_SEP); } Notice how the for starts at elem = 1, so if part is not NULL (and it is never NULL for the first call strsep will always return tmpstr) then ordered_list_data->elements[0] never gets filled. 3. ordered_list_data->elements_size is set but never validated. You should compare elem after the loop with ordered_list_data->elements_size and make sure they match. IOW verify that 0-(ordered_list_data->elements_size-1) entries of the ordered_list_data->elements[] array have been filled. 4. For specific values of eloc the code expects the current order_obj[elem] to be either an integer or a string, but this is not validated. Please validate that order_obj[elem].type matches with what is expected (string or int) for the current value of eloc. This all makes me wonder if this specific code-path has been tested ? Please make sure to test this specific code-path. Regards, Hans > > --- > Based on the latest platform-drivers-x86.git/for-next > --- > drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > index cffc1c9ba3e7..b19644ed12e0 100644 > --- a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > +++ b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > @@ -258,13 +258,11 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord > eloc++; > break; > case ORD_LIST_ELEMENTS: > - size = ordered_list_data->elements_size; > - > /* > * Ordered list data is stored in hex and comma separated format > * Convert the data and split it to show each element > */ > - ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); > + ret = hp_convert_hexstr_to_str(str_value, strlen(str_value), &tmpstr, &tmp_len); > if (ret) > goto exit_list; > > @@ -279,7 +277,7 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord > strscpy(ordered_list_data->elements[olist_elem], > part, > sizeof(ordered_list_data->elements[olist_elem])); > - part = strsep(&part_tmp, SEMICOLON_SEP); > + part = strsep(&part_tmp, COMMA_SEP); > } > > kfree(str_value);
Hi Hans, On Mon, Aug 7, 2023 at 6:28 AM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi Jorge, > > On 8/1/23 21:16, Jorge Lopez wrote: > > Replace method how the string length is calculated. > > Removed unused variable 'size' > > > > Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com> > > While reviewing this I have noticed that the parsing of ORD_LIST_ELEMENTS > in hp_populate_ordered_list_elements_from_package() seems to be quite buggy: > > 1. Normally str_value and value_len get set for string type package elements by: > > case ACPI_TYPE_STRING: > if (elem != PREREQUISITES && elem != ORD_LIST_ELEMENTS) { > ret = hp_convert_hexstr_to_str(order_obj[elem].string.pointer, > order_obj[elem].string.length, > &str_value, &value_len); > if (ret) > continue; > } > break; > > But notice how the hp_convert_hexstr_to_str() call gets stepped when > elem == ORD_LIST_ELEMENTS . > > Yes when next dealing with ORD_LIST_ELEMENTS the never updated str_value and value_len > get used: > > switch (eloc) { > ... > case ORD_LIST_ELEMENTS: > /* > * Ordered list data is stored in hex and comma separated format > * Convert the data and split it to show each element > */ > ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); > if (ret) > goto exit_list; > > So that does not seem right. I will investigate. > > 2. ordered_list_data->elements[0] never gets filled when there actually is a comma in > the ordered-list, iow when there is more then 1 element: > > part_tmp = tmpstr; > part = strsep(&part_tmp, COMMA_SEP); > if (!part) > strscpy(ordered_list_data->elements[0], > tmpstr, > sizeof(ordered_list_data->elements[0])); > > for (elem = 1; elem < MAX_ELEMENTS_SIZE && part; elem++) { > strscpy(ordered_list_data->elements[elem], > part, > sizeof(ordered_list_data->elements[elem])); > part = strsep(&part_tmp, SEMICOLON_SEP); > } > > Notice how the for starts at elem = 1, so if part is not NULL (and it is never NULL for the first call strsep will always return tmpstr) then ordered_list_data->elements[0] never gets filled. > I will investigate and make the necessary corrections. > 3. ordered_list_data->elements_size is set but never validated. You should compare elem after the loop with ordered_list_data->elements_size and make sure they match. IOW verify that 0-(ordered_list_data->elements_size-1) entries of the ordered_list_data->elements[] array have been filled. ordered_list_data->elements_size is checked against MAX_ELEMENTS_SIZE and not against the number of elements in the array. Initially, size value was reported (sysfs) but after a couple reviews, size was removed from being reported (sysfs). size value will be determined by the application when it enumerates the values reported in elements. > > 4. For specific values of eloc the code expects the current order_obj[elem] to be either an integer or a string, but this is not validated. Please validate that order_obj[elem].type matches with what is expected (string or int) for the current value of eloc. The purpose for 'eloc' is to help skip reading values such ORD_LIST_ELEMENTS and PREREQUISITES when ORD_LIST_ELEMENTS and/or PREREQUISITES_SIZE values are zero. Normally, 'eloc' and 'elem' are the same. > > This all makes me wonder if this specific code-path has been tested ? Please make sure to test this specific code-path. > This code path was tested previously. I will make sure the path is tested in deeper detail. > Regards, > > Hans > > > > > > > > > --- > > Based on the latest platform-drivers-x86.git/for-next > > --- > > drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c | 6 ++---- > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > > index cffc1c9ba3e7..b19644ed12e0 100644 > > --- a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > > +++ b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c > > @@ -258,13 +258,11 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord > > eloc++; > > break; > > case ORD_LIST_ELEMENTS: > > - size = ordered_list_data->elements_size; > > - > > /* > > * Ordered list data is stored in hex and comma separated format > > * Convert the data and split it to show each element > > */ > > - ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); > > + ret = hp_convert_hexstr_to_str(str_value, strlen(str_value), &tmpstr, &tmp_len); > > if (ret) > > goto exit_list; > > > > @@ -279,7 +277,7 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord > > strscpy(ordered_list_data->elements[olist_elem], > > part, > > sizeof(ordered_list_data->elements[olist_elem])); > > - part = strsep(&part_tmp, SEMICOLON_SEP); > > + part = strsep(&part_tmp, COMMA_SEP); > > } > > > > kfree(str_value); >
Hi, On 8/8/23 22:25, Jorge Lopez wrote: > Hi Hans, > > On Mon, Aug 7, 2023 at 6:28 AM Hans de Goede <hdegoede@redhat.com> wrote: <snip> >> 3. ordered_list_data->elements_size is set but never validated. You should compare elem after the loop with ordered_list_data->elements_size and make sure they match. IOW verify that 0-(ordered_list_data->elements_size-1) entries of the ordered_list_data->elements[] array have been filled. > > ordered_list_data->elements_size is checked against MAX_ELEMENTS_SIZE > and not against the number of elements in the array. Initially, size > value was reported (sysfs) but after a couple reviews, size was > removed from being reported (sysfs). size value will be determined by > the application when it enumerates the values reported in elements. Right, but after splitting the string on commas there should be ordered_list_data->elements_size entries, right ? So we should verify that. Also what if the string after splitting has more entries then MAX_ELEMENTS_SIZE, then currently the code will overflow the array, so the loop splitting the string on commas should ensure that MAX_ELEMENTS_SIZE is not exceeded. >> >> 4. For specific values of eloc the code expects the current order_obj[elem] to be either an integer or a string, but this is not validated. Please validate that order_obj[elem].type matches with what is expected (string or int) for the current value of eloc. > > The purpose for 'eloc' is to help skip reading values such > ORD_LIST_ELEMENTS and PREREQUISITES when ORD_LIST_ELEMENTS and/or > PREREQUISITES_SIZE values are zero. > Normally, 'eloc' and 'elem' are the same. Never mind what I meant to say is that you should to a check like this: /* Check that both expected and read object type match */ if (expected_order_types[eloc] != order_obj[elem].type) { pr_err("Error expected type %d for elem %d, but got type %d instead\n" expected_order_types[eloc], elem, order_obj[elem].type); return -EIO; } But I see now that that check is already there. Regards, Hans
On Tue, Aug 8, 2023 at 4:52 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 8/8/23 22:25, Jorge Lopez wrote: > > Hi Hans, > > > > On Mon, Aug 7, 2023 at 6:28 AM Hans de Goede <hdegoede@redhat.com> wrote: > > <snip> > > >> 3. ordered_list_data->elements_size is set but never validated. You should compare elem after the loop with ordered_list_data->elements_size and make sure they match. IOW verify that 0-(ordered_list_data->elements_size-1) entries of the ordered_list_data->elements[] array have been filled. > > > > ordered_list_data->elements_size is checked against MAX_ELEMENTS_SIZE > > and not against the number of elements in the array. Initially, size > > value was reported (sysfs) but after a couple reviews, size was > > removed from being reported (sysfs). size value will be determined by > > the application when it enumerates the values reported in elements. > > Right, but after splitting the string on commas there should be ordered_list_data->elements_size entries, right ? So we should verify that. Also what if the string after splitting has more entries then MAX_ELEMENTS_SIZE, then currently the code will overflow the array, so the loop splitting the string on commas should ensure that MAX_ELEMENTS_SIZE is not exceeded. That is correct. It is expected for the element size value to be 1 and does not represent the actual number of elements stored in comma separated format. Element size value will be recalculated to report the correct number of data elements present. The loop restricts the max number of elements to MAX_ELEMENTS_SIZE to avoid overflow the array.. I will make the necessary correction. > > >> > >> 4. For specific values of eloc the code expects the current order_obj[elem] to be either an integer or a string, but this is not validated. Please validate that order_obj[elem].type matches with what is expected (string or int) for the current value of eloc. > > > > The purpose for 'eloc' is to help skip reading values such > > ORD_LIST_ELEMENTS and PREREQUISITES when ORD_LIST_ELEMENTS and/or > > PREREQUISITES_SIZE values are zero. > > Normally, 'eloc' and 'elem' are the same. > > Never mind what I meant to say is that you should to a check like this: > > /* Check that both expected and read object type match */ > if (expected_order_types[eloc] != order_obj[elem].type) { > pr_err("Error expected type %d for elem %d, but got type %d instead\n" > expected_order_types[eloc], elem, order_obj[elem].type); > return -EIO; > } > > But I see now that that check is already there. > > Regards, > > Hans > >
diff --git a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c index cffc1c9ba3e7..b19644ed12e0 100644 --- a/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c +++ b/drivers/platform/x86/hp/hp-bioscfg/order-list-attributes.c @@ -258,13 +258,11 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord eloc++; break; case ORD_LIST_ELEMENTS: - size = ordered_list_data->elements_size; - /* * Ordered list data is stored in hex and comma separated format * Convert the data and split it to show each element */ - ret = hp_convert_hexstr_to_str(str_value, value_len, &tmpstr, &tmp_len); + ret = hp_convert_hexstr_to_str(str_value, strlen(str_value), &tmpstr, &tmp_len); if (ret) goto exit_list; @@ -279,7 +277,7 @@ static int hp_populate_ordered_list_elements_from_package(union acpi_object *ord strscpy(ordered_list_data->elements[olist_elem], part, sizeof(ordered_list_data->elements[olist_elem])); - part = strsep(&part_tmp, SEMICOLON_SEP); + part = strsep(&part_tmp, COMMA_SEP); } kfree(str_value);