Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Add defines for __raw_{read,write}{b,w,l}() functions to make
make asm-generic/io.h aware of them.

Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>

sparse reports the following warning:

  CHECK   arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c
arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c:29:9: warning: cast removes address space '<asn:2>' of expression
arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c:30:9: warning: cast removes address space '<asn:2>' of expression

This is because of (void *) casts for using memcpy() as a substitute.

Do like other architectures, __force the cast to silence the warning

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

In phys_to_virt() and virt_to_phys(), if CONFIG_ADDR_MAP is defined,
they use addrmap_ translation APIs to do the address translation.
However these APIs only work in post-relocation phase.

Update the code logic to fall back to use the default one when in
pre-relocation phase.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Define the read*_*/write*_* macros for the PowerPC platform to be able
to use the macros in wait_bit.h.

Signed-off-by: Mario Six <mario.six@gdsys.cc>

Convert the powerpc architecture to make use of the new asm-generic/io.h
to provide address mapping functions. As powerpc can actually perform
non-identity mapping between physical & virtual addresses we can't
simply make use of the generic phys_to_virt() & virt_to_phys()
functions. However since map_physmem() already effectively implemented
the same thing as virt_to_phys() we can simply implement virt_to_phys()
instead of map_physmem() & use the generic map_physmem(). We also drop
the no-op unmap_physmem().

This has only been build-tested, feedback from architecture maintainers
is welcome.

Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: Wolfgang Denk <wd@denx.de>

A number of headers define functions as "extern inline" which is
causing problems with gcc5.  The reason is that starting with
version 5.1, gcc defaults to the standard C99 semantics for the
inline keyword.

Under the traditional GNU inline semantics, an "extern inline"
function would never create an external definition, the same
as inline *without* extern in C99.  In C99, and "extern inline"
definition is simply an external definition with an inline hint.
In short, the meanings of inline with and without extern are
swapped between GNU and C99.

The upshot is that all these definitions in header files create
an external definition wherever those headers are included,
resulting in multiple definition errors at link time.

Changing all these functions to "static inline" fixes the problem
since this works as desired in all gcc versions.  Although the
semantics are slightly different (a static inline definition may
result in an actual function being emitted), it works as intended
in practice.

This patch also removes extern prototype declarations for the
changed functions where they existed.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Previously the driver was only tested on Power SoCs. Different barrier
instructions are needed for ARM SoCs.

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

Linux Kernel abolished include/linux/config.h long time ago.
(around version v2.6.18..v2.6.19)

We don't need to provide Linux copatibility any more.

This commit deletes include/linux/config.h
and fixes source files not to include this.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

a fixup __iomem definition in arch code appears to be placed there as a cover
up from a code import from linux when u-boot didn't yet have a compiler.h,
introduced by commit 812711ce6b3a386125dcf0d6a59588e461abbb87 "Implement
__raw_{read,write}[bwl] on all architectures".

git show 812711ce6b3a386125dcf0d6a59588e461abbb87:include/linux/compiler.h
fatal: Path 'include/linux/compiler.h' exists on disk, but not in '812711ce6b3a386125dcf0d6a59588e461abbb87'.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>