[Bug 1928] mpc5674fevb: powerpc/mpc55xx/misc/flash_support.c:183:9: warning: case label value exceeds maximum value for type

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1928

dufault at hda.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dufault at hda.com

--- Comment #3 from dufault at hda.com 2011-10-06 14:00:13 CDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Hardware accessed via bit fields is always trouble even if you think things
> > look ok.
> Partially agreed, bitfields are a double wedged sword - They have pros and
> cons.
> 
> (E.g. if this case was implemented via bit-masks, gcc would not have raised a
> warning, but code would have been silently broken)
> 
> Portability-wise, they are a nightmare, e.g. wrt. byte-order.
> 
> > There is no standards based means to control the size of the access to
> > the specific field.
> As long as these bitfields are sufficiently tied to a specific setup, they
> normally should be OK with gcc. 
> 
> At least, I've never seen a case with gcc where it did not work.
> 

Your analysis is correct, on the MPC5554 the size of the bit field is four, not
three.

This might work fine in all cases and avoid warnings:

int size = FLASH.MCR.B.SIZE;
switch(size) {
...

HOWEVER, someone with the MPC5674 better first check that flash_support.c is
even compatible with the MPC567X. A web search results in this from the
"MPC5566 to MPC5674F Migration Guide":

"The MPC5674F requires a different flash-programming algorithm that will be
provided by FSL as a software driver. Any proprietary flash-programming
algorithms or drivers must be re-coded for the MPC5674F."

It might be a good thing we got that warning.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.