Allow the use of a phase function even if it does not exist on
the associated page.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add support for reading and decoding direct format coefficients to
the PMBus core driver. If the new flag PMBUS_USE_COEFFICIENTS_CMD
is set, the driver will use the COEFFICIENTS register together with
the information in the pmbus_sensor_attr structs to initialize
relevant coefficients for the direct mode format.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
[groeck: Initialize ret with -EINVAL in pmbus_init_coefficients()]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Some PMBus chips respond with invalid data when reading the WRITE_PROTECT
register. For such chips, this flag should be set so that the PMBus core
driver doesn't use the WRITE_PROTECT command to determine its behavior.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The :doc:`foo` tag is auto-generated via automarkup.py.
So, use the filename at the sources, instead of :doc:`foo`.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/32b0db7e79a3ed0e817213113c607a1b819e3867.1622898327.git.mchehab+huawei@kernel.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Currently, for Packet Error Checking (PEC) only the controller
is checked for support. This causes problems on the cisco-8000
platform where a SMBUS transaction errors are observed. This is
because PEC has to be enabled only if both controller and
adapter support it.

Added code to check PEC capability for adapter and enable it
only if both controller and adapter supports PEC.
Signed-off-by: Madhava Reddy Siddareddygari <msiddare@cisco.com>
[Upstream from SONiC https://github.com/Azure/sonic-linux-kernel/pull/215]
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20210605052700.541455-1-pmenzel@molgen.mpg.de
[groeck: Dropped unnecessary continuation line]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

As per current logic the wait time per conversion is arouns 430ms
for 512 samples and around 860ms for 1024 samples for 3 channels
considering 140us as the bus voltage and shunt voltage sampling
conversion time.

This waiting time is a lot for the continuous mode and even for
the single shot mode. For continuous mode when moving average is
considered the waiting for CVRF bit is not required and the data
from the previous conversion is sufficuent. As mentioned in the
datasheet the conversion ready bit is provided to help coordinate
single-shot conversions, we can restrict the use to single-shot
mode only.

Also, the conversion time is for the averaged samples, the wait
time for the polling can omit the number of samples consideration.
Signed-off-by: Ninad Malwade <nmalwade@nvidia.com>
Link: https://lore.kernel.org/r/1622789683-30931-1-git-send-email-nmalwade@nvidia.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

If a fan is not running or not connected, of if fan monitoring is disabled,
the fan count register returns a fixed value of 0xffe0. So far this is then
translated to a RPM value larger than 0. Since this is misleading and does
not really make much sense, report a fan RPM of 0 in this situation.

Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <kubernat@cesnet.cz>
Link: https://lore.kernel.org/r/20210526154022.3223012-7-linux@roeck-us.net

Fault bits in MAX31790 are sticky and have to be cleared explicitly.
A write operation into either the 'Target Duty Cycle' register or the
'Target Count' register is necessary to clear a fault.

At the same time, we can never clear cached fault status values before
reading them because the companion fault status for any given fan is
cleared as well when clearing a fault.

Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <kubernat@cesnet.cz>
Link: https://lore.kernel.org/r/20210526154022.3223012-6-linux@roeck-us.net

pwmX_enable supports three possible values:

0: Fan control disabled. Duty cycle is fixed to 0%
1: Fan control enabled, pwm mode. Duty cycle is determined by
   values written into Target Duty Cycle registers.
2: Fan control enabled, rpm mode
   Duty cycle is adjusted such that fan speed matches
   the values in Target Count registers

The current code does not do this; instead, it mixes pwm control
configuration with fan speed monitoring configuration. Worse, it
reports that pwm control would be disabled (pwmX_enable==0) when
it is in fact enabled in pwm mode. Part of the problem may be that
the chip sets the "TACH input enable" bit on its own whenever the
mode bit is set to RPM mode, but that doesn't mean that "TACH input
enable" accurately reflects the pwm mode.

Fix it up and only handle pwm control with the pwmX_enable attributes.
In the documentation, clarify that disabling pwm control (pwmX_enable=0)
sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN
is set together with RPM_MODE.

While at it, only update the configuration register if the configuration
has changed, and only update the cached configuration if updating the
chip configuration was successful.

Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <kubernat@cesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net

The MAX31790 has two sets of registers for pwm duty cycles, one to request
a duty cycle and one to read the actual current duty cycle. Both do not
have to be the same.

When reporting the pwm duty cycle to the user, the actual pwm duty cycle
from pwm duty cycle registers needs to be reported. When setting it, the
pwm target duty cycle needs to be written. Since we don't know the actual
pwm duty cycle after a target pwm duty cycle has been written, set the
valid flag to false to indicate that actual pwm duty cycle should be read
from the chip instead of using cached values.

Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Václav Kubernát <kubernat@ceesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net

Fans 7..12 do not have their own set of configuration registers.
So far the code ignored that and read beyond the end of the configuration
register range to get the tachometer period. This resulted in more or less
random fan speed values for those fans.

The datasheet is quite vague when it comes to defining the tachometer
period for fans 7..12. Experiments confirm that the period is the same
for both fans associated with a given set of configuration registers.

Fixes: 54187ff9 ("hwmon: (max31790) Convert to use new hwmon registration API")
Fixes: 195a4b42 ("hwmon: Driver for Maxim MAX31790")
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Václav Kubernát <kubernat@cesnet.cz>
Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net

Kernel doc for sht4x_read_values() shows 0 on success, 1 on failure but
the return value on success is actually always positive as it is set to
SHT4X_RESPONSE_LENGTH by a successful call to i2c_master_recv().

Miscellanea:

o Update the kernel doc for sht4x_read_values to 0 for success or -ERRNO
o Remove incorrectly used kernel doc /** header for other _read functions
o Typo fix succesfull->successful
o Reverse a test to unindent a block and use goto unlock
o Declare cmd[SHT4X_CMD_LEN] rather than cmd[]

At least for gcc 10.2, object size is reduced a tiny bit.

$ size drivers/hwmon/sht4x.o*
   text	   data	    bss	    dec	    hex	filename
   1752	    404	    256	   2412	    96c	drivers/hwmon/sht4x.o.new
   1825	    404	    256	   2485	    9b5	drivers/hwmon/sht4x.o.old
Signed-off-by: Joe Perches <joe@perches.com>
Link: https://lore.kernel.org/r/60eedce497137eb34448c0c77e01ec9d9c972ad7.camel@perches.com
Reviewed by: Navin Sankar Velliangiri <navin@linumiz.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This patch adds a hwmon driver for the SHT4x Temperature and
Humidity sensor.
Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com>
[groeck: dropped unnecessary empty line and continuation lines]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The entry for mp2888 is missing and it causes the following
'make htmldocs' build warning:

Documentation/hwmon/mp2888.rst: WARNING: document isn't included in any toctree

Add the mp2888 entry.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210521172218.37592-1-festevam@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

adm1272 supports temperature reporting but it is disabled by default.

Tested:
ls temp1_*
temp1_crit           temp1_highest        temp1_max
temp1_crit_alarm     temp1_input          temp1_max_alarm

cat temp1_input
26642
Signed-off-by: Chu Lin <linchuyuan@google.com>
Link: https://lore.kernel.org/r/20210512171043.2433694-1-linchuyuan@google.com
[groeck: Updated subject to reflect correct driver]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Monolithic Power Systems, Inc. (MPS) dual-loop, digital, multi-phase
controller.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210511055619.118104-4-vadimp@nvidia.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add support for mp2888 device from Monolithic Power Systems, Inc. (MPS)
vendor. This is a digital, multi-phase, pulse-width modulation
controller.

This device supports:
- One power rail.
- Programmable Multi-Phase up to 10 Phases.
- PWM-VID Interface
- One pages 0 for telemetry.
- Programmable pins for PMBus Address.
- Built-In EEPROM to Store Custom Configurations.
- Can configured VOUT readout in direct or VID format and allows
  setting of different formats on rails 1 and 2. For VID the following
  protocols are available: VR13 mode with 5-mV DAC; VR13 mode with
  10-mV DAC, IMVP9 mode with 5-mV DAC.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210511055619.118104-3-vadimp@nvidia.com
[groeck: Add MODULE_IMPORT_NS]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Increase maximum number of phases from 8 to 10 to support multi-phase
devices allowing up to 10 phases.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20210511055619.118104-2-vadimp@nvidia.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.

Therefore, remove the error printing here to simplify code and reduce the
binary size.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210511091843.4561-1-thunder.leizhen@huawei.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add support for Flex BMR310, BMR456, BMR457, BMR458, BMR480, BMR490,
BMR491 and BMR492 to the pmbus driver
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210507194023.61138-4-erik.rosen@metormote.com
[groeck: Fixed minor whitespace error]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add documentation for the new pmbus flags PMBUS_WRITE_PROTECTED,
PMBUS_NO_CAPABILITY and PMBUS_READ_STATUS_AFTER_FAILED_CHECK
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210507194023.61138-3-erik.rosen@metormote.com
[groeck: Added newline at end of file]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Some PMBus chips end up in an undefined state when trying to read an
unsupported register. For such chips, it is necessary to reset the
chip pmbus controller to a known state after a failed register check.
This can be done by reading a known register. By setting this flag the
driver will try to read the STATUS register after each failed
register check. This read may fail, but it will put the chip into a
known state.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210507194023.61138-2-erik.rosen@metormote.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Use platform_device_register_simple() instead of
manually calling platform_device_alloc()/platform_device_add().
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20210508131457.12780-5-W_Armin@gmx.deReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use watchdog_set_nowayout() to process param
setting and change param type to bool.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20210508131457.12780-4-W_Armin@gmx.deReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

strlcpy is considered deprecated.
Replace it with strscpy.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20210508131457.12780-3-W_Armin@gmx.deReviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use devm_kzalloc()/devm_watchdog_register() for
watchdog registration since it allows us to remove
the sch56xx_watchdog_data struct from the drivers
own data structs.
Remove sch56xx_watchdog_unregister since devres
takes care of that now.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20210508131457.12780-2-W_Armin@gmx.deReviewed-by: Hans de Goede <hdegoede@redhat.com>
[groeck: Dropped unnecessary return; at end of void function]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use SPI_MODE_X_MASK instead of open coded variant.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210510141331.56736-1-andriy.shevchenko@linux.intel.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Valid Maxim Integrated ACPI device IDs would start with MXIM,
not with MAX1. On top of that, ACPI device IDs reflecting chip names
are almost always invalid.

Remove the invalid ACPI IDs.

Fixes: 04e1e70a ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This reverts commit b58bd4c6.

None of the ACPI IDs introduced with the reverted patch is a valid ACPI
device ID. Any ACPI users of this driver are advised to use PRP0001 and
a devicetree-compatible device identification.

Fixes: b58bd4c6 ("hwmon: (lm70) Add support for ACPI")
Cc: Andrej Picej <andpicej@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

While UTF-8 characters can be used at the Linux documentation,
the best is to use them only when ASCII doesn't offer a good replacement.
So, replace the occurences of the following UTF-8 characters:

	- U+2010 ('‐'): HYPHEN
	- U+2013 ('–'): EN DASH
	- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/ccdd1bf45963a7748188a97c75f667b37bd43d2f.1620641727.git.mchehab+huawei@kernel.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>

The conversion tools used during DocBook/LaTeX/html/Markdown->ReST
conversion and some cut-and-pasted text contain some characters that
aren't easily reachable on standard keyboards and/or could cause
troubles when parsed by the documentation build system.

Replace the occurences of the following characters:

	- U+2010 ('‐'): HYPHEN
	  as ASCII HYPHEN is preferred over U+2010
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/ba8b5122ac9d4918fd966d0eb0a5ca9d89044b04.1621159997.git.mchehab+huawei@kernel.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Document the DT compatible for TI TMP1075 which
is a LM75 compatible sensor.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://lore.kernel.org/r/20210429121150.106804-2-robert.marko@sartura.hrAcked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

TI TMP1075 is a LM75 compatible sensor, so lets
add support for it.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://lore.kernel.org/r/20210429121150.106804-1-robert.marko@sartura.hrSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Update documentation for zl6100 driver and fix dead links to technical
specifications
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210423153329.33457-3-erik.rosen@metormote.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add support for Renesas ZL8802 Dual Channel/Dual Phase PMBus DC/DC
Digital Controller as well as ZLS1003 and ZLS4009 custom DC/DC
controller chips.
Signed-off-by: Erik Rosen <erik.rosen@metormote.com>
Link: https://lore.kernel.org/r/20210423153329.33457-2-erik.rosen@metormote.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

The BPA-RS600 doesn't follow the PMBus spec for linear data.
Specifically it treats the mantissa as an unsigned 11-bit value instead
of a two's complement 11-bit value. At this point it's unclear whether
this only affects Vin or if Pin/Pout1 are affected as well. Erring on
the side of caution only Vin is dealt with here.

Fixes: 15b2703e ("hwmon: (pmbus) Add driver for BluTek BPA-RS600")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20210616034218.25821-1-chris.packham@alliedtelesis.co.nzSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Merge tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

Pull perf tools fixes from Arnaldo Carvalho de Melo:

 - Correct buffer copying when peeking events

 - Sync cpufeatures/disabled-features.h header with the kernel sources

* tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
  tools headers cpufeatures: Sync with the kernel sources
  perf session: Correct buffer copying when peeking events

Pull NFS client bugfixes from Trond Myklebust:
 "Highlights include:

  Stable fixes:

   - Fix use-after-free in nfs4_init_client()

  Bugfixes:

   - Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()

   - Fix second deadlock in nfs4_evict_inode()

   - nfs4_proc_set_acl should not change the value of NFS_CAP_UIDGID_NOMAP

   - Fix setting of the NFS_CAP_SECURITY_LABEL capability"

* tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  NFSv4: Fix second deadlock in nfs4_evict_inode()
  NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()
  NFS: FMODE_READ and friends are C macros, not enum types
  NFS: Fix a potential NULL dereference in nfs_get_client()
  NFS: Fix use-after-free in nfs4_init_client()
  NFS: Ensure the NFS_CAP_SECURITY_LABEL capability is set when appropriate
  NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.

Pull SCSI fixes from James Bottomley:
 "Four reasonably small fixes to the core for scsi host allocation
  failure paths.

  The root problem is that we're not freeing the memory allocated by
  dev_set_name(), which involves a rejig of may of the free on error
  paths to do put_device() instead of kfree which, in turn, has several
  other knock on ramifications and inspection turned up a few other
  lurking bugs"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: core: Only put parent device if host state differs from SHOST_CREATED
  scsi: core: Put .shost_dev in failure path if host state changes to RUNNING
  scsi: core: Fix failure handling of scsi_add_host_with_dma()
  scsi: core: Fix error handling of scsi_host_alloc()