1. 30 3月, 2021 1 次提交
    • L
      of: base: Fix spelling issue with function param 'prop' · 31e46db0
      Lee Jones 提交于
      Fixes the following W=1 kernel build warning(s):
      
       drivers/of/base.c:1781: warning: Function parameter or member 'prop' not described in '__of_add_property'
       drivers/of/base.c:1781: warning: Excess function parameter 'prob' description in '__of_add_property'
       drivers/of/base.c:1804: warning: Function parameter or member 'prop' not described in 'of_add_property'
       drivers/of/base.c:1804: warning: Excess function parameter 'prob' description in 'of_add_property'
       drivers/of/base.c:1855: warning: Function parameter or member 'prop' not described in 'of_remove_property'
       drivers/of/base.c:1855: warning: Excess function parameter 'prob' description in 'of_remove_property'
      
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Link: https://lore.kernel.org/r/20210329152435.900225-1-lee.jones@linaro.orgSigned-off-by: NRob Herring <robh@kernel.org>
      31e46db0
  2. 28 3月, 2021 2 次提交
  3. 24 3月, 2021 1 次提交
    • L
      of: base: Fix some formatting issues and provide missing descriptions · 3637d49e
      Lee Jones 提交于
      Fixes the following W=1 kernel build warning(s):
      
       drivers/of/base.c:315: warning: Function parameter or member 'cpun' not described in '__of_find_n_match_cpu_property'
       drivers/of/base.c:315: warning: Function parameter or member 'prop_name' not described in '__of_find_n_match_cpu_property'
       drivers/of/base.c:315: warning: Function parameter or member 'cpu' not described in '__of_find_n_match_cpu_property'
       drivers/of/base.c:315: warning: Function parameter or member 'thread' not described in '__of_find_n_match_cpu_property'
       drivers/of/base.c:315: warning: expecting prototype for property holds the physical id of the(). Prototype was for __of_find_n_match_cpu_property() instead
       drivers/of/base.c:1139: warning: Function parameter or member 'match' not described in 'of_find_matching_node_and_match'
       drivers/of/base.c:1779: warning: Function parameter or member 'np' not described in '__of_add_property'
       drivers/of/base.c:1779: warning: Function parameter or member 'prop' not described in '__of_add_property'
       drivers/of/base.c:1800: warning: Function parameter or member 'np' not described in 'of_add_property'
       drivers/of/base.c:1800: warning: Function parameter or member 'prop' not described in 'of_add_property'
       drivers/of/base.c:1849: warning: Function parameter or member 'np' not described in 'of_remove_property'
       drivers/of/base.c:1849: warning: Function parameter or member 'prop' not described in 'of_remove_property'
       drivers/of/base.c:2137: warning: Function parameter or member 'dn' not described in 'of_console_check'
       drivers/of/base.c:2137: warning: Function parameter or member 'name' not described in 'of_console_check'
       drivers/of/base.c:2137: warning: Function parameter or member 'index' not described in 'of_console_check'
      
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20210318104036.3175910-5-lee.jones@linaro.org
      3637d49e
  4. 16 1月, 2021 1 次提交
  5. 06 9月, 2020 1 次提交
  6. 28 7月, 2020 1 次提交
  7. 02 1月, 2020 1 次提交
  8. 25 12月, 2019 1 次提交
    • R
      of: Rework and simplify phandle cache to use a fixed size · 90dc0d1c
      Rob Herring 提交于
      The phandle cache was added to speed up of_find_node_by_phandle() by
      avoiding walking the whole DT to find a matching phandle. The
      implementation has several shortcomings:
      
        - The cache is designed to work on a linear set of phandle values.
          This is true for dtc generated DTs, but not for other cases such as
          Power.
        - The cache isn't enabled until of_core_init() and a typical system
          may see hundreds of calls to of_find_node_by_phandle() before that
          point.
        - The cache is freed and re-allocated when the number of phandles
          changes.
        - It takes a raw spinlock around a memory allocation which breaks on
          RT.
      
      Change the implementation to a fixed size and use hash_32() as the
      cache index. This greatly simplifies the implementation. It avoids
      the need for any re-alloc of the cache and taking a reference on nodes
      in the cache. We only have a single source of removing cache entries
      which is of_detach_node().
      
      Using hash_32() removes any assumption on phandle values improving
      the hit rate for non-linear phandle values. The effect on linear values
      using hash_32() is about a 10% collision. The chances of thrashing on
      colliding values seems to be low.
      
      To compare performance, I used a RK3399 board which is a pretty typical
      system. I found that just measuring boot time as done previously is
      noisy and may be impacted by other things. Also bringing up secondary
      cores causes some issues with measuring, so I booted with 'nr_cpus=1'.
      With no caching, calls to of_find_node_by_phandle() take about 20124 us
      for 1248 calls. There's an additional 288 calls before time keeping is
      up. Using the average time per hit/miss with the cache, we can calculate
      these calls to take 690 us (277 hit / 11 miss) with a 128 entry cache
      and 13319 us with no cache or an uninitialized cache.
      
      Comparing the 3 implementations the time spent in
      of_find_node_by_phandle() is:
      
      no cache:        20124 us (+ 13319 us)
      128 entry cache:  5134 us (+ 690 us)
      current cache:     819 us (+ 13319 us)
      
      We could move the allocation of the cache earlier to improve the
      current cache, but that just further complicates the situation as it
      needs to be after slab is up, so we can't do it when unflattening (which
      uses memblock).
      Reported-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NFrank Rowand <frowand.list@gmail.com>
      Tested-by: NFrank Rowand <frowand.list@gmail.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      90dc0d1c
  9. 09 10月, 2019 1 次提交
  10. 19 9月, 2019 1 次提交
    • U
      of: restore old handling of cells_name=NULL in of_*_phandle_with_args() · 59e9fcf8
      Uwe Kleine-König 提交于
      Before commit e42ee610 ("of: Let of_for_each_phandle fallback to
      non-negative cell_count") the iterator functions calling
      of_for_each_phandle assumed a cell count of 0 if cells_name was NULL.
      This corner case was missed when implementing the fallback logic in
      e42ee610 and resulted in an endless loop.
      
      Restore the old behaviour of of_count_phandle_with_args() and
      of_parse_phandle_with_args() and add a check to
      of_phandle_iterator_init() to prevent a similar failure as a safety
      precaution. of_parse_phandle_with_args_map() doesn't need a similar fix
      as cells_name isn't NULL there.
      
      Affected drivers are:
       - drivers/base/power/domain.c
       - drivers/base/power/domain.c
       - drivers/clk/ti/clk-dra7-atl.c
       - drivers/hwmon/ibmpowernv.c
       - drivers/i2c/muxes/i2c-demux-pinctrl.c
       - drivers/iommu/mtk_iommu.c
       - drivers/net/ethernet/freescale/fman/mac.c
       - drivers/opp/of.c
       - drivers/perf/arm_dsu_pmu.c
       - drivers/regulator/of_regulator.c
       - drivers/remoteproc/imx_rproc.c
       - drivers/soc/rockchip/pm_domains.c
       - sound/soc/fsl/imx-audmix.c
       - sound/soc/fsl/imx-audmix.c
       - sound/soc/meson/axg-card.c
       - sound/soc/samsung/tm2_wm5110.c
       - sound/soc/samsung/tm2_wm5110.c
      
      Thanks to Geert Uytterhoeven for reporting the issue, Peter Rosin for
      helping pinpoint the actual problem and the testers for confirming this
      fix.
      
      Fixes: e42ee610 ("of: Let of_for_each_phandle fallback to non-negative cell_count")
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRob Herring <robh@kernel.org>
      59e9fcf8
  11. 14 9月, 2019 1 次提交
    • U
      of: Let of_for_each_phandle fallback to non-negative cell_count · e42ee610
      Uwe Kleine-König 提交于
      Referencing device tree nodes from a property allows to pass arguments.
      This is for example used for referencing gpios. This looks as follows:
      
      	gpio_ctrl: gpio-controller {
      		#gpio-cells = <2>
      		...
      	}
      
      	someothernode {
      		gpios = <&gpio_ctrl 5 0 &gpio_ctrl 3 0>;
      		...
      	}
      
      To know the number of arguments this must be either fixed, or the
      referenced node is checked for a $cells_name (here: "#gpio-cells")
      property and with this information the start of the second reference can
      be determined.
      
      Currently regulators are referenced with no additional arguments. To
      allow some optional arguments without having to change all referenced
      nodes this change introduces a way to specify a default cell_count. So
      when a phandle is parsed we check for the $cells_name property and use
      it as before if present. If it is not present we fall back to
      cells_count if non-negative and only fail if cells_count is smaller than
      zero.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRob Herring <robh@kernel.org>
      e42ee610
  12. 07 6月, 2019 1 次提交
  13. 11 4月, 2019 1 次提交
    • F
      of: Improve of_phandle_iterator_next() error message · af3be70a
      Florian Fainelli 提交于
      Understanding why of_phandle_iterator_next() returns an error can
      sometimes be hard to decipher based solely on the error message, a
      typical error example is that #foo-cells = <X> and the phandle property
      used has a smaller number of cells specified, e.g.:
      
      	#thermal-sensor-cells = <1>;
      	phandle = <&scmi_sensor>
      
      instead of:
      
      	phandle <&scmi_sensor 0>;
      
      Instead, make it clear what the expectations are towards debugging
      incorrect Device Tree faster:
      
      OF: /thermal-zones/scmi-thermal: #thermal-sensor-cells = 1, found 0 instead
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      af3be70a
  14. 22 12月, 2018 2 次提交
  15. 06 12月, 2018 1 次提交
  16. 28 11月, 2018 1 次提交
  17. 02 11月, 2018 1 次提交
  18. 22 10月, 2018 1 次提交
  19. 15 10月, 2018 2 次提交
  20. 29 9月, 2018 3 次提交
  21. 25 9月, 2018 1 次提交
  22. 20 9月, 2018 1 次提交
  23. 12 9月, 2018 1 次提交
  24. 08 9月, 2018 1 次提交
  25. 31 8月, 2018 1 次提交
  26. 29 8月, 2018 1 次提交
    • J
      of: add helper to lookup compatible child node · 36156f92
      Johan Hovold 提交于
      Add of_get_compatible_child() helper that can be used to lookup
      compatible child nodes.
      
      Several drivers currently use of_find_compatible_node() to lookup child
      nodes while failing to notice that the of_find_ functions search the
      entire tree depth-first (from a given start node) and therefore can
      match unrelated nodes. The fact that these functions also drop a
      reference to the node they start searching from (e.g. the parent node)
      is typically also overlooked, something which can lead to use-after-free
      bugs.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NRob Herring <robh@kernel.org>
      36156f92
  27. 16 7月, 2018 1 次提交
  28. 08 3月, 2018 1 次提交
    • F
      of: cache phandle nodes to reduce cost of of_find_node_by_phandle() · 0b3ce78e
      Frank Rowand 提交于
      Create a cache of the nodes that contain a phandle property.  Use this
      cache to find the node for a given phandle value instead of scanning
      the devicetree to find the node.  If the phandle value is not found
      in the cache, of_find_node_by_phandle() will fall back to the tree
      scan algorithm.
      
      The cache is initialized in of_core_init().
      
      The cache is freed via a late_initcall_sync() if modules are not
      enabled.
      
      If the devicetree is created by the dtc compiler, with all phandle
      property values auto generated, then the size required by the cache
      could be 4 * (1 + number of phandles) bytes.  This results in an O(1)
      node lookup cost for a given phandle value.  Due to a concern that the
      phandle property values might not be consistent with what is generated
      by the dtc compiler, a mask has been added to the cache lookup algorithm.
      To maintain the O(1) node lookup cost, the size of the cache has been
      increased by rounding the number of entries up to the next power of
      two.
      
      The overhead of finding the devicetree node containing a given phandle
      value has been noted by several people in the recent past, in some cases
      with a patch to add a hashed index of devicetree nodes, based on the
      phandle value of the node.  One concern with this approach is the extra
      space added to each node.  This patch takes advantage of the phandle
      property values auto generated by the dtc compiler, which begin with
      one and monotonically increase by one, resulting in a range of 1..n
      for n phandle values.  This implementation should also provide a good
      reduction of overhead for any range of phandle values that are mostly
      in a monotonic range.
      
      Performance measurements by Chintan Pandya <cpandya@codeaurora.org>
      of several implementations of patches that are similar to this one
      suggest an expected reduction of boot time by ~400ms for his test
      system.  If the cache size was decreased to 64 entries, the boot
      time was reduced by ~340 ms.  The measurements were on a 4.9.73 kernel
      for arch/arm64/boot/dts/qcom/sda670-mtp.dts, contains 2371 nodes and
      814 phandle values.
      Reported-by: NChintan Pandya <cpandya@codeaurora.org>
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      0b3ce78e
  29. 12 2月, 2018 1 次提交
    • S
      of: Support parsing phandle argument lists through a nexus node · bd6f2fd5
      Stephen Boyd 提交于
      Platforms like 96boards have a standardized connector/expansion
      slot that exposes signals like GPIOs to expansion boards in an
      SoC agnostic way. We'd like the DT overlays for the expansion
      boards to be written once without knowledge of the SoC on the
      other side of the connector. This avoids the unscalable
      combinatorial explosion of a different DT overlay for each
      expansion board and SoC pair.
      
      We need a way to describe the GPIOs routed through the connector
      in an SoC agnostic way. Let's introduce nexus property parsing
      into the OF core to do this. This is largely based on the
      interrupt nexus support we already have. This allows us to remap
      a phandle list in a consumer node (e.g. reset-gpios) through a
      connector in a generic way (e.g. via gpio-map). Do this in a
      generic routine so that we can remap any sort of variable length
      phandle list.
      
      Taking GPIOs as an example, the connector would be a GPIO nexus,
      supporting the remapping of a GPIO specifier space to multiple
      GPIO providers on the SoC. DT would look as shown below, where
      'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
      expansion port where boards can be plugged in, and
      'expansion_device' is a device on the expansion board.
      
      	soc {
      		soc_gpio1: gpio-controller1 {
      			#gpio-cells = <2>;
      		};
      
      		soc_gpio2: gpio-controller2 {
      			#gpio-cells = <2>;
      		};
      	};
      
      	connector: connector {
      		#gpio-cells = <2>;
      		gpio-map = <0 0 &soc_gpio1 1 0>,
      			   <1 0 &soc_gpio2 4 0>,
      			   <2 0 &soc_gpio1 3 0>,
      			   <3 0 &soc_gpio2 2 0>;
      		gpio-map-mask = <0xf 0x0>;
      		gpio-map-pass-thru = <0x0 0x1>
      	};
      
      	expansion_device {
      		reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
      	};
      
      The GPIO core would use of_parse_phandle_with_args_map() instead
      of of_parse_phandle_with_args() and arrive at the same type of
      result, a phandle and argument list. The difference is that the
      phandle and arguments will be remapped through the nexus node to
      the underlying SoC GPIO controller node. In the example above,
      we would remap 'reset-gpios' from <&connector 2 GPIO_ACTIVE_LOW>
      to <&soc_gpio1 3 GPIO_ACTIVE_LOW>.
      
      Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Signed-off-by: NStephen Boyd <stephen.boyd@linaro.org>
      Signed-off-by: NRob Herring <robh@kernel.org>
      bd6f2fd5
  30. 08 1月, 2018 1 次提交
  31. 03 1月, 2018 1 次提交
  32. 21 11月, 2017 1 次提交
  33. 18 10月, 2017 1 次提交
    • F
      of: overlay: remove a dependency on device node full_name · e0a58f3e
      Frank Rowand 提交于
      The "%pOF" printf format was recently added to print the
      full name of a device tree node, with the intent of changing
      the node full_name field to contain only the node name instead
      of the full path of the node.
      
      dup_and_fixup_symbol_prop() duplicates a property from the
      "/__symbols__" node of an overlay device tree.  The value
      of each duplicated property must be fixed up to include
      the full path of a node in the live device tree.  The
      current code uses the node's full_name for that purpose.
      Update the code to use the "%pOF" printf format to
      determine the node's full path.
      Signed-off-by: NFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      e0a58f3e
  34. 17 10月, 2017 2 次提交