Merge branches 'pci/hotplug', 'pci/msi', 'pci/virtualization' and 'pci/misc' into next
* pci/hotplug:
PCI: rphahp: Fix endianess issues
PCI: Allow hotplug service drivers to operate in polling mode
PCI: pciehp: Acknowledge spurious "cmd completed" event
PCI: pciehp: Use PCI_EXP_SLTCAP_PSN define
PCI: hotplug: Remove unnecessary "dev->bus" test
* pci/msi:
GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()
PCI/MSI: Simplify populate_msi_sysfs()
PCI/portdrv: Use pci_enable_msix_exact() instead of pci_enable_msix()
* pci/virtualization:
PCI: Add Patsburg (X79) to Intel PCH root port ACS quirk
* pci/misc:
PCI: Fix use of uninitialized MPS value
PCI: Remove dead code
MAINTAINERS: Add arch/x86/kernel/quirks.c to PCI file patterns
PCI: Remove unnecessary __ref annotations
PCI: Fail new_id for vendor/device values already built into driver
PCI: Add new ID for Intel GPU "spurious interrupt" quirk
PCI: Update my email address
PCI: Fix incorrect vgaarb conditional in WARN_ON()
PCI: Use designated initialization in PCI_VDEVICE
PCI: Remove old serial device IDs
PCI: Remove unnecessary includes of <linux/init.h>
powerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal
If "pcie_bus_config == PCIE_BUS_PERFORMANCE", we don't initialize "smpss",
so we pass a pointer to garbage into pcie_bus_configure_set(), where we
compute "mps" based on the garbage. We then pass the garbage "mps" to
pcie_write_mps(), which ignores it in the PCIE_BUS_PERFORMANCE case.
Coverity isn't smart enough to deduce that we ignore the garbage (it's a
lot to expect from a human, too), so initialize "smpss" to a safe value in
all cases.
MAINTAINERS: Add arch/x86/kernel/quirks.c to PCI file patterns
I'm not asserting any claim over arch/x86/kernel/quirks.c, and I don't plan
to merge changes to it, but some of the quirks there are PCI-related, and
I'd like to see changes to them.
Some PCI functions used to be marked __devinit. When CONFIG_HOTPLUG was
not set, these functions were discarded after boot. A few callers of these
__devinit functions were marked __ref to indicate that they could safely
call the __devinit functions even though the callers were not __devinit.
But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref
annotations is also gone, so remove them. Relevant historical commits:
Bandan Das [Wed, 2 Apr 2014 01:32:59 +0000 (21:32 -0400)]
PCI: Fail new_id for vendor/device values already built into driver
While using the sysfs new_id interface, the user can unintentionally feed
incorrect values if the driver static table has a matching entry. This is
possible since only the device and vendor fields are mandatory and the rest
are optional. As a result, store_new_id() will fill in default values that
are then passed on to the driver and can have unintended consequences.
As an example, consider the ixgbe driver and the 82599EB network card:
This will pass a pci_device_id with driver_data = 0 to ixgbe_probe(), which
uses that zero to index a table of card operations. The zeroth entry of
the table does *not* correspond to the 82599 operations.
This change returns an error if the user attempts to add a dynid for a
vendor/device combination for which a static entry already exists.
However, if the user intentionally wants a different set of values, she
must provide all the 7 fields and that will be accepted.
[bhelgaas: drop KVM text since the problem isn't KVM-specific] Signed-off-by: Bandan Das <bsd@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
ALSA: hda - Suppress CORBRP clear on Nvidia controller chips
The recent commit (ca460f86521) changed the CORB RP reset procedure to
follow the specification with a couple of sanity checks.
Unfortunately, Nvidia controller chips seem not following this way,
and spew the warning messages like:
snd_hda_intel 0000:00:10.1: CORB reset timeout#1, CORBRP = 0
This patch adds the workaround for such chips. It just skips the new
reset procedure for the known broken chips.
As the i915.enable_ppgtt is read-only it cannot be changed after the
module is loaded and so we can perform an early sanitization of the
values.
v2:
- Add comment and pimp commit message (Chris)
- Use the param consistently (Jani)
v3:
- Fix init sequence on pre-gen6 by moving the sanitize_ppgtt call to
gtt_init. Fixes boot hangs on pre-gen6.
- Add a debug output for the sanitize ppgtt mode.
References: https://lkml.org/lkml/2014/4/17/599
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77916 Cc: Alessandro Suardi <alessandro.suardi@gmail.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Grant Likely [Tue, 29 Apr 2014 11:05:22 +0000 (12:05 +0100)]
drivercore: deferral race condition fix
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.
The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.
The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:
In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.
The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.
This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: Grant Likely <grant.likely@linaro.org> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Cc: Stable <stable@vger.kernel.org> # v3.4+
Because of parisc's cache aliasing constraints we need to map shared pages at a
multiple of 4MB while most other architectures can map files at any multiple of
PAGE_SIZE. In the past this constraint was ensured by calculating a virtual
offset into this 4MB region which is based on the physical address of the
kernel mapping variable (right-shift value of filp->f_mapping by 8 bits).
Since we only have a 32bit userspace (even when running on a 64bit kernel) this
often leads to large gaps in the maps of the userspace processes and to out of
memory situations even if physical memory was still free. Of course I did
played with other variants of shifting the f_mapping value to find better
offsets but this didn't helped either.
This patch chooses a different approach.
It adds the additional field i_mmap_lastmmap to the address_space struct to
keep track of the last mapping of a shared file. With this bookkeeping it's
possible for the parisc memory allocator to
a) choose a new mapping offset if the file hasn't been mapped yet, and
b) take the last-used mapping if it was already mapped by another process.
Overall this approach leads to a more condensed memory usage on parisc because
the shared files will now be mapped much closer to each other. This is e.g.
visible with shared libraries which are now not any longer cluttered around
in the userspace process but close to each other at the top of the userspace
memory.
There are only a couple of architectures that override _STK_LIM_MAX to
a non-infinity value. This changes the stack allocation semantics in
subtle ways. For example, GNU make changes its stack allocation to the
hard maximum defined by _STK_LIM_MAX. As a results, threads executed
by processes running under make are allocated a stack size of
_STK_LIM_MAX rather than a sensible default value. This causes various
thread stress tests to fail when they can't muster more than about 50
threads.
The attached change implements the default behavior used by the
majority of architectures.
Signed-off-by: John David Anglin <dave.anglin@bell.net> Reviewed-by: Carlos O'Donell <carlos@systemhalted.org> Cc: stable@vger.kernel.org # 3.8+ Signed-off-by: Helge Deller <deller@gmx.de>
Thomas Petazzoni [Tue, 22 Apr 2014 21:26:13 +0000 (23:26 +0200)]
memory: mvebu-devbus: add a devbus, keep-config property
Currently, the mvebu-devbus Device Tree binding makes defining the
timing parameters mandatory.
However, in practice, when converting Orion5x platforms to the Device
Tree, we may not necessarily have easy access to the hardware
platforms to fetch those values which were not defined in old-style
board files: all these platforms rely on the bootloader setting the
timing parameters correctly.
In order to facilitate the migration to the Device Tree of this
platform, this commit relaxes the mvebu-devbus Device Tree binding by
introducing a 'devbus,keep-config' boolean property, which, if
defined, will ignore all timing parameters passed in the Device Tree,
and simply rely on the timing values already defined by the
bootloader.
Thomas Petazzoni [Tue, 22 Apr 2014 21:26:12 +0000 (23:26 +0200)]
memory: mvebu-devbus: add Orion5x support
This commit adds support for the Orion5x family of Marvell processors
into the mvebu-devbus driver. It differs from the already supported
Armada 370/XP by:
* Having a single register (instead of two) for doing all the timing
configuration.
* Having a few less timing configuration parameters.
For this reason, a separate compatible string "marvell,orion-devbus"
is introduced.
Thomas Petazzoni [Tue, 22 Apr 2014 21:26:11 +0000 (23:26 +0200)]
memory: mvebu-devbus: split functions
The mvebu-devbus driver currently only supports the Armada 370/XP
family, but it can also cover the Orion5x family. However, the Orion5x
family has a different organization of the registers.
Therefore, in preparation to the introduction of Orion5x support, we
separate into two functions the code that 1/ retrieves the timing
parameters from the Device Tree and 2/ applies those timings
parameters into the hardware registers.
Thomas Petazzoni [Tue, 22 Apr 2014 21:26:10 +0000 (23:26 +0200)]
memory: mvebu-devbus: use _SHIFT suffixes instead of _BIT
As noted by Sebastian Hesselbarth, the definitions in mvebu-devbus.c
are not bit definition, but rather shift values, so a _SHIFT prefix
would make more sense. This commit therefore replaces the *_BIT
definitions by *_SHIFT definitions.
Thomas Petazzoni [Tue, 22 Apr 2014 21:26:09 +0000 (23:26 +0200)]
memory: mvebu-devbus: use ARMADA_ prefix in defines
The mvebu-devbus driver currently only supports the Armada 370/XP
family, but it can also cover the Orion5x family. However, the Orion5x
family has a different organization of the register. Therefore, in
preparation to the introduction of Orion5x support, we rename the
Armada 370/XP specific definitions to have an ARMADA_ prefix.
David S. Miller [Tue, 29 Apr 2014 05:12:34 +0000 (01:12 -0400)]
Merge branch 'sparc32-sparse'
Sam Ravnborg says:
====================
sparse warning fixes in arch/sparc/
The following patch-set address a lot of sparse warnings
in the sparc32 specific parts of arch/sparc/.
A few sparc64 bits are touched too when code are shared.
Within arch/sparc/mm/ only two warnings remains.
These are related to the return value of of_ioremap() which is __iomem.
Within arch/sparc/kernel/ only three files now produces sparse warnings:
sys_sparc_32.c
time_32.c
auxio_32.c
The fixes was not obvious so the warnings was left for now.
When looking at tadpole.c I was left with the impression that most
of the code was actually unused - but for now I added a "TODO".
This is made on top of 3.15-rc2.
This set replaces the two sets sent the last days.
V2:
- Do not add extern in front of prototypes.
- Tidy up a few changelongs
There are still sparse warnings left that are easy to address.
But this fixes the majority.
====================
Sam Ravnborg [Mon, 21 Apr 2014 19:39:44 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in leon_smp.c
Fix following warnings:
leon_smp.c:133:6: warning: symbol 'leon_smp_setbroadcast' was not declared. Should it be static?
leon_smp.c:151:14: warning: symbol 'leon_smp_getbroadcast' was not declared. Should it be static?
leon_smp.c:269:6: warning: symbol 'leon_irq_rotate' was not declared. Should it be static?
leon_smp.c:355:6: warning: symbol 'leonsmp_ipi_interrupt' was not declared. Should it be static?
leon_smp.c:457:6: warning: symbol 'leon_cross_call_irq' was not declared. Should it be static?
Add static.
Remove unused functions.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:43 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in sun4d_smp.c
Fix following warnings:
sun4d_smp.c:113:13: warning: symbol 'smp4d_boot_cpus' was not declared. Should it be static?
sun4d_smp.c:121:5: warning: symbol 'smp4d_boot_one_cpu' was not declared. Should it be static?
sun4d_smp.c:162:13: warning: symbol 'smp4d_smp_done' was not declared. Should it be static?
sun4d_smp.c:353:6: warning: symbol 'smp4d_cross_call_irq' was not declared. Should it be static?
sun4d_smp.c:363:6: warning: symbol 'smp4d_percpu_timer_interrupt' was not declared. Should it be static?
Add proper declarations
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:42 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in sun4m_smp.c
Fix following warnings:
sun4m_smp.c:72:13: warning: symbol 'smp4m_boot_cpus' was not declared. Should it be static?
sun4m_smp.c:78:5: warning: symbol 'smp4m_boot_one_cpu' was not declared. Should it be static?
sun4m_smp.c:120:13: warning: symbol 'smp4m_smp_done' was not declared. Should it be static?
sun4m_smp.c:230:6: warning: symbol 'smp4m_cross_call_irq' was not declared. Should it be static?
sun4m_smp.c:240:6: warning: symbol 'smp4m_percpu_timer_interrupt' was not declared. Should it be static?
Add proper declarations.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:41 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in leon_pmc.c
Fix following warnings:
leon_pmc.c:15:14: warning: symbol 'pmc_leon_fixup_ids' was not declared. Should it be static?
leon_pmc.c:22:5: warning: symbol 'pmc_leon_need_fixup' was not declared. Should it be static?
leon_pmc.c:41:6: warning: symbol 'pmc_leon_idle_fixup' was not declared. Should it be static?
leon_pmc.c:65:6: warning: symbol 'pmc_leon_idle' was not declared. Should it be static?
Add static to definitions.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:40 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in leon_kernel.c
Fix following warnings:
leon_kernel.c:40:15: warning: symbol 'leon3_gptimer_idx' was not declared. Should it be static?
leon_kernel.c:68:6: warning: symbol 'leon_eirq_setup' was not declared. Should it be static?
leon_kernel.c:273:13: warning: symbol 'leon_percpu_timer_ce_interrupt' was not declared. Should it be static?
Define symbols as static.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:39 +0000 (21:39 +0200)]
sparc: fix sparse warnings in of_device_common.c
Fix following warnings (both sparc32 and sparc64):
of_device_common.c:13:14: warning: symbol 'irq_of_parse_and_map' was not declared. Should it be static?
of_device_common.c:24:5: warning: symbol 'of_address_to_resource' was not declared. Should it be static?
of_device_common.c:37:14: warning: symbol 'of_iomap' was not declared. Should it be static?
Add missing includes.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:38 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in unaligned_32.c
Fix following warnings:
unaligned_32.c:146:15: warning: symbol 'safe_compute_effective_address' was not declared. Should it be static?
unaligned_32.c:235:17: warning: symbol 'kernel_unaligned_trap' was not declared. Should it be static?
unaligned_32.c:319:17: warning: symbol 'user_unaligned_trap' was not declared. Should it be static?
Add proper declarations in kernel.h + setup.h
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:36 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in smp_32.c
Fix following warnings:
smp_32.c:300:6: warning: symbol 'arch_cpu_pre_starting' was not declared. Should it be static?
smp_32.c:320:6: warning: symbol 'arch_cpu_pre_online' was not declared. Should it be static?
smp_32.c:347:6: warning: symbol 'sparc_start_secondary' was not declared. Should it be static?
Add missing static definition.
This left one warning:
warning: symbol 'setup_profiling_timer' was not declared.
This is a global symbol that has no declaration in any global header.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:35 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in auxio_32.c
Fix following warnings:
auxio_32.c:23:14: warning: symbol 'auxio_register' was not declared. Should it be static?
auxio_32.c:26:13: warning: symbol 'auxio_probe' was not declared. Should it be static?
auxio_32.c:108:13: warning: symbol 'auxio_power_probe' was not declared. Should it be static?
Add proper decalarations for the above.
The leaves one sparse warning:
auxio_32.c:130:33: warning: cast removes address space of expression
This is here:
auxio_power_register = (unsigned char *) of_ioremap()
This is __iomem that is removed from return value of of_ioremap()
The pointer is later used without any helpers in process_32.c:
*auxio_power_register |= AUXIO_POWER_OFF;
It would be simple to introduce a few sbus() helpers.
But as I was not sure this was correct the warning are left as-is.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Sam Ravnborg [Mon, 21 Apr 2014 19:39:34 +0000 (21:39 +0200)]
sparc32: fix sparse warnings in leon_pci_grpci2.c
Fix following warnings:
leon_pci_grpci2.c:218:1: warning: symbol 'grpci2_dev_lock' was not declared. Should it be static?
leon_pci_grpci2.c:219:20: warning: symbol 'grpci2priv' was not declared. Should it be static?
leon_pci_grpci2.c:221:5: warning: symbol 'grpci2_map_irq' was not declared. Should it be static?
leon_pci_grpci2.c:564:6: warning: symbol 'grpci2_hw_init' was not declared. Should it be
static?
+ a lot of these:
leon_pci_grpci2.c:252:9: warning: incorrect type in argument 1 (different address spaces)
Declare the symbols static as they are only used in this file.
Added missing __iomem annotations.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / karo-tx-linux.git / log