linux-stable.git/drivers/fsi, branch linux-5.17.y

fsi: Aspeed: Fix a potential double free

2022-04-08T11:58:24+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-08T11:58:23+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-08T11:58:23+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: sbefifo: Use interruptible mutex locking

2021-10-21T23:24:33+00:00

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:33+00:00

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

fsi: occ: Store the SBEFIFO FFDC in the user response buffer

2021-10-21T23:24:32+00:00

If the SBEFIFO response indicates an error, store the response in the
user buffer and return an error. Previously, the user had no way of
obtaining the SBEFIFO FFDC.

The user's buffer now contains data in the event of a failure. No change
in the event of a successful transfer.

Signed-off-by: Eddie James 
Link: https://lore.kernel.org/r/20211019205307.36946-3-eajames@linux.ibm.com
Signed-off-by: Joel Stanley

fsi: occ: Use a large buffer for responses

2021-10-21T23:20:55+00:00

Allocate a large buffer for each OCC to handle response data. This
removes memory allocation during an operation, and also allows for
the maximum amount of SBE FFDC.

Previously for the putsram and attn commands, only 32 words would have
been available, and for getsram, only up to the size of the transfer.
SBE FFDC might be up to 8Kb.

The SBE interface expects data to be specified in units of words (4
bytes), defined as OCC_MAX_RESP_WORDS.

This change allows the full FFDC capture to be implemented, where before
it was not available.

Signed-off-by: Eddie James 
Link: https://lore.kernel.org/r/20211019205307.36946-2-eajames@linux.ibm.com
Signed-off-by: Joel Stanley

fsi: occ: Force sequence numbering per OCC

2021-10-15T04:39:25+00:00

Set and increment the sequence number during the submit operation.
This prevents sequence number conflicts between different users of
the interface. A sequence number conflict may result in a user
getting an OCC response meant for a different command. Since the
sequence number is now modified, the checksum must be calculated and
set before submitting the command.

Signed-off-by: Eddie James 
Reviewed-by: Joel Stanley 
Link: https://lore.kernel.org/r/20210721190231.117185-2-eajames@linux.ibm.com
Signed-off-by: Joel Stanley

fsi/sbefifo: Fix reset timeout

2021-06-04T06:36:57+00:00

On BMCs with lower timer resolution than 1ms, msleep(1) will take
way longer than 1ms, so looping 10k times won't wait for 10s but
significantly longer.

Fix this by using jiffies like the rest of the code.

Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
Signed-off-by: Joachim Fenkes 
Link: https://lore.kernel.org/r/20200724071518.430515-3-joel@jms.id.au
Signed-off-by: Joel Stanley

fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE

2021-06-04T05:53:40+00:00

When the SBE requests a reset via the down FIFO, that is also the
FIFO we should go and reset ;)

Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
Signed-off-by: Joachim Fenkes 
Signed-off-by: Joel Stanley 
Link: https://lore.kernel.org/r/20200724071518.430515-2-joel@jms.id.au
Signed-off-by: Joel Stanley