qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v1 2/4] bitops: Add UInt32StateInfo and help


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/4] bitops: Add UInt32StateInfo and helper functions
Date: Mon, 4 Mar 2013 17:20:33 +1000

Hi Gerd,

On Mon, Mar 4, 2013 at 4:55 PM, Gerd Hoffmann <address@hidden> wrote:
>> +/**
>> + * A descriptor for a Uint32 that is part of guest accessible device state
>> + * @ro: whether or not the bit is read-only state comming out of reset
>> + * @w1c: bits with the common write 1 to clear semantic.
>
>> + * @nw0: bits that cant be written with a 0 by the guest (sticky 1)
>> + * @nw1: bits that cant be written with a 1 by the guest (sticky 0)
>
> Why these?
>
> reset=0 + ro=1 equals nw1=1
> reset=1 + ro=1 equals nw0=1
>

Some bits in my devices can only be written one-way they are either
"stuck on" once they are written, or only the hardware is allowed to
write the other way. Setting both nw0 and nw1 is equivalent to ro. In
the devcfg example, bits in the LOCK bits are sticky (the idea is once
the firmware locks them the booted system cant unlock them for
security and we want to test the firmware as a guest).

>> + * @width: width of the uint32t. Only the @width least significant bits are
>> + * valid. All others are silent Read-as-reset/WI.
>
> That's kida redundant with "ro" too.  I'd do it the other way around
> btw:  Specify the writable bits instead of the read-only ones.  width=8
> easily be written as wmask=0xff then.

In V2 ill be doing some work to make this more flexible regarding
widths to address Blues comments. Ill incorporate this as well, and I
think I can make it work getting rid of the width altogether.

Regards,
Peter

>
> cheers,
>   Gerd
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]