public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001463] LPC17XX supplementary code/option patch
Date: Thu, 26 Jan 2012 10:18:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Please do not reply to this email. Use the web interface provided at:

--- Comment #4 from Ilija Kocho <> 2012-01-26 10:18:32 GMT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Hi Bernard
> > 
> > Thank you for your contribution.
> > 
> > Past couple of days I have committed patches for Bug 1001395 (including bug
> > 1001443) and Bug 1001432. You may need to synchronize your patches accordingly.
> I've first updated my copy of ecos-cvs before making the patch. More exactly I
> was waiting for you to commit to make my patch ;-)
> > 
> > I could see that some patches cover issues reported (by you) in other bugs. Can
> > you submit them there (and obsolete some patches of my own of course)?
> > Splitting patches will speed up check in for some of them.
> You are probably referring to bug #1001407. Yes the proposed patch includes
> changes similar to attachment 1481 [details] (however I didn't use the word 'omplemented'
> in the comments ;-)) but it adds many more hardware related definitions. Maybe
> you commit your patch, and then I'll submit a new one that won't have the same
> fixes? At the moment I have chosen to make my diff vs the ecos cvs repo and I
> don't consider pending patches. Maybe I should do differently?

Since you have your focus on LPC17xx IMO you could do this fixes better than
me. When you reported the discrepancies I wasn't aware that you are submitting
copyright assignment, otherwise I would have asked you to propose patches.
Now I would ask you to merge the fixes related to missing/wrong #defines. IMO
the best place to submit this "super" patch is bug #1001407 since you can at
the same time obsolete my patch.

Also it will relief me from LPC17xx and shall give me more time for other jobs:
GCC, etc... 

> > 
> > Also, on your initiative we have started some discussion on bit banding at Bug
> > 1001442 so we can continue there with your patches.
> So let's first decide how bitband is handled and afterwards I'll update the
> proposed patch accordingly. Or I can remove the bitband macros in the proposed
> patch.

Your proposal could be a start point, sou you may re-submit macros at Bug
1001442. However, as I mentioned earlier, I would be happy with generic CORTEXM
(or CORTEX_M) macros (where applicable) on architectural level. The headline of
Bug 1001442 could be changed accordingly. Let's continue our discussion there.


Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

      parent reply	other threads:[~2012-01-26 10:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-25 16:17 [Bug 1001463] New: " bugzilla-daemon
2012-01-25 16:18 ` [Bug 1001463] " bugzilla-daemon
2012-01-25 21:42 ` bugzilla-daemon
2012-01-26  9:05 ` bugzilla-daemon
2012-01-26 10:18 ` bugzilla-daemon [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).