1. 03 May, 2019 1 commit
    • Stephen Boyd's avatar
      clk: Cache core in clk_fetch_parent_index() without names · 1a079560
      Stephen Boyd authored
      If a clk has specified parents via clk_hw pointers it won't specify the
      globally unique names for the parents. Without the unique names, we
      can't fallback to comparing them against the name of the 'parent'
      pointer here. Therefore, do a pointer comparison against the clk_hw
      pointers too and cache the clk_core structure if they match. This fixes
      parent lookup code for clks that only specify clk_hw pointers and
      nothing else, like muxes that are purely inside a clk controller.
      
      Similarly, if the parent pointer isn't cached after trying to match
      clk_core or clk_hw pointers, lookup the pointer from DT or via clkdev
      lookups instead of relying purely on the globally unique clk name match.
      This should allow us to move away from having to specify global names
      for clk parents entirely.
      
      While we're in the area, add some comments so it's clearer what's going
      on. The if statements don't lend themselves to much clarity in their raw
      form.
      
      Fixes: fc0c209c ("clk: Allow parents to be specified without string names")
      Reported-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      1a079560
  2. 23 Apr, 2019 1 commit
  3. 19 Apr, 2019 8 commits
    • Stephen Boyd's avatar
      clk: fixed-factor: Let clk framework find parent · ecbf3f17
      Stephen Boyd authored
      Convert this driver to a more modern way of specifying parents now that
      we have a way to specify clk parents by DT index. This lets us nicely
      avoid a problem where a parent clk name isn't know because the parent
      clk hasn't been registered yet.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      ecbf3f17
    • Stephen Boyd's avatar
      clk: Allow parents to be specified via clkspec index · 601b6e93
      Stephen Boyd authored
      Some clk providers are simple DT nodes that only have a 'clocks'
      property without having an associated 'clock-names' property. In these
      cases, we want to let these clk providers point to their parent clks
      without having to dereference the 'clocks' property at probe time to
      figure out the parent's globally unique clk name. Let's add an 'index'
      property to the parent_data structure so that clk providers can indicate
      that their parent is a particular index in the 'clocks' DT property.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      601b6e93
    • Stephen Boyd's avatar
      clk: Look for parents with clkdev based clk_lookups · dde4eff4
      Stephen Boyd authored
      In addition to looking for DT based parents, support clkdev based
      clk_lookups. This should allow non-DT based clk drivers to participate
      in the parent lookup process.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      dde4eff4
    • Stephen Boyd's avatar
      clk: Allow parents to be specified without string names · fc0c209c
      Stephen Boyd authored
      The common clk framework is lacking in ability to describe the clk
      topology without specifying strings for every possible parent-child
      link. There are a few drawbacks to the current approach:
      
       1) String comparisons are used for everything, including describing
       topologies that are 'local' to a single clock controller.
      
       2) clk providers (e.g. i2c clk drivers) need to create globally unique
       clk names to avoid collisions in the clk namespace, leading to awkward
       name generation code in various clk drivers.
      
       3) DT bindings may not fully describe the clk topology and linkages
       between clk controllers because drivers can easily rely on globally unique
       strings to describe connections between clks.
      
      This leads to confusing DT bindings, complicated clk name generation
      code, and inefficient string comparisons during clk registration just so
      that the clk framework can detect the topology of the clk tree.
      Furthermore, some drivers call clk_get() and then __clk_get_name() to
      extract the globally unique clk name just so they can specify the parent
      of the clk they're registering. We have of_clk_parent_fill() but that
      mostly only works for single clks registered from a DT node, which isn't
      the norm. Let's simplify this all by introducing two new ways of
      specifying clk parents.
      
      The first method is an array of pointers to clk_hw structures
      corresponding to the parents at that index. This works for clks that are
      registered when we have access to all the clk_hw pointers for the
      parents.
      
      The second method is a mix of clk_hw pointers and strings of local and
      global parent clk names. If the .fw_name member of the map is set we'll
      look for that clk by performing a DT based lookup of the device the clk
      is registered with and the .name specified in the map. If that fails,
      we'll fallback to the .name member and perform a global clk name lookup
      like we've always done before.
      
      Using either one of these new methods is entirely optional. Existing
      drivers will continue to work, and they can migrate to this new approach
      as they see fit. Eventually, we'll want to get rid of the 'parent_names'
      array in struct clk_init_data and use one of these new methods instead.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Rob Herring <robh@kernel.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      fc0c209c
    • Stephen Boyd's avatar
      clk: Add of_clk_hw_register() API for early clk drivers · 89a5ddcc
      Stephen Boyd authored
      In some circumstances drivers register clks early and don't have access
      to a struct device because the device model isn't initialized yet. Add
      an API to let drivers register clks associated with a struct device_node
      so that these drivers can participate in getting parent clks through DT.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Rob Herring <robh@kernel.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      89a5ddcc
    • Stephen Boyd's avatar
      driver core: Let dev_of_node() accept a NULL dev · 1b833924
      Stephen Boyd authored
      We'd like to chain this in places where the 'dev' argument might be
      NULL. Let this function take a NULL 'dev' so this can work.
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Rob Herring <robh@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      1b833924
    • Stephen Boyd's avatar
      clk: Prepare for clk registration API that uses DT nodes · fceaa7d8
      Stephen Boyd authored
      Split out the body of the clk_register() function so it can be shared
      between the different types of registration APIs (DT, device).
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Rob Herring <robh@kernel.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      fceaa7d8
    • Stephen Boyd's avatar
      clkdev: Move clk creation outside of 'clocks_mutex' · d1011cba
      Stephen Boyd authored
      We don't need to hold the 'clocks_mutex' here when we're creating a clk
      pointer from a clk_lookup structure. Instead, we just need to make sure
      that the lookup doesn't go away while we dereference the lookup pointer
      to extract the clk_hw pointer out of it. Let's move things around
      slightly so that we have a new function to get the clk_hw out of the
      lookup with the right locking and then chain the two together for what
      used to be __clk_get_sys().
      
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      d1011cba
  4. 18 Apr, 2019 1 commit
    • Stephen Boyd's avatar
      clkdev: Hold clocks_mutex while iterating clocks list · 5a7efdac
      Stephen Boyd authored
      We recently introduced a change to support devm clk lookups. That change
      introduced a code-path that used clk_find() without holding the
      'clocks_mutex'. Unfortunately, clk_find() iterates over the 'clocks'
      list and so we need to prevent the list from being modified at the same
      time. Do this by holding the mutex and checking to make sure it's held
      while iterating the list.
      
      Note, we don't really care if the lookup is freed after we find it with
      clk_find() because we're just doing a pointer comparison, but if we did
      care we would need to keep holding the mutex while we dereference the
      clk_lookup pointer.
      
      Fixes: 3eee6c7d ("clkdev: add managed clkdev lookup registration")
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Acked-by: default avatarMatti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
      Tested-by: default avatarJeffrey Hugo <jhugo@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      5a7efdac
  5. 12 Apr, 2019 2 commits
  6. 11 Apr, 2019 1 commit
  7. 10 Apr, 2019 1 commit
  8. 29 Mar, 2019 2 commits
  9. 25 Mar, 2019 1 commit
  10. 19 Mar, 2019 4 commits
  11. 18 Mar, 2019 1 commit
  12. 17 Mar, 2019 14 commits
  13. 16 Mar, 2019 3 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
    • Linus Torvalds's avatar
      Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 477558d7
      Linus Torvalds authored
      Pull more SCSI updates from James Bottomley:
       "This is the final round of mostly small fixes and performance
        improvements to our initial submit.
      
        The main regression fix is the ia64 simscsi build failure which was
        missed in the serial number elimination conversion"
      
      * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (24 commits)
        scsi: ia64: simscsi: use request tag instead of serial_number
        scsi: aacraid: Fix performance issue on logical drives
        scsi: lpfc: Fix error codes in lpfc_sli4_pci_mem_setup()
        scsi: libiscsi: Hold back_lock when calling iscsi_complete_task
        scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink
        scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port
        scsi: hisi_sas: Set PHY linkrate when disconnected
        scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw
        scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO
        scsi: hisi_sas: Change return variable type in phy_up_v3_hw()
        scsi: qla2xxx: check for kstrtol() failure
        scsi: lpfc: fix 32-bit format string warning
        scsi: lpfc: fix unused variable warning
        scsi: target: tcmu: Switch to bitmap_zalloc()
        scsi: libiscsi: fall back to sendmsg for slab pages
        scsi: qla2xxx: avoid printf format warning
        scsi: lpfc: resolve static checker warning in lpfc_sli4_hba_unset
        scsi: lpfc: Correct __lpfc_sli_issue_iocb_s4 lockdep check
        scsi: ufs: hisi: fix ufs_hba_variant_ops passing
        scsi: qla2xxx: Fix panic in qla_dfs_tgt_counters_show
        ...
      477558d7