BMC/Intel-BMC/linux.git/Documentation, branch dev-5.8-intel

hwmon: peci: add energy sensor to peci-cpupower

2021-01-05T11:03:14+00:00

Add support for energy consumption of CPU package sensor. Energy is reported in micro Joules and exposed under energyN_input file. Change-Id: I853e9ba8f7223a3cbfbbdf82719aee78999486da Signed-off-by: Olender, Agata

Merge v5.8.17, commit '6d07b544ce203a684d9ca52635dcf2f4fc89b7d4' into dev-5.8-intel

2020-11-05T01:31:53+00:00

Merge tag 'v5.8.17' into dev-5.8

2020-10-30T02:37:00+00:00

This is the 5.8.17 stable release Signed-off-by: Joel Stanley

dt-bindings: crypto: Specify that allwinner, sun8i-a33-crypto needs reset

2020-10-29T09:08:13+00:00

[ Upstream commit 884d1a334ae8130fabede56f59b224619ad6bca4 ] When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset. Furthermore, there are no need to use items to list only one compatible in compatible list. Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS") Signed-off-by: Corentin Labbe Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20200907175437.4464-1-clabbe.montjoie@gmail.com Signed-off-by: Sasha Levin

netsec: ignore 'phy-mode' device property on ACPI systems

2020-10-29T09:08:10+00:00

[ Upstream commit acd7aaf51b20263a7e62d2a26569988c63bdd3d8 ] Since commit bbc4d71d63549bc ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the Realtek PHY driver will override any TX/RX delay set by hardware straps if the phy-mode device property does not match. This is causing problems on SynQuacer based platforms (the only SoC that incorporates the netsec hardware), since many were built with this Realtek PHY, and shipped with firmware that defines the phy-mode as 'rgmii', even though the PHY is configured for TX and RX delay using pull-ups. From the driver's perspective, we should not make any assumptions in the general case that the PHY hardware does not require any initial configuration. However, the situation is slightly different for ACPI boot, since it implies rich firmware with AML abstractions to handle hardware details that are not exposed to the OS. So in the ACPI case, it is reasonable to assume that the PHY comes up in the right mode, regardless of whether the mode is set by straps, by boot time firmware or by AML executed by the ACPI interpreter. So let's ignore the 'phy-mode' device property when probing the netsec driver in ACPI mode, and hardcode the mode to PHY_INTERFACE_MODE_NA, which should work with any PHY provided that it is configured by the time the driver attaches to it. While at it, document that omitting the mode is permitted for DT probing as well, by setting the phy-mode DT property to the empty string. Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") Signed-off-by: Ard Biesheuvel Reviewed-by: Ilias Apalodimas Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20201018163625.2392-1-ardb@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

x86/fpu: Allow multiple bits in clearcpuid= parameter

2020-10-29T09:07:14+00:00

[ Upstream commit 0a4bb5e5507a585532cc413125b921c8546fc39f ] Commit 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") changed clearcpuid parsing from __setup() to cmdline_find_option(). While the __setup() function would have been called for each clearcpuid= parameter on the command line, cmdline_find_option() will only return the last one, so the change effectively made it impossible to disable more than one bit. Allow a comma-separated list of bit numbers as the argument for clearcpuid to allow multiple bits to be disabled again. Log the bits being disabled for informational purposes. Also fix the check on the return value of cmdline_find_option(). It returns -1 when the option is not found, so testing as a boolean is incorrect. Fixes: 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument") Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200907213919.2423441-1-nivedita@alum.mit.edu Signed-off-by: Sasha Levin

icmp: randomize the global rate limiter

2020-10-29T09:07:05+00:00

[ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ] Keyu Man reported that the ICMP rate limiter could be used by attackers to get useful signal. Details will be provided in an upcoming academic publication. Our solution is to add some noise, so that the attackers no longer can get help from the predictable token bucket limiter. Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reported-by: Keyu Man Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

hwmon: (pmbus/core) Add support for rated attributes

2020-10-09T21:47:19+00:00

Adding implementation for new attributes (rated_min/rated_max) to cover PMBus specification about rated values reporting: MFR_VIN_MIN, MFR_VIN_MAX, MFR_IIN_MAX, MFR_PIN_MAX, MFR_VOUT_MIN, MFR_VOUT_MAX, MFR_IOUT_MAX, MFR_POUT_MAX, MFR_MAX_TEMP_1/2/3. Tested with OpenBMC stack. All rated attributes were available and reported correct values. Signed-off-by: Zbigniew Lukwinski

docs: hwmon: Add attributes to report rated values

2020-10-09T21:47:19+00:00

New attributes (rated_min/rated_max) are being added the hwmon ABI. They are needed to cover rated values documented by PMBus specification: PMBus Power System Mgt Protocol Specification - Part II – Revision 1.3.1, chapters: 22.3.1 - 22.3.10, 22.3.15 Signed-off-by: Zbigniew Lukwinski

hwmon: peci: dimmpower implementation

2020-10-09T21:47:19+00:00

1. Peci dimmpower module implementation. 2. Enable DIMM avarage power, power limit, power limit max setting, power limit min setting reading and expose them under power1_avarage, power1_cap, power1_cap_max, power1_cap_min in sysfs. 3. Enable DIMM power limit writing through power1_cap. Tested: * on WilsonCity platform, * power1_avarage, power1_cap, power1_cap_max and power1_cap_min work as expected Signed-off-by: Zbigniew Lukwinski