The sgi values calculated in read_set_clear_sgi_pend_reg() and
write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4
with catastrophic results in that subfunctions ended up overwriting
memory not allocated for the expected purpose.
This showed up as bugs in kfree() and the kernel complaining a lot of
you turn on memory debugging.
This addresses: http://marc.info/?l=kvm&m=141164910007868&w=2
Reported-by: Shannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
When the device id for an IOAPIC is overridden on the kernel
command line, the iommu driver has to make sure it sets up a
DTE for this device id.
Reported-by: Su Friendy <friendy.su@sony.com.cn>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Pull gpio fixes from Linus Walleij:
"Two GPIO fixes:
- GPIO direction flags where handled wrong in the new descriptor-
based API, so direction changes did not always "take".
- Fix a handler installation race in the generic GPIO irqchip code"
* tag 'gpio-v3.17-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: Fix potential NULL handler data in chained irqchip handler
gpio: Fix gpio direction flags not getting set
Commit 71054d8841 ("x86, hpet: Introduce x86_msi_ops.setup_hpet_msi")
introduced x86_msi_ops.setup_hpet_msi to setup hpet MSI irq
when irq remapping enabled. This caused a regression of
hpet MSI irq remapping.
Original code flow before commit 71054d8841:
hpet_setup_msi_irq()
arch_setup_hpet_msi()
setup_hpet_msi_remapped()
remap_ops->setup_hpet_msi()
alloc_irte()
msi_compose_msg()
hpet_msi_write()
...
Current code flow after commit 71054d8841:
hpet_setup_msi_irq()
x86_msi.setup_hpet_msi()
setup_hpet_msi_remapped()
intel_setup_hpet_msi()
alloc_irte()
Currently, we only call alloc_irte() for hpet MSI, but
do not composed and wrote its msg...
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Some more AVS-related drivers are arriving. Update MAINTAINERS to
reflect that myself and Nishanth will keep an eye on the new ones as
well.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
IO domain voltages on some Rockchip SoCs are variable but need to be
kept in sync between the regulators and the SoC using a special
register.
A specific example using rk3288:
- If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
Said another way, this driver simply handles keeping bits in the SoC's
general register file (GRF) in sync with the actual value of a voltage
hooked up to the pins.
Note that this driver specifically doesn't include:
- any logic for deciding what voltage we should set regulators to
- any logic for deciding whether regulators (or internal SoC blocks)
should have power or not have power
If there were some other software that had the smarts of making
decisions about regulators, it would work in conjunction with this
driver. When that other software adjusted a regulator's voltage then
this driver would handle telling the SoC about it. A good example is
vqmmc for SD. In that case the dw_mmc driver simply is told about a
regulator. It changes the regulator between 3.3V and 1.8V at the
right time. This driver notices the change and makes sure that the
SoC is on the same page.
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman: fix compiler warnings]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Pull "Allwinner drivers additions for 3.18" from Maxime Ripard:
Nothing major, just handling the RTC driver changes needed for the A31/A23.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'sunxi-drivers-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc
rtc: sun6i: Add sun6i RTC driver
Pull "Allwinner defconfig additions for 3.18" from Maxime Ripard
Nothing major, just a few drivers additions and misc options
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'sunxi-defconfig-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
ARM: sunxi_defconfig: add NLS_CODEPAGE_437 and NLS_ISO8859_1
ARM: sunxi: Add A31 RTC driver to multi_v7_defconfig
ARM: sunxi: Add A31 RTC driver to sunxi_defconfig
Pull "Fifth Round of Renesas ARM Based SoC Soc Updates for v3.18" from Simon Horman:
* r8a7740: Fix documentation error copied from elsewhere
* r8a7794: Reserve memory for CMA in a manner consistent to
other R-Car Gen2 SoCs
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'renesas-soc5-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: r8a7740 legacy: Fix copied bug in comment
ARM: shmobile: r8a7794: Reserve memory as other R-Car Gen2 SoCs
Pull "Fifth Round of Renesas ARM Based SoC DT Updates for v3.18" from Simon Horman:
* Document manufacturer for KZM boards
* Use SoC-specific irqc compatible property
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'renesas-dt5-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: Add manufacturer for KZM boards
ARM: shmobile: r8a73a4 dtsi: Add SoC-specific irqc compatible property
Pull "fix PXA3xx SSP naming issue" from Haojian Zhuang:
It's imported by 972a55b62 ASoC: fix pxa-ssp compiling issue under mach-mmp from v3.5
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'pxa3xx-ssp-name' of https://git.kernel.org/pub/scm/linux/kernel/git/hzhuang1/linux:
ARM: pxa3xx: provide specific platform_devices for all ssp ports
ARM: pxa: ssp: provide platform_device_id for PXA3xx
Pull "ARM: tegra: tegra_defconfig changes for 3.18" from Stephen Warren:
Support is enabled for Venice2's touchpad, and Tegra124's AHCI (SATA)
controller, as used on Jetson TK1.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'tegra-for-3.18-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ARM: tegra: enable Atmel touchpad in defconfig
ARM: tegra: Add options for Tegra AHCI support to tegra_defconfig
Contains an update to 3.17-rc2.
Pull "ARM: tegra: device tree changes for 3.18" from Stephen Warren:
The main highlights are:
* SATA and PCIe support added to Tegra124, and enabled on Jetson TK1.
* Touchpad enabled on Venice2 (although the driver still has a few issues
to be worked out).
* NVIDIA reference boards rely on the bootloader to program the pinmux.
* Support added for the Acer Chromebook 13 (CB5).
* DT nodes added for the Tegra flow controller HW module. This will
help reduce use of iomap.h in a future code cleanup.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'tegra-for-3.18-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ARM: tegra: enable PCIe in Jetson TK1 DT
ARM: tegra: add PCIe to Tegra124 DT
ARM: tegra: rely on bootloader pinmux programming on Tegra124
ARM: tegra: add Acer Chromebook 13 device tree
ARM: tegra: Move pwm and dpaux labels to tegra124.dtsi
ARM: tegra: add touchpad to Venice2 DT
ARM: tegra: Add device tree nodes for flow controller
ARM: tegra: add PCIe-related pins to the Jetson TK1 pinmux tables
ARM: tegra: Add SATA and SATA power to Jetson TK1 device tree
ARM: tegra: Add SATA controller to Tegra124 device tree
Pull "ARM: tegra: core SoC code changes for 3.18" from Stephen Warren:
the primary change here gets its address information from DT rather than
iomap.h. This removes one more user of iomap.h, and will help allow the
code to move to a location that can be shared between arch/arm and
arch/arm64.
An unused header file was also removed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'tegra-for-3.18-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ARM: tegra: remove unused tegra_emc.h
ARM: tegra: Initialize flow controller from DT
of: Add NVIDIA Tegra flow controller bindings
Pull "More AT91 DT material for 3.18" from Nicolas Ferre:
- specify DMA channels for USART on sama5d3 and choose peripherals
that will use them on the EK boards
- SSC update for audio on at91sam9rl and at91sam9g20
- addition of the NFC clock and new pinctrl compatible string
to use enhancements that will land in drivers during this release
- several new nodes and fixes
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'at91-dt3' of git://github.com/at91linux/linux-at91:
ARM: at91/dt: at91sam9m10g45ek add rtc node
ARM: at91/dt: sama5d3: use new pinctrl compatible string
ARM: at91/dt: sama5d3: add the nfc clock
ARM: at91/dt: declare sckc node on at91sam9g45
ARM: at91/dt: Fix typo regarding can0_clk
ARM: at91/dt: at91sam9g20: switch ssc compatible string
ARM: at91/dt: at91sam9rl: switch ssc compatible string
ARM: at91: sama5d3xek: reserve dma channel for audio
ARM: at91: sama5d3: add usart dma configurations
In PCIe r1.0, sec 5.10.2, bit 0 of the Uncorrectable Error Status, Mask,
and Severity Registers was for "Training Error." In PCIe r1.1, sec 7.10.2,
bit 0 was redefined to be "Undefined."
Rename PCI_ERR_UNC_TRAIN to PCI_ERR_UNC_UND to reflect this change.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Add strings for all AER error bits defined in PCIe r3.0.
[bhelgaas: changelog, drop designated initializer change]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This patch adds the basic machine file for the MesonX SoCs. Only Meson6
is populated.
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The Meson6 SoC is produced by Amlogic inc. and it is based on 2 Cortex
A9 and an ARM Mali-400 GPU.
This patch adds two basic DTSI for the preliminary support of Meson and
Meson6 SoCs. Another DTS is also added for supporting the atv1200 board,
produced by Geniatech inc.
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This patch updates the multi_v7_defconfig with the CONFIG_* needed by
the just added Meson anch. It also adds a new defconfig specifically for
the Meson SoCs.
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add the UART definitions needed to support earlyprintk for MesonX SoCs
on UARTAO.
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Paulo Zanoni reported a lockdep splat with a locking inversion between
fpriv->fbs_lock and the modeset locks. This issue was introduced in
commit f2b50c1161
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Sep 12 17:07:32 2014 +0200
drm: Fixup locking for universal cursor planes
This here is actually one of the rare cases where lockdep hits a false
positive: The deadlock only happens in drm_fb_release, which cleans up
the file private structure when all the references are gone. So the
locking is the very last one and no one else can deadlock. It also
doesn't protect anything at all, since all ioctls are guaranteed to
have returned at this point - otherwise they'd still hold a reference
on the file.
So let's just drop it and replace it with a big comment.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reported-and-Tested-by: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Replace bare numbers like "BIT(0)" with the existing #defines, e.g.,
PCI_ERR_COR_RCVR, to improve maintainability. This way grep will find more
uses of the #defines.
No functional change.
[bhelgaas: changelog]
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.
Both triggers should work with all host/device controllers. Tested only
with musb.
Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.
Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)
Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µs
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the next commit, we will want the usb-common module to be composed of
two object files. Since Kbuild cannot "append" another object to an
existing one, we need to rename usb-common.c to something
else (common.c) and create usb-common.o by linking the wanted objects
together. Currently, usb-common.o comprises only common.o.
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the recently introduced usb_gadget_giveback_request() in favor of
direct invocation of the completion routine.
All places in drivers/usb/ matching "[-.]complete(" were replaced with a
call to usb_gadget_giveback_request(). This was compile-tested with all
ARM drivers enabled and runtime-tested for musb.
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All USB peripheral controller drivers call completion routines directly.
This patch adds usb_gadget_giveback_request() which will be used instead
of direct invocation in the next patch. The goal here is to have a place
where common functionality can be added.
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iommu_bus_init() registers a bus notifier on the given bus by using
a statically defined notifier block:
static struct notifier_block iommu_bus_nb = {
.notifier_call = iommu_bus_notifier,
};
This same notifier block is used for all busses. This causes a
problem for notifiers registered after iommu has registered this
callback on multiple busses. The problem is that a subsequent
notifier being registered on a bus which has this iommu notifier
will also get linked in to the notifier list of all other busses
which have this iommu notifier.
This patch fixes this by allocating the notifier_block at runtime.
Some error checking is also added to catch any allocation failure
or notifier registration error.
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Pull EFI fixes from Matt Fleming:
* Revert the static library changes from the merge window since they're
causing issues for Macbooks and Fedora + Grub2 (Matt Fleming)
* Delete the misleading "setup_efi_pci() failed!" message which some
people are seeing when booting EFI (Matt Fleming)
* Fix printing strings from the 32-bit EFI boot stub by only passing
32-bit addresses to the firmware (Matt Fleming)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Pull devicetree bug fixes and documentation from Grant Likely:
"Several bug fix commits for issues found in the v3.17 rc series.
Most of these are minor in that they aren't actively dangerous, but
they have been seen in the wild. The one important fix is commit
7dbe5849fb ("of: make sure of_alias is initialized before accessing
it"), without which some powerpc platforms will fail to find stdout
for the console"
* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
of/fdt: fix memory range check
of: Fix memory block alignment in early_init_dt_add_memory_arch()
of: make sure of_alias is initialized before accessing it
of: Documentation regarding attaching OF Selftest testdata
of: Disabling OF functions that use sysfs if CONFIG_SYSFS disabled
of: correct of_console_check()'s return value
For a PCI device, aliases from the IVRS table won't be populated
into dma_alias_devfn until after iommu_init_device() is called on
each device. We therefore want to split init_iommu_group() to
be called from a separate loop immediately following.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: Joerg Roedel <jroedel@suse.de>
It turns out that our assumption that aliases are always to the same
slot isn't true. One particular platform reports an IVRS alias of the
SATA controller (00:11.0) for the legacy IDE controller (00:14.1).
When we hit this, we attempt to use a single IOMMU group for
everything on the same bus, which in this case is the root complex.
We already have multiple groups defined for the root complex by this
point, resulting in multiple WARN_ON hits.
This patch makes these sorts of aliases work again with IOMMU groups
by reworking how we search through the PCI address space to find
existing groups. This should also now handle looped dependencies and
all sorts of crazy inter-dependencies that we'll likely never see.
The recursion used here should never be very deep. It's unlikely to
have individual aliases and only theoretical that we'd ever see a
chain where one alias causes us to search through to yet another
alias. We're also only dealing with PCIe device on a single bus,
which means we'll typically only see multiple slots in use on the root
complex. Loops are also a theoretically possibility, which I've
tested using fake DMA alias quirks and prevent from causing problems
using a bitmap of the devfn space that's been visited.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Cc: stable@vger.kernel.org # 3.17
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Some of the KGDB macros used for generating the BRK instructions had the
wrong spelling for DBG and KGDB abbreviations.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn
instructions (where the optional alignment hint is given but incorrect)
as LDR/STR, leading to register corruption. Detect these and correctly
treat them as unhandled, so that userspace gets the fault it expects.
Reported-by: Simon Hosie <simon.hosie@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
SCTLR.HA (hardware access flag) is deprecated and not actually
implemented by any CPUs. Furthermore, it can confuse cr_alignment checks
where the whole value of SCTLR is compared against the value sitting in
the hardware, since the bit is actually RAZ/WI and will not match the
saved cr_alignment value.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Following a recent series of enhancements to the insn code the ARMv8
allnoconfig build has been generating a large number of warnings in the
form of:
arch/arm64/kernel/insn.c:689:8: warning: 'insn' may be used uninitialized in this function [-Wmaybe-uninitialized]
This is because BUG() and related macros can be compiled out so we get
execution paths which normally result in a panic compiling out to noops
instead.
I wasn't able to immediately identify a sensible return value to use in
these cases so just return AARCH64_BREAK_FAULT - this is all "should
never happen" code so hopefully it never has a practical impact.
Signed-off-by: Mark Brown <broonie@kernel.org>
[catalin.marinas@arm.com: AARCH64_BREAK_FAULT definition contributed by Daniel Borkmann]
[catalin.marinas@arm.com: replace return 0 with AARCH64_BREAK_FAULT]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
When we have PCM (FE/BE) opened or DAPM widgets triggered we need power
up/down DSP accordingly. The DSP will do ref count of these requests
i.e. link these runtime_get/put calls of DSP
Also fix some preexisting spacing error.
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
