| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
An sht3x sensor include limits register which contains temperature
and humidity limit values. After a reset, pre-defined values are loaded
into that register. During the probe function, the driver reads the
limits register. However, if the reads are made too early, and the bus
is clocked at high frequencies (e.g. 100 kHz or more), the loading could be
not completed and the sensor returns a NACK which causes the probe to fail.
A delay of at least 500 us before the first read solves this issue.
Signed-off-by: Emiliano Ingrassia <ingrassia@epigenesys.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Building without CONFIG_LEDS_CLASS causes a link failure:
drivers/hwmon/pmbus/ibm-cffps.o: In function `ibm_cffps_probe':
ibm-cffps.c:(.text+0x4f4): undefined reference to `devm_of_led_classdev_register'
This adds the required dependency.
Fixes: ef9e1cdf419a ("hwmon: (pmbus/cffps) Add led class device ...")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
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>
|
|
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>
|
|
The ASPEED SoC must deassert a reset in order to use the PWM/tach
peripheral.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The device tree bindings are updated to document the resets phandle, and
the example is updated to match what is expected for both the reset and
clock phandle.
Note that the bindings should have always had the reset controller, as
the hardware is unusable without it.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
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>
|
|
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>
|
|
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.
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>
|
|
Sparse reports:
drivers/hwmon/hih6130.c:56: warning:
No description found for parameter 'client'
drivers/hwmon/hih6130.c:56: warning:
Excess struct member 'hwmon_dev' description in 'hih6130'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Sparse reports:
drivers/hwmon/iio_hwmon.c:36: warning:
No description found for parameter 'groups'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Sparse reports:
drivers/hwmon/sht15.c:188: warning:
No description found for parameter 'len'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Sparse reports:
drivers/hwmon/sht21.c:60: warning:
No description found for parameter 'client'
drivers/hwmon/sht21.c:60:
warning: Excess struct member 'hwmon_dev' description in 'sht21'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
sparse reports:
drivers/hwmon/hwmon.c:681: warning:
No description found for parameter 'chip'
drivers/hwmon/hwmon.c:681: warning:
Excess function parameter 'info' description in
'hwmon_device_register_with_info'
drivers/hwmon/hwmon.c:789: warning:
No description found for parameter 'chip'
drivers/hwmon/hwmon.c:789: warning:
No description found for parameter 'groups'
drivers/hwmon/hwmon.c:789: warning:
Excess function parameter 'info' description in
'devm_hwmon_device_register_with_info'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Before this patch:
$ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
alias: i2c:max31785a
alias: i2c:max31785
After this patch:
$ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias
alias: i2c:max31785a
alias: i2c:max31785
alias: of:N*T*Cmaxim,max31785aC*
alias: of:N*T*Cmaxim,max31785a
alias: of:N*T*Cmaxim,max31785C*
alias: of:N*T*Cmaxim,max31785
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Calibration register is used for calculating current register in
hardware according to datasheet:
current = shunt_volt * calib_register / 2048 (ina 226)
current = shunt_volt * calib_register / 4096 (ina 219)
Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in
order to avoid truncation error and provide best precision allowed
by shunt_voltage measurement. Make current scale value follow changes
of shunt_resistor from sysfs as calib_register value is now fixed.
Power_lsb value should also follow shunt_resistor changes as stated in
datasheet:
power_lsb = 25 * current_lsb (ina 226)
power_lsb = 20 * current_lsb (ina 219)
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
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: Guenter Roeck <linux@roeck-us.net>
|
|
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: Guenter Roeck <linux@roeck-us.net>
|
|
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: Guenter Roeck <linux@roeck-us.net>
|
|
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: Guenter Roeck <linux@roeck-us.net>
|
|
LM25063 was never released. Drop support for it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
'default n' is default, so there is no need to specify it explicitly.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
Samuel Mendoza-Jonas
Emiliano Ingrassia
Arnd Bergmann
eajames@linux.vnet.ibm.com
Joel
Edward A. James
Guenter Roeck
Javier Martinez Canillas
Maciej Purski
Andrew Jeffery
Sinan Kaya