The overwhelming bulk of this pull request is a change from Uwe
Kleine-König which changes the return type of the remove() function to
void as part of some wider work he's doing to do this for all bus types,
causing updates to most SPI device drivers. The branch with that on has
been cross merged with a couple of other trees which added new SPI
drivers this cycle, I'm not expecting any build issues resulting from
the change.
Otherwise it's been a relatively quiet release with some new device
support, a few minor features and the welcome completion of the
conversion of the subsystem to use GPIO descriptors rather than numbers:
- Change return type of remove() to void.
- Completion of the conversion of SPI controller drivers to use GPIO
descriptors rather than numbers.
- Quite a few DT schema conversions.
- Support for multiple SPI devices on a bus in ACPI systems.
- Big overhaul of the PXA2xx SPI driver.
- Support for AMD AMDI0062, Intel Raptor Lake, Mediatek MT7986 and
MT8186, nVidia Tegra210 and Tegra234, Renesas RZ/V2L, Tesla FSD and
Sunplus SP7021.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmI4b+8ACgkQJNaLcl1U
h9AB+Qf/WhPzDSCdhK1repnSmEpRNs/J6hItmY2H6pTQaWALpfTB0+p1Nb5tAotg
fHbu6a2AsiiwWt+tDal44GFYhS0CDSOT4hqgLV8msyDDPPJqqr7A2dbu7YrCjTVI
TgNZNwxW7c2LgqBXR9GV7NPWYoxYxveoYh+L+05MSuSQxSOvPl6LUZiZPnPufQM6
dCpEh19atrtasFg3rFnslWBd2C3h8hb6YT7vUZs9gxhg3FvSgpYQwzz5SfFgHXK6
Rg07m8fDTSjf2qo1C4pc/d1Ni1xBe7aHKMtjtR3jJ4q8QqiawfCcvvOep/Iaec1+
s3qnDthohWMJoF1W6ERf3HiAgNIfhg==
=4tlR
-----END PGP SIGNATURE-----
Merge tag 'spi-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"The overwhelming bulk of this pull request is a change from Uwe
Kleine-König which changes the return type of the remove() function to
void as part of some wider work he's doing to do this for all bus
types, causing updates to most SPI device drivers. The branch with
that on has been cross merged with a couple of other trees which added
new SPI drivers this cycle, I'm not expecting any build issues
resulting from the change.
Otherwise it's been a relatively quiet release with some new device
support, a few minor features and the welcome completion of the
conversion of the subsystem to use GPIO descriptors rather than
numbers:
- Change return type of remove() to void.
- Completion of the conversion of SPI controller drivers to use GPIO
descriptors rather than numbers.
- Quite a few DT schema conversions.
- Support for multiple SPI devices on a bus in ACPI systems.
- Big overhaul of the PXA2xx SPI driver.
- Support for AMD AMDI0062, Intel Raptor Lake, Mediatek MT7986 and
MT8186, nVidia Tegra210 and Tegra234, Renesas RZ/V2L, Tesla FSD and
Sunplus SP7021"
[ And this is obviously where that spi change that snuck into the
regulator tree _should_ have been :^]
* tag 'spi-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (124 commits)
spi: fsi: Implement a timeout for polling status
spi: Fix erroneous sgs value with min_t()
spi: tegra20: Use of_device_get_match_data()
spi: mediatek: add ipm design support for MT7986
spi: Add compatible for MT7986
spi: sun4i: fix typos in comments
spi: mediatek: support tick_delay without enhance_timing
spi: Update clock-names property for arm pl022
spi: rockchip-sfc: fix platform_get_irq.cocci warning
spi: s3c64xx: Add spi port configuration for Tesla FSD SoC
spi: dt-bindings: samsung: Add fsd spi compatible
spi: topcliff-pch: Prevent usage of potentially stale DMA device
spi: tegra210-quad: combined sequence mode
spi: tegra210-quad: add acpi support
spi: npcm-fiu: Fix typo ("npxm")
spi: Fix Tegra QSPI example
spi: qup: replace spin_lock_irqsave by spin_lock in hard IRQ
spi: cadence: fix platform_get_irq.cocci warning
spi: Update NXP Flexspi maintainer details
dt-bindings: mfd: maxim,max77802: Convert to dtschema
...
Sadly, while firmware 1.5 fixed temperature labels on my
Inspiron 3505, it also caused fan type calls to take
ca. 4 seconds with the fan being at full speed.
Fix the resulting delays by adding the model to the
blacklist.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220318183408.13286-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If there is an input undervoltage fault, reported in STATUS_INPUT
command response, there is quite likely a "Unit Off For Insufficient
Input Voltage" condition as well.
Add a constant for bit 3 of STATUS_INPUT. Update the Vin limit
attributes to include both bits in the mask for clearing faults.
If an input undervoltage fault occurs, causing a unit off for
insufficient input voltage, but the unit is off bit is not cleared, the
STATUS_WORD will not be updated to clear the input fault condition.
Including the unit is off bit (bit 3) allows for the input fault
condition to completely clear.
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Link: https://lore.kernel.org/r/20220317232123.2103592-1-bjwyman@gmail.com
Fixes: b4ce237b7f ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers")
[groeck: Dropped unnecessary ()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use of_device_get_match_data() to simplify the code.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Link: https://lore.kernel.org/r/20220315023412.2118415-1-chi.minghao@zte.com.cn
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for Texas Instruments TMP464 and TMP468 temperature sensor
ICs.
TI's TMP464 is an I2C temperature sensor chip. This chip is similar
to TI's TMP421 chip, but with 16bit-wide registers (instead of
8bit-wide registers). The chip has one local sensor and four remote
sensors. TMP468 is similar to TMP464 but has one local and eight
remote sensors.
Originally-from: Agathe Porte <agathe.porte@nokia.com>
Cc: Agathe Porte <agathe.porte@nokia.com>
Cc: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Tested-by: Agathe Porte <agathe.porte@nokia.com>
Link: https://lore.kernel.org/r/20220222223610.23098-2-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Current driver assume PWR_AVG and VI_AVG as 1 by default, and user needs
to set sample averaging via sysfs manually.
This patch parses the properties "adi,power-sample-average" and
"adi,volt-curr-sample-average" from device tree, and setting sample
averaging during probe. Input value must be one of value in the
list [1, 2, 4, 8, 16, 32, 64, 128].
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
Link: https://lore.kernel.org/r/20220302123817.27025-2-potin.lai@quantatw.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for another Infineon Multi-phase controller chip. The
xdpe11280 uses linear instead of vid data format for VOUT. Detect
VOUT_MODE format during identification and skip the xdpe122 related
adaptions in case it is linear.
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Link: https://lore.kernel.org/r/fa6a4b636a05ecb337d132824efca2545188a2a2.1646214248.git.sylv@sylv.io
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Extend aquacomputer_d5next driver to expose hardware temperature sensors
of the Aquacomputer Farbwerk 360 RGB controller, which communicates through
a proprietary USB HID protocol.
Four temperature sensors are available. Additionally, serial number and
firmware version are exposed through debugfs.
This driver has been tested on x86_64.
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
After doing some research, it seems that Fujitsu's
hardware monitoring solution exports data describing
which temperature sensors affect which fans, similar
to the data in fan_source of the ftsteutates driver.
Writing 0 into these registers forces the fans to
full speed.
Export this data with standard attributes.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220224061210.16452-3-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
pwm[1-*]_auto_channels_temp is documented as an official
hwmon sysfs attribute, yet there is no support for it in
the new with_info-API. Fix that.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220224061210.16452-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The TMP125 is a 2 degree Celsius accurate Digital
Temperature Sensor with a SPI interface.
The temperature register is a 16-bit, read-only register.
The MSB (Bit 15) is a leading zero and never set. Bits 14
to 5 are the 1+9 temperature data bits in a two's
complement format. Bits 4 to 0 are useless copies of
Bit 5 value and therefore ignored.
This was tested on a Aerohive HiveAP-350.
Bonus: lm70 supports TMP122/TMP124 as well.
I added them to the Kconfig module description.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://lore.kernel.org/r/43b19cbd4e7f51e9509e561b02b5d8d0e7079fac.1645175187.git.chunkeey@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Export the power caps data for the soft minimum power cap through hwmon.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220215151022.7498-5-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add regulator supply into PWBUS_REGULATOR macro. This makes it optional
to define a vin-supply in DT. Not defining a supply will add a dummy
regulator supply instead and only cause the following debug output:
```
Looking up vin-supply property in node [...] failed
```
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Link: https://lore.kernel.org/r/58f2ff7b90233fad3d7ae2e9d66d5192e2c1ac01.1645437439.git.sylv@sylv.io
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On the Dell Inspiron 3505, three temperature sensors are
available through the SMM interface. However since they
do not have an associated type, they are not detected.
Probe for those sensors in case no type was detected.
_i8k_get_temp() is used instead of i8k_get_temp()
since it is sometimes faster and the result is
easier to check (no -ENODATA) since we do not
care about the actual temp value.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220215191113.16640-5-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Right now, we only use bits 0 to 7 of the fan/temp sensor number
by doing number & 0xff. Passing the value as a u8 makes this
step unnecessary. Also add checks to the ioctl handler since
users might get confused when passing 0x00000101 does the same
as passing 0x00000001.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20220215191113.16640-4-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When enabling said module parameter, the driver ignores
all feature blacklists on relevant models, which has the
potential for strange side effects. Also there seems to
be a slight chance for unsupported devices to behave
badly when probed for features.
In such cases, the kernel should be tainted to inform
people that these issues might have been caused by
the dell_smm_hwmon driver with "force" enabled.
Also reword the parameter description to remind users
that enabling "force" also enables blacklisted features.
Tested on a Dell Inspiron 3505.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20220215191113.16640-8-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add sysfs entries for DVFS due to a VRM Vdd over-temperature condition,
and add the GPU throttling condition bits (such that if bit 1 is set,
GPU1 is throttling).
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220215151022.7498-4-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
BMC control applications need to check the OCC mode returned by the
OCC poll response, so export it in sysfs with the other OCC-specific
data.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220215151022.7498-3-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
BMC control applications need to check the Idle Power Saver status
byte returned by the OCC poll response, so export it in sysfs with
the other OCC-specific data.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220215151022.7498-2-eajames@linux.ibm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Remove the call to dev_info() from the board detection function, which
is called from probe(), not only to be in line with hwmon driver rules, but
also because the message duplicates the error code returned from probe()
for that case (ENODEV).
Changes in:
- v2: add missing newline (style).
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220217194318.2960472-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
While these chips aren't strictly advertised as voltage regulators per
se, they (aside from the lm25056) support the PMBus OPERATION command
to enable and disable their outputs and have status bits for reporting
various warnings and faults, and can hence usefully support all the
pmbus_regulator_ops operations.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20220219000742.20126-1-zev@bewilderbeest.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The various PMBus status bits don't all map perfectly to the more
limited set of REGULATOR_ERROR_* flags, but there's a reasonable
number where they correspond well enough.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20220219000359.19985-1-zev@bewilderbeest.net
[groeck: Added missing locking]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reading DSDT code for ASUS X470-based boards (the ones served by the
asus_wmi_Sensors driver), where ASUS put hardware monitoring functions
into the WMI code, reveals that fan and current sensors data is
unsigned. For the current sensor that was confirmed by a user who showed
high enough current value for overflow.
Thus let's assume that the signedness of the sensors is determined by its
type and that only temperature ones provide signed numbers.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220211164855.265698-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Adds thermal_cooling device support to the tc654/tc655
driver. This make it possible to integrate it into a
device-tree supported thermal-zone node as a
cooling device.
I have been using this patch as part of the Netgear WNDR4700
Centria NAS Router support within OpenWrt since 2016.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://lore.kernel.org/r/20220213004733.2421193-1-chunkeey@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It is not the laptops, but the /proc/i8k interface that is legacy (or so
I think was the intention of the help text author). The old description
was confusing, fix this.
The phrase "Say Y if you intend to run this kernel on old Dell laptops
or want to use userspace package i8kutils." was introduced in 2015, in
commit 039ae58503 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k")
I think that "old laptops" was about hotkey and Fn key support - this
driver in the 2.4 kernels' era apparently had these capabilities
(see: https://github.com/vitorafsr/i8kutils , description of
"repeat_rate" kernel module parameter).
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Pali Rohár <pali@kernel.org>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Gross <markgross@kernel.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220212125654.357408-2-mat.jonczyk@o2.pl
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In Kconfig, inside the "Processor type and features" menu, there is
the CONFIG_I8K option: "Dell i8k legacy laptop support". This is
very confusing - enabling CONFIG_I8K is not required for the kernel to
support old Dell laptops. This option is specific to the dell-smm-hwmon
driver, which mostly exports some hardware monitoring information and
allows the user to change fan speed.
This option is misplaced, so move CONFIG_I8K to drivers/hwmon/Kconfig,
where it belongs.
Also, modify the dependency order - change
select SENSORS_DELL_SMM
to
depends on SENSORS_DELL_SMM
as it is just a configuration option of dell-smm-hwmon. This includes
changing the option type from tristate to bool. It was tristate because
it could select CONFIG_SENSORS_DELL_SMM=m .
When running "make oldconfig" on configurations with
CONFIG_SENSORS_DELL_SMM enabled , this change will result in an
additional question (which could be printed several times during
bisecting). I think that tidying up the configuration is worth it,
though.
Next patch tweaks the description of CONFIG_I8K.
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Pali Rohár <pali@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Mark Gross <markgross@kernel.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220212125654.357408-1-mat.jonczyk@o2.pl
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
A user discovered [1] the CPU Core voltage sensor, which spans 2
registers and provides output in mV. Althroug the discovery was made
with a X470 chipset, the sensor is present in X570 (tested with C8H).
For now simply add it to each board with the CPU current sensor present.
[1] https://github.com/zeule/asus-ec-sensors/issues/12
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Denis Pauk <pauk.denis@gmail.com>
Link: https://lore.kernel.org/r/20220208094244.1106312-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Describe the only available channel, implement read, write
and is_visible callbacks.
Also, pass name to core driver for the i2c device so that
it can be used to register hwmon device.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20211221215841.2641417-4-demonsingur@gmail.com
[groeck: Adjusted to use regmap]
Tested-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Using regmap lets us use the regmap subsystem for SPI vs. I2C register
accesses. It lets us hide access differences in backend code and lets
the common code just access registers without knowing their size.
We can also use regmap for register caching.
Tested-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Temperature sensor readings are signed, which is hinted by their blank
value (oxd8, 216 as unsigned and -40 as signed). T_Sensor, Crosshair
VIII Hero, and a freezer were used to confirm that.
Here we read fan sensors as signed too, because with their typical
values and 2-byte width, I can't tell a difference between signed and
unsigned, as I don't have a high speed chipset fan.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220204163045.576903-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
There is no such struct as "asus_ec_sensors", it was supposed to be
"ec_sensors_data". This typo does not affect either build or runtime.
Fixes: c4b1687d6897 ("hwmon: (asus-ec-sensors) add driver for ASUS EC")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220205092015.GA612@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Recently 'cur_state' user space 'sysfs' interface 'sysfs' has been
deprecated. This interface is used in Nvidia systems for setting fan
speed limit. Currently fan speed limit is set from the user space by
setting 'sysfs' 'cur_state' attribute to 'max_state + n', where 'n' is
required limit, for example: 15 for 50% speed limit, 20 for full fan
speed enforcement.
The purpose of this feature is to provides ability to limit fan speed
according to some system wise considerations, like absence of some
replaceable units (PSU or line cards), high system ambient temperature,
unreliable transceivers temperature sensing or some other factors which
indirectly impacts system's airflow.
The motivation is to support fan low limit feature through 'hwmon'
interface.
Use 'hwmon' 'pwm' attribute for setting low limit for fan speed in
case 'thermal' subsystem is configured in kernel. In this case setting
fan speed through 'hwmon' will never let the 'thermal' subsystem to
select a lower duty cycle than the duty cycle selected with the 'pwm'
attribute.
From other side, fan speed is to be updated in hardware through 'pwm'
only in case the requested fan speed is above last speed set by
'thermal' subsystem, otherwise requested fan speed will be just stored
with no PWM update.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220126141825.13545-1-vadimp@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This driver provides the same data as the asus_wmi_ec_sensors driver
(and gets it from the same source) but does not use WMI, polling
the ACPI EC directly.
That provides two enhancements: sensor reading became quicker (on some
systems or kernel configuration it took almost a full second to read
all the sensors, that transfers less than 15 bytes of data), the driver
became more flexible. The driver now relies on ACPI mutex to lock access
to the EC in the same way as the WMI code does.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220124015658.687309-2-eugene.shalygin@gmail.com
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Denis Pauk <pauk.denis@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the watchdog was already enabled by the BIOS after booting, the
watchdog infrastructure needs to regularly send keepalives to
prevent a unexpected reset.
WDOG_ACTIVE only serves as an status indicator for userspace,
we want to use WDOG_HW_RUNNING instead.
Since my Fujitsu Esprimo P720 does not support the watchdog,
this change is compile-tested only.
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: fb551405c0 (watchdog: sch56xx: Use watchdog core)
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220131211935.3656-5-W_Armin@gmx.de
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
msleep(1) will often sleep more than 20ms, slowing down sensor
and watchdog reads/writes. Use usleep_range() as recommended
in timers-howto.rst to fix that.
Tested on a Fujitsu Esprimo P720.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220131211935.3656-4-W_Armin@gmx.de
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
