Re: [RFC PATCH-for-6.1 8/9] hw/clock: Declare clock_new() internally

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

On 4/19/21 4:26 PM, Peter Maydell wrote:
> On Fri, 9 Apr 2021 at 07:24, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> To enforce correct API usage, restrict the clock creation to
>> hw/core/. The only possible ways to create a clock are:
>>
>> - Constant clock at the board level
>>   Using machine_create_constant_clock() in machine_init()
>>
>> - Propagated clock in QDev
>>   Using qdev_init_clock_in() or qdev_init_clock_out() in
>>   TYPE_DEVICE instance_init().
> 
> Why isn't it OK to have a constant clock inside a device ?

I'm not an electronic engineer, so I guessed because I never used
a component which generate a clock source without being externally
excited by a crystal or oscillator. Such exciters are components
on the board. I might be wrong.

Using clock source out of qdev is giving us headache... So I'm
trying to enforce all clocks being used via qdev. Looking at the
resting cases and thinking about hardware, my understanding is
what's left belong to the "(constant) clock source on the board",
added this machine_create_constant_clock() method to complete the
enforced API.

Maybe what I'm trying to fix is a side-effect of the non-qdev reset
problem, and if we get a QOM tree reset, then a clock on a non-qdev
object would properly propagate its constant value to its children.