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

[Laszlo Ersek]

On 10/17/19 17:41, Igor Mammedov wrote:
> On Thu, 10 Oct 2019 14:33:19 +0200
> Laszlo Ersek <address@hidden> 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)

Makes sense, thanks!
Laszlo

>> (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
>>
>