From: Dan Malek <dan@embeddededge.com>
To: Sarnath Kannan <sparc64@rediffmail.com>
Cc: ashish anand <ashisha@india.infogain.com>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: "OpenPIC versus EPIC" in MPC8240 !
Date: Mon, 12 Nov 2001 11:41:51 -0500 [thread overview]
Message-ID: <3BEFFBCF.7010600@embeddededge.com> (raw)
In-Reply-To: 20011112084114.25202.qmail@mailFA3.rediffmail.com
Sarnath Kannan wrote:
> Hi Ashish,
> what I felt was, populating reserved areas
> is a bug.
It's only a bug if we don't know we are doing this and
it is causing problems. We know we can do what we
are doing without trouble. I'm not trying to
justify this hack or claim it is the proper solution.
It just happens to work, allows us to take advantage of
existing software functions, and someday it may be changed.
When someone like you shows up and your only concern or
contribution is to fix this function, then do it. I don't
want to hear why you think someone else did it wrong or what
someone else should do to make it better. Just fix the damn
thing! When someone like me is trying to do hundreds of things
to get a board port done, using any existing code is exactly
what I'm going to do. For EPIC I could take advantage of a
bunch of existing code instead of discussing why it should
change, or rewriting and testing on a whole bunch of other platforms
that doesn't help me make progress. If you have the time to
rewirte and test it on _everything_ affected, go right ahead.
> I has said that this could be a __possible__
> cause for getting bogus interrupts. I would
> say there is 80% possibility.
You are just digging a deeper hole. Bugs are either 100% there
or not there at all. There isn't an 80% possibility of a bug.......
The _conditions_ under which a bug can appear are variable,
but a bug is a bug.
> Moreover if u can read the EPIC manual,
> u can notice that IVPR and SVPR both start
> at offset 0x50200. ( So the IVPR space is
> not a continous 24 entries. It is actually
> overalapped and discontinous )
If you actually _understood_ what you read, you would notice
this register space has different functions depending upon
the configuration of the EPIC and the design of the hardware
surrounding it. You will also notice that because of the way
we initialize and utilize the openpic and interrupt management
functions that we properly configure the interrupt source registers
for the board design.
> I have no idea of hurting people. But if a bug
> is pointed out, there is no harm in accepting it.
More importanly, you should do something constructive and fix it.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-11-12 16:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 8:41 Re: "OpenPIC versus EPIC" in MPC8240 ! Sarnath Kannan
2001-11-12 16:41 ` Dan Malek [this message]
2001-11-12 16:51 ` Dag Nygren
2001-11-12 16:58 ` Dan Malek
2001-11-12 18:00 ` Dag Nygren
-- strict thread matches above, loose matches on Subject: below --
2001-11-13 6:42 James F Dougherty
2001-11-13 7:17 ` Dag Nygren
2001-11-07 14:11 Sarnath Kannan
2001-11-11 23:56 ` ashish anand
2001-11-01 10:13 Sarnath Kannan
2001-11-01 17:13 ` Dan Malek
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=3BEFFBCF.7010600@embeddededge.com \
--to=dan@embeddededge.com \
--cc=ashisha@india.infogain.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=sparc64@rediffmail.com \
/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 NNTP newsgroup(s).