- May 26, 2014
-
-
Arnd Bergmann authored
patch 37ebbcff ("arm: iop13xx: Use sparse irqs for MSI") moved iop13xx over to sparse IRQ support, but this broke the build for the msi.c file, which now has to include mach/irqs.h itself. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/12285212.fBJyVfk69p@wuerfel Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
- May 21, 2014
-
-
Thomas Gleixner authored
Reason: Import the change which might be pulled in from net Signed-off-by: -
Eyal Perry authored
Instead of requiring each consumer of the IRQ affinity notifier to have themselves be explicitly dependent on CONFIG_SMP, make the definition of struct irq_affinity_notify to exist independently of that config option and introduce a stub for irq_set_affinity_notifier() under non SMP configuration. Fixes: 2eacc23c ("net/mlx4_core: Enforce irq affinity changes immediatly") Signed-off-by:
Eyal Perry <eyalpe@mellanox.com> Signed-off-by:
Amir Vadai <amirv@mellanox.com> Cc: Ben Hutchings <bhutchings@solarflare.com> Cc: Yevgeny Petrilin <yevgenyp@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: David S. Miller <davem@davemloft.net> Link: http://lkml.kernel.org/r/1400597820-30685-1-git-send-email-amirv@mellanox.com Signed-off-by:
-
- May 16, 2014
-
-
Thomas Gleixner authored
No more users. Get rid of the cruft. Signed-off-by:
Grant Likely <grant.likely@linaro.org> Tested-by:
Tony Luck <tony.luck@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140507154341.012847637@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
Switch over to the new interface. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Create a new interface and confine it with a config switch which makes clear that this is just legacy support and not to be used for new code. Signed-off-by:
-
Thomas Gleixner authored
No more users. And it's not going to come back. If you need hotplugable irq chips, use irq domains. Signed-off-by:
-
Thomas Gleixner authored
We want to get rid of the public interface. Signed-off-by:
-
Thomas Gleixner authored
There is no need to mark the lower interrupts as reserved in order to exclude them from dynamic allocation. Provide arch_dynirq_lower_bound() to exclude the lower space. Signed-off-by:
-
Thomas Gleixner authored
S390 is not using the generic show interrupts implementation so the extra arch_show_interrupts() is just useless. Signed-off-by:
-
Thomas Gleixner authored
alloc_irq_desc() returns an integer and as documented either a valid irq number or a negative error code. Checking for NO_IRQ is definitely not the proper error handling. Signed-off-by:
-
Thomas Gleixner authored
The preceding call to irq_create_identity_mapping() marks the interrupt as allocated already. Remove the leftover. Signed-off-by:
Simon Horman <horms@verge.net.au> Cc: linux-sh@vger.kernel.org Link: http://lkml.kernel.org/r/20140507154339.189047829@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
That's a leftover from the time where x86 supported SPARSE_IRQ=n. Signed-off-by:
-
Thomas Gleixner authored
No more users outside of itanic. Confine it. Signed-off-by:
-
Thomas Gleixner authored
Get rid of the private allocator and switch over to sparse IRQs. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Link: http://lkml.kernel.org/r/20140507154338.423715783@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
No functional change. Just convert to the new interface. Signed-off-by:
-
Thomas Gleixner authored
No functional change. Just convert to the new interface. Signed-off-by:
-
Thomas Gleixner authored
No functional change. Just convert to the new interface. Signed-off-by:
-
Thomas Gleixner authored
No functional change. Just convert to the new interface. Signed-off-by:
-
Thomas Gleixner authored
No functional change. Just convert to the new interface. Signed-off-by:
-
Thomas Gleixner authored
We want to convert the drivers over to the new interface and finally tile to sparse irqs. Implement irq_alloc/free_hwirq() for step by step migration. Signed-off-by:
-
Thomas Gleixner authored
No more users. Remove the cruft Signed-off-by:
-
Thomas Gleixner authored
Just stumbled over it when staring into ia64 irq handling. Signed-off-by:
-
Thomas Gleixner authored
ia64 and x86 share this driver. x86 is moving to a different irq allocation and ia64 keeps its private irq_create/destroy stuff. Use macros to redirect to one or the other. Yes, macros to avoid include hell. Signed-off-by:
Joerg Roedel <joro@8bytes.org> Cc: x86@kernel.org Cc: linux-ia64@vger.kernel.org Cc: iommu@lists.linux-foundation.org Link: http://lkml.kernel.org/r/20140507154336.372289825@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
ia64 returns a negative error code when allocation fails andx86 returns 0. Make it handle both. Signed-off-by:
-
Thomas Gleixner authored
No need to expose this outside of the ioapic code. The dynamic allocations are guaranteed not to happen in the gsi space. See commit 62a08ae2 . Signed-off-by:
-
Thomas Gleixner authored
No functional change just less crap. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by:
-
Thomas Gleixner authored
No functional change, just cleaned up a bit. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: x86@kernel.org Cc: linux-pci@vger.kernel.org Link: http://lkml.kernel.org/r/20140507154335.452206351@linutronix.de Signed-off-by:
-
Thomas Gleixner authored
No functional change. The request to allocate the irq above NR_IRQS_LEGACY is completely pointless as the implementation enforces that the dynamic allocations are above the GSI interrupts, which includes the legacy PIT irqs. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by:
-
Thomas Gleixner authored
Use the new interfaces. No functional change. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by:
-
Thomas Gleixner authored
The create_irq variants are going away. Use the new interface. The core and arch code already excludes the gsi interrupts from the allocation, so no functional change. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by:
-
Thomas Gleixner authored
This is just a cleanup to get rid of the create/destroy_irq variants which were designed in hell. The long term solution for x86 is to switch over to irq domains and cleanup the whole vector allocation mess. The generic irq_alloc_hwirqs() interface deliberately prevents multi-MSI vector allocation to further enforce the irq domain conversion (aside of the desire to support ioapic hotplug). Signed-off-by:
-
Thomas Gleixner authored
Not really the solution to the problem, but at least it confines the mess in the core code and allows to get rid of the create/destroy_irq variants from hell, i.e. 3 implementations with different semantics plus the x86 specific variants __create_irqs and create_irq_nr which have been invented in another circle of hell. x86 : x86 should be converted to irq domains and I'm deliberately making it impossible to do the multi-vector MSI support by adding more crap to the current mess. It's not that hard to do and I'm really tired of the trainwrecks which have been invented by baindaid engineering so far. Any attempt to do multi-vector MSI or ioapic hotplug without converting to irq domains is NAKed hereby. tile: Might use irq domains as well, but it has a very limited interrupt space, so handling it via this functionality might be the right thing to do even in the long run. ia64: That's an hopeless case, as I doubt that anyone has the stomach to rewrite the homebrewn dynamic allocation facilities. I stared at it for a couple of hours and gave up. The create/destroy_irq mess could be made private to itanic right away if there wouldn't be the iommu/dmar driver being shared with x86. So to do that I'm going to add a separate ia64 specific implementation later in order not to deep-six itanic right away. Signed-off-by: -
Thomas Gleixner authored
Copy and paste leftovers with no functionality at all. Signed-off-by:
-
Thomas Gleixner authored
No need for a private allocator. The core code handles it already. Allocate the non MSI irqs right at boot time via machine_desc->nr_irqs and let the sparse core handle the MSI space. Signed-off-by:
-
Thomas Gleixner authored
Reason: Get the upstream and urgent fixes before applying more complex changes. Signed-off-by:
-
- May 14, 2014
-
-
Jason Cooper authored
Thomas Gleixner has asked me to assist with the review and merging of patches for the irqchip subsystem. Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1400006821-32145-1-git-send-email-jason@lakedaemon.net Signed-off-by:
-
- May 10, 2014
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Peter Anvin: "A somewhat unpleasantly large collection of small fixes. The big ones are the __visible tree sweep and a fix for 'earlyprintk=efi,keep'. It was using __init functions with predictably suboptimal results. Another key fix is a build fix which would produce output that simply would not decompress correctly in some configuration, due to the existing Makefiles picking up an unfortunate local label and mistaking it for the global symbol _end. Additional fixes include the handling of 64-bit numbers when setting the vdso data page (a latent bug which became manifest when i386 started exporting a vdso with time functions), a fix to the new MSR manipulation accessors which would cause features to not get properly unblocked, a build fix for 32-bit userland, and a few new platform quirks" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, vdso, time: Cast tv_nsec to u64 for proper shifting in update_vsyscall() x86: Fix typo in MSR_IA32_MISC_ENABLE_LIMIT_CPUID macro x86: Fix typo preventing msr_set/clear_bit from having an effect x86/intel: Add quirk to disable HPET for the Baytrail platform x86/hpet: Make boot_hpet_disable extern x86-64, build: Fix stack protector Makefile breakage with 32-bit userland x86/reboot: Add reboot quirk for Certec BPC600 asmlinkage: Add explicit __visible to drivers/*, lib/*, kernel/* asmlinkage, x86: Add explicit __visible to arch/x86/* asmlinkage: Revert "lto: Make asmlinkage __visible" x86, build: Don't get confused by local symbols x86/efi: earlyprintk=efi,keep fix
-
- May 09, 2014
-
-
Boris Ostrovsky authored
With tk->wall_to_monotonic.tv_nsec being a 32-bit value on 32-bit systems, (tk->wall_to_monotonic.tv_nsec << tk->shift) in update_vsyscall() may lose upper bits or, worse, add them since compiler will do this: (u64)(tk->wall_to_monotonic.tv_nsec << tk->shift) instead of ((u64)tk->wall_to_monotonic.tv_nsec << tk->shift) So if, for example, tv_nsec is 0x800000 and shift is 8 we will end up with 0xffffffff80000000 instead of 0x80000000. And then we are stuck in the subsequent 'while' loop. We need an explicit cast. Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/1399648287-15178-1-git-send-email-boris.ostrovsky@oracle.com Acked-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: <stable@vger.kernel.org> # v3.14 Signed-off-by:
H. Peter Anvin <hpa@zytor.com>
-
