aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-sqlite.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28thermal/core: Move thermal_set_delay_jiffies to staticDaniel Lezcano3-8/+7
The function 'thermal_set_delay_jiffies' is only used in thermal_core.c but it is defined and implemented in a separate file. Move the function to thermal_core.c and make it static. Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220722200007.1839356-7-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/core: Remove unneeded EXPORT_SYMBOLSDaniel Lezcano1-2/+0
Different functions are exporting the symbols but are actually only used by the thermal framework internals. Remove these EXPORT_SYMBOLS. Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Link: https://lore.kernel.org/r/20220722200007.1839356-6-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/of: Move thermal_trip structure to thermal.hDaniel Lezcano2-12/+12
The structure thermal_trip is now generic and will be usable by the different sensor drivers in place of their own structure. Move its definition to thermal.h to make it accessible. Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220722200007.1839356-5-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/of: Remove the device node pointer for thermal_tripDaniel Lezcano2-10/+0
The device node pointer is no longer needed in the thermal trip structure, remove it. Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220722200007.1839356-4-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/of: Replace device node match with device node searchDaniel Lezcano1-20/+44
The thermal_of code builds a trip array associated with the node pointer in order to compare the trip point phandle with the list. The thermal trip is a thermal zone property and should be moved there. If some sensors have hardcoded trip points, they should use the exported structure instead of redefining again and again their own structure and data to describe exactly the same things. In order to move this to the thermal.h header and allow more cleanup, we need to remove the node pointer from the structure. Instead of building storing the device node, we search directly in the device tree the corresponding node. That results in a simplification of the code and allows to move the structure to thermal.h Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Link: https://lore.kernel.org/r/20220722200007.1839356-3-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/core: Remove duplicate information when an error occursDaniel Lezcano1-4/+4
The pr_err already tells it is an error, it is pointless to add the 'Error:' string in the messages. Remove them. Cc: Alexandre Bailon <abailon@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linexp.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220722200007.1839356-2-daniel.lezcano@linexp.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/core: Avoid calling ->get_trip_temp() unnecessarilyDaniel Lezcano1-6/+2
As the trip temperature is already available when calling the function handle_critical_trips(), pass it as a parameter instead of having this function calling the ops again to retrieve the same data. Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20220718145038.1114379-2-daniel.lezcano@linaro.org
2022-07-28thermal/tools/tmon: Fix typo 'the the' in commentSlark Xiao1-1/+1
Replace 'the the' with 'the' in the comment. Signed-off-by: Slark Xiao <slark_xiao@163.com> Link: https://lore.kernel.org/r/20220722104047.83312-1-slark_xiao@163.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/tools/tmon: Include pthread and time headers in tmon.hMarkus Mayer1-0/+3
Include sys/time.h and pthread.h in tmon.h, so that types "pthread_mutex_t" and "struct timeval tv" are known when tmon.h references them. Without these headers, compiling tmon against musl-libc will fail with these errors: In file included from sysfs.c:31:0: tmon.h:47:8: error: unknown type name 'pthread_mutex_t' extern pthread_mutex_t input_lock; ^~~~~~~~~~~~~~~ make[3]: *** [<builtin>: sysfs.o] Error 1 make[3]: *** Waiting for unfinished jobs.... In file included from tui.c:31:0: tmon.h:54:17: error: field 'tv' has incomplete type struct timeval tv; ^~ make[3]: *** [<builtin>: tui.o] Error 1 make[2]: *** [Makefile:83: tmon] Error 2 Signed-off-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Acked-by: Alejandro González <alejandro.gonzalez.correo@gmail.com> Tested-by: Alejandro González <alejandro.gonzalez.correo@gmail.com> Fixes: 94f69966faf8 ("tools/thermal: Introduce tmon, a tool for thermal subsystem") Link: https://lore.kernel.org/r/20220718031040.44714-1-f.fainelli@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/ti-soc-thermal: Fix comment typoJason Wang1-1/+1
The double `and' is duplicated in line 229, remove one. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220715051829.30927-1-wangborong@cdjrlc.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/qcom/spmi-adc-tm5: Register thermal zones as hwmon sensorsDmitry Baryshkov1-0/+5
Register thermal zones as hwmon sensors to let userspace read temperatures using standard hwmon interface. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20220719054940.755907-2-dmitry.baryshkov@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/qcom/temp-alarm: Register thermal zones as hwmon sensorsDmitry Baryshkov1-0/+5
Register thermal zones as hwmon sensors to let userspace read temperatures using standard hwmon interface. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20220719054940.755907-1-dmitry.baryshkov@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/u8500: Remove unnecessary print function dev_err()Yang Li1-6/+2
The print function dev_err() is redundant because platform_get_irq() already prints an error. Eliminate the follow coccicheck warnings: ./drivers/thermal/db8500_thermal.c:162:2-9: line 162 is redundant because platform_get_irq() already prints an error ./drivers/thermal/db8500_thermal.c:176:2-9: line 176 is redundant because platform_get_irq() already prints an error Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20220719003556.74460-1-yang.lee@linux.alibaba.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/rzg2l: Fix commentsBiju Das1-7/+11
This patch replaces 'Capture times'->'Total number of ADC data samples' as the former does not really explain much. It also fixes the typo * caliberation->calibration Lastly, as per the coding style /* should be on a separate line. This patch fixes this issue. Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20220718121440.556408-1-biju.das.jz@bp.renesas.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/sun8i: Fix typo in commentJulia Lawall1-1/+1
Spelling mistake (triple letters) in comment. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Acked-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220521111145.81697-36-Julia.Lawall@inria.fr Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/k3_j72xx_bandgap: Make k3_j72xx_bandgap_j721e_data and k3_j72xx_bandgap_j7200_data staticJin Xiaoyun1-2/+2
Fix sparse warnings: drivers/thermal/k3_j72xx_bandgap.c:532:36: sparse: sparse: symbol 'k3_j72xx_bandgap_j721e_data' was not declared. Should it be static? drivers/thermal/k3_j72xx_bandgap.c:536:36: sparse: sparse: symbol 'k3_j72xx_bandgap_j7200_data' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jin Xiaoyun <jinxiaoyun2@huawei.com> Link: https://lore.kernel.org/r/20220613063111.654893-1-jinxiaoyun2@huawei.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/k3_j72xx_bandgap: Fix array underflow in prep_lookup_table()Dan Carpenter1-2/+0
This while loop exits with "i" set to -1 and so then it sets: derived_table[-1] = derived_table[0] - 300; There is no need for this assignment at all. Just delete it. Fixes: 72b3fc61c752 ("thermal: k3_j72xx_bandgap: Add the bandgap driver support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YoetjwcOEzYEFp9b@kili Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/k3_j72xx_bandgap: Fix ref_table memory leak during probeBryan Brattlof1-2/+5
If an error occurs in the k3_j72xx_bandgap_probe() function the memory allocated to the 'ref_table' will not be released. Add a err_free_ref_table step to the error path to free 'ref_table' Fixes: 72b3fc61c752 ("thermal: k3_j72xx_bandgap: Add the bandgap driver support") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20220525213617.30002-1-bb@ti.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/core: Remove DROP_FULL and RAISE_FULLDaniel Lezcano2-13/+0
The trends DROP_FULL and RAISE_FULL are not used and were never used in the past AFAICT. Remove these conditions as they seems to not be handled anywhere. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20220629151012.3115773-2-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/core: Use clamp() helper in the stepwise governorDaniel Lezcano1-11/+4
The code is actually clampling the next cooling device state using the lowest and highest states of the thermal instance. That code can be replaced by the clamp() macro which does exactly the same. It results in a simpler routine to read. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20220629151012.3115773-1-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/u8500: Remove the get_trend functionDaniel Lezcano1-22/+4
The get_trend function relies on the interrupt to set the raising or dropping trend. However the interpolated temperature is already giving the temperature information to the thermal framework which is able to deduce the trend. Remove the trend code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220616202537.303655-3-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/tegra: Remove get_trend functionDaniel Lezcano1-32/+0
The get_trend function does already what the generic framework does. Remove it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20220616202537.303655-2-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/qcom: Remove get_trend functionDaniel Lezcano2-14/+0
There is a get_trend function which is a wrapper to call a private get_trend function. However, this private get_trend function is not assigned anywhere. Remove this dead code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Amit Kucheria <amitk@kernel.org> Link: https://lore.kernel.org/r/20220616202537.303655-1-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: rcar-gen3-thermal: Add r8a779f0 supportWolfram Sang1-5/+14
Add support for R-Car S4. The S4 IP differs a bit from its siblings in such way that it has 3 out of 4 TSC nodes for Linux and the interrupts are not routed to the INTC-AP but to the ECM. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220610201701.7946-2-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: rcar-gen3-thermal: use positive logicWolfram Sang1-11/+10
When handling the V3U/r8a779a0 exception, avoid using 'not:' because then its subschemas are far away in the 'else:' branch. Keep them together using positive logic. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20220610201701.7946-1-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: qcom,spmi-temp-alarm: convert to dtschemaKrzysztof Kozlowski2-51/+85
Convert the Qualcomm QPNP PMIC Temperature Alarm to DT Schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220608112702.80873-1-krzysztof.kozlowski@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/rcar_gen3_thermal: Improve logging during probeWolfram Sang1-2/+2
When setting up a new board, a plain "Can't register thermal zone" didn't help me much because the thermal zones in DT were all fine. I just had a sensor entry too much in the parent TSC node. Reword the failure/success messages to contain the sensor number to make it easier to understand which sensor is affected. Example output now: rcar_gen3_thermal e6198000.thermal: Sensor 0: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 1: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 2: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 3: Can't register thermal zone Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20220610200500.6727-1-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28MAINTAINERS: add include/dt-bindings/thermal to THERMALLukas Bulwahn1-0/+1
Maintainers of the directory Documentation/devicetree/bindings/thermal are also the maintainers of the corresponding directory include/dt-bindings/thermal. Add the file entry for include/dt-bindings/thermal to the appropriate section in MAINTAINERS. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220613124309.28790-1-lukas.bulwahn@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/devfreq_cooling: Extend the devfreq_cooling_device with opsLukasz Luba1-18/+9
Remove unneeded global variable devfreq_cooling_ops which is used only as a copy pattern. Instead, extend the struct devfreq_cooling_device with the needed ops structure. This also simplifies the allocation/free code during the setup/cleanup. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-5-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling: Update outdated commentsLukasz Luba1-26/+18
The code has moved and left some comments stale. Update them where there is a need. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-4-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling : Refactor thermal_power_cpu_get_power tracingLukasz Luba2-37/+9
Simplify the thermal_power_cpu_get_power trace event by removing complicated cpumask and variable length array. Now the tools parsing trace output don't have to hassle to get this power data. The simplified format version uses 'policy->cpu'. Remove also the 'load' information completely since there is very little value of it in this trace event. To get the CPUs' load (or utilization) there are other dedicated trace hooks in the kernel. This patch also simplifies and speeds-up the main cooling code when that trace event is enabled. Rename the trace event to avoid confusion of tools which parse the trace file. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-3-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling: Use private callback ops for each cooling deviceLukasz Luba1-9/+6
It is very unlikely that one CPU cluster would have the EM and some other won't have it (because EM registration failed or DT lacks needed entry). Although, we should avoid modifying global variable with callbacks anyway. Redesign this and add safety for such situation. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20220613124327.30766-2-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-06-30thermal: intel_tcc_cooling: Add TCC cooling support for RaptorLakeSumeet Pawnikar1-0/+1
Add RaptorLake to the list of processor models supported by the Intel TCC cooling driver. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> [ rjw: Subject edits, new changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-25thermal: int340x: Add Meteor Lake PCI device IDSumeet Pawnikar2-0/+2
Add Meteor Lake PCI ID for processor thermal device. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-24lockdown: also lock down previous kgdb useDaniel Thompson4-3/+87
KGDB and KDB allow read and write access to kernel memory, and thus should be restricted during lockdown. An attacker with access to a serial port (for example, via a hypervisor console, which some cloud vendors provide over the network) could trigger the debugger so it is important that the debugger respect the lockdown mode when/if it is triggered. Fix this by integrating lockdown into kdb's existing permissions mechanism. Unfortunately kgdb does not have any permissions mechanism (although it certainly could be added later) so, for now, kgdb is simply and brutally disabled by immediately exiting the gdb stub without taking any action. For lockdowns established early in the boot (e.g. the normal case) then this should be fine but on systems where kgdb has set breakpoints before the lockdown is enacted than "bad things" will happen. CVE: CVE-2022-21499 Co-developed-by: Stephen Brennan <stephen.s.brennan@oracle.com> Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-05-23smack: Remove redundant assignmentsMichal Orzel1-1/+0
Get rid of redundant assignments which end up in values not being read either because they are overwritten or the function ends. Reported by clang-tidy [deadcode.DeadStores] Signed-off-by: Michal Orzel <michalorzel.eng@gmail.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2022-05-23MAINTAINERS: add KEYS-TRUSTED-CAAMAhmad Fatoum1-0/+9
Create a maintainer entry for CAAM trusted keys in the Linux keyring. Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23doc: trusted-encrypted: describe new CAAM trust sourceAhmad Fatoum1-1/+39
Update documentation for trusted key use with the Cryptographic Acceleration and Assurance Module (CAAM), an IP on NXP SoCs. Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23KEYS: trusted: Introduce support for NXP CAAM-based trusted keysAhmad Fatoum6-2/+109
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core built into many newer i.MX and QorIQ SoCs by NXP. The CAAM does crypto acceleration, hardware number generation and has a blob mechanism for encapsulation/decapsulation of sensitive material. This blob mechanism depends on a device specific random 256-bit One Time Programmable Master Key that is fused in each SoC at manufacturing time. This key is unreadable and can only be used by the CAAM for AES encryption/decryption of user data. This makes it a suitable backend (source) for kernel trusted keys. Previous commits generalized trusted keys to support multiple backends and added an API to access the CAAM blob mechanism. Based on these, provide the necessary glue to use the CAAM for trusted keys. Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23crypto: caam - add in-kernel interface for blob generatorAhmad Fatoum4-0/+289
The NXP Cryptographic Acceleration and Assurance Module (CAAM) can be used to protect user-defined data across system reboot: - When the system is fused and boots into secure state, the master key is a unique never-disclosed device-specific key - random key is encrypted by key derived from master key - data is encrypted using the random key - encrypted data and its encrypted random key are stored alongside - This blob can now be safely stored in non-volatile memory On next power-on: - blob is loaded into CAAM - CAAM writes decrypted data either into memory or key register Add functions to realize encrypting and decrypting into memory alongside the CAAM driver. They will be used in a later commit as a source for the trusted key seal/unseal mechanism. Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23crypto: caam - determine whether CAAM supports blob encap/decapAhmad Fatoum3-3/+19
Depending on SoC variant, a CAAM may be available, but with some futures fused out. The LS1028A (non-E) SoC is one such SoC and while it indicates BLOB support, BLOB operations will ultimately fail, because there is no AES support. Add a new blob_present member to reflect whether both BLOB support and the AES support it depends on is available. These will be used in a follow-up commit to allow blob driver initialization to error out on SoCs without the necessary hardware support instead of failing at runtime with a cryptic caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected. Co-developed-by: Michael Walle <michael@walle.cc> Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23KEYS: trusted: allow use of kernel RNG for key materialAhmad Fatoum4-10/+57
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate the random key material. However, both users and future backends may want to place less trust into the quality of the trust source's random number generator and instead reuse the kernel entropy pool, which can be seeded from multiple entropy sources. Make this possible by adding a new trusted.rng parameter, that will force use of the kernel RNG. In its absence, it's up to the trust source to decide, which random numbers to use, maintaining the existing behavior. Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Acked-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23KEYS: trusted: allow use of TEE as backend without TCG_TPM supportAhmad Fatoum4-17/+42
With recent rework, trusted keys are no longer limited to TPM as trust source. The Kconfig symbol is unchanged however leading to a few issues: - TCG_TPM is required, even if only TEE is to be used - Enabling TCG_TPM, but excluding it from available trusted sources is not possible - TEE=m && TRUSTED_KEYS=y will lead to TEE support being silently dropped, which is not the best user experience Remedy these issues by introducing two new boolean Kconfig symbols: TRUSTED_KEYS_TPM and TRUSTED_KEYS_TEE with the appropriate dependencies. Any new code depending on the TPM trusted key backend in particular or symbols exported by it will now need to explicitly state that it depends on TRUSTED_KEYS && TRUSTED_KEYS_TPM The latter to ensure the dependency is built and the former to ensure it's reachable for module builds. There are no such users yet. Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Andreas Rammhold <andreas@rammhold.de> Tested-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm: Add field upgrade mode support for Infineon TPM2 modulesStefan Mahnke-Hartmann1-1/+5
TPM2_GetCapability with a capability that has the property type value of TPM_PT_TOTAL_COMMANDS returns a zero length list, when an Infineon TPM2 is in field upgrade mode. Since an Infineon TPM2.0 in field upgrade mode returns RC_SUCCESS on TPM2_Startup, the field upgrade mode has to be detected by TPM2_GetCapability. Signed-off-by: Stefan Mahnke-Hartmann <stefan.mahnke-hartmann@infineon.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm: Fix buffer access in tpm2_get_tpm_pt()Stefan Mahnke-Hartmann1-1/+10
Under certain conditions uninitialized memory will be accessed. As described by TCG Trusted Platform Module Library Specification, rev. 1.59 (Part 3: Commands), if a TPM2_GetCapability is received, requesting a capability, the TPM in field upgrade mode may return a zero length list. Check the property count in tpm2_get_tpm_pt(). Fixes: 2ab3241161b3 ("tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf") Cc: stable@vger.kernel.org Signed-off-by: Stefan Mahnke-Hartmann <stefan.mahnke-hartmann@infineon.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23char: tpm: cr50_i2c: Suppress duplicated error message in .remove()Uwe Kleine-König1-2/+2
Returning an error value in an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As tpm_cr50_i2c_remove() emits an error message already and the additional error message by the i2c core doesn't add any useful information, change the return value to zero to suppress this error message. Note that if i2c_clientdata is NULL, there is something really fishy. Assuming no memory corruption happened (then all bets are lost anyhow), tpm_cr50_i2c_remove() is only called after tpm_cr50_i2c_probe() returned successfully. So there was a tpm chip registered before and after tpm_cr50_i2c_remove() its privdata is freed but the associated character device isn't removed. If after that happened userspace accesses the character device it's likely that the freed memory is accessed. For that reason the warning message is made a bit more frightening. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm: cr50: Add new device/vendor ID 0x504a6666Jes B. Klinke1-3/+4
Accept one additional numerical value of DID:VID for next generation Google TPM with new firmware, to be used in future Chromebooks. The TPM with the new firmware has the code name TI50, and is going to use the same interfaces. Signed-off-by: Jes B. Klinke <jbk@chromium.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm: Remove read16/read32/write32 calls from tpm_tis_phy_opsJohannes Holland6-161/+118
Only tpm_tis and tpm_tis_synquacer have a dedicated way to access multiple bytes at once, every other driver will just fall back to read_bytes/write_bytes. Therefore, remove the read16/read32/write32 calls and move their logic to read_bytes/write_bytes. Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Johannes Holland <johannes.holland@infineon.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm: ibmvtpm: Correct the return value in tpm_ibmvtpm_probe()Xiu Jianfeng1-0/+1
Currently it returns zero when CRQ response timed out, it should return an error code instead. Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before proceeding") Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2022-05-23tpm/tpm_ftpm_tee: Return true/false (not 1/0) from bool functionsHaowen Bai1-1/+1
Return boolean values ("true" or "false") instead of 1 or 0 from bool functions. Signed-off-by: Haowen Bai <baihaowen@meizu.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.