First of all and unlike I2C, it's not the master that dictates how many
bytes to read in block read operation. It's the device that informs the
master how many bytes it's sending back.
Thus, for ichsmb_bread() the count parameter is purely an output
parameter. The code has been changed to reflect that.
The sanity checking of the response length is now done once it (the
first byte of the response) is received.
While here, handling of ICH_HST_STA_FAILED status bit has been added.
Plus some code style improvements and some new code comments in the
vicinity of the changed code.
The ichsmb driver does not actually handle SMBALERT, other than by logging the
first 16 occurences of the ICH_HST_STA_SMBALERT_STS_SMBALERT status
flag. Because the SMBALERT is not acknowledged by the host, clearing it in the
host status register does not appear to work as long as some slave device is
pulling the SMBALERT line low, at least for C2000 chips. As a result, if a slave
device does pull SMBALERT low the interrupt handler will always loop its maximum
of 16 times attempting to clear all status register flags and device_printf the
status register. The result is the kernel message buffer is littered with these
device_printfs at every interrupt.
To remedy the problem, the ICH_HST_STA_SMBALERT_STS flag is zeroed in the read
host status register value, just as with ICH_HST_STA_INUSE_STS and
ICH_HST_STA_HOST_BUSY. This allows the loop to break when no other flags that
must be handled are set in the host status register. Additionally, because the
SMBALERT is not actually handled the SMBALERT logging is omitted as it has no
actual function at this time.
Reviewed by: imp
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D39966
Delay the attachment of children, when requested, until after interrutps are
running. This is often needed to allow children to run transactions on i2c or
spi busses. It's a common enough idiom that it will be useful to have its own
wrapper.
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D21465
This fixes a "timed sleep before timers are working" panic seen
while attaching jedec_dimm(4) instances too early in the boot.
Submitted by: ian
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D21452
Most calls to bus_alloc_resource() use "anywhere" as the range, with a given
count. Migrate these to use the new bus_alloc_resource_anywhere() API.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D5370
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
- SMBus Controller
- SATA Controller
- HD Audio Controller
- Watchdog Controller
Thanks to Seth Heasley (seth.heasley@intel.com) for providing us code.
MFC after 3 days
This is SMBus controller found in Intel Platform Controller Hub (PCH),
which is a general name that refers to Intel 5 Series chipsets and
3400 Series chipsets.
Submitted by: Dmitry S. Luhtionov <mitya@cabletv.dp.ua>
MFC after: 3 days
Ideally we should attempt attaching only to known supported devices.
But I am not sure that we have all supported PCI IDs already listed,
and I am too young to die, err, I don't want to take the heat from
causing a trouble to someone.
MFC after: 1 week
X-ToDo: drop the default case
for slave addressing by using left-adjusted slave addresses (i.e.
xxxxxxx0b).
- Require the low bit of the slave address to always be zero in smb(4) to
help catch broken applications.
- Adjust some code in the IPMI driver to not convert the slave address for
SSIF to a right-adjusted address. I (or possibly ambrisko@) added this in
the past to (unknowingly) work around the bug in ichsmb(4).
Submitted by: Andriy Gapon <avg of icyb.net.ua> (1,2)
MFC after: 1 month
- Use printf() and device_printf() instead of log() in ichsmb(4).
- Create the mutex sooner during ichsmb(4) attach.
- Attach the interrupt handler later during ichsmb(4) attach to avoid
races.
- Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus
driver does this already.
- Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and
viapm(4).
- Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values
into BARs, and the PCI bus layer will allocate resources now if needed.
- Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4)
attached to the PCI device and created an intsmb(4) child. Now,
intsmb(4) just attaches to PCI directly.
- Change several intsmb functions to take a softc instead of a device_t
to make things simpler.
- Change smbus_callback() to pass a void * rather than caddr_t.
- Change smbus_bread() to pass a pointer to the count and have it be an
in/out parameter. The input is the size of the buffer (same as before),
but on return it will contain the actual amount of data read back from
the bus. Note that this value may be larger than the input value. It
is up to the caller to treat this as an error if desired.
- Change the SMB_BREAD ioctl to write out the updated struct smbcmd which
will contain the actual number of bytes read in the 'count' field. To
preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD
which doesn't copy the updated smbcmd back out to userland. I doubt anyone
actually used the old BREAD anyway as it was rediculous to do a bulk-read
but not tell the using program how much data was actually read.
- Make the smbus driver and devclass public in the smbus module and
push all the DRIVER_MODULE()'s for attaching the smbus driver to
various foosmb drivers out into the foosmb modules. This makes all
the foosmb logic centralized and allows new foosmb modules to be
self-contained w/o having to hack smbus.c everytime a new smbus driver
is added.
- Add a new SMB_EINVAL error bit and use it in place of EINVAL to return
an error for bad arguments (such as invalid counts for bread and bwrite).
- Map SMB bus error bits to EIO in smbus_error().
- Make the smbus driver call bus_generic_probe() and require child drivers
such as smb(4) to create device_t's via identify routines. Previously,
smbus just created one anonymous device during attach, and if you had
multiple drivers that could attach it was just random chance as to which
driver got to probe for the sole device_t first.
- Add a mutex to the smbus(4) softc and use it in place of dummy splhigh()
to protect the 'owner' field and perform necessary synchronization for
smbus_request_bus() and smbus_release_bus().
- Change the bread() and bwrite() methods of alpm(4), amdpm(4), and
viapm(4) to only perform a single transaction and not try to use a
loop of multiple transactions for a large request. The framing and
commands to use for a large transaction depend on the upper-layer
protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the
smb(4) driver never allowed bulk read/writes of more than 32-bytes
anyway. The other smb drivers only performed single transactions.
- Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4),
amdpm(4), amdsmb(4), intpm(4), and nfsmb(4).
- Use SMB_xxx errors in viapm(4).
- Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems
from child devices making smb upcalls that would use the mutex during
their detach methods.
MFC after: 1 week
Reviewed by: jmg (mostly)
signal is received during the msleep, the msleep is retried
indefinitely as it just keeps returning ERESTART because of
the pending signal.
Instead, just don't PCATCH - the signal can wait.
Sponsored by: Sophos/ActiveState
