hcd-pci.c in usbcore contains a check for wakeup requests racing with
controller suspend. This check is going to be moved out of usbcore
and into the individual controller drivers, where it can apply to all
platforms, not just PCI.
This patch adds the check to uhci-hcd. Ironically, none of the
non-PCI platform drivers for uhci-hcd implement suspend/resume.
Nevertheless, this change is needed to accomodate the upcoming change
to usbcore.
The patch also removes an outdated check of the root hub state. For
one thing, the PM layer has long been quite reliable about suspending
root hubs before controllers. For another, virtually the same check
is also made in hcd-pci.c; there's no point in repeating it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hcd-pci.c in usbcore contains a check for wakeup requests racing with
controller suspend. This check is going to be moved out of usbcore
and into the individual controller drivers, where it can apply to all
platforms, not just PCI.
This patch adds the check to ehci-hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch changes a dev_warn() call in usbcore to dev_dbg(). It's
not necessary to warn about drivers missing a reset-resume callback,
since the reset-resume method is optional.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes an endian-related error in ohci-hcd (detected by
sparse) and clarifies a comment explaining a peculiar locking
arrangement that sparse warns about.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes several sparse errors in ehci-hcd introduced by
commit 3d091a6f70 (USB: EHCI: AMD periodic frame list table quirk).
Although the problem fixed by that commit affects only little-endian
systems, the source code has to use types appropriate for big-endian
too.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes a type mismatch in ehci-hcd caused by commit
b35c5009bb (USB: EHCI: create per-TT bandwidth tables). The c_maskp
parameter in check_intr_schedule() was changed to point to unsigned
int rather than __hc32, but the prototype declaration wasn't adjusted
accordingly.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's my pull request for usb-next and 3.13. My xHCI tree is closed
after this point, since I won't be able to run my full tests while I'm in
Scotland. After Kernel Summit, I'll be on vacation with access to email
from Oct 26th to Nov 6th.
Here's what's in this request:
- Patches to fix USB 2.0 Link PM issues that cause USB 3.0 devices to not
enumerate or misbehave when plugged into a USB 2.0 port. Those are
marked for stable.
- A msec vs jiffies bug fix by xiao jin, which results in fairly harmless
behavior, and thus isn't marked for stable.
- Xenia's patches to refactor the xHCI command handling code, which makes
it much more readable and consistent.
- Misc cleanup patches, one by Sachin Kamat and three from Dan Williams.
Here's what's not in this request:
- Dan's two patches to allow the xHCI host to use the "Windows" or "new"
enumeration scheme. I did not have time to test those, and I want to
run them with as many USB devices as I can get a hold of. That will
have to wait for 3.14.
- Xenia's patches to remove xhci_readl in favor of readl. I'll queue
those for 3.14 after I test them.
- The xHCI streams update, UAS fixes, and usbfs streams support. I'm not
comfortable with changes and fixes to that patchset coming in this late.
I would rather wait for 3.14 and be really sure the streams support is
stable before we add new userspace API and remove CONFIG_BROKEN from the
uas driver.
- Julius' patch to clear the port reset bit on hub resume that came in
a couple days ago. It looks harmless, but I would rather take the time
to test and queue it for usb-linus and the stable trees once 3.13-rc1
is out.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSYH+2AAoJEBMGWMLi1Gc5XnkP/RN7Npl576unFyKV9alGn+yw
imimJBKXpzoWomnSQWO/AcPyFxYA2sm22WFVNIyz/qMq2koo5xk9dM1atxr1lAmJ
NaLnyf0yCKmyTWW+EGlIUa+FBM29WyXnSwMF2UAIN35ZVwqfpJmunLs8kLxW3Sie
ZJoz2MMZNrgNW83Bj1e3HaRFez4goYx1pslM4MpLuno8pHumrWFu5ySk8naxjRyk
Yz6DRBHaa8fYLA36Pk+KkmtE9a5JO+ZCe6yMljmj0T6wiawjtzgukO2pUdxjC+b7
nb/4dsR3nxlpf6O3wR7BRDLcY3zrQM2RjjOuvpyoZ1/kPgtl83RfwkuSWzQ2o+bT
3tV4K5mIdfwHU+oUqlvzjjGHmjN62bO5g3b0HFRKxcMQL4QxmjuEW9mymXzLx/BT
9UG9vta6mW6F/dwL2olLIha64a+vTvV3U4Jn4DDAYUtFtEmH0EYLgzBwSLHKm/ZE
YuroUT7CK6JgLsQHohXQ5jw3sUgsqF4zBL4SvtZrCHSp4agOi+WocMfnPWkETqAo
mOyw7F9ZouG04hsRs3kbCAwaXiBreSgElVeJXcDtZ8W/zbumLChR9jenM52UxFgk
TAJ6ymRP7BKdVree9u3i+usQkxLGvf6imtbAiYveR+1EReDxCV7+NRJz/uEdxTDX
5rLqvhV+1WllJhzRnbao
=H4xp
-----END PGP SIGNATURE-----
Merge tag 'for-usb-next-2013-10-17' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next
Sarah writes:
xhci: Final patches for 3.13
Hi Greg,
Here's my pull request for usb-next and 3.13. My xHCI tree is closed
after this point, since I won't be able to run my full tests while I'm in
Scotland. After Kernel Summit, I'll be on vacation with access to email
from Oct 26th to Nov 6th.
Here's what's in this request:
- Patches to fix USB 2.0 Link PM issues that cause USB 3.0 devices to not
enumerate or misbehave when plugged into a USB 2.0 port. Those are
marked for stable.
- A msec vs jiffies bug fix by xiao jin, which results in fairly harmless
behavior, and thus isn't marked for stable.
- Xenia's patches to refactor the xHCI command handling code, which makes
it much more readable and consistent.
- Misc cleanup patches, one by Sachin Kamat and three from Dan Williams.
Here's what's not in this request:
- Dan's two patches to allow the xHCI host to use the "Windows" or "new"
enumeration scheme. I did not have time to test those, and I want to
run them with as many USB devices as I can get a hold of. That will
have to wait for 3.14.
- Xenia's patches to remove xhci_readl in favor of readl. I'll queue
those for 3.14 after I test them.
- The xHCI streams update, UAS fixes, and usbfs streams support. I'm not
comfortable with changes and fixes to that patchset coming in this late.
I would rather wait for 3.14 and be really sure the streams support is
stable before we add new userspace API and remove CONFIG_BROKEN from the
uas driver.
- Julius' patch to clear the port reset bit on hub resume that came in
a couple days ago. It looks harmless, but I would rather take the time
to test and queue it for usb-linus and the stable trees once 3.13-rc1
is out.
Sarah Sharp
Some bits of the 'CRB' register have different functions when read or
written, so add macros to define the read-only parts.
Add macros to define the widths of the bitfields in the 'CRA' and 'CRB'
registers and the standard encoder setup value.
Add macros to construct and extract parts of the 'CRA' and 'CRB'
register values and the standard encoder setup value, along with a
couple of general helper macros for the above.
Redefine the bitfield mask macros for 'CRA', 'CRB' and standard encoder
setup using the above.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are some bits in the 'CRB' register not defined in "s626.h".
Three of these are read-only bits that overlay the write-only interrupt
control bits. Another missing bit controls whether counter 'B' is
cleared when counter 'A' overflows. Add the missing bit definitions for
completeness.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The counter 'A' clock polarity field in the 'CRA' register is only 1 bit
wide, but the `S626_CRAMSK_CLKPOL_A` macro shows it as 2 bits wide,
which would overlap with the counter 'A' interrupt source field. This
is harmless as the macro isn't actually used yet, but correct it anyway
as I want to use it!
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The macros `S626_CLKSRC_COUNTER`, `S626_CLKSRC_TIMER` and
`S626_CLKSRC_EXTENDER` are used logically to set the operating mode of
an encoder channel. `S626_CLKSRC_COUNTER` (0) is also used as a 2-bit
physical value to set the counter source of an encoder channel to
"encoder".
Rename the macros to `S626_ENCMODE_COUNTER`, `S626_ENCMODE_TIMER` and
`S626_ENCMODE_EXTENDER` and rename some other macros and (unused)
functions relating to the encoder mode for consistency.
Define new macros to specify the physical counter source values for the
'CRA' register and rename the corresponding bitshift and mask macros
accordingly. The physical values for the counter source are:
S626_CNTSRC_ENCODER = 0 // encoder
S626_CNTSRC_DIGIN = 1 // digital inputs
S626_CNTSRC_SYSCLK = 2 // system clock up
S626_CNTSRC_SYSCLK_DOWN = 3 // system clock down
Also use the `S626_CNTSRC_SYSCLK` value as a bitmask (bit 1) to indicate
either of the system clock values, with the direction (bit 0) indicated
separately in this case.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When setting the clock source for one of the 'A' encoders to operate in
"counter" mode in `s626_set_mode_a()`, bitshift the clock source value by
`S626_CRABIT_CLKSRC_A` for consistency with the other modes. This has
no effect on the value since `S626_CRABIT_CLKSRC_A` is 0.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When setting up an encoder channel, the setup value includes a polarity
and direction, but these are the same bit of the setup value:
S626_CLKPOL_POS = S626_CNTDIR_UP = 0
S626_CLKPOL_NEG = S626_CNTDIR_DOWN = 1
In the construction of the setup value, both the CLKPOL and the CNTDIR
constants are shifted by the same amount `S626_BF_CLKPOL`. Only the
following combinations are set up currently (this may change if user
configuration of the encoder is implemented properly):
(S626_CLKPOL_POS << S626_BF_CLKPOL)
(S626_CLKPOL_POS << S626_BF_CLKPOL) |
(S626_CNTDIR_UP << S626_BF_CLKPOL)
(S626_CLKPOL_POS << S626_BF_CLKPOL) |
(S626_CNTDIR_DOWN << S626_BF_CLKPOL)
The first two are used in "counter" mode and is equivalent to:
(S626_CLKPOL_POS << S626_BF_CLKPOL)
The last one is used in "timer" mode and is equivalent to:
(S626_CNTDIR_DOWN << S626_BF_CLKPOL)
Use the shorter equivalents. The comments in "s626.h" indicate that the
'CLKPOL' constants make more sense for the "counter" mode (when the
encoders operate as up/down counters) and the 'CNTDIR' constants make
more sense for the "timer" mode.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `unsigned char chan_is_bipolar[]` member of `struct rtd_private` is
used with some macros as a packed array of 1-bit values that indicate
whether the corresponding entries in the hardware's "channel-gain" table
have been set to a bipolar (1) or unipolar (0) range, as the raw samples
from the hardware need to be cooked differently in each case.
Replace the declaration of the member with a standard Linux bitfield
using `DECLARE_BITFIELD()`, and replace the home-grown macros used
access the bitfield with the standard Linux non-atomic bitop functions,
`__set_bit()`, `__clear_bit()` and `test_bit()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed two coding style issues, specifically:
ft1000_proc.c:35: ERROR: space required before the open parenthesis '('
ft1000_proc.c:42: ERROR: space required before the open parenthesis '('
Signed-off-by: Aldo Iljazi <me@aldo.io>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is necessary so that xillybus_core uses the correct device pointer
for PCIe devices in diagnostic message calls (dev_err, dev_warn and dev_info)
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary spaces between function names and open
parentheses in router_proc.c to meet kernel coding style.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reformat a pointer variable in lib-move.c to meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary parentheses from return statements to
eliminate errors generated by checkpatch.pl and meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed lines to not exceed more than 80 columns per line to meet
kernel coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move open braces to previous lines in lib-move.c to meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary whitespace around open parentheses in lib-move.c
to meet kernel coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove spaces between function names and open parentheses to
eliminate warnings generated by checkpatch.pl and meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Help ensure that Lars-Peter gets CCed on dmaengine related patches by
adding a MAINTAINERS entry for the helpers.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A number of small, fairly unexciting, fixes for drivers - nothing stand
out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
iQIcBAABAgAGBQJSYWzPAAoJELSic+t+oim92SQP/j3VAY0EMslcV2xMPk8ly9qK
7YqSNfwdF3YQVoM5kEdlIB3f84j82qRQ3A6/ZQui9OsZ0j5x1OZ5XCQ2csE+IzuB
e3wkDWdPfw59lCi+zS5YthpgnpuorBPpW14QcjPFp+Iqv13ajOEe0cRPnxAAL7aD
j4Uszxx1aPj5HLsjJQmwzq7ooy6BXw5pg4DrzoZ0dEp+YYmLug5j6ml7e2HicUrH
IlSz0cgcMGaD8vfN+DiUjeUU3Hf5t2v5YREqy643oFkjFREiPCd4XKBm0nD3zQZ3
rtQXVUNTVkm1AuTtCboUaGvDzQBtI8EX9DSNLi3CsLg1CNgUVUXII4IizZF5pxYA
vYaSN7GdARD4SkRtUWKZhGmohnj1ATPG9XXlfunHKJkKJN5C99b12oACT4ewxOTc
yBYxgkApfjj0VpPTjsTocfMDUt17bZMF6jzWa6GIk5ABw6yFCtPn3jspa5XJO/eo
HZ4FtlA9uY+X3oVEzFBh+btxaIyBMJ1zCZVNu0GqvZEVGhuIuV0TiiE94e6v+XOz
Cijx8Wt4m6Ohw2NCkBI7IEusv6bHnwaDRScBiUgIFo7Cmn0htd8por+br3gn7dF7
6Rcge3n6LUrzrWa7eesFoQ4rGlq8rzv8Nml0C2fW04Nom8J4u8z4nnxVEkVUI0g2
U1vsg7JszqtIoh1mvi8+
=aZuy
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.12
A number of small, fairly unexciting, fixes for drivers - nothing stand
out.
This patch adds some default settings for the generic dmaengine PCM driver for
the case that no config has been supplied. The following defaults are used:
* Use snd_dmaengine_pcm_prepare_slave_config for preparing the DMA slave
config.
* 512kB for the prealloc buffer size. This value has been chosen based on
'feels about right' and is not backed up by any scientific facts. We
may need to come up with something smarter in the future but it should
work fine for now.
With this infrastructure in place we can finally write DAI drivers which are
independent of the DMA controller they are connected to. This is e.g. useful if
the DAI IP core is reused across different SoCs, but the SoCs uses different DMA
controllers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently each platform making use the the generic dmaengine PCM driver still
needs to provide a custom snd_pcm_hardware struct which specifies the
capabilities of the DMA controller, e.g. the maximum period size that can be
supported. This patch adds code which uses the newly introduced
dma_get_slave_caps() API to query this information from the dmaengine driver.
The new code path will only be taken if the 'pcm_hardware' field of the
snd_dmaengine_pcm_config struct is NULL.
The patch also introduces a new 'fifo_size' field to the
snd_dmaengine_dai_dma_data struct which is used to initialize the
snd_pcm_hardware 'fifo_size' field and needs to be set by the DAI driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
There is no need for the CODEC to go to standby on resume since the core will
power it up as needed and in any case it is an idle_bias_off CODEC so would
normally sit with bias off while idle.
Signed-off-by: Mark Brown <broonie@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
If we have control over the LDO then disable it during suspend; the device
is already being put into reset so will be non-functional over suspend
anyway and this will save a small amount of power.
Signed-off-by: Mark Brown <broonie@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
The core support for ep93xx (currently only the DMA driver) does not
depend on the architecture at all and everything else has more strict
dependencies so enable compile test builds for improved build coverage.
Signed-off-by: Mark Brown <broonie@linaro.org>
cci_enable_port_for_self written in asm and it works with h/w
registers that are in little endian format. When run in big
endian mode it needs byteswaped constants before/after it
writes/reads to/from such registers
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
In order for ASID macro to be used as expression passed to
inline asm as 'r' operand it needs to give 32 bit unsigned result,
not unsigned 64bit expression.
Otherwise when 64bit ASID is passed to inline assembler statement
as 'r' operand (32bit) compiler behavior is not well specified.
For example when __flush_tlb_mm function compiled in big endian
case, and ASID is passed to tlb_op macro directly, 0 will be passed
as 'mcr 15, 0, r4, cr8, cr3, {2}' argument in r4, unless ASID
macro changed to produce 32 bit result.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
In big endian mode mcpm_entry_point is first function
that called on secondaries CPU. First it should switch
CPU into big endian code.
[ben.dooks@codethink.co.uk: merge fix patch from Victor into this]
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
In case of BE8 kernel data is in BE order whereas code stays in LE
order. Move sigreturn_codes to separate .S file and use proper
assembler mnemonics for these code snippets. In this case compiler
will take care of proper instructions byteswaps for BE8 case.
Change assumes that sufficiently Thumb-capable tools are used to
build kernel.
Problem was discovered during ltp testing of BE system: all rt_sig*
tests failed. Tested against the same tests in both BE and LE modes.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Fix inline asm for atomic64_xxx functions in arm atomic.h. Instead of
%H operand specifiers code should use %Q for least significant part
of the value, and %R for the most significant part of the value. %H
always returns the higher of the two register numbers, and therefore
it is not endian neutral. %H should be used with ldrexd and strexd
instructions.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
The arch_kgdb_breakpoint() function uses an inline assembly directive
to assemble a specific instruction using .word. This means the linker
will not treat is as an instruction, and therefore incorrectly swap
the endian-ness if running BE8.
As noted, this code means that kgdb is really only usable on arm32
kernels, and should be made dependant on not being a thumb2 kernel
until fixed. However this is not something to be added to this patch.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text. This
means that the BUG() macro does not get trapped properly.
Change to using <asm/opcodes.h> to provide the necessary ARM instruction
building as we cannot rely on gcc/gas having the `.inst` instructions
which where added to try and resolve this issue (reported by Dave Martin
<Dave.Martin@arm.com>).
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Use <asm/opcodes.h> to correctly transform instruction byte ordering
into in-memory ordering.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
The <hardware/coresight.h> needs to take into account the endian-ness
of the processor when reading and writing data, so change to using
the readl/writel relaxed variants from the raw ones.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
To avoid having to make every text section swap the instruction order
of all instructions, make sure modules are built also built with --be8
(as is the current kernel final link).
If we do not do this, we would end up having to swap all instructions
when loading a module, instead of just the instructions that we are
applying ELF relocations to.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
