Messages in this thread | | | Date | Fri, 12 Feb 2010 22:10:02 +1000 | From | Greg Ungerer <> | Subject | Re: m68knommu: duplicate _ramvec[vba+CPMVEC_RISCTIMER] assignment in init_IRQ() |
| |
Hi Roel,
On 02/11/2010 12:10 AM, Roel Kluin wrote: > Looking at arch/m68knommu/platform/68360/ints.c I noted two things that > stood out: > > 1) on line 110: > > _ramvec[vba+CPMVEC_RISCTIMER] = inthandler; /* reserved */ > > and 114: > > _ramvec[vba+CPMVEC_RISCTIMER] = inthandler; /* timer table */ > > The same definitions are used, and in the first case the comment and > definition do not correspond.
Yes, that does look odd. I am not intimately familiar with the 68360, but looking at the underlying vector numbers I would say that the entry with the "reserved" comment is superfluous, and should be removed.
(That code has been that way as far back as I could see, certainly into 2.4 kernels).
> 2) while all other definitions are used like this: > > _ramvec[vba+CPMVEC_DEF2] = inthandler; > ... > _ramvec[vba+CPMVEC_DEF1] = inthandler; > > This is not true for CPMVEC_RESERVED: > > _ramvec[vba+CPMVEC_RESERVED1] = inthandler; /* reserved */ > ... > _ramvec[vba+CPMVEC_RESERVED2] = inthandler; /* reserved */ > > Is this a bug?
I am not sure I follow. Is it the ascending/descending numerical ordering that you are worried about?
I don't know why the original author ordered the assignments in the opposite order of the definitions, but I don't see it making any difference here. So I don't see a bug.
Regards Greg
------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close, FAX: +61 7 3891 3630 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
| |