Re: m68knommu: duplicate _ramvec[vba+CPMVEC_RISCTIMER] assignmentin init_IRQ()
From: Greg Ungerer
Date: Fri Feb 12 2010 - 07:10:17 EST
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@xxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/