Re: [PATCH v3 3/5] drivers/acpi: Introduce Platform Firmware Runtime Update device driver

[Rafael J. Wysocki]

On Wed, Sep 22, 2021 at 7:28 PM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 23, 2021 at 12:33:21AM +0800, Chen Yu wrote:
> > On Wed, Sep 22, 2021 at 11:10:02AM +0200, Greg Kroah-Hartman wrote:
> > > 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@xxxxxxxxx>
> > > > >
> > > > > 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?
> > >
> > One end user is the cloud user.
>
> What exactly do you mean by "cloud user"?
>
> > Currently there is no dedicated userspace tool developed to use this
> > feature AFAIK.
>
> Wonderful, then it is not needed to be added to the kernel :)
>
> > It was expected that the end users
> > could refer to the self test tool to customize their tools. I'm not sure if
> > this is the proper way to propose the feature, may I have your suggestion on
> > this, should I create a separate git repository for this tool, or put it in
> > tools/selftestings as it is now?
>
> No, do not add this to the kernel unless you have a real need and user
> for this.
>
>
> > > > > > +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?
> > >
> > There are pfru_update and pfru_telemetry in the patch, and there is plan to
> > add a pfru_prm device in the future, which stands for "Platform Runtime Mechanism".
> > I'll move them to /dev/ in next version.
>
> That is a very generic name for a very platform specific and arch
> specific interface.  As this is an ACPI interface, why not use that name
> prefix?

It is not supposed to be either arch-specific or platform-specific.
The spec is hosted by the UEFI Forum and it is fairly generic IIUC.
In principle, it could be used to update any kind of platform firmware
possible to update without system restart.

That said, the I/F to the platform firmware is based on ACPI methods,
so "acpi_" would be a reasonable prefix choice.