On Tue, Jun 21, 2016 at 12:45 PM, Peter Maydell <[email protected]> wrote: > On 21 June 2016 at 19:25, Alistair Francis <[email protected]> > wrote: >> On Fri, Jun 10, 2016 at 4:02 AM, Peter Maydell <[email protected]> >> wrote: >>>> +/** >>>> + * Init a block of consecutive registers into a container MemoryRegion. A >>>> + * number of constant register definitions are parsed to create a >>>> corresponding >>>> + * array of RegisterInfo's. >>>> + * >>>> + * @owner: device owning the registers >>>> + * @rae: Register definitions to init >>>> + * @num: number of registers to init (length of @rae) >>>> + * @ri: Register array to init >>>> + * @data: Array to use for register data >>>> + * @container: Memory region to contain new registers >>>> + * @ops: Memory region ops to access registers. >>>> + * @debug enabled: turn on/off verbose debug information >>>> + */ >>>> + >>>> +void register_init_block32(DeviceState *owner, const RegisterAccessInfo >>>> *rae, >>>> + int num, RegisterInfo *ri, uint32_t *data, >>>> + MemoryRegion *container, const MemoryRegionOps >>>> *ops, >>>> + bool debug_enabled, uint64_t memory_size); >>> >>> This doesn't seem to contemplate register arrays which are mostly >>> consecutive but have some unimplemented/reserved regions. >> >> I disagree, we only init registers that are described in the device. >> Doing work for blank spaces seems unnecessary. > > It says "consecutive registers" -- if that doesn't mean > "all these registers have to be in a single block what > does it mean?
You are right, the comment is wrong. I have removed consecutive from the comment. Thanks, Alistair > > thanks > -- PMM >
