Re: [PATCH 3/3] platform/wmi: Expose the raw WDG data in sysfs

[Darren Hart <dvhart@infradead.org>]

On Tue, Aug 01, 2017 at 10:40:40PM +0200, Pali Rohár wrote:
> On Tuesday 01 August 2017 13:19:16 Andy Lutomirski wrote:
> > On Tue, Aug 1, 2017 at 1:03 PM, Darren Hart <dvhart@infradead.org> wrote:
> > > On Tue, Aug 01, 2017 at 08:37:28AM -0700, Andy Lutomirski wrote:
> > >> This adds a sysfs binary attribute 'wdg' on the bus device
> > >> (i.e. /sys/class/wmi_bus/wmi_bus-*/wdg) that contains the raw _WDG
> > >> data from ACPI.  This can be used along with the wmi-bmof driver to
> > >> decode the raw interface data from ACPI.
> > >
> > > I don't recall seeing mention of this is the documentation I read as a
> > > requirement to decoding the interface with the bmof. Do Windows systems export
> > > _WDG to userspace?
> > >
> > > Why do we need to export _WDG?
> > 
> > This was a feature that Pali asked for.  Pali, since you seem to be
> > working on userspace tooling, can you explain exactly what you'd use
> > it for?
> 
> Take raw BMOF and WDG buffers from ACPI and parse them in userspace.
> Then provide needed information like mapping from MOF event name to ACPI
> event name based on info from WDG buffer.
> 

So first, I'm not opposed to adding it if that's what needed. However, I don't
want to start pushing ACPI objects to sysfs without:

1) Confirming it's necessary
2) Getting Rafael's take on this practice, as if this is to become something we
do, some kind of ACPI_OBJECT_SYSFS_EXPORT macro provided by ACPI would probably
be the right way to do it.

My understanding of the BMOF data is that it provided us "with a description of
all data blocks, WMI methods, and events for the device" [1].

If that's accurate, why do we need the _WDG? This just seems contrary to what
the BMOF data is supposed to be for.

> Ideally ability to create dump of BMOF and WDG on one computer and then
> parse those data on another.
> 
> Having original BMOF and WDG structures is a good for debugging and
> development purpose.

For debugging purposes, the fwts and acpidump tools will provide this.

> > On my laptop, at the very least, it would allow user code to determine
> > that there's a WMI GUID that doesn't show up in sysfs.  It doesn't
> > show up in sysfs because the ACPI methods are completely missing, but
> > it's still there in WDG.  This prints a warning when wmi.ko is loaded,
> > but maybe the userspace tooling would care, for debugging if nothing
> > else.

In this case, I'd argue userspace should only be aware of what the kernel
decides to expose, based on, at the very least, compliance with the WMI
documentation.

1. https://wiki.ubuntu.com/Kernel/Reference/WMI
-- 
Darren Hart
VMware Open Source Technology Center