| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This fixes symbol access errors and taint when built as a module
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The MAX31785(A) has shown erratic behaviour across multiple system
designs, unexpectedly clock stretching and NAKing transactions. Perform
a one-shot retry if necessary for all access attempts.
OpenBMC-Staging-Count: 2
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: George Keishing <gkeishin@in.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The driver may have overridden the pmbus_read_byte_data() callback, so
make sure we use that to achieve expected behaviour.
This helps in the MAX31785 case where we may need to perform a one-shot
retry of transfers in the face of a failure.
OpenBMC-Staging-Count: 2
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Eddie James <eajames@linux.vnet.ibm.com>
Tested-by: George Keishing <gkeishin@in.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Work around the shonky behaviour seen with the MAX31785 where we fail
to set the page register in some circumstances.
There's no real elegant way to do this. We can propagate the error up,
but that forces us to retry the operation way up the call tree in any
number of places. It also forces callers to split out pmbus_set_page()
from the pmbus_{read,write}_{byte,word}_data() functions in order to
differentiate between a failure to set the page and a failure to read a
register (that might not exist, in which case an error is anticiptated).
OpenBMC-Staging-Count: 2
Cc: Eddie James <eajames@linux.vnet.ibm.com>
Cc: Matt Spinler <mspinler@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Eddie James <eajames@linux.vnet.ibm.com>
Tested-by: George Keishing <gkeishin@in.ibm.com>
|
|
|
|
|
|
| |
OpenBMC-Staging-Count: 2
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: George Keishing <gkeishin@in.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The for loop without ++i cause either infinite loop or random memory
access issues, e.g. unable to handle kernel NULL or kernel oops in
snprintf.
Fix it by adding ++i in the for loop.
OpenBMC-Staging-Count: 1
Signed-off-by: Lei YU <mine260309@gmail.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose the gpiN_fault fields of mfr_status as individual debugfs
attributes. This provides a way for users to be easily notified of gpi
faults. Also provide the whole mfr_status register in debugfs.
Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 72816cb06e7153c22aed8776949f558b635aa2c0)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a struct gpio_chip and define some methods so that this device's
I/O can be accessed via /sys/class/gpio.
Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit ca781fb7fd95ba90eda6936a27fc1e3202f99d6a)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Power values were overflowing INT_MAX when being converted to
microwatts, even though the storage was sufficiently large (unsigned 64
bit). Change literals to unsigned long long. Also change tmep storage to u32
to avoid overflows at 65000 millidegrees.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ir35221 datasheet describes specific scaling factors for a number of
commands which the current driver applies when reading.
However now that the ir35221 has been tested on machines with more
easily verifiable readings these descriptions have turned out to be
superfluous and reading each command according to the linear format is
sufficient.
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 08f411bcb5fbd96c53d4535e0526f70b971ee5d5)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we received the following warning:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.13.16-00190-g78a200cb21ab #2393
Hardware name: Generic DT based system
...
[<8005ac18>] (lock_acquire) from [<804c0dcc>] (_raw_spin_lock_irqsave+0x60/0x74)
[<804c0dcc>] (_raw_spin_lock_irqsave) from [<8035ecc0>] (p9_sbe_occ_send_cmd+0x30/0x100)
[<8035ecc0>] (p9_sbe_occ_send_cmd) from [<8035c9ac>] (occ_poll+0x60/0x210)
[<8035c9ac>] (occ_poll) from [<8035d9c8>] (occ_setup+0x50/0x1260)
[<8035d9c8>] (occ_setup) from [<8035edf0>] (p9_sbe_occ_probe+0x60/0x7c)
[<8035edf0>] (p9_sbe_occ_probe) from [<802b97c8>] (platform_drv_probe+0x60/0xbc)
[<802b97c8>] (platform_drv_probe) from [<802b78f0>] (driver_probe_device+0x2e4/0x450)
Provide a static key to lockdep to help with this dynamically allocated mutex.
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hwmon occ implementation allocates GFP_KERNEL memory in
occ_open_common(), therefore we cannot call it under a spinlock as it
may sleep. Compiling with lock debugging enabled gives us the following
warning:
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2879 lockdep_trace_alloc+0xf0/0x124
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
CPU: 0 PID: 1 Comm: swapper Not tainted 4.10.17-00526-g1cbacc6bd3a1 #2334
Hardware name: ASpeed SoC
[<80010eec>] (unwind_backtrace) from [<8000e664>] (show_stack+0x20/0x24)
[<8000e664>] (show_stack) from [<80249160>] (dump_stack+0x20/0x28)
[<80249160>] (dump_stack) from [<8001d3a0>] (__warn+0xe0/0x108)
[<8001d3a0>] (__warn) from [<8001d40c>] (warn_slowpath_fmt+0x44/0x4c)
[<8001d40c>] (warn_slowpath_fmt) from [<8005d2cc>] (lockdep_trace_alloc+0xf0/0x124)
[<8005d2cc>] (lockdep_trace_alloc) from [<8012bb1c>] (kmem_cache_alloc_trace+0x3c/0x284)
[<8012bb1c>] (kmem_cache_alloc_trace) from [<8034fa2c>] (occ_open_common+0x30/0xac)
[<8034fa2c>] (occ_open_common) from [<80350bac>] (occ_drv_open+0x24/0x28)
[<80350bac>] (occ_drv_open) from [<803638fc>] (p9_sbe_occ_send_cmd+0x44/0x13c)
[<803638fc>] (p9_sbe_occ_send_cmd) from [<803615b8>] (occ_poll+0x6c/0x1c0)
[<803615b8>] (occ_poll) from [<80363a84>] (p9_sbe_occ_probe+0x90/0x178)
[<80363a84>] (p9_sbe_occ_probe) from [<802b9850>] (platform_drv_probe+0x60/0xbc)
Avoid the warning (or the need for GFP_ATOMIC) and allow for reduced
system latency by using a mutex instead. Mutual exclusion is the only
requirement, we do not need to block pre-emption.
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Improve code clarity (and searchability) by renaming the lock to
client_lock. The end result is it is easier to search for uses in the
source file.
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Using 'occ' as the context variable caused naming conflicts in some
instances. Instead use 'ctx' which should make it clear it's the
associated drvdata and make way for calling other object pointers 'occ'.
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
| |
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
This power supply device doesn't correctly manage it's own fault led.
Add an led class device and register it so that userspace can manage
power supply fault led as necessary.
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit ef9e1cdf419a37065364edb47bd6dd9aee1bcb7d)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This power supply device regularly fails to read VOUT_MODE due to the
CML bit going high. This results in an incorrect exponent used for the
voltage data, and therefore the power supply reports incorrect voltage.
Work around this by setting the pmbus flag to skip the CML check.
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Fixes: f69316d62c70 ("hwmon: (pmbus) Add IBM Common Form Factor (CFF) ...")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 4471879acf926221231fe68ebc30f9cad0d7f7c8)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add debugfs entries for additional power supply data, including part
number, serial number, FRU number, firmware revision, ccin, and the
input history of the power supply. The input history is 10 minutes of
input power data in the form of twenty 30-second packets. Each packet
contains average and maximum power for that 30 second period.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
[groeck: Fixed endianness problem]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit d6bb645a1704cba3884bf03d5a8bd86915b5e650)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Pmbus client drivers, if they want to use debugfs, should use the same
root directory as the pmbus debugfs entries are using. Therefore, export
the device dentry for the pmbus client.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit eb6489b696ad22a8464e20502e18014434b4b0ea)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the OCC driver parses the device tree and creates platform
devices for each child node found there. This was used to probe the
OCC hwmon devices. However, this doesn't make sense since hmwon isn't a
device. Therefore, just directly create a platform device for each OCC
for the hwmon driver to probe.
OpenBMC-Staging-Count: 1
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Smatch reports:
drivers/hwmon/w83773g.c:105
get_fault() warn: shift has higher precedence than mask
Code analysis shows that the code is indeed wrong.
Fix it, and while we are at it, drop unnecessary typecast.
OpenBMC-Staging-Count: 2
Fixes: 86a10c802362 ("hwmon: Add W83773G driver")
Cc: Lei YU <mine260309@gmail.com>
Reviewed-by: Lei YU <mine260309@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.
Note that it does not reasset the reset, as users may not wish for the
PWM unit to stop working when the driver is removed.
OpenBMC-Staging-Count: 1
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
| |
Sort the headers in preperation for future changes.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 54b943e69691329805349440b157b36e34051a57)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous value reduced the time required to determine
the fan value, however, it's also used as the final timeout
mechanism. The prevous value would work for any fan speed
greater than around 3k RPM. This increased value, lets the fan
speeds return quickly but will wait longer to handle speeds below 3k
RPM.
Testing: this value was determined through experimentation on the ast2400
on the Quanta-q71l. This configurations runs 8 fans attached to the
controller.
Signed-off-by: Patrick Venture <venture@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 762b1e88801357770889d013c5d20fe110d1f456)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support in aspeed-pwm-tacho driver for cooling device creation.
This cooling device could be bound to a thermal zone
for the thermal control. Device will appear in /sys/class/thermal
folder as cooling_deviceX. Then it could be bound to particular
thermal zones. Allow specification of the cooling levels
vector - PWM duty cycle values in a range from 0 to 255
which correspond to thermal cooling states.
Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit f198907d2ff6db9541863764576aaf3bc9f58ec0)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
| |
Nuvoton W83773G is a hardware monitor IC providing one local
temperature and two remote temperature sensors.
OpenBMC-Staging-Count: 1
Signed-off-by: Lei YU <mine260309@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of i2c_smbus_xfer_emulated() included in the driver.
Further, to expose the second rotor tachometer value to userspace the
values are exposed through virtual pages. We re-route accesses to
FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on pages 23-28 (not defined by the
hardware) to the same registers on pages 0-5, and with the latter command we
extract the value from the second word of the four-byte response.
* The documentation recommends the slower rotor be associated with
TACHSEL=0, which corresponds to the first word of the response. The TACHSEL=0
measurement is used by the controller's closed-loop fan management to judge
target fan rate.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller, which
extends the READ_FAN_SPEED_1 PMBus register from two to four bytes to support
tach readings for both rotors of a dual rotor fan. This extended register
contains two word-sized values, one reporting the rate of the fastest rotor,
the other the rate of the slowest. The concept of virtual pages aids this
situation by mapping the page number onto the value to be selected from the
vectored result.
We should not try to set virtual pages on the device as such a page explicitly
doesn't exist; add a flag so we can avoid doing so.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation makes use of the new fan control virtual registers exposed
by the pmbus core. It mixes use of the default implementations with some
overrides via the read/write handlers to handle FAN_COMMAND_1 on the MAX31785,
whose definition breaks the value range into various control bands dependent on
RPM or PWM mode.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
Fans in a PMBus device are driven by the configuration of two registers,
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The unit of FAN_COMMAND_x is dependent on the
operational fan mode, RPM or PWM percent duty, as determined by the
corresponding configuration in FAN_CONFIG_x_y.
The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
FAN_COMMAND_x is implemented with the addition of virtual registers to
facilitate the necessary side-effects of each access:
1. PMBUS_VIRT_FAN_TARGET_x
2. PMBUS_VIRT_PWM_x
3. PMBUS_VIRT_PWM_ENABLE_x
Some complexity arises with the fanX_target and pwmX attributes both mapping
onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and
RPM, so we can't display values in either attribute in terms of the other
(which in my mind is the intuitive, if impossible, behaviour). This problem
also affects the pwmX_enable attribute which allows userspace to switch between
full speed, manual PWM and a number of automatic control modes, possibly
including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to
reach a RPM target, the behaviour of fanX_target).
The next most intuitive behaviour is for fanX_target and pwmX to simply be
independent, to retain their most recently set value even if that value is not
active on the hardware (due to switching to the alternative control mode). This
property of retaining the value independent of the hardware state has useful
results for both userspace and the kernel: Userspace always sees a sensible
value in the attribute (the last thing it was set to, as opposed to 0 or
receiving an error on read), and the kernel can use the attributes as a value
cache. This latter point eases the implementation of pwmX_enable, which can
look up the associated pmbus_sensor object, take its cached value and apply it
to hardware on changing control mode. This ensures we will not arbitrarily set
a PWM value as an RPM value or vice versa, and we can assume that the RPM or
PWM value set was sensible at least at some point in the past.
Finally, the DIRECT mode coefficients of some controllers is different between
RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture the
necessary coefficients. As pmbus core had no PWM support previously PSC_FAN
continues to be used to capture the RPM DIRECT coefficients, but in order to
avoid falsely applying RPM scaling to PWM values I have introduced the
PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow
drivers to explicitly declare PWM support in order to have the attributes
exposed.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel
fan management with temperature and remote voltage sensing. It supports
various fan control features, including PWM frequency control, temperature
hysteresis, dual tachometer measurements, and fan health monitoring.
This patch presents a basic driver using only the existing features of the
PMBus subsystem.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
[groeck: Modified description to clarify that fan control is not yet provided]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 4d420a6a9ddd72bd25baa6e667dd0581506eeacb)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pmbus core may call read/write word data functions with a page value
of -1, intending to perform the operation without setting the page.
However, the read/write word data functions accept only unsigned 8-bit
page numbers, and therefore cannot check for negative page number to
avoid setting the page. This results in setting the page number to 0xFF.
This may result in errors or undefined behavior of some devices
(specifically the ir35221, which allows the page to be set to 0xFF,
but some subsequent operations to read registers may fail).
Switch the pmbus_set_page page parameter to an integer and perform the
check for negative page there. Make read/write functions consistent in
accepting an integer page number parameter.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Fixes: cbcdec6202c9 ("hwmon: (pmbus): Access word data for STATUS_WORD")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 6dcf2fb5e8db3704f50af1f198256cb4e2453f8b)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Add the driver to monitor IBM CFF power supplies with hwmon over
pmbus.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
[groeck: drop 'default n'; include bitops.h instead of jiffies.h]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit f69316d62c7066edc4693b85c6e9f987eed62772)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export all the available status registers through debugfs. This is
useful for hardware diagnostics, especially on multi-page pmbus devices,
as user-space access of the i2c space could corrupt the pmbus page
accounting.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit 1e069dfd96dfeacf1d781f6eaea9426aed0b0909)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add PB_STATUS_INPUT as the generic alarm bit for iin and pin. We also
need to redo the status register checking before setting up the boolean
attribute, since it won't necessarily check STATUS_WORD if the device
doesn't support it, which we need for this bit.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit c159be9e902a59a117e67d466c872ecc46240ba5)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pmbus always reads byte data from the status register, even if
configured to use STATUS_WORD. Use a function pointer to read the
correct amount of data from the registers.
Also switch to try STATUS_WORD first before STATUS_BYTE on init.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit cbcdec6202c934bd72fca4fe9db255d84f907dbe)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
| |
Switch the storage of status registers to 16 bit values. This allows us
to store all the bits of STATUS_WORD.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
(cherry picked from commit a66a6eb9db10bd630bacf31e33505302c8e8303c)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
| |
In order to aid application usage of the error, throttling, and
presence count properties, use sysfs_notify to notify users of change on
these attributes.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Add logic to detect a number of error scenarios on the OCC. Export any
errors through an additional non-hwmon device attribute. The error
counting and state verification are required by the OCC hardware
specification.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
| |
Create device attributes for additional OCC properties that do not
belong as hwmon sensors. These provide additional information as to the
state of the processor and system.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
| |
Setup the sensor attributes for every OCC sensor found by the first poll
response. Register the attributes with hwmon. Add hwmon documentation
for the driver.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
| |
Add structures to define all sensor types and versions. Add sysfs show
and store functions for each sensor type. Add a method to construct the
"set user power cap" command and send it to the OCC. Add rate limit to
polling the OCC (in case user-space reads our hwmon entries rapidly).
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add method to parse the response from the OCC poll command. This only
needs to be done during probe(), since the OCC shouldn't change the
number or format of sensors while it's running. The parsed response
allows quick access to sensor data, as well as information on the
number and version of sensors, which we need to instantiate hwmon
attributes.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the P8 OCC, add the procedure to send a command to the OCC over I2C
bus. This involves writing the OCC command registers with serial
communication operations (SCOMs) interpreted by the I2C slave. For the
P9 OCC, add a procedure to use the OCC in-kernel API to send a command
to the OCC through the SBE engine.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OCC is a device embedded on a POWER processor that collects and
aggregates sensor data from the processor and system. The OCC can
provide the raw sensor data as well as perform thermal and power
management on the system.
This driver provides a hwmon interface to the OCC from a service
processor (e.g. a BMC). The driver supports both POWER8 and POWER9 OCCs.
Communications with the POWER8 OCC are established over standard I2C
bus. The driver communicates with the POWER9 OCC through the FSI-based
OCC driver, which handles the lower-level communication details.
This patch lays out the structure of the OCC hwmon driver. There are two
platform drivers, one each for P8 and P9 OCCs. These are probed through
the I2C tree and the FSI-based OCC driver, respectively. The patch also
defines the first common structures and methods between the two OCC
versions.
OpenBMC-Staging-Count: 2
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc 7.1 complains that the driver uses sprintf() and thus does not validate
the length of output buffers.
drivers/hwmon/applesmc.c: In function 'applesmc_show_fan_position':
drivers/hwmon/applesmc.c:82:21: warning:
'%d' directive writing between 1 and 5 bytes into a region of size 4
Fix the problem by using scnprintf() instead of sprintf() throughout the
driver. Also explicitly limit the number of supported fans to avoid actual
buffer overruns and thus invalid keys.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference driver polled but mentioned it was possible to sleep
for a computed period to know when it's ready to read. However, polling
with minimal sleeps is quick and works. This also improves responsiveness
from the driver.
Testing: tested on ast2400 on quanta-q71l
Signed-off-by: Patrick Venture <venture@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce the fan_tach period such that the fan controller uses a shorter
period to measure the rpm.
The original period of 0x1000 was chosen as a conversative value from the
reference implementation. Through experimentation on the quanta-q71l
board, I was able to drive the number down which ultimately reduced the
time the controller would use to determine the fan_tach. This value was
recently tested and accepted downstream on the IBM Zaius board which uses
the ast2500.
Future work: It may be worthwhile as this is a tunable parameter to the
system, to allow overriding it through the device tree.
Testing: Tested on an ast2400 sitting on a quanta-q71l and ast2500 on
power9.
Signed-off-by: Patrick Venture <venture@google.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|