1. 23 Apr, 2019 19 commits
  2. 19 Apr, 2019 5 commits
    • Linus Walleij's avatar
      irqchip: Add driver for IXP4xx · 5b978c10
      Linus Walleij authored
      The IXP4xx (arch/arm/mach-ixp4xx) is an old Intel XScale
      platform that has very wide deployment and use.
      
      As part of modernizing the platform, we need to implement a
      proper irqchip in the irqchip subsystem.
      
      The IXP4xx irqchip is tightly jotted together with the GPIO
      controller, and whereas in the past we would deal with this
      complex logic by adding necessarily different code, we can
      nowadays modernize it using a hierarchical irqchip.
      
      The actual IXP4 irqchip is a simple active low level IRQ
      controller, whereas the GPIO functionality resides in a
      different memory area and adds edge trigger support for
      the interrupts.
      
      The interrupts from GPIO lines 0..12 are 1:1 mapped to
      a fixed set of hardware IRQs on this IRQchip, so we
      expect the child GPIO interrupt controller to go in and
      allocate descriptors for these interrupts.
      
      For the other interrupts, as we do not yet have DT
      support for this platform, we create a linear irqdomain
      and then go in and allocate the IRQs that the legacy
      boards use. This code will be removed on the DT probe
      path when we add DT support to the platform.
      
      We add some translation code for supporting DT
      translations for the fwnodes, but we leave most of that
      for later.
      
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      5b978c10
    • Linus Walleij's avatar
      ARM: ixp4xx: Convert to SPARSE_IRQ · dc8ef8cd
      Linus Walleij authored
      This localizes the <mach/irqs.h> header to the mach-ixp4xx
      directory, removes NR_IRQS and switches IXP4xx over to using
      SPARSE_IRQ.
      
      This is a prerequisite for DT support.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      dc8ef8cd
    • Linus Walleij's avatar
      ARM: ixp4xx: Pass IRQ resource to beeper · 075df31a
      Linus Walleij authored
      All IXP4xx devices except the beeper passes the IRQ as a
      resource, augment the NSLU2 beeper to do the same.
      
      This is a prerequisite for SPARSE_IRQ.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      075df31a
    • Linus Walleij's avatar
      ARM: ixp4xx: Convert to MULTI_IRQ_HANDLER · 98ac0cc2
      Linus Walleij authored
      This rewrites the IXP4xx to use MULTI_IRQ_HANDLER and
      create an irqdomain for the irqchip in the platform. We
      convert the timer to request the interrupt like any other
      driver in the process.
      
      We bump all IRQs to 16+offset to avoid using IRQ 0 and
      set NR_IRQS to 512 (the default for most systems).
      This conveniently fits with the first 16 IRQs being
      pre-allocated when using SPARSE_IRQ.
      
      This is a prerequisite for SPARSE_IRQ and DT boot.
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      98ac0cc2
    • Linus Walleij's avatar
      ARM: ixp4xx: Add myself as maintainer · 64534e06
      Linus Walleij authored
      I am working on the platform right now so might as well
      maintain it for a bit.
      Suggested-by: default avatarKrzysztof Hałasa <khalasa@piap.pl>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      64534e06
  3. 17 Mar, 2019 14 commits
  4. 16 Mar, 2019 2 commits
    • Linus Torvalds's avatar
      Merge tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux · a9dce667
      Linus Torvalds authored
      Pull pidfd system call from Christian Brauner:
       "This introduces the ability to use file descriptors from /proc/<pid>/
        as stable handles on struct pid. Even if a pid is recycled the handle
        will not change. For a start these fds can be used to send signals to
        the processes they refer to.
      
        With the ability to use /proc/<pid> fds as stable handles on struct
        pid we can fix a long-standing issue where after a process has exited
        its pid can be reused by another process. If a caller sends a signal
        to a reused pid it will end up signaling the wrong process.
      
        With this patchset we enable a variety of use cases. One obvious
        example is that we can now safely delegate an important part of
        process management - sending signals - to processes other than the
        parent of a given process by sending file descriptors around via scm
        rights and not fearing that the given process will have been recycled
        in the meantime. It also allows for easy testing whether a given
        process is still alive or not by sending signal 0 to a pidfd which is
        quite handy.
      
        There has been some interest in this feature e.g. from systems
        management (systemd, glibc) and container managers. I have requested
        and gotten comments from glibc to make sure that this syscall is
        suitable for their needs as well. In the future I expect it to take on
        most other pid-based signal syscalls. But such features are left for
        the future once they are needed.
      
        This has been sitting in linux-next for quite a while and has not
        caused any issues. It comes with selftests which verify basic
        functionality and also test that a recycled pid cannot be signaled via
        a pidfd.
      
        Jon has written about a prior version of this patchset. It should
        cover the basic functionality since not a lot has changed since then:
      
            https://lwn.net/Articles/773459/
      
        The commit message for the syscall itself is extensively documenting
        the syscall, including it's functionality and extensibility"
      
      * tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
        selftests: add tests for pidfd_send_signal()
        signal: add pidfd_send_signal() syscall
      a9dce667
    • Linus Torvalds's avatar
      Merge tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · f67e3fb4
      Linus Torvalds authored
      Pull device-dax updates from Dan Williams:
       "New device-dax infrastructure to allow persistent memory and other
        "reserved" / performance differentiated memories, to be assigned to
        the core-mm as "System RAM".
      
        Some users want to use persistent memory as additional volatile
        memory. They are willing to cope with potential performance
        differences, for example between DRAM and 3D Xpoint, and want to use
        typical Linux memory management apis rather than a userspace memory
        allocator layered over an mmap() of a dax file. The administration
        model is to decide how much Persistent Memory (pmem) to use as System
        RAM, create a device-dax-mode namespace of that size, and then assign
        it to the core-mm. The rationale for device-dax is that it is a
        generic memory-mapping driver that can be layered over any "special
        purpose" memory, not just pmem. On subsequent boots udev rules can be
        used to restore the memory assignment.
      
        One implication of using pmem as RAM is that mlock() no longer keeps
        data off persistent media. For this reason it is recommended to enable
        NVDIMM Security (previously merged for 5.0) to encrypt pmem contents
        at rest. We considered making this recommendation an actively enforced
        requirement, but in the end decided to leave it as a distribution /
        administrator policy to allow for emulation and test environments that
        lack security capable NVDIMMs.
      
        Summary:
      
         - Replace the /sys/class/dax device model with /sys/bus/dax, and
           include a compat driver so distributions can opt-in to the new ABI.
      
         - Allow for an alternative driver for the device-dax address-range
      
         - Introduce the 'kmem' driver to hotplug / assign a device-dax
           address-range to the core-mm.
      
         - Arrange for the device-dax target-node to be onlined so that the
           newly added memory range can be uniquely referenced by numa apis"
      
      NOTE! I'm not entirely happy with the whole "PMEM as RAM" model because
      we currently have special - and very annoying rules in the kernel about
      accessing PMEM only with the "MC safe" accessors, because machine checks
      inside the regular repeat string copy functions can be fatal in some
      (not described) circumstances.
      
      And apparently the PMEM modules can cause that a lot more than regular
      RAM.  The argument is that this happens because PMEM doesn't necessarily
      get scrubbed at boot like RAM does, but that is planned to be added for
      the user space tooling.
      
      Quoting Dan from another email:
       "The exposure can be reduced in the volatile-RAM case by scanning for
        and clearing errors before it is onlined as RAM. The userspace tooling
        for that can be in place before v5.1-final. There's also runtime
        notifications of errors via acpi_nfit_uc_error_notify() from
        background scrubbers on the DIMM devices. With that mechanism the
        kernel could proactively clear newly discovered poison in the volatile
        case, but that would be additional development more suitable for v5.2.
      
        I understand the concern, and the need to highlight this issue by
        tapping the brakes on feature development, but I don't see PMEM as RAM
        making the situation worse when the exposure is also there via DAX in
        the PMEM case. Volatile-RAM is arguably a safer use case since it's
        possible to repair pages where the persistent case needs active
        application coordination"
      
      * tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        device-dax: "Hotplug" persistent memory for use like normal RAM
        mm/resource: Let walk_system_ram_range() search child resources
        mm/memory-hotplug: Allow memory resources to be children
        mm/resource: Move HMM pr_debug() deeper into resource code
        mm/resource: Return real error codes from walk failures
        device-dax: Add a 'modalias' attribute to DAX 'bus' devices
        device-dax: Add a 'target_node' attribute
        device-dax: Auto-bind device after successful new_id
        acpi/nfit, device-dax: Identify differentiated memory with a unique numa-node
        device-dax: Add /sys/class/dax backwards compatibility
        device-dax: Add support for a dax override driver
        device-dax: Move resource pinning+mapping into the common driver
        device-dax: Introduce bus + driver model
        device-dax: Start defining a dax bus model
        device-dax: Remove multi-resource infrastructure
        device-dax: Kill dax_region base
        device-dax: Kill dax_region ida
      f67e3fb4