Move the quantative easing fields into arch_global_data and tidy up.

Signed-off-by: Simon Glass <sjg@chromium.org>

Move this field into arch_global_data and tidy up.

Signed-off-by: Simon Glass <sjg@chromium.org>

This processor, though very similar to other members of the
PowerQUICC II Pro family (namely 8308, 8360 and 832x), provides
yet another feature set than any supported sibling.

Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

P1015 is the same as P1011 and P1016 is the same as P1012 from software
point of view. They have different packages but share SVRs.

Signed-off-by: York Sun <yorksun@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>

Fix this:
uec.c: In function 'uec_initialize':
uec.c:1404:12: warning: assignment from incompatible pointer type

Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>

A few subsystems are using the same define "NAMESIZE".  This has been
working so far because they define it to the same number.  However, I
want to change the size of eth_device's NAMESIZE, so rather than tweak
the define names, simply drop references to it.  Almost no one does,
and the handful that do can easily be changed to a sizeof().

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Several macros are used to identify and locate the microcode binary image
that U-boot needs to upload to the QE or Fman.  Both the QE and the Fman
use the QE Firmware binary format to package their respective microcode data,
which is why the same macros are used for both.  A given SOC will only have
a QE or an Fman, so this is safe.

Unfortunately, the current macro definition and usage has inconsistencies.
For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
of NAND.  There's no way to know by looking at a variable how it's supposed
to be used.

In the future, the code which uploads QE firmware and Fman firmware will
be merged.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

uec.c: In function 'uec_stop':
uec.c:267:22: warning: variable 'uccf' set but not used [-Wunused-but-set-variable]
uec.c: In function 'uec_set_mac_if_mode':
uec.c:328:15: warning: variable 'uec_info' set but not used [-Wunused-but-set-variable]
uec.c: In function 'adjust_link':
uec.c:519:11: warning: variable 'uec_regs' set but not used [-Wunused-but-set-variable]

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The fsl_phy_enet_if enum was, essentially, the phy_interface_t enum.
This meant that drivers which used fsl_phy_enet_if to deal with
PHY interfaces would have to convert between the two (or we would have
to have them mirror each other, and deal with the ensuing maintenance
headache). Instead, we switch all clients of fsl_phy_enet_if over to
phy_interface_t, which should become the standard, anyway.

Signed-off-by: Andy Fleming <afleming@freescale.com>
Acked-by: Detlev Zundel <dzu@denx.de>

There were a few files which were already using phy_read and phy_write
for their PHY function names.  It's only a few places, and the name
seems most appropriate for the high-level abstraction, so let's
rename the other versions to something more specific.

Also, uec_phy.c had a marvell_init function which I renamed to not
conflict with the one in marvell.c

Lastly, uec_phy.c was putting a space between the phy writing
function names, and the open paren, so I fixed that

Signed-off-by: Andy Fleming <afleming@freescale.com>
Acked-by: Detlev Zundel <dzu@denx.de>