From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: ecos-patches@sourceware.org
Cc: andrew@lunn.ch, uwe.kindler@cetoni.de
Subject: Re: LPC2xxx patch for support of vectored interrupt controller
Date: Wed, 22 Aug 2007 09:23:00 -0000 [thread overview]
Message-ID: <20070822092307.GC2126@grumpf.hope-2000.org> (raw)
In-Reply-To: <20070822084244.GG31057@lunn.ch>
On Wed, Aug 22, 2007 at 10:42:44AM +0200, Andrew Lunn wrote:
> On Tue, Aug 21, 2007 at 08:10:59AM +0200, cetoni GmbH - Uwe Kindler wrote:
> > Btw. the assertion I put into the code is wrong:
> >
> > CYG_ASSERT(vector <= CYGNUM_HAL_INTERRUPT_EINT3 &&
> > vector >= CYGNUM_HAL_INTERRUPT_EINT0 , "Invalid vector");
> >
> > should be:
> >
> > CYG_ASSERT(vector <= CYGNUM_HAL_INTERRUPT_EINT3 ||
> > vector >= CYGNUM_HAL_INTERRUPT_EINT0 , "Invalid vector");
>
> Please could you submit a patch.
May I suggest that you think about this again?
The only configurable interrupts are EINT0 to EINT3. So this assertion
makes sure that the vector passed to hal_interrupt configure is less or
equal to EINT3 _and_ greater or equal to EINT0. And if this is not true
the assertion fails. If you change the assertion the way suggested you
could also just remove it, since _all_ vectors are either less or equal
to EINT3, or greater or equal to EINT0, or both.
> Should there also be another check like:
>
> CYG_ASSERT(vector <= CYGNUM_HAL_ISR_MAX &&
> vector >= CYGNUM_HAL_ISR_MIN , "Invalid vector");
>
> If you pass it an invalid vector, such as 33, you end up shifting 1 by
> 33 which i guess results in 0. The code will then set/reset the level
> on every single interrupt!
This assertion cannot fail if the previous assertion did not fail, and
if the previous assertion failed it is never reached. Any vector less or
equal to EINT3 is also less than ISR_MAX, and any vector greater or equal
to EINT0 is also greater than ISR_MIN.
> If the hardware is not capable of setting priority and level for these
> vectors, we should check for this. I suggest we make the test case a
> little bit more intelligent so that it only tries to do things which
> the hardware is capable of doing. In some respect, the test failing is
> correct!
This could probably be done by introducing something like
CYGNUM_HAL_ISR_CONF_MAX and _MIN to the HALs.
--
%SYSTEM-F-ANARCHISM, The operating system has been overthrown
next prev parent reply other threads:[~2007-08-22 9:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-21 6:12 cetoni GmbH - Uwe Kindler
2007-08-21 7:36 ` Hans Rosenfeld
2007-08-22 8:42 ` Andrew Lunn
2007-08-22 9:23 ` Hans Rosenfeld [this message]
2007-08-22 9:45 ` Andrew Lunn
2007-08-22 9:49 ` cetoni GmbH - Uwe Kindler
-- strict thread matches above, loose matches on Subject: below --
2007-07-10 6:11 uwe.kindler
2007-07-30 18:10 ` Andrew Lunn
2007-08-17 14:02 ` Hans Rosenfeld
2007-08-17 17:14 ` Hans Rosenfeld
2007-08-20 5:52 ` cetoni GmbH - Uwe Kindler
2007-08-20 15:14 ` Hans Rosenfeld
2007-08-22 8:25 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070822092307.GC2126@grumpf.hope-2000.org \
--to=rosenfeld@grumpf.hope-2000.org \
--cc=andrew@lunn.ch \
--cc=ecos-patches@sourceware.org \
--cc=uwe.kindler@cetoni.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).