Re: [Qemu-arm] [PATCH 1/8] bcm2835_sbm: add BCM2835 mailboxes

[Peter Crosthwaite]

On Wed, Dec 23, 2015 at 12:32 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 22/12/2015 00:33, Peter Crosthwaite wrote:
>>>> >>
>>>> >> case 0x80..0x8c
>>> >
>>> > Woah! Is that standard C?
>>> >
>> Yes, its probably one of the more recent language standards though.
>> QEMU does use to more modern features liberally.
>
> It's actually "case 0x80 ... 0x8c:".
>
>>> Notice that this file comes from Linux. I know it's not pretty, but

Where in Linux exactly? I am actually having trouble finding the
original source. Grepping around linux-next, there is no mach
bcm-2708. I can see this mach in an rPI specific fork, but I don't see
it in upstream Linux.

Is it the case that Gregory did this work some time ago now, and that
original source has been refactored away to something different
anyway?

In the grepping I also notice that you are defining the regspecs in
header for the SP804 timer, which we already model and manages its own
defs. Those should be in an sp804 specific header, and Linux does the
same:

$ git grep TIMER_CTRL_DIV1
drivers/clocksource/timer-integrator-ap.c:              ctrl |= TIMER_CTRL_DIV16
drivers/clocksource/timer-integrator-ap.c:              ctrl |= TIMER_CTRL_DIV16
drivers/clocksource/timer-sp.h:#define TIMER_CTRL_DIV1          (0 << 2)
drivers/clocksource/timer-sp.h:#define TIMER_CTRL_DIV16 (1 << 2)        /* ACVR

>>> can we please keep it as-is, for comparison purposes? I'm not sure
>>> there's much value in cleaning it up locally...
>>
>> It looks very autogenerated and seems pretty nasty on the repetition.
>>
>> As implementers of the hardware, it is much rarer to need these
>> repetitious defs than the software users on the other side. "Do
>> something specific with CPU#3's Mbox#5" is going to appear in
>> software, but hardware implementers generally don't have a choice to
>> implement things specifically and it usually ends up being looped and
>> the exploded defs are never used. If there are only a handful of
>> genuinely single defs needed, can they be fished out?
>
> I see your point and I'm definitely in favor of rewriting headers from
> scratch when practical, but any cleanup made is a recipe for unwanted
> changes and bugs, especially if the source is full of repetitions.
>

If this is from Linux, and we want this to be immutable, then
shouldn't we be managing it via our existing linux-headers import
scripts?

Regards,
Peter

> Paolo