BMC/Intel-BMC/linux.git/drivers/fsi, branch dev-5.15-intel

fsi: sbefifo: Add detailed debugging information

2022-04-27T10:11:36+00:00

Provide more output on the timeout status, and make some vdbg calls into dbg calls so they can be enabled at runtime. OpenBMC-Staging-Count: 1 Link: https://lore.kernel.org/r/20220415050757.281158-1-joel@jms.id.au Signed-off-by: Joel Stanley

fsi: occ: Fix checksum failure mode

2022-04-27T08:49:12+00:00

Change the checksum errno to something different than the errno used for a bad SBE message. In addition, don't set the user's response length to the data length in this case, since it's not SBE FFDC. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20220426154956.27205-2-eajames@linux.ibm.com Signed-off-by: Joel Stanley

Merge tag 'v5.15.34' into dev-5.15

2022-04-14T08:19:30+00:00

This is the 5.15.34 stable release Signed-off-by: Joel Stanley

fsi: Aspeed: Fix a potential double free

2022-04-08T12:23:44+00:00

[ Upstream commit 83ba7e895debc529803a7a258653f2fe9bf3bf40 ] 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 Signed-off-by: Sasha Levin

fsi: scom: Remove retries in indirect scoms

2022-04-08T12:23:44+00:00

[ Upstream commit ab1b79159ad5a6dc4e4994b49737f7feb13b7155 ] 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 Signed-off-by: Sasha Levin

fsi: scom: Fix error handling

2022-04-08T12:23:44+00:00

[ Upstream commit d46fddd52d11eb6a3a7ed836f9f273e9cf8cd01c ] 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 Signed-off-by: Sasha Levin

fsi: Add trace events in initialization path

2022-02-22T02:56:41+00:00

Add definitions for trace events to show the scanning flow. OpenBMC-Staging-Count: 1 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-22T02:56:38+00:00

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. OpenBMC-Staging-Count: 1 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-22T02:56:36+00:00

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. OpenBMC-Staging-Count: 1 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-22T02:56:33+00:00

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. OpenBMC-Staging-Count: 1 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