From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Chen Yu <yu.c.chen@intel.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
Aubrey Li <aubrey.li@intel.com>, Ashok Raj <ashok.raj@intel.com>,
Mike Rapoport <rppt@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Hans de Goede <hdegoede@redhat.com>,
Ben Widawsky <ben.widawsky@intel.com>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v3 3/5] drivers/acpi: Introduce Platform Firmware Runtime Update device driver
Date: Wed, 22 Sep 2021 11:10:02 +0200 [thread overview]
Message-ID: <YUry6tzScXMD007X@kroah.com> (raw)
In-Reply-To: <20210922090442.GA16963@chenyu5-mobl1>
On Wed, Sep 22, 2021 at 05:04:42PM +0800, Chen Yu wrote:
> Hi Greg,
> On Tue, Sep 21, 2021 at 05:59:05PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 17, 2021 at 12:02:18AM +0800, Chen Yu wrote:
> > > Introduce the pfru_update driver which can be used for Platform Firmware
> > > Runtime code injection and driver update. 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.
> > >
> > > Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> >
> > Where is the userspace code that uses this ioctl and has tested it out
> > to verify it works properly? A link to that in the changelog would be
> > great to have.
> >
> The patch [5/5] is a self testing tool to test the whole feature. I'll send a
> new version and Cc you too.
That tests it, but does not answer the question of who will actually use
this. What userspace tool needs this new api?
> > > +static void dump_update_result(struct pfru_updated_result *result)
> > > +{
> > > + pr_debug("Update result:\n");
> > > + pr_debug("Status:%d\n", result->status);
> > > + pr_debug("Extended Status:%d\n", result->ext_status);
> > > + pr_debug("Authentication Time Low:%lld\n", result->low_auth_time);
> > > + pr_debug("Authentication Time High:%lld\n", result->high_auth_time);
> > > + pr_debug("Execution Time Low:%lld\n", result->low_exec_time);
> > > + pr_debug("Execution Time High:%lld\n", result->high_exec_time);
> >
> > Why not dev_dbg()? Same for all pr_* calls in this "driver".
> >
> >
> Ok, I'll switch to dev_dbg() in next version.
> > > +static long pfru_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > > +{
> > > + void __user *p;
> > > + int ret = 0, rev;
> > > +
> > > + p = (void __user *)arg;
> > > +
> > > + switch (cmd) {
> > > + case PFRU_IOC_SET_REV:
> > > + if (copy_from_user(&rev, p, sizeof(unsigned int)))
> > > + return -EFAULT;
> > > + if (!pfru_valid_revid(rev))
> > > + return -EFAULT;
> > > + pfru_dev->rev_id = rev;
> > > + break;
> > > + case PFRU_IOC_STAGE:
> > > + ret = start_acpi_update(START_STAGE);
> > > + break;
> > > + case PFRU_IOC_ACTIVATE:
> > > + ret = start_acpi_update(START_ACTIVATE);
> > > + break;
> > > + case PFRU_IOC_STAGE_ACTIVATE:
> > > + ret = start_acpi_update(START_STAGE_ACTIVATE);
> > > + break;
> > > + default:
> > > + ret = -ENOIOCTLCMD;
> >
> > Wrong value :(
> Previously I thought that ENOIOCTLCMD stands for 'invalid ioctl command'.
> After checking the lkml discussion, it seems that ENOIOCTLCMD should not
> be returned to user space. ENOTTY might be more suitible if I understand
> correctly.
> http://lkml.iu.edu/hypermail/linux/kernel/0105.1/0734.html
Yes, ENOTTY is correct.
> > > + break;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +#ifdef CONFIG_COMPAT
> > > +static long compat_pfru_ioctl(struct file *filep, unsigned int cmd,
> > > + unsigned long arg)
> > > +{
> > > + return pfru_ioctl(filep, cmd, arg);
> > > +}
> > > +#endif
> >
> > Why is this compat ioctl needed at all?
> >
> We can not control if the user space tool would be compiled as 32bit.
Then create your ioctl so that a compat ioctl is not needed at all.
There is no need to ever use this for new ioctl commands these days.
> But I realize that a compat_ptr() was missing. Will fix it in next version.
> > > +static struct miscdevice pfru_misc_dev = {
> > > + .minor = MISC_DYNAMIC_MINOR,
> > > + .name = "pfru_update",
> > > + .nodename = "pfru/update",
> >
> > Why is this in a subdirectory? What requires this? Why not just
> > "pfru"?
> >
> The pfru directory might be reused for pfru_telemetry device, whose driver
> is in 4/5 patch, I'll Cc you with the whole patch set in next version.
"might be" is not a valid reason. Why does this simple driver deserve a
whole /dev/ subdirectory?
thanks,
greg k-h
next prev parent reply other threads:[~2021-09-22 9:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 15:53 [PATCH v3 0/5] Introduce Platform Firmware Runtime Update and Telemetry drivers Chen Yu
2021-09-16 15:58 ` [PATCH v3 1/5] Documentation: Introduce Platform Firmware Runtime Update documentation Chen Yu
2021-09-27 17:26 ` Rafael J. Wysocki
2021-09-16 16:00 ` [PATCH v3 2/5] efi: Introduce EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER and corresponding structures Chen Yu
2021-09-27 17:33 ` Rafael J. Wysocki
2021-09-16 16:02 ` [PATCH v3 3/5] drivers/acpi: Introduce Platform Firmware Runtime Update device driver Chen Yu
2021-09-21 15:59 ` Greg Kroah-Hartman
2021-09-22 9:04 ` Chen Yu
2021-09-22 9:10 ` Greg Kroah-Hartman [this message]
2021-09-22 16:33 ` Chen Yu
2021-09-22 17:28 ` Greg Kroah-Hartman
2021-09-27 17:40 ` Rafael J. Wysocki
2021-10-05 4:08 ` Chen Yu
2021-10-05 4:12 ` Chen Yu
2021-09-28 12:22 ` Rafael J. Wysocki
2021-10-05 4:24 ` Chen Yu
2021-09-16 16:03 ` [PATCH v3 4/5] drivers/acpi: Introduce Platform Firmware Runtime Update Telemetry Chen Yu
2021-09-28 12:40 ` Rafael J. Wysocki
2021-09-16 16:04 ` [PATCH v3 5/5] selftests/pfru: add test for Platform Firmware Runtime Update and Telemetry 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=YUry6tzScXMD007X@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andriy.shevchenko@intel.com \
--cc=ardb@kernel.org \
--cc=ashok.raj@intel.com \
--cc=aubrey.li@intel.com \
--cc=ben.widawsky@intel.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=hdegoede@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).