qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Baumann
Subject: Re: [Qemu-arm] [PATCH 1/8] bcm2835_sbm: add BCM2835 mailboxes
Date: Mon, 21 Dec 2015 23:59:08 +0000

> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Monday, 21 December 2015 15:33
> On Mon, Dec 21, 2015 at 3:15 PM, Andrew Baumann
> <address@hidden> wrote:
> >> From: Peter Crosthwaite [mailto:address@hidden
> >> Sent: Monday, 21 December 2015 14:49
> >> On Thu, Dec 3, 2015 at 10:01 PM, Andrew Baumann
> >> <address@hidden> wrote:
> >> > +
> >> > +    switch (offset) {
> >> > +    case 0x80:  /* MAIL0_READ */
> >> > +    case 0x84:
> >> > +    case 0x88:
> >> > +    case 0x8c:
> >>
> >> 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.

Notwithstanding that it's widely used in QEMU (and a nice feature too), and not 
that I have a problem with adopting it, but just because I'm a pedant: this is 
definitely not in C99 (per qemu/HACKING). It doesn't appears in C11 either (at 
least not the final draft). It's a gcc extension:
http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html

> > [...]
> >> > --- /dev/null
> >> > +++ b/include/hw/arm/bcm2835_arm_control.h
> >> > @@ -0,0 +1,481 @@
> >> > +/*
> >> > + *  linux/arch/arm/mach-bcm2708/arm_control.h
> > [...]
> >> When you have a regular structure like this, you should collapse it
> >> down using some arithmatic:
> >
> > Notice that this file comes from Linux. I know it's not pretty, but 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 think so. I'll do that then.

Andrew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]