kernel.git/arch/m68k/platform, branch linux-3.15.y

m68k: Simplify low level interrupt handling code

2013-11-13T19:21:46Z

The low level interrupt entry code of m68k contains the following: add_preempt_count(HARDIRQ_OFFSET); do_IRQ(); irq_enter(); add_preempt_count(HARDIRQ_OFFSET); handle_interrupt(); irq_exit(); sub_preempt_count(HARDIRQ_OFFSET); if (in_interrupt()) return; <---- On m68k always taken! if (local_softirq_pending()) do_softirq(); sub_preempt_count(HARDIRQ_OFFSET); if (in_hardirq()) return; if (status_on_stack_has_interrupt_priority_mask > 0) return; if (local_softirq_pending()) do_softirq(); ret_from_exception: if (interrupted_context_is_kernel) return: .... I tried to find a proper explanation for this, but the changelog is sparse and there are no mails explaining it further. But obviously this relates to the interrupt priority levels of the m68k and tries to be extra clever with nested interrupts. Though this cleverness just adds code bloat to the interrupt hotpath. For the common case of non nested interrupts the code runs through two extra conditionals to the only important one, which checks whether the return is to kernel or user space. For the nested case the checks for in_hardirq() and the priority mask value on stack catch only the case where the nested interrupt happens inside the hard irq context of the first interrupt. If the nested interrupt happens while the first interrupt handles soft interrupts, then these extra checks buy nothing. The nested interrupt will fall through to the final kernel/user space return check at ret_from_exception. Changing the code flow in the following way: do_IRQ(); irq_enter(); add_preempt_count(HARDIRQ_OFFSET); handle_interrupt(); irq_exit(); sub_preempt_count(HARDIRQ_OFFSET); if (in_interrupt()) return; if (local_softirq_pending()) do_softirq(); ret_from_exception: if (interrupted_context_is_kernel) return: makes the region protected by the hardirq count slightly smaller and the softirq handling is invoked with a minimal deeper stack. But otherwise it's completely functional equivalent and saves 104 bytes of text in arch/m68k/kernel/entry.o. This modification allows us further to get rid of the limitations which m68k puts on the preempt_count layout, so we can make the preempt count bits completely generic. Signed-off-by: Thomas Gleixner Tested-by: Michael Schmitz Acked-by: Geert Uytterhoeven Cc: Linux/m68k Cc: Andreas Schwab Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311112052360.30673@ionos.tec.linutronix.de

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k

2013-11-11T09:17:07Z

Pull m68k updates from Geert Uytterhoeven: "Summary: - __put_user_unaligned may/will be used by btrfs - m68k part of a global cleanup" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: Remove deprecated IRQF_DISABLED m68k/m68knommu: Implement __get_user_unaligned/__put_user_unaligned()

m68k: Remove deprecated IRQF_DISABLED

2013-09-26T07:54:16Z

This patch proposes to remove the IRQF_DISABLED flag from m68k architecture code. It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker Signed-off-by: Geert Uytterhoeven

Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu

2013-09-09T16:04:46Z

Pull m68knommu fixes from Greg Ungerer: "Just a small collection of cleanups and fixes this time, no big changes. The most interresting are to make the m68k and m68knommu consistently use CONFIG_IOMAP, clean out some unused board config options and flush the cache on signal stack creation" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: m68k: remove 16 unused boards in Kconfig.machine m68k: define 'VM_DATA_DEFAULT_FLAGS' no matter whether has 'NOMMU' or not m68knommu: user generic iomap to support ioread*/iowrite* m68k/coldfire: flush cache when creating the signal stack frame m68knommu: Mark functions only called from setup_arch() __init

m68knommu: Mark functions only called from setup_arch() __init

2013-08-26T06:51:13Z

Some functions that are only called (indirectly) from setup_arch() lack __init annotations. Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer

PCI: Delay enabling bridges until they're needed

2013-07-25T18:35:03Z

We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code. This patch changes this so we don't enable a bridge until necessary, i.e., until we enable a PCI device behind the bridge. We do this in the generic pci_enable_device() path, so this also removes the arch-specific code to enable bridges. [bhelgaas: changelog] Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

m68k/PCI: Remove redundant call of pci_bus_add_devices()

2013-06-14T23:38:39Z

pci_scan_bus() has called pci_bus_add_devices() already, so remove the redundant call of pci_bus_add_devices(). subsys_init() callbacks will be invoked before device_init() callbacks, so it should be safe to remove the redundant calls. [bhelgaas: split unicore32 into a separate patch] Signed-off-by: Jiang Liu Signed-off-by: Bjorn Helgaas Acked-by: Greg Ungerer

m68knommu: enable Timer on coldfire 532x

2013-04-28T23:17:59Z

This patch enables the initial Timer on coldfire 532x systems. Without this, the scheduler will not be triggered and the system hangs, after all sequential code is executed. It should also apply on later kernel versions. Signed-off-by: Christian Gieseler Signed-off-by: Greg Ungerer

m68knommu: make ColdFire M532x platform support more v3 generic

2013-04-28T23:17:58Z

The M532x CPU platform support can be used on more ColdFire CPU families than just the 532x types. So rename and reconfigure it to reflect that. The ColdFire 537x family has virtualy identical internals to the 532x, and so it will be able to share this code when we add support for them. Signed-off-by: Greg Ungerer

m68knommu: create and use a common M53xx ColdFire class of CPUs

2013-04-28T23:17:58Z

The current CONFIG_M532x support definitions are actually common to a larger set of version 3 ColdFire CPU types. In the future we want to add support for the 537x family. It is very similar to the 532x internally, and will be able to use most of the same definitions. Create a CONFIG_M53xx option that is enabled to support any of the common 532x and 537x CPU types. Convert the current users of CONFIG_M532x to use CONFIG_M53xx instead. Signed-off-by: Greg Ungerer