Re: [Qemu-devel] [PATCH v3 20/20] arm: add Faraday FTSPI020 SPI flash controller support

[Paolo Bonzini]

Il 07/02/2013 13:13, Andreas Färber ha scritto:
> Am 07.02.2013 13:04, schrieb Peter Maydell:
>> On 7 February 2013 11:50, Andreas Färber <address@hidden> 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.
> 
> The truth is (and that applies to the hw/ refactoring series as well)
> that we don't have a clear distinction between "public" and "private"
> headers for devices.

Both of you are right.  Perhaps qtests should live in hw/tests.  Not
going to do that myself for now.

>>> 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).
> 
> gtk-doc for instance needs to scan one directory, so having all headers
> in include/ would be beneficial long-term - today we do not get
> generated documentation for qdev-core.h.
> 
> The separation between PCI internal helpers and
> structs/typedefs-to-be-used is made by including specific headers
> depending on what you need.
> 
> In the refcatoring thread I suggested that if we want to have all SPI
> devices in hw/spi/ then each device that needs a public function
> declaration or TYPE_ or struct should export its own header.

I think that's not a bad thing.

> If we group
> them into a common directory such as hw/arm/ that could be shared across
> SoC devices.

And then you get problems with NEED_CPU_H... :)

> Therefore I was suggesting not to split up too much but
> seem to be overruled. ;) There's downsides to everything.

Yes, that's why I call the current situation a local optimum.

Paolo