lkml.org 
[lkml]   [2010]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2010-02-12 13:13    [W:0.585 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site