Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 11月, 2020 1 次提交
  3. 03 11月, 2020 1 次提交
  5. 05 10月, 2020 1 次提交
  7. 02 10月, 2020 1 次提交
    • A
      regulator: core: Enlarge max OF property name length to 64 chars · e9bb4a06
      由 AngeloGioacchino Del Regno 提交于 
      Some regulator drivers may be defining very long names: this is the
case with the qcom_smd and qcom_spmi regulators, where we need to
parse the regulator parents from DT.

For clarity, this is an example:
{ "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo,
  "vdd_l8_l9_l10_l11_l12_l13_l14" },
pm660-regulators {
	...
	vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>
	...
};
Now, with a 32 characters limit, the function is trying to parse,
exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of
the right one, which is 37 chars long in this specific case.

... And this is not only the case with PM660/PM660L, but also with
PMA8084, PM8916, PM8950 and others that are not implemented yet.

The length of 64 chars was chosen based on the longest parsed property
name that I could find, which is in PM8916, and would be 53 characters
long.
At that point, rounding that to 64 looked like being the best idea.
Signed-off-by: NAngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
      e9bb4a06
  9. 29 9月, 2020 3 次提交
  11. 22 9月, 2020 2 次提交
  13. 08 9月, 2020 1 次提交
  15. 01 9月, 2020 1 次提交
  17. 24 8月, 2020 1 次提交
  19. 19 8月, 2020 2 次提交
  21. 17 8月, 2020 7 次提交
  23. 24 7月, 2020 1 次提交
    • V
      regulator: fix memory leak on error path of regulator_register() · 9177514c
      由 Vladimir Zapolskiy 提交于 
      The change corrects registration and deregistration on error path
of a regulator, the problem was manifested by a reported memory
leak on deferred probe:

    as3722-regulator as3722-regulator: regulator 13 register failed -517

    # cat /sys/kernel/debug/kmemleak
    unreferenced object 0xecc43740 (size 64):
      comm "swapper/0", pid 1, jiffies 4294937640 (age 712.880s)
      hex dump (first 32 bytes):
        72 65 67 75 6c 61 74 6f 72 2e 32 34 00 5a 5a 5a  regulator.24.ZZZ
        5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
      backtrace:
        [<0c4c3d1c>] __kmalloc_track_caller+0x15c/0x2c0
        [<40c0ad48>] kvasprintf+0x64/0xd4
        [<109abd29>] kvasprintf_const+0x70/0x84
        [<c4215946>] kobject_set_name_vargs+0x34/0xa8
        [<62282ea2>] dev_set_name+0x40/0x64
        [<a39b6757>] regulator_register+0x3a4/0x1344
        [<16a9543f>] devm_regulator_register+0x4c/0x84
        [<51a4c6a1>] as3722_regulator_probe+0x294/0x754
        ...

The memory leak problem was introduced as a side ef another fix in
regulator_register() error path, I believe that the proper fix is
to decouple device_register() function into its two compounds and
initialize a struct device before assigning any values to its fields
and then using it before actual registration of a device happens.

This lets to call put_device() safely after initialization, and, since
now a release callback is called, kfree(rdev->constraints) shall be
removed to exclude a double free condition.

Fixes: a3cde953 ("regulator: core: fix regulator_register() error paths to properly release rdev")
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Cc: Wen Yang <wenyang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20200724005013.23278-1-vz@mleia.comSigned-off-by: NMark Brown <broonie@kernel.org>
      9177514c
  25. 20 7月, 2020 1 次提交
  27. 15 7月, 2020 1 次提交
  29. 30 5月, 2020 1 次提交
  31. 29 5月, 2020 1 次提交
  33. 30 4月, 2020 1 次提交
  35. 14 4月, 2020 1 次提交
  37. 14 3月, 2020 1 次提交
  39. 05 3月, 2020 1 次提交
    • J
      regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work · dca0b449
      由 John Stultz 提交于 
      The regulator_init_complete_work logic defers the cleanup for an
arbitrary 30 seconds of time to allow modules loaded by userland
to start.

This arbitrary timeout is similar to the
driver_deferred_probe_timeout value, and its been suggested we
align these so users have a method to extend the timeouts as
needed.

So this patch changes the logic to use the
driver_deferred_probe_timeout value for the delay value if it
is set (using a delay of 0 if it is not).

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dca0b449
  41. 21 1月, 2020 1 次提交
  43. 17 1月, 2020 1 次提交
  45. 10 12月, 2019 1 次提交
    • C
      regulator: core: avoid unneeded .list_voltage calls · 6d30fc51
      由 Cristian Marussi 提交于 
      Inside machine_constraints_voltage() a loop is in charge of verifying that
each of the defined voltages are within the configured constraints and
that those constraints are in fact compatible with the available voltages'
list.

When the registered regulator happens to be defined with a wide range of
possible voltages the above O(n) loop can be costly.
Moreover since this behaviour is triggered during the registration process,
it means also that it can be easily triggered at probe time, slowing down
considerably some module loading.

On the other side if such wide range of voltage values happens to be also
continuous and without discontinuity of any kind, the above potentially
cumbersome operation is also useless.

For these reasons, avoid such .list_voltage poll loop when regulator is
described as 'continuous_voltage_range' as is, indeed, similarly already
done inside regulator_is_supported_voltage().
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.comSigned-off-by: NMark Brown <broonie@kernel.org>
      6d30fc51
  47. 03 12月, 2019 1 次提交
  49. 27 11月, 2019 1 次提交
  51. 15 11月, 2019 2 次提交
  53. 28 10月, 2019 2 次提交
  55. 17 9月, 2019 1 次提交