[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180320020651.GA14709@guoren>
Date: Tue, 20 Mar 2018 10:06:54 +0800
From: Guo Ren <ren_guo@...ky.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
daniel.lezcano@...aro.org, jason@...edaemon.net, arnd@...db.de,
c-sky_gcc_upstream@...ky.com, gnu-csky@...tor.com,
thomas.petazzoni@...tlin.com, wbx@...ibc-ng.org
Subject: Re: [PATCH 06/19] csky: IRQ handling
Hi Thomas,
On Mon, Mar 19, 2018 at 02:16:37PM +0100, Thomas Gleixner wrote:
> > +static inline unsigned long arch_local_irq_save(void)
> > +{
> > + unsigned long flags;
>
> Newline between declaration and code please.
OK
> > +void csky_do_IRQ(int irq, struct pt_regs *regs)
>
> static? If not, then it needs a declaration in a header somewhere.
Yes, need static.
> > +asmlinkage void csky_do_auto_IRQ(struct pt_regs *regs)
> > +{
> > + unsigned long irq, psr;
> > +
> > + asm volatile("mfcr %0, psr":"=r"(psr));
> > +
> > + irq = (psr >> 16) & 0xff;
> > +
> > + if (irq == 10)
> > + irq = csky_get_auto_irqno();
> > + else
> > + irq -= 32;
>
> Please add a comment explaining this magic here. Magic numbers w/o
> explanation are bad.
Yes, you are right. I will fixup them next.
PSR is our Processor Status Register and it store the vector number.
'10' is our auto-interrupt exception entry and we need get the irqno
from the interrupt-controller.
The "vector num > 32" is our vector interrupt exception entries, so we
can calculate the irq-num by vector-num and no need to access the
interrupt-controller's io regs.
Best Regards
Guo Ren
Powered by blists - more mailing lists