From: Andrew Lunn <andrew@lunn.ch>
To: cetoni GmbH - Uwe Kindler <uwe.kindler@cetoni.de>
Cc: ecos-patches@sourceware.org,
Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
Subject: Re: LPC2xxx patch for support of vectored interrupt controller
Date: Wed, 22 Aug 2007 08:42:00 -0000 [thread overview]
Message-ID: <20070822084244.GG31057@lunn.ch> (raw)
In-Reply-To: <46CA81F3.60109@cetoni.de>
On Tue, Aug 21, 2007 at 08:10:59AM +0200, cetoni GmbH - Uwe Kindler wrote:
> Hello Hans,
>
> ------>
> I think it would be better to change this assertion into
> a simple test, so that calling hal_interrupt_configure() with an
> un-configurable interrupt vector just does nothing.
> <-----
>
> I dont't agree with this change. If I configure a system and do a mistake
> setting up interrupt priorities then my only chance and a very good way to
> catch this error is this assertion. If you silently drop this failure just
> to make a test case happy then you may pass the test but you will run into
> trouble with your real application.
>
> 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. 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!
> Hello Andrew, what do you think about the patch. Is it okay to remove the
> assertion just to make test cases happy?
I would prefer to keep the assertion. Interrupt code is never easy to
debug and get right. When it does not work you have little idea why it
does not work. So i like tests like this which will prevent some of
the silly mistakes.
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!
Andrew
next prev parent reply other threads:[~2007-08-22 8:42 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 [this message]
2007-08-22 9:23 ` Hans Rosenfeld
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=20070822084244.GG31057@lunn.ch \
--to=andrew@lunn.ch \
--cc=ecos-patches@sourceware.org \
--cc=rosenfeld@grumpf.hope-2000.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).