On 7 February 2013 11:50, Andreas Färber <afaer...@suse.de> wrote: > Am 07.02.2013 07:59, schrieb Kuo-Jung Su: >>>> +/****************************************************************************** >>>> + * FTSPI020 registers >>>> + >>>> *****************************************************************************/ >>>> +#define REG_CMD0 0x00 /* Flash address */ >>>> +#define REG_CMD1 0x04 >>>> +#define REG_CMD2 0x08 >>>> +#define REG_CMD3 0x0c >>>> +#define REG_CTRL 0x10 /* Control Register */ >>>> +#define REG_ACT 0x14 /* AC Timing Register */ >>>> +#define REG_STR 0x18 /* Status Register */ >>>> +#define REG_ICR 0x20 /* Interrupt Control Register */ >>>> +#define REG_ISR 0x24 /* Interrupt Status Register */ >>>> +#define REG_RDST 0x28 /* Read Status Register */ >>>> +#define REG_REV 0x50 /* Revision Register */ >>>> +#define REG_FEA 0x54 /* Feature Register */ >>>> +#define REG_DATA 0x100 /* Data Register */ >>>> + >>> >>> These can just live in the C file - they are private to the implementation. > > No. Having them in a header means they can be reused by qtests.
Do we really want to change the public/private boundaries of our source code just for the benefit of the test framework? Ugh. > To embed the device into a SoC object, the state struct and TYPE_ > constant should be in the header. That applies to each device part of > the SoC rather than on the board. I would like it if we could define what we consider to be best practice for public/private header files for QOM devices (in particular whether we need a public header for every device with the TYPE_ constants &c). -- PMM
