aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-11-15regulator: core: Let boot-on regulators be powered offPascal Paillet1-1/+3
Boot-on regulators are always kept on because their use_count value is now incremented at boot time and never cleaned. Only increment count value for alway-on regulators. regulator_late_cleanup() is now able to power off boot-on regulators when unused. Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") Signed-off-by: Pascal Paillet <p.paillet@st.com> Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-07regulator: ab8500: Remove SYSCLKREQ from enum ab8505_regulator_idStephan Gerhold1-2/+0
Those regulators are not actually supported by the AB8500 regulator driver. There is no ab8500_regulator_info for them and no entry in ab8505_regulator_match. As such, they cannot be registered successfully, and looking them up in ab8505_regulator_match causes an out-of-bounds array read. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191106173125.14496-2-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-07regulator: ab8500: Remove AB8505 USB regulatorStephan Gerhold2-18/+0
The USB regulator was removed for AB8500 in commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator"). It was then added for AB8505 in commit 547f384f33db ("regulator: ab8500: add support for ab8505"). However, there was never an entry added for it in ab8505_regulator_match. This causes all regulators after it to be initialized with the wrong device tree data, eventually leading to an out-of-bounds array read. Given that it is not used anywhere in the kernel, it seems likely that similar arguments against supporting it exist for AB8505 (it is controlled by hardware). Therefore, simply remove it like for AB8500 instead of adding an entry in ab8505_regulator_match. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-06regulator: fan53555: add chip id for Silergy SYR83XVasily Khoruzhick1-0/+2
SYR83X is used in Rockpro64 and it has die ID == 9. All other registers are the same as in SYR82X Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://lore.kernel.org/r/20191106161211.1700663-1-anarsoul@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-29regulator: fixed: add off-on-delayPeng Fan2-0/+3
Depends on board design, the gpio controlling regulator may connects with a big capacitance. When need off, it takes some time to let the regulator to be truly off. If not add enough delay, the regulator might have always been on, so introduce off-on-delay to handle such case. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572311875-22880-3-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-29dt-bindings: regulator: fixed: add off-on-delay-us propertyPeng Fan1-0/+4
When disabling a fixed regulator, it may take some time to let the voltage drop to the expected value, such as zero. If not delay enough time, the regulator might have been always enabled. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572311875-22880-2-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-28regulator: core: Allow generic coupling only for always-on regulatorsDmitry Osipenko1-0/+6
The generic voltage balancer doesn't work correctly if one of regulator couples turns off. Currently there are no users in kernel for that case, although let's explicitly show that this case is unsupported for those who will try to use that feature. Link: https://lore.kernel.org/linux-samsung-soc/20191008170503.yd6GscYPLxjgrXqDuCO7AJc6i6egNZGJkVWHLlCxvA4@z/ Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20191025002240.25288-2-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09regulator: uniphier: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191009150203.8052-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09regulator: stm32-vrefbuf: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191009150138.11640-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: da9062: Simplify da9062_buck_set_mode for BUCK_MODE_MANUAL caseAxel Lin1-6/+3
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify the logic as the result is the same. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Remove rk817_set_suspend_voltage functionAxel Lin1-16/+1
The implement is exactly the same as rk808_set_suspend_voltage, so just use rk808_set_suspend_voltage instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-3-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Fix warning message in rk817_set_ramp_delayAxel Lin1-1/+1
The default in rk817_set_ramp_delay is 25MV rather than 10MV. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Constify rk817 regulator_opsAxel Lin1-5/+5
These regulator_ops variables never need to be modified, make them const so compiler can put them to .rodata. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: max77686: switch to using fwnode_gpiod_get_indexDmitry Torokhov1-2/+3
gpiod_get_from_of_node() is being retired in favor of fwnode_gpiod_get_index(), that behaves similar to gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-8-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: tps65132: switch to using devm_fwnode_gpiod_get()Dmitry Torokhov1-7/+10
devm_fwnode_get_index_gpiod_from_child() is going away as the name is too unwieldy, let's switch to using the new devm_fwnode_gpiod_get(). Note that we no longer need to check for NULL as devm_fwnode_gpiod_get() will return -ENOENT if GPIO is missing. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-7-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: da9211: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-6/+6
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191004231017.130290-6-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: s2mps11: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-4/+3
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-5-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: tps65090: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-11/+15
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-4-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: slg51000: switch to using fwnode_gpiod_get_indexDmitry Torokhov1-8/+5
devm_gpiod_get_from_of_node() is being retired in favor of [devm_]fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Note that now that we have a good non-devm API for getting GPIO from arbitrary firmware node, there is no reason to use devm API here as regulator core takes care of managing lifetime of "enable" GPIO and we were immediately detaching requested GPIO from devm anyway. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-3-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: s5m8767: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-4/+3
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-2-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: pbias: Get rid of struct pbias_regulator_dataAxel Lin1-43/+26
Only the desc field is really used, so use struct regulator_desc instead. Then struct pbias_regulator_data can be removed. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191007114320.20977-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: da9062: Simplify the code iterating all regulatorsAxel Lin1-4/+1
It's more straightforward to use for statement here. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: qcom-rpmh: add PM6150/PM6150L regulator supportKiran Gunda1-1/+61
Add support for PM6150/PM6150L regulators. This ensures that consumers are able to modify the physical state of PMIC regulators. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570183734-30706-3-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: dt-bindings: Add PM6150x compatiblesKiran Gunda1-0/+4
Add PM6150 and PM6150L compatibles for Qualcomm SC7180 platfrom. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570183734-30706-2-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: max8907: Fix the usage of uninitialized variable in max8907_regulator_probe()Yizhuo1-3/+12
Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: qcom-rpmh: Fix PMIC5 BoB min voltageKiran Gunda1-2/+2
Correct the PMIC5 BoB min voltage from 0.3V to 3V. Also correct the voltage selector accordingly. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570184215-5355-1-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-03gpiolib: introduce fwnode_gpiod_get_index()Dmitry Torokhov3-15/+62
This introduces fwnode_gpiod_get_index() that iterates through common gpio suffixes when trying to locate a GPIO within a given firmware node. We also switch devm_fwnode_gpiod_get_index() to call fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on its own. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190913032240.50333-3-dmitry.torokhov@gmail.com Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-10-03gpiolib: introduce devm_fwnode_gpiod_get_index()Dmitry Torokhov2-20/+40
devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode in question does not have to be a child of device node. Let's rename it to devm_fwnode_gpiod_get_index() and keep the old name for compatibility for now. Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the callers need a single GPIO. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20190913032240.50333-2-dmitry.torokhov@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-10-02regulator: Document "regulator-boot-on" binding more thoroughlyDouglas Anderson1-1/+6
The description of "regulator-boot-on" was a little unclear, at least to me. Did this property mean that we should turn the regulator on at boot? Or perhaps it was intended only to be used for regulators where we couldn't read the state at bootup to indicate what state we should assume? The answer, it turns out, is both [1]. Let's document this. [1] https://lore.kernel.org/r/20190923181431.GU2036@sirena.org.uk Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20191001124531.v2.1.Ice34ad5970a375c3c03cb15c3859b3ee501561bf@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: bd718x7: Add MODULE_ALIAS()Guido Günther1-0/+1
This fixes device probing when built as a module Signed-off-by: Guido Günther <agx@sigxcpu.org> Link: https://lore.kernel.org/r/46ce3400e227dd88d51486c02a6152c9ec52acbb.1569875042.git.agx@sigxcpu.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: pfuze100-regulator: Variable "val" in pfuze100_regulator_probe() could be uninitializedYizhuo1-1/+7
In function pfuze100_regulator_probe(), variable "val" could be initialized if regmap_read() fails. However, "val" is used to decide the control flow later in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20190929170957.14775-1-yzhai003@ucr.edu Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: lochnagar: Add on_off_delay for VDDCORECharles Keepax1-0/+1
The VDDCORE regulator takes a good length of time to discharge down, so add an on_off_delay to ensure DCVDD is removed before it is powered on again. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191001132017.1785-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: pcap-regulator: remove unused variable 'SW3_table'YueHaibing1-4/+0
drivers/regulator/pcap-regulator.c:89:27: warning: SW3_table defined but not used [-Wunused-const-variable=] It is never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190928085540.45332-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: da9063: Simplify da9063_buck_set_mode for BUCK_MODE_MANUAL caseAxel Lin1-6/+3
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify the logic as the result is the same. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20190926055128.23434-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: pbias: Use of_device_get_match_dataAxel Lin1-4/+2
Use of_device_get_match_data to simplify the code a bit. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20190925101256.19030-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: qcom_spmi: Add support for PM8004 regulatorsAngelo G. Del Regno2-0/+11
This Power IC is used in combination with various PMIC combos, generally found on boards with MSM8992, MSM8994, MSM8996, MSM8956, MSM8976 and others, usually at address 0x5 on the SPMI bus, and its usual usage is to provide power to the GPU and/or to the CPU clusters (APC0/APC1). Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20190921095043.62593-6-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: qcom_smd: Add PM8950 regulatorsAngelo G. Del Regno2-0/+113
The PM8950 provides 6 SMPS regulators, of which 5 HFSMPS and one FTSMPS2.5 (s5), and 23 LDOs. Add these to the RPM regulator driver. Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20190921095043.62593-4-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: qcom_spmi: Add PM8950 SPMI regulatorAngelo G. Del Regno2-0/+55
The PM8950 has 5 HFSMPS, 1 FTSMPS2.5 (s5, controlling APC voltage) and 23 LDO regulators. Add the configuration for this chip. Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20190921095043.62593-3-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01fixed-regulator: dt-bindings: Fixed building error for compatible propertyPragnesh Patel1-2/+2
Compatible property is not of type 'string', so remove const: from it. Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1568875145-2864-1-git-send-email-pragnesh.patel@sifive.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: ti-abb: Fix timeout in ti_abb_wait_txdone/ti_abb_clear_all_txdoneAxel Lin1-18/+8
ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns true in the latest iteration of the while loop because the timeout value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest iteration of the while loop. Fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-30Linux 5.4-rc1Linus Torvalds1-2/+2
2019-09-30csky: Move static keyword to the front of declarationKrzysztof Wilczynski1-1/+1
Move the static keyword to the front of declaration of csky_pmu_of_device_ids, and resolve the following compiler warning that can be seen when building with warnings enabled (W=1): arch/csky/kernel/perf_event.c:1340:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Signed-off-by: Krzysztof Wilczynski <kw@linux.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-30csky: entry: Remove unneeded need_resched() loopValentin Schneider1-4/+0
Since the enabling and disabling of IRQs within preempt_schedule_irq() is contained in a need_resched() loop, we don't need the outer arch code loop. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-30csky: Fixup csky_pmu.max_period assignmentMao Han1-1/+1
The csky_pmu.max_period has type u64, and BIT() can only return 32 bits unsigned long on C-SKY. The initialization for max_period will be incorrect when count_width is bigger than 32. Use BIT_ULL() Signed-off-by: Mao Han <han_mao@c-sky.com> Signed-off-by: Guo Ren <ren_guo@c-sky.com>
2019-09-30csky: Fixup add zero_fp fixup perf backtrace panicGuo Ren2-21/+31
We need set fp zero to let backtrace know the end. The patch fixup perf callchain panic problem, because backtrace didn't know what is the end of fp. Signed-off-by: Guo Ren <ren_guo@c-sky.com> Reported-by: Mao Han <han_mao@c-sky.com>
2019-09-30csky: Use generic free_initrd_mem()Mike Rapoport1-16/+0
The csky implementation of free_initrd_mem() is an open-coded version of free_reserved_area() without poisoning. Remove it and make csky use the generic version of free_initrd_mem(). Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Guo Ren <guoren@kernel.org>
2019-09-29Revert "Revert "ext4: make __ext4_get_inode_loc plug""Linus Torvalds1-0/+3
This reverts commit 72dbcf72156641fde4d8ea401e977341bfd35a05. Instead of waiting forever for entropy that may just not happen, we now try to actively generate entropy when required, and are thus hopefully avoiding the problem that caused the nice ext4 IO pattern fix to be reverted. So revert the revert. Cc: Ahmed S. Darwish <darwish.07@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Willy Tarreau <w@1wt.eu> Cc: Alexander E. Patrakov <patrakov@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29random: try to actively add entropy rather than passively wait for itLinus Torvalds1-1/+61
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it caused a bootup regression due to lack of entropy at bootup together with arguably broken user space that was asking for secure random numbers when it really didn't need to. See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug"). This aims to solve the issue by actively generating entropy noise using the CPU cycle counter when waiting for the random number generator to initialize. This only works when you have a high-frequency time stamp counter available, but that's the case on all modern x86 CPU's, and on most other modern CPU's too. What we do is to generate jitter entropy from the CPU cycle counter under a somewhat complex load: calling the scheduler while also guaranteeing a certain amount of timing noise by also triggering a timer. I'm sure we can tweak this, and that people will want to look at other alternatives, but there's been a number of papers written on jitter entropy, and this should really be fairly conservative by crediting one bit of entropy for every timer-induced jump in the cycle counter. Not because the timer itself would be all that unpredictable, but because the interaction between the timer and the loop is going to be. Even if (and perhaps particularly if) the timer actually happens on another CPU, the cacheline interaction between the loop that reads the cycle counter and the timer itself firing is going to add perturbations to the cycle counter values that get mixed into the entropy pool. As Thomas pointed out, with a modern out-of-order CPU, even quite simple loops show a fair amount of hard-to-predict timing variability even in the absense of external interrupts. But this tries to take that further by actually having a fairly complex interaction. This is not going to solve the entropy issue for architectures that have no CPU cycle counter, but it's not clear how (and if) that is solvable, and the hardware in question is largely starting to be irrelevant. And by doing this we can at least avoid some of the even more contentious approaches (like making the entropy waiting time out in order to avoid the possibly unbounded waiting). Cc: Ahmed Darwish <darwish.07@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Nicholas Mc Guire <hofrat@opentech.at> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Willy Tarreau <w@1wt.eu> Cc: Alexander E. Patrakov <patrakov@gmail.com> Cc: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29Documentation/process: Clarify disclosure rulesThomas Gleixner1-7/+33
The role of the contact list provided by the disclosing party and how it affects the disclosure process and the ability to include experts into the development process is not really well explained. Neither is it entirely clear when the disclosing party will be informed about the fact that a developer who is not covered by an employer NDA needs to be brought in and disclosed. Explain the role of the contact list and the information policy along with an eventual conflict resolution better. Reported-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.1909251028390.10825@nanos.tec.linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-28selftests/ftrace: Fix same probe error testSteven Rostedt (VMware)1-1/+1
The "same probe" selftest that tests that adding the same probe fails doesn't add the same probe and passes, which fails the test. Fixes: b78b94b82122 ("selftests/ftrace: Update kprobe event error testcase") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>