Re: [RFC 1/3] acpi: cpuhp: fix 'Command data' description is spec

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 10 Oct 2019 14:33:19 +0200
Laszlo Ersek <lersek@redhat.com> wrote:

> On 10/09/19 15:22, Igor Mammedov wrote:
> > QEMU returns 0, in case of erro or invalid value in 'Command field',
> > make spec match reality, i.e.  
> 
> Unfinished thought?
yep, I'll fix it up.

[...]
> > index ee219c8358..ac5903b2b1 100644
> > --- a/docs/specs/acpi_cpu_hotplug.txt
> > +++ b/docs/specs/acpi_cpu_hotplug.txt
> > @@ -44,9 +44,10 @@ read access:
> >             3-7: reserved and should be ignored by OSPM
> >      [0x5-0x7] reserved
> >      [0x8] Command data: (DWORD access)  
> 
> since we're fixing this dword field description, can you spell out the
> endianness too?
Since it's ACPI oriented interface (i.e. guest AML LE access implied),
I'd prefer to spell it out once in spec so it would cover all integer
fields vs doing it per filed. (less chance to make mistake later)


> (I think endianness is relevant here, because patch#2 suggests selectors
> can be looped over. So selectors are actual integers, not just 32-bit
> opaque blobs.)
> 
> > -          in case of error or unsupported command reads is 0xFFFFFFFF
> > +          in case of error or unsupported command reads is 0x0
> >            current 'Command field' value:
> > -              0: returns PXM value corresponding to device
> > +              0: returns CPU selector value corresponding to a CPU with
> > +                 pending event.
> >  
> >  write access:
> >      offset:
> >   
> 
> Thanks!
> Laszlo
>