From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Chen Yu <yu.c.chen@intel.com>
Cc: linux-acpi@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>, Len Brown <lenb@kernel.org>,
Ashok Raj <ashok.raj@intel.com>, Mike Rapoport <rppt@kernel.org>,
Aubrey Li <aubrey.li@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/4] drivers/acpi: Introduce Platform Firmware Runtime Update device driver
Date: Fri, 22 Oct 2021 23:05:55 +0300 [thread overview]
Message-ID: <YXMZoz5vfwsawN49@smile.fi.intel.com> (raw)
In-Reply-To: <545536e714c32c905fd3614bf4fec65d11fb6541.1634899519.git.yu.c.chen@intel.com>
On Sat, Oct 23, 2021 at 01:09:51AM +0800, Chen Yu wrote:
> Introduce the pfru_update driver which can be used for Platform Firmware
> Runtime code injection and driver update[1]. The user is expected to
> provide the update firmware in the form of capsule file, and pass it to
> the driver via ioctl. Then the driver would hand this capsule file to the
> Platform Firmware Runtime Update via the ACPI device _DSM method. At last
> the low level Management Mode would do the firmware update.
>
> The corresponding userspace tool and man page will be introduced at
> tools/power/acpi/pfru.
>
> [1] https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf
Instead use Link: tag ?
...
> +enum cap_index {
> + CAP_STATUS_IDX,
> + CAP_UPDATE_IDX,
> + CAP_CODE_TYPE_IDX,
> + CAP_FW_VER_IDX,
> + CAP_CODE_RT_VER_IDX,
> + CAP_DRV_TYPE_IDX,
> + CAP_DRV_RT_VER_IDX,
> + CAP_DRV_SVN_IDX,
> + CAP_PLAT_ID_IDX,
> + CAP_OEM_ID_IDX,
> + CAP_OEM_INFO_IDX,
> + CAP_NR_IDX,
Is it terminator entry? Drop comma then. Same for all other similar cases.
> +};
...
> +static int get_image_type(efi_manage_capsule_image_header_t *img_hdr,
> + struct pfru_device *pfru_dev)
> +{
> + guid_t *image_type_id = &img_hdr->image_type_id;
> +
> + /* check whether this is a code injection or driver update */
> + if (guid_equal(image_type_id, &pfru_dev->code_uuid))
> + return CODE_INJECT_TYPE;
> + else if (guid_equal(image_type_id, &pfru_dev->drv_uuid))
> + return DRIVER_UPDATE_TYPE;
> + else
> + return -EINVAL;
In both cases redundant 'else'.
> +}
...
> +static int adjust_efi_size(efi_manage_capsule_image_header_t *img_hdr,
> + int size)
> +{
> + /*
> + * The (u64 hw_ins) was introduced in UEFI spec version 2,
> + * and (u64 capsule_support) was introduced in version 3.
> + * The size needs to be adjusted accordingly. That is to
> + * say, version 1 should subtract the size of hw_ins+capsule_support,
> + * and version 2 should sbstract the size of capsule_support.
> + */
> + size += sizeof(efi_manage_capsule_image_header_t);
> + switch (img_hdr->ver) {
> + case 1:
> + size -= 2 * sizeof(u64);
> + break;
> + case 2:
> + size -= sizeof(u64);
> + break;
> + default:
> + /* only support version 1 and 2 */
> + return -EINVAL;
> + }
> + return size;
Perhaps directly return this from the cases?
> +}
...
> +static long pfru_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> + struct pfru_update_cap_info cap;
> + struct pfru_device *pfru_dev;
> + void __user *p;
> + int ret = 0, rev;
return 0; (see below)?
> + pfru_dev = to_pfru_dev(file);
> + p = (void __user *)arg;
> +
> + switch (cmd) {
> + case PFRU_IOC_QUERY_CAP:
> + ret = query_capability(&cap, pfru_dev);
> + if (ret)
> + return ret;
> +
> + if (copy_to_user(p, &cap, sizeof(cap)))
> + return -EFAULT;
> +
> + break;
> + case PFRU_IOC_SET_REV:
> + if (copy_from_user(&rev, p, sizeof(unsigned int)))
> + return -EFAULT;
> +
> + if (!pfru_valid_revid(rev))
> + return -EINVAL;
> +
> + pfru_dev->rev_id = rev;
> + break;
> + case PFRU_IOC_STAGE:
> + ret = start_acpi_update(START_STAGE, pfru_dev);
> + break;
> + case PFRU_IOC_ACTIVATE:
> + ret = start_acpi_update(START_ACTIVATE, pfru_dev);
> + break;
> + case PFRU_IOC_STAGE_ACTIVATE:
> + ret = start_acpi_update(START_STAGE_ACTIVATE, pfru_dev);
> + break;
> + default:
> + ret = -ENOTTY;
> + break;
> + }
> + return ret;
You may return 0 here and directly return from the cases above.
> +}
...
> + /* map the communication buffer */
Comment style inconsistency. Compare to...
> + /* Check if the capsule header has a valid version number. */
...this one. However, here, since it's one line, no period is needed.
...
> +out:
> + devm_kfree(&pdev->dev, pfru_dev);
What is this? WHy?!
> +}
...
> +static int __init pfru_init(void)
> +{
> + return platform_driver_register(&acpi_pfru_driver);
> +}
> +
> +static void __exit pfru_exit(void)
> +{
> + platform_driver_unregister(&acpi_pfru_driver);
> +}
> +
> +module_init(pfru_init);
> +module_exit(pfru_exit);
NIH module_platform_driver().
...
> +#include <linux/uuid.h>
This is wrong. Please, use raw buffers.
...
Missed types.h.
...
> +struct pfru_payload_hdr {
> + __u32 sig;
> + __u32 hdr_version;
> + __u32 hdr_size;
> + __u32 hw_ver;
> + __u32 rt_ver;
> + uuid_t platform_id;
No way. Use __u8[16].
uuid_t is internal type for kernel.
> +};
...
> +struct pfru_update_cap_info {
> + enum pfru_dsm_status status;
> + __u32 update_cap;
> +
> + uuid_t code_type;
Ditto.
> + __u32 fw_version;
> + __u32 code_rt_version;
> + uuid_t drv_type;
Ditto.
> + __u32 drv_rt_version;
> + __u32 drv_svn;
> + uuid_t platform_id;
> + uuid_t oem_id;
Ditto.
> + char oem_info[];
> +};
...
> +struct pfru_updated_result {
> + enum pfru_dsm_status status;
> + enum pfru_dsm_status ext_status;
What?! Are you sure enum is the same size on all possible architectures?
> + __u64 low_auth_time;
> + __u64 high_auth_time;
> + __u64 low_exec_time;
> + __u64 high_exec_time;
> +};
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-10-22 20:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-22 17:09 [PATCH v5 0/4] Introduce Platform Firmware Runtime Update and Telemetry drivers Chen Yu
2021-10-22 17:09 ` [PATCH v5 1/4] efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures Chen Yu
2021-10-22 17:09 ` [PATCH v5 2/4] drivers/acpi: Introduce Platform Firmware Runtime Update device driver Chen Yu
2021-10-22 20:05 ` Andy Shevchenko [this message]
2021-10-23 13:15 ` Chen Yu
2021-10-22 17:10 ` [PATCH v5 3/4] drivers/acpi: Introduce Platform Firmware Runtime Update Telemetry Chen Yu
2021-10-22 20:08 ` Andy Shevchenko
2021-10-22 17:10 ` [PATCH v5 4/4] tools: Introduce power/acpi/pfru/pfru Chen Yu
2021-10-22 20:12 ` Andy Shevchenko
2021-10-23 13:19 ` Chen Yu
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=YXMZoz5vfwsawN49@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=ardb@kernel.org \
--cc=ashok.raj@intel.com \
--cc=aubrey.li@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rppt@kernel.org \
--cc=yu.c.chen@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.