Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1460125rwr; Fri, 5 May 2023 14:41:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5JojW0m3gd4AWhb16KuX1g8+1NqccS74EIcov+xJF0LiL1DTvzaxmA5JkCg7qeFOVWj9x1 X-Received: by 2002:a05:6a20:7d9d:b0:ff:7e58:c232 with SMTP id v29-20020a056a207d9d00b000ff7e58c232mr7948pzj.39.1683322915148; Fri, 05 May 2023 14:41:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683322915; cv=none; d=google.com; s=arc-20160816; b=JwigAahsfCkcchKSXNYDpfnY+lslfYDa8a8a5yduxia2f2ACLo2U/uBJvcQpsd03q3 JcSOo5NxdKe8EzNaF+KwoovaXRIBmHgdzIrnIt3WQ+A/rXIFFdd5OQKb7T5FQFb/9r5T gwcTeYKVpcEYOpfvL3prZwm0rLk6VLscOjDGD3nrPbU+5sR/9d8EMh9PhMPz+Sf+6AiY VaoEa1jUMRtmOLbKgGU9LSLz+Lx0KTTCO6akNdhaW20vS6d86gVVBoFpDrexyaV1ybgF i48Hx7Pgw4v8Q4EdHmUjZkhptSwTClPqClhSHzfHsE+EDUMcWQTC8kTghmTcVLGBwolE GLRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:dkim-signature:date; bh=WFMxpe4mZWogHKuyhL/moTpE2yTVhbcW6gKKP/qoOuc=; b=gq1pt50jwdu2ksieNb/bZgwD2nhWTVmBgRsNe7+GErtg/k24cEfAK+ChLj+oRWp+PH kWCO1qqSW46RAfAyJCnrXe3jj8vITfb314TmqLQQyyWP+ctGOBhxnLK6iizmeg6yBexV /4tfsimZk9GF/in6qaUIv6r2sW9xO93M5yKi70ghM74Zy+0VmbRZkqLloh41OY9gdCUc 35zHeTVbjxI5ipCeKKS4OFmlq4HwDHslfE6d+G4Ul0o6vPCnkk+gok+blXYm80POKxsU m7XEcHjBoZ7jnBHZJhH46Zrq8kC+1lrOiGL8xy8CtoHifHaCNZZLhT/+z8FxeMnQ3Dxp wVeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@t-8ch.de header.s=mail header.b=aLgyEs4h; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r7-20020a63e507000000b004fc39adf481si3046366pgh.381.2023.05.05.14.41.41; Fri, 05 May 2023 14:41:54 -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=@t-8ch.de header.s=mail header.b=aLgyEs4h; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231679AbjEEVLS (ORCPT + 99 others); Fri, 5 May 2023 17:11:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230106AbjEEVLR (ORCPT ); Fri, 5 May 2023 17:11:17 -0400 Received: from todd.t-8ch.de (todd.t-8ch.de [IPv6:2a01:4f8:c010:41de::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C16F46B7; Fri, 5 May 2023 14:11:14 -0700 (PDT) Date: Fri, 5 May 2023 23:11:11 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=t-8ch.de; s=mail; t=1683321072; bh=9K6Xo+2FAJY+HhScMhfLDUV2iVPLGTOgwshlRYpJtn0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aLgyEs4ht/xCZ7IBeqZlcbhJpk7ww/UkEz1CVQ4/B0snE7Wg+z97dD1Vv9jCVS8ao J5bARIl3v/453B8nuPvbGBw3JF5xqXHUGvE/3Rerr4odYyNeWHGcXgVMM9dn7lBOP2 MRr3YDQ6eF4Hv6nG11aMNKBE8iVE4xgjlJqxKGGA= From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Jorge Lopez Cc: hdegoede@redhat.com, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 05/14] HP BIOSCFG driver - ordered-attributes Message-ID: <34539db1-98a4-4696-934b-af04d74720cc@t-8ch.de> References: <20230420165454.9517-1-jorge.lopez2@hp.com> <20230420165454.9517-6-jorge.lopez2@hp.com> <24fb56f9-49c6-432d-8c2f-17df7f7e37b2@t-8ch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-05-05 11:09:55-0500, Jorge Lopez wrote: > On Sun, Apr 23, 2023 at 1:55 AM wrote: > > > > On 2023-04-20 11:54:45-0500, Jorge Lopez wrote: > > > .../x86/hp/hp-bioscfg/ordered-attributes.c | 563 ++++++++++++++++++ > > > 1 file changed, 563 insertions(+) > > > create mode 100644 drivers/platform/x86/hp/hp-bioscfg/ordered-attributes.c > > > > > > diff --git a/drivers/platform/x86/hp/hp-bioscfg/ordered-attributes.c b/drivers/platform/x86/hp/hp-bioscfg/ordered-attributes.c > > > new file mode 100644 > > > index 000000000000..5e5d540f728d > > > --- /dev/null > > > +++ b/drivers/platform/x86/hp/hp-bioscfg/ordered-attributes.c > > > @@ -0,0 +1,563 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Functions corresponding to ordered list type attributes under > > > + * BIOS ORDERED LIST GUID for use with hp-bioscfg driver. > > > + * > > > + * Copyright (c) 2022 HP Development Company, L.P. > > > + */ > > > + > > > +#include "bioscfg.h" > > > + > > > +GET_INSTANCE_ID(ordered_list); > > > + > > > +static ssize_t current_value_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf) > > > +{ > > > + > > > + int instance_id = get_ordered_list_instance_id(kobj); > > > + > > > + if (instance_id < 0) > > > + return -EIO; > > > + > > > + return sysfs_emit(buf, "%s\n", > > > + bioscfg_drv.ordered_list_data[instance_id].current_value); > > > +} > > > + > > > +/* > > > + * validate_ordered_list_value - > > > + * Validate input of current_value against possible values > > > > Does the firmware not also validate this? > > > > If so it may be easier to just let it do so and remove the validations > > from the driver. > > Yes. the firmware validates the data. > Will remove the validation > > > > > + * > > > + * @instance_id: The instance on which input is validated > > > + * @buf: Input value > > > + */ > > > +static int validate_ordered_list_values(int instance_id, const char *buf) > > > +{ > > > + int ret = 0; > > > + int found = 0; > > > + char *new_values = NULL; > > > + char *value; > > > + int elem; > > > + int elem_found = 0; > > > + > > > + /* Is it a read only attribute */ > > > + if (bioscfg_drv.ordered_list_data[instance_id].common.is_readonly) > > > + return -EIO; > > > + > > > + new_values = kstrdup(buf, GFP_KERNEL); > > > + > > > + /* > > > + * Changes to ordered list values require checking that new > > > + * values are found in the list of elements. > > > + */ > > > + elem_found = 0; > > > + while (elem_found < bioscfg_drv.ordered_list_data[instance_id].elements_size) { > > > + > > > + value = strsep(&new_values, ","); > > > > The docs say the separator is semicolon. > > BIOS reports the current value using ',' as separator instead of ";". > > ./hp-bioscfg/attributes/UEFI Boot Order/current_value > HDD:M.2:3,HDD:USB:1(Disabled),HDD:M.2:4,HDD:M.2:1,HDD:M.2:2,NETWORK > IPV4:EMBEDDED:1,NETWORK IPV6:EMBEDDED:1,NETWORK > IPV4:EXPANSION:1,NETWORK IPV6:EXPANSION:1 > > To avoid having to convert from "," to ";" and vice versa, I will > update the documentation to reflect the use of "'," commas as the > separator The enum data format uses ";". Therefore it makes sense to also stick to ";". The implementation detail of the BIOS using ',' should not matter to users. > > > + if (value != NULL) { > > > + if (!*value) > > > + continue; > > > + elem_found++; > > > + } > > > + > > > + found = 0; > > > + for (elem = 0; elem < bioscfg_drv.ordered_list_data[instance_id].elements_size; elem++) { > > > + if (!strcasecmp(bioscfg_drv.ordered_list_data[instance_id].elements[elem], value)) { > > > > It's surprising that this is case-insensitive. > > As validated in earlier reviews, BIOS rejects strings that do not > match the internal values. > > > > > > + found = 1; > > > + break; > > > + } > > > + } > > > + > > > + > > > + if (!found) { > > > + ret = -EINVAL; > > > + goto out_list_value; > > > + } > > > + } > > > + > > > + if (elem_found == bioscfg_drv.ordered_list_data[instance_id].elements_size) { > > > + pr_warn("Number of new values is not equal to number of ordered list elements (%d)\n", > > > + bioscfg_drv.ordered_list_data[instance_id].elements_size); > > > + ret = -EINVAL; > > > + goto out_list_value; > > > + } > > > + > > > +out_list_value: > > > + kfree(new_values); > > > + return ret; > > > +} > > > > This algorithm does not seem to validate that different values are > > provided. > > > > So if "possible_values" is "foo,bar,baz" this function would accept > > "foo,foo,foo". > > > > BIOS will reject strings such as "foo,foo,foo" when the current value > is "foo,bar,baz". It is ok to provide a string which items are > ordered differently. i.e. "baz,bar,foo" > validate_ordered_list_values() function will be removed as indicated earlier. > > > > + > > > +/* > > > + * validate_ordered_input() - > > > + * Validate input of current_value against possible values > > > + * > > > + * @instance_id: The instance on which input is validated > > > + * @buf: Input value > > > + */ > > > +static int validate_ordered_list_input(int instance_id, const char *buf) > > > +{ > > > + int ret = 0; > > > + > > > + ret = validate_ordered_list_values(instance_id, buf); > > > + if (ret < 0) > > > + return -EINVAL; > > > + > > > + /* > > > + * set pending reboot flag depending on > > > + * "RequiresPhysicalPresence" value > > > + */ > > > + if (bioscfg_drv.ordered_list_data[instance_id].common.requires_physical_presence) > > > + bioscfg_drv.pending_reboot = true; > > > + > > > + return ret; > > > +} > > > + > > > +static void update_ordered_list_value(int instance_id, char *attr_value) > > > +{ > > > + strscpy(bioscfg_drv.ordered_list_data[instance_id].current_value, > > > + attr_value, > > > + sizeof(bioscfg_drv.ordered_list_data[instance_id].current_value)); > > > +} > > > + > > > +ATTRIBUTE_S_COMMON_PROPERTY_SHOW(display_name_language_code, ordered_list); > > > +static struct kobj_attribute ordered_list_display_langcode = > > > + __ATTR_RO(display_name_language_code); > > > + > > > +ATTRIBUTE_S_COMMON_PROPERTY_SHOW(display_name, ordered_list); > > > +static struct kobj_attribute ordered_list_display_name = > > > + __ATTR_RO(display_name); > > > + > > > +ATTRIBUTE_PROPERTY_STORE(current_value, ordered_list); > > > +static struct kobj_attribute ordered_list_current_val = > > > + __ATTR_RW_MODE(current_value, 0644); > > > + > > > + > > > +ATTRIBUTE_N_COMMON_PROPERTY_SHOW(prerequisites_size, ordered_list); > > > +static struct kobj_attribute ordered_list_prerequisites_size_val = > > > + __ATTR_RO(prerequisites_size); > > > + > > > +ATTRIBUTE_V_COMMON_PROPERTY_SHOW(prerequisites, ordered_list); > > > +static struct kobj_attribute ordered_list_prerequisites_val = > > > + __ATTR_RO(prerequisites); > > > + > > > +ATTRIBUTE_N_PROPERTY_SHOW(elements_size, ordered_list); > > > +static struct kobj_attribute ordered_list_elements_size_val = > > > + __ATTR_RO(elements_size); > > > > "size" and "length" attributes are fairly useless to userspace. > > They can't be trusted to provide information about another attribute as > > the information can be out of date when the other attribute is read. > > > > Prerequisites, prerequisites_size and elements_size will be removed > > > > + > > > +ATTRIBUTE_VALUES_PROPERTY_SHOW(elements, ordered_list); > > > +static struct kobj_attribute ordered_list_elements_val = > > > + __ATTR_RO(elements); > > > + > > > > > > + > > > + > > > +int populate_ordered_list_elements_from_package(union acpi_object *order_obj, > > > + int order_obj_count, > > > + int instance_id) > > > +{ > > > + char *str_value = NULL; > > > + int value_len; > > > + int ret = 0; > > > + u32 size = 0; > > > + u32 int_value; > > > + int elem = 0; > > > + int reqs; > > > + int eloc; > > > + char *tmpstr = NULL; > > > + char *part_tmp = NULL; > > > + int tmp_len = 0; > > > + char *part = NULL; > > > + > > > + if (!order_obj) > > > + return -EINVAL; > > > + > > > + strscpy(bioscfg_drv.ordered_list_data[instance_id].common.display_name_language_code, > > > + LANG_CODE_STR, > > > + sizeof(bioscfg_drv.ordered_list_data[instance_id].common.display_name_language_code)); > > > > This seems to be the same for every type. Can it not be moved into > > common code? > > Each instance requires to report 'display_name_language_code' hence it > cannot be moved to a common code. Can it every be different from LANG_CODE_STR? If not instead of having one kobj_attribute diplay_langcode for each string/enum/integer/etc you could have one kobj_attribute defined in bioscfg.c and then added to each string_attrs, enum_attrs... The _show() callback for this attribute would just return the constant string. This removes the need for many attribute definition, members in the data struct, initialization of these member...