| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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: 1
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>
|
|
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 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.
OpenBMC-Staging-Count: 1
Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
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: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Use the new pinconf parameter for state persistence to expose the
associated capability of the Aspeed GPIO controller.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1b43d26985745901c87e0dca44c9b57896062306)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.
The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.
The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit e10f72bf4b3e8885c1915a119141481e7fc45ca8)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Currently, the GPIO interface is said to Open Drain if it is Single
Ended and active LOW. Similarly, it is said as Open Source if it is
Single Ended and active HIGH.
The active HIGH/LOW is used in the interface for setting the pin
state to HIGH or LOW when enabling/disabling the interface.
In Open Drain interface, pin is set to HIGH by putting pin in
high impedance and LOW by driving to the LOW.
In Open Source interface, pin is set to HIGH by driving pin to
HIGH and set to LOW by putting pin in high impedance.
With above, the Open Drain/Source is unrelated to the active LOW/HIGH
in interface. There is interface where the enable/disable of interface
is ether active LOW or HIGH but it is Open Drain type.
Hence decouple the Open Drain with Single Ended + Active LOW and
Open Source with Single Ended + Active HIGH.
Adding different flag for the Open Drain/Open Source which is valid
only when Single ended flag is enabled.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 4c0facddb7d88c78c8bd977c16faa647f079ccda)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Make fwnode_get_named_gpiod() consistent with the rest of
gpiod_get() like API, i.e. configure GPIO pin immediately after
request.
Besides obvious clean up it will help to configure pins based
on firmware provided resources.
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit a264d10ff45c688293d9112fddd8d29c819e0853)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
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.
OpenBMC-Staging-Count: 1
Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com>
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.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
[groeck: Fixed endianness problem]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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.
OpenBMC-Staging-Count: 1
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>
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.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Yong Li found that writes to the AST2500 strapping register were not
properly supported by the Aspeed pinctrl core and provided a patch to
rectify the problem. Several revisions of the patch were posted and
ultimately v4 should have been applied, however some unfortunate
liberal application of tags on my part lead to confusion between v3[1]
and v4[2].
Generate the diff between v3 and v4 to apply as a fixup patch.
[1] http://patchwork.ozlabs.org/patch/801662/
[2] http://patchwork.ozlabs.org/patch/802946/
Cc: Yong Li <sdliyong@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 5241bd16c7576de3cf189e3e40b01bd4fa10f803)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write ‘1’) to SCU7C
Signed-off-by: Yong Li <sdliyong@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1865af212dfa0819ca21c7e5c18c2a75202c1827)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Port D and port E GPIO loopback modes are commonly enabled via hardware
straps for use with front-panel buttons. When the BMC is powered
off or fails to boot, the front-panel buttons are directly connected to
the host chipset via the loopback to allow direct power-on and reset
control. Once the BMC has booted, the loopback mode must be disabled for
the BMC to take over control of host power-on and reset.
Disabling these loopback modes requires writing to the hardware strap
register which violates the current design of assuming the system
designer chose the strap settings for a specific reason and they should
be treated as read-only. Only the two bits of the strap register related
to these loopback modes are allowed to be written and comments have been
added to explain why.
Signed-off-by: Rick Altherr <raltherr@google.com>
Acked-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit c825676b0823fd43a4d08bf865f81bb188b51db1)
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Clients were receiving the ECANCELED errno when the client is removed
during a transfer. Use ENODEV instead, as ECANCELED is for AIO ops.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Christopher Bostic <cbostic@linux.vnet.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Driver wasn't cleaning up on timeout or in an error situation properly.
Need to do a full reset if we fail in order to re-stablish a good state
of the engine.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
During a transfer, in the event that the SBE isn't running, the driver
will wait for data to appear in the FIFO forever. This doesn't work at
BMC boot time if any transfers are attempted (by OCC driver probing, for
example), as it will just hang the boot. So add a simple timeout
mechanism when the driver reschdules waiting for data to show up in the
FIFO.
Tested on witherspoon by rebooting the BMC successfully with chassis
power on.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Reduce kernel log spam from PMBus core failing a PAGE command to the
MAX37185 (and any other device). It's a hardware-design or driver
related fault, and is not anything the user can fix. Therefore reduce
it from warn to debug.
OpenBMC-Staging-Count: 1
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Andrew Geissler <geissonator@gmail.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: 1
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: Matt Spinler mspinler@linux.vnet.ibm.com
|
|
Avoid setting PAGE to a unsupported value on the MAX31785 to avoid
errors from the hardware in circumstances that we know it will fail.
The virtual pages are used to expose the non-standard tacho measurements
for the second rotor of a dual-rotor fan. Maxim's implementation breaks
with the PMBus standard by providing a four-byte response to what is
usually a two-byte command.
OpenBMC-Staging-Count: 1
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: Matt Spinler mspinler@linux.vnet.ibm.com
|
|
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. We should not try to set virtual pages on the
device; add a flag so we can avoid doing so.
OpenBMC-Staging-Count: 1
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: Matt Spinler mspinler@linux.vnet.ibm.com
|
|
If extended sensors are present, the driver is doing bad memory access
since we weren't allocating enough memory for the extended sensors. Fix
this with proper allocation for extended sensor attributes.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Deleting an element of a list while iterating means that you'll access
recently freed memory when getting the next list element.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
The MFR_ID and MFR_MODEL, which are manually read before probing the
pmbus core, are only valid for the two pages that the ir35221 has
available. Since we don't know the state of the device when we start
probing, set the page number first before reading id and model.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
If data is found in the FIFO, the driver currently immediately fails
the probe. Instead, try a reset request and poll for it's completion for
a while (this protocol is defined in the SBE FIFO spec, though the
timeout lengths are my own invention).
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Transfers weren't being cleaned up if they were complete but the user
never finished reading. This is very common.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
There was a race condition where: sbefifo remove() is called, a transfer
is queued, a client is waiting, and a client is released at the same
time. In this situation, remove() wakes up the client waiter, which
destroys the client's list of transfers. This must be done since in an
error case, we don't know if the transfers are deleted or not. Then,
the client is released. Since it has no transfers, it fails to cancel
the queued transfer. This transfer then wakes up on the timer, where it
attempts to access it's client buffers, which have been freed.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Need to alert user space when we change throttling state.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Remove the error on detecting occs_present mismatch. Add a new sysfs
entry for occs_present field. Add sysfs_notify for this field, if it
changes.
Two reasons for this change:
1) Userspace app was having trouble handling this error code, since if you
bind the master OCC device first, you'll immediately get an error that we
haven't bound the same number of OCCs as the OCC reports are available.
2) This error checking for "number of OCC devices bound" isn't designed well
anyway, and makes more sense in userspace. The original intent was to implement
all of the OCC requirements in the driver, but we have an application running
on top that can pick up the slack, as it were.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Should not return -ECANCELED when the device has been removed. Instead,
use -ENODEV.
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
|
|
Prevent hanging forever waiting for OCC ops to complete.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
This is now handled in the occ driver.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Potential for bad memory access in the worker function. Now fixed by
using reference counters.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Need some data to indicate to clients and the rest of the driver when
the device is being removed, so add a cancel boolean. Fix up both the
probe and remove functions to properly handle failures and prevent
deadlocks.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
[joel: Use ENODEV instead of ECANCELLED, as it is for cancelled AIO
operations]
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Waiting for OCC to return something other than "command in progress"
should only be done in the worker function, instead of clients repeating
the entire transfer when they receive "command in progress." In this way
clients don't have to check for that return status.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Fixup some existing comments as well.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
The purpose was to set that pointer null before probing. However, it is
set null by the kernel by default.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Need to clean up the index list structure.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
For better flow and to meet Linux standards.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
We check user buffer access when we copy the data in read()/write()
anyway.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Safeguard the access functions.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Switch to __be16 from u16 and __be32 from u32. Also, use kernel access
of unaligned be16 instead of manually creating a big-endian value from
the occ response buffer.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Left over from when xfr was an independant structure. Remove these calls
as xfr is a part of the client struct.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Need to include everything we use and not rely on recursive includes.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
We should check to see if the XFR is complete, not just for a failure
or for available data. If we hit EOT without getting more data, we may
wait forever.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
|
Probe didn't handle a failed misc device registration properly. Remove
had the potential for hangs. Also, remove the list of SBEFIFOs and
instead just use the device "driver data" pointer.
OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James <eajames@us.ibm.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
|
