The big.LITTLE architecture is composed of two clusters of cpus. One cluster
contains less powerful but more energy efficient processors and the other
cluster groups the powerful but energy-intensive cpus.
The TC2 testchip implements two clusters of CPUs (A7 and A15 clusters in
a big.LITTLE configuration) connected through a CCI interconnect that manages
coherency of their respective L2 caches and intercluster distributed
virtual memory messages (DVM).
TC2 testchip integrates a power controller that manages cores resets, wake-up
IRQs and cluster low-power states. Power states are managed at cluster
level, which means that voltage is removed from a cluster iff all cores
in a cluster are in a wfi state. Single cores can enter a reset state
which is identical to wfi in terms of power consumption but simplifies the
way cluster states are entered.
This patch provides a multiple driver CPU idle implementation for TC2
which paves the way for a generic big.LITTLE idle driver for all
upcoming big.LITTLE based systems on chip.
The driver relies on the MCPM infrastructure to coordinate and manage
core power states; in particular MCPM allows to suspend specific cores
and hides the CPUs coordination required to shut-down clusters of CPUs.
Power down sequences for the respective clusters are implemented in the
MCPM TC2 backend, with all code needed to clean caches and exit coherency.
The multiple driver CPU idle infrastructure allows to define different
C-states for big and little cores, determined at boot by checking the
part id of the possible CPUs and initializing the respective logical
masks in the big and little drivers.
Current big.little systems are composed of A7 and A15 clusters, as
implemented in TC2, but in the future that may change and the driver
will have evolve to retrieve what is a 'big' cpu and what is a 'little'
cpu in order to build the correct topology.
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Amit Kucheria <amit.kucheria@linaro.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
To prevent cores from exiting wfi when they are about to be shut down
the GIC CPU IF must be disabled so that the GIC CPU IF IRQ output line
is not asserted to the cores. wfi completion must be prevented since,
in absence of coordinating HW logic, if the power controller receives
a standbywfi signal but in the meantime the processor restarts executing
owing to a pending IRQ, the core might be reset when running in a
non-quiescent state (eg with pending load/store transactions)
Raw GIC distributor IRQ signals are routed to the power controller, that
is capable of taking core out of reset on pending IRQs even if their GIC
CPU IF is disabled, thus keeping the normal wfi behaviour.
GIC CPU IF is restored upon CPU wake-up by the respective MCPM API
consumers (ie CPU idle driver and suspend to RAM thread).
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
When processors are about to hit low power states, the assertion of
standbywfi signal, triggered by the wfi instruction, is essential to
entering low power modes. If an IRQ is pending on the processor at the
time wfi is issued, the wfi instruction completes and the processor
restarts execution without asserting the standbywfi signal. Depending
on the platform power controller HW this behaviour can be acceptable or
not; if this behaviour must be prevented software should be provided
with a way to disable the routing of interrupts to the core IRQ pins.
On systems where raw GIC distributor interrupts are connected to the power
controller as wake-up events (hence the power controller still senses
IRQs and can wake up cores upon IRQ pending), the GIC CPU interface can
be disabled on power down, so that the GIC CPU IF output is gated and wfi
cannot complete, thereby preventing the standbywfi issue.
This patch adds a simple function to the GIC driver that allows to
disable the GIC CPU IF from power down procedures.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
[rewrote commit log]
Signed-off-by: Olof Johansson <olof@lixom.net>
If ext_debugging is enabled and path[depth].p_ext is NULL, len
and lblock are printed non initialized
Signed-off-by: Andi Shyti <andi@etezian.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When trying to debug an interrupt delivery problem I noticed that not
all of the wakeup conditions on the worker thread were included in the
debug message. This patch rectifies that.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9462 requires this HW fix for ASPM to work properly.
Also, since WARegVal is used only for the AR8003 family,
use AR_SREV_9300_20_OR_LATER.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When DEBUG is defined, dev_dbg_ratelimited uses dynamic debug data
structures even when CONFIG_DYNAMIC_DEBUG is not defined.
It leads to build break.
For example, when I try to use dev_dbg_ratelimited in USB code and
CONFIG_USB_DEBUG is enabled, but CONFIG_DYNAMIC_DEBUG is not, I get:
CC [M] drivers/usb/host/xhci-ring.o
drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_intr_tx’:
drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function ‘DEFINE_DYNAMIC_DEBUG_METADATA’ [-Werror=implicit-function-declaration]
drivers/usb/host/xhci-ring.c:3059:3: error: ‘descriptor’ undeclared (first use in this function)
drivers/usb/host/xhci-ring.c:3059:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/usb/host/xhci-ring.c:3059:3: error: implicit declaration of function ‘__dynamic_pr_debug’ [-Werror=implicit-function-declaration]
drivers/usb/host/xhci-ring.c: In function ‘xhci_queue_isoc_tx_prepare’:
drivers/usb/host/xhci-ring.c:3847:3: error: ‘descriptor’ undeclared (first use in this function)
cc1: some warnings being treated as errors
make[2]: *** [drivers/usb/host/xhci-ring.o] Error 1
make[1]: *** [drivers/usb/host] Error 2
make: *** [drivers/usb/] Error 2
This patch separates definition for CONFIG_DYNAMIC_DEBUG and DEBUG cases.
[Note, Sarah moved the comment above the macro to avoid checkpatch
warnings.]
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These offsets are not used, and in some cases are completely reserved
even in the spec, but I'm adding them for completeness just to match
the diagrams in the spec, e.g., PCIe spec r3.0, sec 7.8.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The convention of showing bits in a mask of the full register width, e.g.,
"0x00000007" instead of "0x07" for a field in a 32-bit register, is common
but not universal in this file. This patch makes it consistently used at
least for the PCIe capability.
Whitespace and zero-extension changes only; no functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
pci_pcie_cap2() was replaced by pcie_capability_read_word() and similar
functions, so update the comment.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The PCI_EXP_TYPE_PCI_BRIDGE is a *PCIe* function that is a bridge to
PCI/PCI-X. See PCIe spec r3.0, sec 7.8.2.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The regmap_debugfs_get_dump_start() function maps from a file offset to the
register that can be found at that position in the file. This is done using a
look-up table. Commit d6814a7d ("regmap: debugfs: Suppress cache for partial
register files") added a check to bypass the look-up table for partial register
files, since the offsets in that table are only correct for the full register
file. The check incorrectly uses the file offset instead of the register base
address and returns it. This will cause the file offset to be interpreted as a
register address which will result in a incorrect output from the registers file
for all reads except at position 0.
The issue can easily be reproduced by doing small reads the registers file, e.g.
`dd if=registers bs=10 count=5`.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
From Simon Horman:
Renesas ARM based SoC SMP updates for v3.12
* Per-CPU SMP boot and sleep code on SoCs that use SCU
* Shared SCU CPU Hotplug code on r8a7779 and sh73a0 SoCs
* Shared SCU CPU boot code on emev2, r8a7779 and sh73a0 SoCs
* tag 'renesas-smp-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: Per-CPU SMP boot / sleep code for SCU SoCs
ARM: shmobile: Introduce per-CPU SMP boot / sleep code
ARM: shmobile: Use shared SCU CPU Hotplug code on r8a7779
ARM: shmobile: Use shared SCU CPU Hotplug code on sh73a0
ARM: shmobile: Add shared SCU CPU Hotplug code
ARM: shmobile: Use shared SCU SMP boot code on emev2
ARM: shmobile: Use shared SCU SMP boot code on r8a7779
ARM: shmobile: Use shared SCU SMP boot code on sh73a0
ARM: shmobile: Introduce shared SCU SMP boot code
Signed-off-by: Olof Johansson <olof@lixom.net>
From Simon Horman:
Third round of Renesas ARM based SoC cleanups for v3.12
* Remove global GPIO_NR definition from sh73a0 SoC
* Remove unnecessary nfsroot settings from bootargs of
kzm9d and armadillo800eva
* Rename irq initialisation functions of r8a7779 SoC
to make them consistent with other SoCs
* Simplify irq initialisation of r8a7740 SoC
* Add missing __initdata annotations to bockw board, and
r8a7790 and r8a7779 SoCs
* Refactor time initialisation and remove shmobile_init_time.
- This affects the following boards: kzm9g, marzen, ape6evm,
armadillo800eva and bockw
- This affects the following SoCs: r8a7790, r8a7779, r7a7740, r7a73a4
* Cleanup device registration code of r8a7778 SoC
* tag 'renesas-cleanup3-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (45 commits)
ARM: shmobile: sh73a0: Remove global GPIO_NR definition
ARM: shmobile: kzm9d: remove nfsroot settings from bootargs
ARM: shmobile: armadillo800eva: remove nfsroot settings from bootargs
ARM: shmobile: r8a7779: move r8a7779_init_irq_xxx() to setup
ARM: shmobile: r8a7740: move r8a7740_init_irq_of() to setup
ARM: shmobile: bockw: add missing __initdata
ARM: shmobile: r8a7790: add missing __initdata
ARM: shmobile: r8a7779: add missing __initdata
ARM: shmobile: Remove unused shmobile_init_time()
ARM: shmobile: Use clocksource_of_init() on r8a7790
ARM: shmobile: Use default ->init_time() on KZM9G DT ref
ARM: shmobile: Use default ->init_time() on Marzen DT ref
ARM: shmobile: Use default ->init_time() on APE6EVM DT ref
ARM: shmobile: Use default ->init_time() on APE6EVM
ARM: shmobile: Use default ->init_time() on Armadillo DT ref
ARM: shmobile: Use default ->init_time() on Bockw DT ref
ARM: shmobile: Use default ->init_time() on Bockw
ARM: shmobile: Use default ->init_time() on r8a7779
ARM: shmobile: Use default ->init_time() on r8a7778
ARM: shmobile: Use default ->init_time() on r8a7740
...
Signed-off-by: Olof Johansson <olof@lixom.net>
From Simon Horman:
Second round of Renesas ARM based SoC cleanups for v3.12
* Remove mach/hardware.h which has no useful contents
* Remove ag5evm board support
* Remove kota2 board support
* Use pm-rmobile on sh7372 and r8a7740 SoCs only, it is otherwise unneeded
* Remove use of INTC header on r8a7779 and r8a7740 SoCs
* Cleanup registration of usb phy in r8a7779 SoC
* Remove '0x's from R8A7779 DTS file for r8a7779 SoC
* tag 'renesas-cleanup2-for-v3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (74 commits)
ARM: shmobile: r8a7779: Remove '0x's from R8A7779 DTS file
ARM: shmobile: r8a7779: cleanup registration of usb phy
ARM: shmobile: No need to use INTC header on r8a7779
ARM: shmobile: No need to use INTC demux on r8a7740
ARM: shmobile: Use pm-rmobile on sh7372 and r8a7740 only
ARM: shmobile: r8a73a4: Remove ->init_machine() special case
ARM: shmobile: Remove include <mach/hardware.h>
ARM: shmobile: Remove Marzen use of <mach/hardware.h>
ARM: shmobile: Remove r8a7779 use of <mach/hardware.h>
ARM: shmobile: Remove EMEV2 use of <mach/hardware.h>
ARM: shmobile: Remove sh7372 use of <mach/hardware.h>
ARM: shmobile: Remove sh73a0 use of <mach/hardware.h>
ARCH: ARM: shmobile: Remove ag5evm board support
ARCH: ARM: shmobile: Remove kota2 board support
leds: Remove leds-renesas-tpu driver
ARM: shmobile: sh73a0: Remove all GPIOs
ARM: shmobile: kota2: Use leds-pwm + pwm-rmob
ARM: shmobile: armadillo800eva: Add backlight support
ARM: shmobile: Setup r8a7790 arch timer based on MD pins
ARM: shmobile: Introduce r8a7790_read_mode_pins()
...
Signed-off-by: Olof Johansson <olof@lixom.net>
Implement ib_create_flow() and ib_destroy_flow().
Translate the verbs structures provided by the user to HW structures
and call the MLX4_QP_FLOW_STEERING_ATTACH/DETACH firmware commands.
On the ATTACH command completion, the firmware provides a 64-bit
registration ID, which is placed into struct mlx4_ib_flow that wraps
the instance of struct ib_flow which is retuned to caller. Later,
this reg ID is used for detaching that flow from the firmware.
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Implement ib_uverbs_create_flow() and ib_uverbs_destroy_flow() to
support flow steering for user space applications.
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Add infrastructure to support extended uverbs capabilities in a
forward/backward manner. Uverbs command opcodes which are based on
the verbs extensions approach should be greater or equal to
IB_USER_VERBS_CMD_THRESHOLD. They have new header format and
processed a bit differently.
Whenever a specific IB_USER_VERBS_CMD_XXX is extended, which practically means
it needs to have additional arguments, we will be able to add them without creating
a completely new IB_USER_VERBS_CMD_YYY command or bumping the uverbs ABI version.
This patch for itself doesn't provide the whole scheme which is also dependent
on adding a comp_mask field to each extended uverbs command struct.
The new header framework allows for future extension of the CMD arguments
(ib_uverbs_cmd_hdr.in_words, ib_uverbs_cmd_hdr.out_words) for an existing
new command (that is a command that supports the new uverbs command header format
suggested in this patch) w/o bumping ABI version and with maintaining backward
and formward compatibility to new and old libibverbs versions.
In the uverbs command we are passing both uverbs arguments and the provider arguments.
We split the ib_uverbs_cmd_hdr.in_words to ib_uverbs_cmd_hdr.in_words which will now carry only
uverbs input argument struct size and ib_uverbs_cmd_hdr.provider_in_words that will carry
the provider input argument size. Same goes for the response (the uverbs CMD output argument).
For example take the create_cq call and the mlx4_ib provider:
The uverbs layer gets libibverb's struct ibv_create_cq (named struct ib_uverbs_create_cq
in the kernel), mlx4_ib gets libmlx4's struct mlx4_create_cq (which includes struct
ibv_create_cq and is named struct mlx4_ib_create_cq in the kernel) and
in_words = sizeof(mlx4_create_cq)/4 .
Thus ib_uverbs_cmd_hdr.in_words carry both uverbs plus mlx4_ib input argument sizes,
where uverbs assumes it knows the size of its input argument - struct ibv_create_cq.
Now, if we wish to add a variable to struct ibv_create_cq, we can add a comp_mask field
to the struct which is basically bit field indicating which fields exists in the struct
(as done for the libibverbs API extension), but we need a way to tell what is the total
size of the struct and not assume the struct size is predefined (since we may get different
struct sizes from different user libibverbs versions). So we know at which point the
provider input argument (struct mlx4_create_cq) begins. Same goes for extending the
provider struct mlx4_create_cq. Thus we split the ib_uverbs_cmd_hdr.in_words to
ib_uverbs_cmd_hdr.in_words which will now carry only uverbs input argument struct size and
ib_uverbs_cmd_hdr.provider_in_words that will carry the provider (mlx4_ib) input argument size.
Signed-off-by: Igor Ivanov <Igor.Ivanov@itseez.com>
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
The RDMA stack allows for applications to create IB_QPT_RAW_PACKET
QPs, which receive plain Ethernet packets, specifically packets that
don't carry any QPN to be matched by the receiving side. Applications
using these QPs must be provided with a method to program some
steering rule with the HW so packets arriving at the local port can be
routed to them.
This patch adds ib_create_flow(), which allow providing a flow
specification for a QP. When there's a match between the
specification and a received packet, the packet is forwarded to that
QP, in a the same way one uses ib_attach_multicast() for IB UD
multicast handling.
Flow specifications are provided as instances of struct ib_flow_spec_yyy,
which describe L2, L3 and L4 headers. Currently specs for Ethernet, IPv4,
TCP and UDP are defined. Flow specs are made of values and masks.
The input to ib_create_flow() is a struct ib_flow_attr, which contains
a few mandatory control elements and optional flow specs.
struct ib_flow_attr {
enum ib_flow_attr_type type;
u16 size;
u16 priority;
u32 flags;
u8 num_of_specs;
u8 port;
/* Following are the optional layers according to user request
* struct ib_flow_spec_yyy
* struct ib_flow_spec_zzz
*/
};
As these specs are eventually coming from user space, they are defined and
used in a way which allows adding new spec types without kernel/user ABI
change, just with a little API enhancement which defines the newly added spec.
The flow spec structures are defined with TLV (Type-Length-Value)
entries, which allows calling ib_create_flow() with a list of variable
length of optional specs.
For the actual processing of ib_flow_attr the driver uses the number
of specs and the size mandatory fields along with the TLV nature of
the specs.
Steering rules processing order is according to the domain over which
the rule is set and the rule priority. All rules set by user space
applicatations fall into the IB_FLOW_DOMAIN_USER domain, other domains
could be used by future IPoIB RFS and Ethetool flow-steering interface
implementation. Lower numerical value for the priority field means
higher priority.
The returned value from ib_create_flow() is a struct ib_flow, which
contains a database pointer (handle) provided by the HW driver to be
used when calling ib_destroy_flow().
Applications that offload TCP/IP traffic can also be written over IB
UD QPs. The ib_create_flow() / ib_destroy_flow() API is designed to
support UD QPs too. A HW driver can set IB_DEVICE_MANAGED_FLOW_STEERING
to denote support for flow steering.
The ib_flow_attr enum type supports usage of flow steering for promiscuous
and sniffer purposes:
IB_FLOW_ATTR_NORMAL - "regular" rule, steering according to rule specification
IB_FLOW_ATTR_ALL_DEFAULT - default unicast and multicast rule, receive
all Ethernet traffic which isn't steered to any QP
IB_FLOW_ATTR_MC_DEFAULT - same as IB_FLOW_ATTR_ALL_DEFAULT but only for multicast
IB_FLOW_ATTR_SNIFFER - sniffer rule, receive all port traffic
ALL_DEFAULT and MC_DEFAULT rules options are valid only for Ethernet link type.
Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
When I included the "empty" function for sysfs_create_groups() when
CONFIG_SYSFS=n, I forgot to return a value for it, so things blew up the
build. This patch fixes that, stupid me.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit bb2314b479.
It wasn't necessarily wrong per se, but we're still busily discussing
the exact details of this all, so I'm going to revert it for now.
It's true that you can already do flink() through /proc and that flink()
isn't new. But as Brad Spengler points out, some secure environments do
not mount proc, and flink adds a new interface that can avoid path
lookup of the source for those kinds of environments.
We may re-do this (and even mark it for stable backporting back in 3.11
and possibly earlier) once the whole discussion about the interface is done.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eventfd_fget() tests to see whether the file is an eventfd file, which
we then immediately pass to eventfd_ctx_fileget(), which again tests
whether the file is an eventfd file. Simplify slightly by using
fdget() so that we only test that we're looking at an eventfd once.
fget() could also be used, but fdget() makes use of fget_light() for
another slight optimization.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c: In function 'ar9003_hw_ant_ctrl_apply':
>> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3618: warning: 'regval' is used uninitialized in this function
It seems obvious that 'regval' should have been 'value'...
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-e is a non-standard echo option, echo output is
implementation-dependent when it is used. Replace echo -e
with printf as suggested by POSIX echo manual.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
It turns out that if we exit the guest due to a hcall instruction (sc 1),
and the loading of the instruction in the guest exit path fails for any
reason, the call to kvmppc_ld() in kvmppc_get_last_inst() fetches the
instruction after the hcall instruction rather than the hcall itself.
This in turn means that the instruction doesn't get recognized as an
hcall in kvmppc_handle_exit_pr() but gets passed to the guest kernel
as a sc instruction. That usually results in the guest kernel getting
a return code of 38 (ENOSYS) from an hcall, which often triggers a
BUG_ON() or other failure.
This fixes the problem by adding a new variant of kvmppc_get_last_inst()
called kvmppc_get_last_sc(), which fetches the instruction if necessary
from pc - 4 rather than pc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Currently the code assumes that once we load up guest FP/VSX or VMX
state into the CPU, it stays valid in the CPU registers until we
explicitly flush it to the thread_struct. However, on POWER7,
copy_page() and memcpy() can use VMX. These functions do flush the
VMX state to the thread_struct before using VMX instructions, but if
this happens while we have guest state in the VMX registers, and we
then re-enter the guest, we don't reload the VMX state from the
thread_struct, leading to guest corruption. This has been observed
to cause guest processes to segfault.
To fix this, we check before re-entering the guest that all of the
bits corresponding to facilities owned by the guest, as expressed
in vcpu->arch.guest_owned_ext, are set in current->thread.regs->msr.
Any bits that have been cleared correspond to facilities that have
been used by kernel code and thus flushed to the thread_struct, so
for them we reload the state from the thread_struct.
We also need to check current->thread.regs->msr before calling
giveup_fpu() or giveup_altivec(), since if the relevant bit is
clear, the state has already been flushed to the thread_struct and
to flush it again would corrupt it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
The offset to add to the hosts monotonic time, kvmclock_offset, is
calculated against the monotonic time at KVM_SET_CLOCK ioctl time.
Request a master clock update at this time, to reduce a potentially
unbounded difference between the values of the masterclock and
the clock value used to calculate kvmclock_offset.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Commit 8e44ddc3f3 ("powerpc/kvm/book3s: Add support for H_IPOLL and
H_XIRR_X in XICS emulation") added a call to get_tb() but didn't
include the header that defines it, and on some configs this means
book3s_xics.c fails to compile:
arch/powerpc/kvm/book3s_xics.c: In function ‘kvmppc_xics_hcall’:
arch/powerpc/kvm/book3s_xics.c:812:3: error: implicit declaration of function ‘get_tb’ [-Werror=implicit-function-declaration]
Cc: stable@vger.kernel.org [v3.10, v3.11]
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
err was overwritten by a previous function call, and checked to be 0. If
the following page allocation fails, 0 is going to be returned instead
of -ENOMEM.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number
when failure occurs, so it need a type cast for comparing.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Support for single-step in the emulator (new in 3.12) does not work for
MMIO or PIO writes, because they are completed without returning to
the emulator. This is not worse than what we had in 3.11; still, add
comments so that the issue is not forgotten.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Include "linux/export.h" to avoid following warnings during compilation:
/***
pinctrl/pinctrl-utils.c:53:1: warning: data definition has no type or storage class [enabled by default]
pinctrl/pinctrl-utils.c:53:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
pinctrl/pinctrl-utils.c:53:1: warning: parameter names (without types) in function declaration [enabled by default]
pinctrl/pinctrl-utils.c:70:1: warning: data definition has no type or storage class [enabled by default]
pinctrl/pinctrl-utils.c:70:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
pinctrl/pinctrl-utils.c:70:1: warning: parameter names (without types) in function declaration [enabled by default]
pinctrl/pinctrl-utils.c:98:1: warning: data definition has no type or storage class [enabled by default]
pinctrl/pinctrl-utils.c:98:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
pinctrl/pinctrl-utils.c:98:1: warning: parameter names (without types) in function declaration [enabled by default]
pinctrl/pinctrl-utils.c:122:1: warning: data definition has no type or storage class [enabled by default]
pinctrl/pinctrl-utils.c:122:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
pinctrl/pinctrl-utils.c:122:1: warning: parameter names (without types) in function declaration [enabled by default]
pinctrl/pinctrl-utils.c:135:1: warning: data definition has no type or storage class [enabled by default]
pinctrl/pinctrl-utils.c:135:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Wimplicit-int]
pinctrl/pinctrl-utils.c:135:1: warning: parameter names (without types) in function declaration [enabled by default]
**/
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch simplifies the code and makes it better in readability.
Now the logic in the while loop is simply
"write to ALTERA_SPI_TXDATA then read from ALTERA_SPI_TXDATA".
There is a slightly logic change because now we avoid a read-write cycle when
hw->len is 0. Since the code in bitbang library will call bitbang->txrx_bufs()
only when t->len is not 0, this is not a problem.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Thomas Chou <thomas@wytron.com.tw>
Signed-off-by: Mark Brown <broonie@linaro.org>
If "irq == NUM_EINT" then it writes one space beyond the end of the
eint_data->domains[] array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The intent here was to test if the bit was set or not but there is a
logical vs bitwise AND typo so it is true if any bits are set.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
