* pci/config:
PCI: xilinx: Convert to use generic config accessors
PCI: xgene: Convert to use generic config accessors
PCI: tegra: Convert to use generic config accessors
PCI: rcar: Convert to use generic config accessors
PCI: generic: Convert to use generic config accessors
powerpc/powermac: Convert PCI to use generic config accessors
powerpc/fsl_pci: Convert PCI to use generic config accessors
ARM: ks8695: Convert PCI to use generic config accessors
ARM: sa1100: Convert PCI to use generic config accessors
ARM: integrator: Convert PCI to use generic config accessors
ARM: cns3xxx: Convert PCI to use generic config accessors
PCI: Add generic config accessors
powerpc/PCI: Add struct pci_ops member names to initialization
mn10300/PCI: Add struct pci_ops member names to initialization
MIPS: PCI: Add struct pci_ops member names to initialization
frv/PCI: Add struct pci_ops member names to initialization
Convert the rcar-gen2 host PCI driver to use the generic config access
functions.
This changes the I/O accessors from io(read|write)X to readX/writeX
variants which are equivalent on ARM.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
CC: Simon Horman <horms@verge.net.au>
CC: linux-sh@vger.kernel.org
Convert the generic host PCI driver to use the generic config access
functions.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
CC: linux-arm-kernel@lists.infradead.org
Convert the powermac PCI driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX variants.
I believe these should be equivalent for PCI config space accesses, but
confirmation would be nice.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: linuxppc-dev@lists.ozlabs.org
Convert the fsl_pci driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX variants.
I believe these should be equivalent for PCI config space accesses, but
confirmation would be nice.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: linuxppc-dev@lists.ozlabs.org
Convert the ks8695 PCI driver to use the generic config access functions.
This changes accesses from __raw_readX/__raw_writeX to readX/writeX
variants.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
Convert the sa1100 nanoengine PCI driver to use the generic config access
functions.
Change accesses from __raw_readX/__raw_writeX to readX/writeX variants.
This removes the spinlock because it is unnecessary. The config read and
write functions are already protected with a spinlock.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
Convert the integrator PCI driver to use the generic config access
functions.
This changes accesses from __raw_readX/__raw_writeX to readX/writeX
variants. The spinlock is removed because it is unnecessary. The config
read and write functions are already protected with a spinlock and no
access can occur during the .pre_init function.
[arnd: remove unused "flags"]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
This converts the Versatile PCI host code to a platform driver using the
commom DT parsing and setup. The driver uses only an empty ARM
pci_sys_data struct and does not use pci_common_init_dev init function.
The old host code will be removed in a subsequent commit when Versatile is
completely converted to DT.
I've tested this on QEMU with the sym53c8xx driver in both i/o and memory
mapped modes.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
CC: Russell King <linux@arm.linux.org.uk>
CC: Peter Maydell <peter.maydell@linaro.org>
Add the PCI controller node for the Versatile/PB board.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
CC: Russell King <linux@arm.linux.org.uk>
In the function of_pci_get_host_bridge_resources() if the parsing of ranges
fails, previously allocated resources inclusive of bus_range are not freed
and are not expected to be freed by the function caller on error return.
This patch fixes the issues by adding code that properly frees resources
and bus_range before exiting the function with an error return value.
Fixes: cbe4097f8a ("of/pci: Add support for parsing PCI host bridge resources from DT")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Rob Herring <robh+dt@kernel.org>
Add binding documentation for the PCI controller found on Versatile PB
boards.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
CC: Kumar Gala <galak@codeaurora.org>
* pci/enumeration:
PCI: Generate uppercase hex for modalias var in uevent
* pci/hotplug:
PCI: pciehp: Handle surprise add even if surprise removal isn't supported
* pci/resource:
PCI: Fix infinite loop with ROM image of size 0
* pci/virtualization:
PCI: Add Wellsburg (X99) to Intel PCH root port ACS quirk
PCI: Add DMA alias quirk for Adaptec 3405
PCI: Add ACS quirk for Emulex NICs
PCI: Mark AMD/ATI VGA devices that don't reset on D3hot->D0 transition
PCI: Add flag for devices that don't reset on D3hot->D0 transition
PCI: Mark Atheros AR93xx to avoid bus reset
PCI: Add flag for devices where we can't use bus reset
If the image size would ever read as 0, pci_get_rom_size() could keep
processing the same image over and over again. Exit the loop if we ever
read a length of zero.
This fixes a soft lockup on boot when the radeon driver calls
pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.
[bhelgaas: changelog, reference]
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
Reported-by: Federico <federicotg@gmail.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org
This driver should be including clk.h as it's a clock consumer, not a clock
provider that needs to register clocks early.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Tanmay Inamdar <tinamdar@apm.com>
Intel has confirmed that the Wellsburg chipset, while not reporting ACS,
does provide the proper isolation through the RCBA/BSPR registers, so the
same quirk works for this set of device IDs.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Don Dugger <donald.d.dugger@intel.com>
The Adaptec 3405 is actually an Intel 80333 I/O processor where the exposed
device at 0e.0 is actually the address translation unit of the I/O
processor and a hidden, private device at 01.0 masters the DMA for the
device. Create a fixed alias between the exposed and hidden devfn so we
can enable the IOMMU.
Scenarios like this are potentially likely for any device incorporating
this I/O processor, so this little bit of abstraction with the fixed alias
table should make future additions trivial.
Without this fix, booting a system with the Intel IOMMU enabled and an
Adaptec 3405 at 02:0e.0 results in a flood of errors like this:
dmar: DRHD: handling fault status reg 3
dmar: DMAR:[DMA Write] Request device [02:01.0] fault addr ffbff000
DMAR:[fault reason 02] Present bit in context entry is clear
[bhelgaas: changelog, comment]
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Adaptec OEM Raid Solutions <aacraid@adaptec.com>
The xilinx PCIe driver prints a register value whose type is propagated to
the type returned by the GENMASK() macro. Unfortunately, that type has
recently changed as the result of a bug fix, so now we get a warning about
the type:
drivers/pci/host/pcie-xilinx.c: In function 'xilinx_pcie_clear_err_interrupts':
drivers/pci/host/pcie-xilinx.c:154:3: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
Change the code so we always print the number as an 'unsigned long' type to
avoid the warning. The original code was fine on 32-bit architectures but
not on 64-bit. Now it works as expected on both.
Fixes: 00b4d9a141 ("bitops: Fix shift overflow in GENMASK macros")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Convert the cns3xxx PCI driver to use the generic config access functions.
This changes accesses from __raw_readl/__raw_writel to readl/writel.
[arnd: remove extra open parenthesis]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
Many PCI controllers' configuration space accesses are memory-mapped and
vary only in address calculation and access checks. There are 2 main
access methods: a decoded address space such as ECAM or a single address
and data register similar to x86. This implementation can support both
cases as well as be used in cases that need additional pre- or post-access
handling.
Add a new pci_ops member, map_bus, which can do access checks and any
necessary setup. It returns the address to use for the configuration space
access. The access types supported are 32-bit only accesses or correct
byte, word, or dword sized accesses.
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
No functional change.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: linuxppc-dev@lists.ozlabs.org
CC: cbe-oss-dev@lists.ozlabs.org
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
No functional change.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
CC: linux-am33-list@redhat.com
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
No functional change.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
No functional change.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
The PCIe spec (r3.0, sec 7.8.9) says Hot-Plug Surprise indicates support
for surprise *removal*, but pciehp checked this to determine if it should
handle presence detect interrupts for device *addition*.
Allow surprise device addition even if the slot doesn't advertise support
for surprise removal.
Keith has a platform with slots for front-loading SFF devices. The slots
do not have attention buttons and do not support surprise removal, but they
do have presence detect. In that case, we still want to use presence
detect for device addition.
Keith's original patch handled surprise insertions only if Hot-Plug Capable
is set. I think that test is superfluous because pciehp only claims slots
that advertise Hot-Plug Capable (see get_port_device_capability()).
Link: http://lkml.kernel.org/r/1419275223-14602-1-git-send-email-keith.busch@intel.com
Based-on-patch-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>
As Skyhawk and BE3-R (both multi-function devices) don't advertise the
PCI-ACS capability, the vfio driver places all the functions of these
devices in a single IOMMU group. Attaching (via PCI-passthru) two
different Skyhawk/BE3-R partitions (nPAR, Flex, etc. PFs) using vfio, to
different guests doesn't work as vfio only allows functions in *different*
IOMMU groups to be assigned to different guests.
As peer-to-peer access between PFs in Skyhawk/BE3-R is not possible, we can
treat them as "fully isolated" even though the device doesn't advertise
ACS. Add a PCI quirk for Skyhawk and BE3-R chips to fix this problem.
Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Some AMD/ATI GPUs report NoSoftRst- to indicate that they perform a reset
when software transitions them from D3hot to D0, but there is no apparent
effect on the device: the monitor remains synced and the framebuffer
contents are retained.
Callers of pci_reset_function() don't necessarily have a way to validate
whether a reset was effective, so we don't want to rely on NoSoftRst if
it's known to be inaccurate. Returning an error in such cases appears to
be the better option. For users like vfio-pci, this allows the driver to
escalate to the bus reset interfaces.
If a device lives on the root bus, there's really no further
escalation path, so we exempt PM reset as potentially better than
nothing.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
should perform an internal reset when transitioning from D3hot to D0 via
software control. Configuration context is lost and the device requires a
full reinitialization sequence.
Unfortunately the definition of "internal reset", beyond the application of
the configuration context, is largely left to the interpretation of the
specific device. Some devices don't seem to perform an "internal reset"
even if they report No_Soft_Reset == 0.
We still need to honor the PCI specification and restore PCI config context
in the event that we do a PM reset, so we don't cache and modify the
PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
intention is to reset the device, like pci_reset_function(), we need a
mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
any significant "internal reset" of the device.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.
[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223d ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]
[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann <andihartmann@freenet.de>
Tested-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.14+
Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.14+
Replace a misspelled function name by %s and then __func__.
The function name contains pcie, not pci as in the string.
This was done using Coccinelle, including the use of Levenshtein distance,
as proposed by Rasmus Villemoes.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.
The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D. Most interface types defined in the spec do not use
alpha characters, so they won't be affected. For example, 00h, 01h, 10h,
20h, etc. are unaffected.
Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.
Commit 89ec3dcf17 ("PCI: Generate uppercase hex for modalias interface
class") fixed only half of the problem. Some udev implementations rely on
the uevent file and not the modalias file.
Fixes: d1ded203ad ("PCI: add MODALIAS to hotplug event for pci devices")
Fixes: 89ec3dcf17 ("PCI: Generate uppercase hex for modalias interface class")
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: stable@vger.kernel.org
Most if not all ARM PCI host controller device drivers either ignore the
domain field in the pci_sys_data structure or just increment it every time
a host controller is probed, using it as a domain counter.
Therefore, instead of relying on pci_sys_data to stash the domain number in
a standard location, ARM pcibios code can be moved to the newly introduced
generic PCI domains code, implemented in commits:
41e5c0f81d ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()")
670ba0c888 ("PCI: Add generic domain handling")
ARM code is made to select PCI_DOMAINS_GENERIC by default, which builds
core PCI code that assigns the domain number through the generic function:
void pci_bus_assign_domain_nr(...)
that relies on a DT property to define the domain number or falls back to a
counter according to a predefined logic; its usage replaces the current
domain assignment code in PCI host controllers present in the kernel.
Tested-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Yijing Wang <wangyijing@huawei.com>
Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> # mvebu
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
CC: Mohit Kumar <mohit.kumar@st.com>
On cns3xxx platforms the PCI controller probing code relies on an
artificial dependency on the domain number to look-up the internal data
structures.
This patch reworks the host controller control data structure and adds a
domain equivalent field named port in it so that the dependency on
pci_sys_data domain field can be eventually removed.
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[lp: added commit log, removed pci_sys_data domain references]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The current logic in arm64 pci_bus_assign_domain_nr() is flawed in that
depending on the host controller configuration for a platform and the
initialization sequence, core code may end up allocating PCI domain numbers
from both DT and the generic domain counter, which would result in PCI
domain allocation aliases/errors.
Fix the logic behind the PCI domain number assignment and move the
resulting code to the PCI core so the same domain allocation logic is used
on all platforms that select CONFIG_PCI_DOMAINS_GENERIC.
[bhelgaas: tidy changelog]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
CC: Rob Herring <robh+dt@kernel.org>
CC: Catalin Marinas <catalin.marinas@arm.com>
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The bridge setup is already done by generic code while scanning the buses.
Do not duplicate (or potentially alter) this setup as a fixup.
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
The bridge setup is already done by generic code while scanning the buses.
Do not duplicate (or potentially alter) this setup as a fixup.
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Thierry Reding <treding@nvidia.com>
No need to set .owner here. The core will do it.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating
failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Phil Edworthy <phil.edworthy@renesas.com>
Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating
failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-By: Murali Karicheri <m-karicheri2@ti.com>
As discussed on LKML http://marc.info/?i=54611D86.4040306%40de.ibm.com
ACCESS_ONCE might fail with specific compilers for non-scalar accesses.
Here is a set of patches to tackle that problem.
The first patch introduce READ_ONCE and ASSIGN_ONCE. If the data structure
is larger than the machine word size memcpy is used and a warning is emitted.
The next patches fix up several in-tree users of ACCESS_ONCE on non-scalar
types.
This merge does not yet contain a patch that forces ACCESS_ONCE to work only
on scalar types. This is targetted for the next merge window as Linux next
already contains new offenders regarding ACCESS_ONCE vs. non-scalar types.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQIcBAABAgAGBQJUkrVGAAoJEBF7vIC1phx8stkP/2LmN5y6LOseoEW06xa5MX4m
cbIKsZNtsGHl7EDcTzzuWs6Sq5/Cj7V3yzeBF7QGbUKOqvFWU3jvpUBCCfjMg37C
77/Vf0ZPrxTXXxeJ4Ykdy2CGvuMtuYY9TWkrRNKmLU0xex7lGblEzCt9z6+mZviw
26/DN8ctjkHRvIUAi+7RfQBBc3oSMYAC1mzxYKBAsAFLV+LyFmsGU/4iofZMAsdt
XFyVXlrLn0Bjx/MeceGkOlMDiVx4FnfccfFaD4hhuTLBJXWitkUK/MRa4JBiXWzH
agY8942A8/j9wkI2DFp/pqZYqA/sTXLndyOWlhE//ZSti0n0BSJaOx3S27rTLkAc
5VmZEVyIrS3hyOpyyAi0sSoPkDnjeCHmQg9Rqn34/poKLd7JDrW2UkERNCf/T3eh
GI2rbhAlZz3v5mIShn8RrxzslWYmOObpMr3HYNUdRk8YUfTf6d6aZ3txHp2nP4mD
VBAEzsvP9rcVT2caVhU2dnBzeaZAj3zeDxBtjcb3X2osY9tI7qgLc9Fa/fWKgILk
2evkLcctsae2mlLNGHyaK3Dm/ZmYJv+57MyaQQEZNfZZgeB1y4k0DkxH4w1CFmCi
s8XlH5voEHgnyjSQXXgc/PNVlkPAKr78ZyTiAfiKmh8rpe41/W4hGcgao7L9Lgiu
SI0uSwKibuZt4dHGxQuG
=IQ5o
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux
Pull ACCESS_ONCE cleanup preparation from Christian Borntraeger:
"kernel: Provide READ_ONCE and ASSIGN_ONCE
As discussed on LKML http://marc.info/?i=54611D86.4040306%40de.ibm.com
ACCESS_ONCE might fail with specific compilers for non-scalar
accesses.
Here is a set of patches to tackle that problem.
The first patch introduce READ_ONCE and ASSIGN_ONCE. If the data
structure is larger than the machine word size memcpy is used and a
warning is emitted. The next patches fix up several in-tree users of
ACCESS_ONCE on non-scalar types.
This does not yet contain a patch that forces ACCESS_ONCE to work only
on scalar types. This is targetted for the next merge window as Linux
next already contains new offenders regarding ACCESS_ONCE vs.
non-scalar types"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux:
s390/kvm: REPLACE barrier fixup with READ_ONCE
arm/spinlock: Replace ACCESS_ONCE with READ_ONCE
arm64/spinlock: Replace ACCESS_ONCE READ_ONCE
mips/gup: Replace ACCESS_ONCE with READ_ONCE
x86/gup: Replace ACCESS_ONCE with READ_ONCE
x86/spinlock: Replace ACCESS_ONCE with READ_ONCE
mm: replace ACCESS_ONCE with READ_ONCE or barriers
kernel: Provide READ_ONCE and ASSIGN_ONCE
