kernel/arch/powerpc/sysdev, branch linux-4.1.y

powerpc/ipic: Fix status get and status clear

2018-01-17T17:55:37Z

[ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ] IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR which is the mask register. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin

axonram: Fix gendisk handling

2018-01-17T17:55:27Z

[ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ] It is invalid to call del_gendisk() when disk->queue is NULL. Fix error handling in axon_ram_probe() to avoid doing that. Also del_gendisk() does not drop a reference to gendisk allocated by alloc_disk(). That has to be done by put_disk(). Add that call where needed. Reported-by: Dan Carpenter Signed-off-by: Jan Kara Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

powerpc/MSI: Fix race condition in tearing down MSI interrupts

2015-10-22T21:43:24Z

commit e297c939b745e420ef0b9dc989cb87bda617b399 upstream. This fixes a race which can result in the same virtual IRQ number being assigned to two different MSI interrupts. The most visible consequence of that is usually a warning and stack trace from the sysfs code about an attempt to create a duplicate entry in sysfs. The race happens when one CPU (say CPU 0) is disposing of an MSI while another CPU (say CPU 1) is setting up an MSI. CPU 0 calls (for example) pnv_teardown_msi_irqs(), which calls msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its hardware IRQ number) is no longer in use. Then, before CPU 0 gets to calling irq_dispose_mapping() to free up the virtal IRQ number, CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an MSI, and gets the same hardware IRQ number that CPU 0 just freed. CPU 1 then calls irq_create_mapping() to get a virtual IRQ number, which sees that there is currently a mapping for that hardware IRQ number and returns the corresponding virtual IRQ number (which is the same virtual IRQ number that CPU 0 was using). CPU 0 then calls irq_dispose_mapping() and frees that virtual IRQ number. Now, if another CPU comes along and calls irq_create_mapping(), it is likely to get the virtual IRQ number that was just freed, resulting in the same virtual IRQ number apparently being used for two different hardware interrupts. To fix this race, we just move the call to msi_bitmap_free_hwirqs() to after the call to irq_dispose_mapping(). Since virq_to_hw() doesn't work for the virtual IRQ number after irq_dispose_mapping() has been called, we need to call it before irq_dispose_mapping() and remember the result for the msi_bitmap_free_hwirqs() call. The pattern of calling msi_bitmap_free_hwirqs() before irq_dispose_mapping() appears in 5 places under arch/powerpc, and appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend") from 2007. Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend") Reported-by: Alexey Kardashevskiy Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman

powerpc: dart_iommu: Remove check for controller_ops == NULL case

2015-04-11T10:49:19Z

Now that we have ported the calls to iommu_init_early_dart to always supply a pci_controller_ops struct, we can safely drop the check. Signed-off-by: Daniel Axtens Signed-off-by: Michael Ellerman

powerpc: Remove shims for pci_controller_ops operations

2015-04-11T10:49:18Z

Remove shims, patch callsites to use pci_controller_ops versions instead. Also move back the probe mode defines, as explained in the patch for pci_probe_mode. Signed-off-by: Daniel Axtens Signed-off-by: Michael Ellerman

powerpc: fsl_pci, swiotlb: Move controller ops from ppc_md to controller_ops

2015-04-11T10:49:17Z

Move the installation of DMA operations out of swiotlb's subsys initcall, and into the generic PCI controller operations struct. These ops are installed conditionally, based on the ppc_swiotlb_enable global. The global can be set in two places: - swiotlb_detect_4g, which is always called at the arch initcall level - setup_pci_atmu, which is called as part of the fsl_add_bridge and fsl_pci_syscore_do_resume. fsl_pci_syscore_do_resume is called late enough that any changes as a result of that call will have no effect. As such, if we test the global and set the operations as part of fsl_add_bridge, after the call to setup_pci_atmu, we can be confident that it will cover all the PCI implementations affected by the changes to dma-swiotlb.c. Signed-off-by: Daniel Axtens Acked-by: Scott Wood Signed-off-by: Michael Ellerman

powerpc: dart_iommu: optionally populate controller_ops on init

2015-04-11T10:49:14Z

If a pci_controller_ops struct is provided to iommu_init_early_dart, populate that with the DMA setup ops, rather than ppc_md. If NULL is provided, populate ppc_md as before. This also patches the call sites for Maple and Power Mac to pass NULL, so existing behaviour is preserved. The benefit of making this optional is that it means we don't have to change dart, Maple and Power Mac over to the controller_ops system in one fell swoop. Signed-off-by: Daniel Axtens Signed-off-by: Michael Ellerman

powerpc: Drop return value of smp_ops->probe()

2015-04-10T10:02:49Z

smp_ops->probe() is currently supposed to return the number of cpus in the system. The last actual usage of the value was removed in May 2007 in e147ec8f1808 "[POWERPC] Simplify smp_space_timers". We still passed the value around until June 2010 when even that was finally removed in c1aa687d499a "powerpc: Clean up obsolete code relating to decrementer and timebase". So drop that requirement, probe() now returns void, and update all implementations. Signed-off-by: Michael Ellerman

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next

2015-04-07T03:07:42Z

Freescale updates from Scott: "Highlights include BMan device tree nodes, an MSI erratum workaround, a couple minor performance improvements, config updates, and misc fixes/cleanup."

powerpc/mpic: Remove WHOAMI readback after EOI

2015-04-01T03:23:20Z

After previous discussions regarding the subject [1][2], there's no clear explanation or reason why the call was needed in the first place. The sensible argument is some sort of synchronization between the CPU and the MPIC, which hasn't been pointed out precisely and is no longer required (at least on BookE platforms). The benefit of this change is saving a MMIO trap per interrupt when running in a KVM guest. [1] https://patchwork.ozlabs.org/patch/429098/ [2] https://patchwork.ozlabs.org/patch/433557/ Signed-off-by: Bogdan Purcareata Signed-off-by: Scott Wood