linux-dev/drivers/fsi, branch linus/master

Merge tag 'fsi-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi into char-misc-next

2022-02-21T16:47:42Z

Joel writes: FSI changes for v5.18 * Improvements in SCOM and OCC drivers for error handling and retries * Addition of tracepoints for initialisation path * API for setting long running SBE FIFO operations * tag 'fsi-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/fsi: fsi: Add trace events in initialization path fsi: sbefifo: Implement FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl fsi: sbefifo: Use specified value of start of response timeout fsi: occ: Improve response status checking fsi: scom: Remove retries in indirect scoms fsi: scom: Fix error handling

fsi: Add trace events in initialization path

2022-02-21T09:08:54Z

Add definitions for trace events to show the scanning flow. Signed-off-by: Eddie James Reviewed-by: Steven Rostedt (Google) Link: https://lore.kernel.org/r/20220207161640.35605-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley

fsi: sbefifo: Implement FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl

2022-02-21T09:08:17Z

FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl sets the read timeout (in seconds) for the response received by sbefifo device from sbe. The timeout affects only the read operation on current sbefifo device fd. Certain SBE operations can take long time to complete and the default timeout of 10 seconds might not be sufficient to start receiving response from SBE. In such cases, allow the timeout to be set to the maximum of 120 seconds. The kernel does not contain the definition of the various SBE operations, so we must expose an interface to userspace to set the timeout for the given operation. Signed-off-by: Amitay Isaacs Signed-off-by: Joel Stanley Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20220121053816.82253-3-joel@jms.id.au Signed-off-by: Joel Stanley

fsi: sbefifo: Use specified value of start of response timeout

2022-02-21T09:08:17Z

For some of the chip-ops where sbe needs to collect trace information, sbe can take a long time (>30s) to respond. Currently these chip-ops will timeout as the start of response timeout defaults to 10s. Instead of default value, use specified value. The require timeout value will be set using ioctl. Signed-off-by: Amitay Isaacs Signed-off-by: Joel Stanley Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20220121053816.82253-2-joel@jms.id.au Signed-off-by: Joel Stanley

fsi: occ: Improve response status checking

2022-02-21T09:07:03Z

If the driver sequence number coincidentally equals the previous command response sequence number, the driver may proceed with fetching the entire buffer before the OCC has processed the current command. To be sure the correct response is obtained, check the command type and also retry if any of the response parameters have changed when the rest of the buffer is fetched. Also initialize the driver with a random sequence number in order to reduce the chances of this happening. Signed-off-by: Eddie James Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20220208152235.19686-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley

fsi: Aspeed: Fix a potential double free

2022-02-04T15:45:39Z

A struct device can never be devm_alloc()'ed. Here, it is embedded in "struct fsi_master", and "struct fsi_master" is embedded in "struct fsi_master_aspeed". Since "struct device" is embedded, the data structure embedding it must be released with the release function, as is already done here. So use kzalloc() instead of devm_kzalloc() when allocating "aspeed" and update all error handling branches accordingly. This prevent a potential double free(). This also fix another issue if opb_readl() fails. Instead of a direct return, it now jumps in the error handling path. Fixes: 606397d67f41 ("fsi: Add ast2600 master driver") Suggested-by: Greg KH Suggested-by: Guenter Roeck Reviewed-by: Guenter Roeck Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/2c123f8b0a40dc1a061fae982169fe030b4f47e6.1641765339.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman

fsi: scom: Remove retries in indirect scoms

2022-01-31T05:26:55Z

In commit f72ddbe1d7b7 ("fsi: scom: Remove retries") the retries were removed from get and put scoms. That patch missed the retires in get and put indirect scom. For the same reason, remove them from the scom driver to allow the caller to decide to retry. This removes the following special case which would have caused the retry code to return early: - if ((ind_data & XSCOM_DATA_IND_COMPLETE) || (err != SCOM_PIB_BLOCKED)) - return 0; I believe this case is handled. Fixes: f72ddbe1d7b7 ("fsi: scom: Remove retries") Signed-off-by: Joel Stanley Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20211207033811.518981-3-joel@jms.id.au Signed-off-by: Joel Stanley

fsi: scom: Fix error handling

2022-01-31T05:26:55Z

SCOM error handling is made complex by trying to pass around two bits of information: the function return code, and a status parameter that represents the CFAM error status register. The commit f72ddbe1d7b7 ("fsi: scom: Remove retries") removed the "hidden" retries in the SCOM driver, in preference of allowing the calling code (userspace or driver) to decide how to handle a failed SCOM. However it introduced a bug by attempting to be smart about the return codes that were "errors" and which were ok to fall through to the status register parsing. We get the following errors: - EINVAL or ENXIO, for indirect scoms where the value is invalid - EINVAL, where the size or address is incorrect - EIO or ETIMEOUT, where FSI write failed (aspeed master) - EAGAIN, where the master detected a crc error (GPIO master only) - EBUSY, where the bus is disabled (GPIO master in external mode) In all of these cases we should fail the SCOM read/write and return the error. Thanks to Dan Carpenter for the detailed bug report. Fixes: f72ddbe1d7b7 ("fsi: scom: Remove retries") Link: https://lists.ozlabs.org/pipermail/linux-fsi/2021-November/000235.html Reported-by: Dan Carpenter Signed-off-by: Joel Stanley Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20211207033811.518981-2-joel@jms.id.au Signed-off-by: Joel Stanley

fsi: sbefifo: Use interruptible mutex locking

2021-10-21T23:24:33Z

Some SBE operations have extremely large responses and can require several minutes to process the response. During this time, the device lock must be held. If another process attempts an operation, it will wait for the mutex for longer than the kernel hung task watchdog allows. Therefore, use the interruptible function to lock the mutex. Signed-off-by: Eddie James Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20210803213016.44739-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley

fsi: sbefifo: Add sysfs file indicating a timeout error

2021-10-21T23:24:33Z

The SBEFIFO timeout error requires special handling in userspace to do recovery operations. Add a sysfs file to indicate a timeout error, and notify pollers when a timeout occurs. This will be used by the openpower-occ-control application. Signed-off-by: Eddie James Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20211019211749.38059-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley