#
f04d61a3 |
| 03-Feb-2023 |
Yu Zhe <yuzhe@nfschina.com> |
fsi: fix some spelling mistakes in comment
Fix typos in comment.
Signed-off-by: Yu Zhe <yuzhe@nfschina.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20230203083
fsi: fix some spelling mistakes in comment
Fix typos in comment.
Signed-off-by: Yu Zhe <yuzhe@nfschina.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20230203083721.23455-1-yuzhe@nfschina.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
2f42220f |
| 12-Jun-2023 |
Eddie James <eajames@linux.ibm.com> |
fsi: sbefifo: Remove limits on user-specified read timeout
There's no reason to limit the user here. The way the driver is designed, extremely large transfers require extremely long timeouts.
Signe
fsi: sbefifo: Remove limits on user-specified read timeout
There's no reason to limit the user here. The way the driver is designed, extremely large transfers require extremely long timeouts.
Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20230612195657.245125-7-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
19c064de |
| 12-Jun-2023 |
Eddie James <eajames@us.ibm.com> |
fsi: sbefifo: Add configurable in-command timeout
A new use case for the SBEFIFO requires a long in-command timeout as the SBE processes each part of the command before clearing the upstream FIFO fo
fsi: sbefifo: Add configurable in-command timeout
A new use case for the SBEFIFO requires a long in-command timeout as the SBE processes each part of the command before clearing the upstream FIFO for the next part of the command.
Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20230612195657.245125-6-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
d6ce872e |
| 12-Jun-2023 |
Eddie James <eajames@linux.ibm.com> |
fsi: sbefifo: Don't check status during probe
The status check during probe doesn't serve any purpose. Any attempt to use the SBEFIFO will result in the same check and cleanup.
Signed-off-by: Eddie
fsi: sbefifo: Don't check status during probe
The status check during probe doesn't serve any purpose. Any attempt to use the SBEFIFO will result in the same check and cleanup.
Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20230612195657.245125-5-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
288f1acf |
| 18-Jul-2023 |
Rob Herring <robh@kernel.org> |
fsi: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that mer
fsi: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20230718205508.1790932-1-robh@kernel.org Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
de4eda9d |
| 16-Sep-2022 |
Al Viro <viro@zeniv.linux.org.uk> |
use less confusing names for iov_iter direction initializers
READ/WRITE proved to be actively confusing - the meanings are "data destination, as used with read(2)" and "data source, as used with wri
use less confusing names for iov_iter direction initializers
READ/WRITE proved to be actively confusing - the meanings are "data destination, as used with read(2)" and "data source, as used with write(2)", but people keep interpreting those as "we read data from it" and "we write data to it", i.e. exactly the wrong way.
Call them ITER_DEST and ITER_SOURCE - at least that is harder to misinterpret...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
#
974c36fb |
| 15-Sep-2022 |
Al Viro <viro@zeniv.linux.org.uk> |
[fsi] WRITE is "data source", not destination...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
b1534a05 |
| 15-Apr-2022 |
Joel Stanley <joel@jms.id.au> |
fsi: sbefifo: Add detailed debugging information
Provide more output on the timeout status, and make some vdbg calls into dbg calls so they can be enabled at runtime.
Signed-off-by: Joel Stanley <j
fsi: sbefifo: Add detailed debugging information
Provide more output on the timeout status, and make some vdbg calls into dbg calls so they can be enabled at runtime.
Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20220415050757.281158-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
a1dc6308 |
| 21-Jan-2022 |
Amitay Isaacs <amitay@ozlabs.org> |
fsi: sbefifo: Implement FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl
FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl sets the read timeout (in seconds) for the response received by sbefifo device from sbe. The ti
fsi: sbefifo: Implement FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl
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 <amitay@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20220121053816.82253-3-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
b8d536d2 |
| 21-Jan-2022 |
Amitay Isaacs <amitay@ozlabs.org> |
fsi: sbefifo: Use specified value of start of response timeout
For some of the chip-ops where sbe needs to collect trace information, sbe can take a long time (>30s) to respond. Currently these chi
fsi: sbefifo: Use specified value of start of response timeout
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 <amitay@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20220121053816.82253-2-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
7cc2f34e |
| 03-Aug-2021 |
Eddie James <eajames@linux.ibm.com> |
fsi: sbefifo: Use interruptible mutex locking
Some SBE operations have extremely large responses and can require several minutes to process the response. During this time, the device lock must be he
fsi: sbefifo: Use interruptible mutex locking
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 <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20210803213016.44739-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
82628034 |
| 19-Oct-2021 |
Eddie James <eajames@linux.ibm.com> |
fsi: sbefifo: Add sysfs file indicating a timeout error
The SBEFIFO timeout error requires special handling in userspace to do recovery operations. Add a sysfs file to indicate a timeout error, and
fsi: sbefifo: Add sysfs file indicating a timeout error
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 <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20211019211749.38059-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
9ab1428d |
| 24-Jul-2020 |
Joachim Fenkes <FENKES@de.ibm.com> |
fsi/sbefifo: Fix reset timeout
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 u
fsi/sbefifo: Fix reset timeout
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 <fenkes@de.ibm.com> Link: https://lore.kernel.org/r/20200724071518.430515-3-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
95152433 |
| 24-Jul-2020 |
Joachim Fenkes <FENKES@de.ibm.com> |
fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE
When the SBE requests a reset via the down FIFO, that is also the FIFO we should go and reset ;)
Fixes: 9f4a8a2d7f9d ("fsi/s
fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE
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 <FENKES@de.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200724071518.430515-2-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
f458c38f |
| 05-Aug-2020 |
Rikard Falkeborn <rikard.falkeborn@gmail.com> |
fsi: sbefifo: Constify sbefifo_ids
The only usage of sbefifo_ids is to assign its address to the id_table field in the fsi_driver struct, which is a const pointer, so make it const to allow the comp
fsi: sbefifo: Constify sbefifo_ids
The only usage of sbefifo_ids is to assign its address to the id_table field in the fsi_driver struct, which is a const pointer, so make it const to allow the compiler to put it in read-only memory
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
7ce98fb6 |
| 26-Jun-2019 |
Eddie James <eajames@linux.ibm.com> |
fsi: sbefifo: Don't fail operations when in SBE IPL state
SBE fifo operations should be allowed while the SBE is in any of the "IPL" states. Operations should succeed in this state.
Fixes: 9f4a8a2d
fsi: sbefifo: Don't fail operations when in SBE IPL state
SBE fifo operations should be allowed while the SBE is in any of the "IPL" states. Operations should succeed in this state.
Fixes: 9f4a8a2d7f9d fsi/sbefifo: Add driver for the SBE FIFO Reviewed-by: Joel Stanley <joel@jms.id.au> Tested-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1561575415-3282-1-git-send-email-eajames@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
aa563d7b |
| 19-Oct-2018 |
David Howells <dhowells@redhat.com> |
iov_iter: Separate type from direction and use accessor functions
In the iov_iter struct, separate the iterator type from the iterator direction and use accessor functions to access them in most pla
iov_iter: Separate type from direction and use accessor functions
In the iov_iter struct, separate the iterator type from the iterator direction and use accessor functions to access them in most places.
Convert a bunch of places to use switch-statements to access them rather then chains of bitwise-AND statements. This makes it easier to add further iterator types. Also, this can be more efficient as to implement a switch of small contiguous integers, the compiler can use ~50% fewer compare instructions than it has to use bitwise-and instructions.
Further, cease passing the iterator type into the iterator setup function. The iterator function can set that itself. Only the direction is required.
Signed-off-by: David Howells <dhowells@redhat.com>
show more ...
|
#
15e2a721 |
| 07-Aug-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi: sbefifo: Bump max command length
Otherwise cronus putmem fails istep and BML fails to upload skiboot
To do that, we still use our one-page command buffer for small commands for speed, and for
fsi: sbefifo: Bump max command length
Otherwise cronus putmem fails istep and BML fails to upload skiboot
To do that, we still use our one-page command buffer for small commands for speed, and for anything bigger, with a limit of 1MB plus a page, we vmalloc a temporary buffer.
The limit was chosen because Cronus will break up any data transfer into 1M chunks (the extra page is for the command header).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
show more ...
|
#
8b052dd6 |
| 24-Jul-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi: sbefifo: Convert to use the new chardev
This converts FSI sbefifo to use the new fsi-core controlled chardev allocator and use a real cdev instead of a miscdev.
One side effect is to fix the o
fsi: sbefifo: Convert to use the new chardev
This converts FSI sbefifo to use the new fsi-core controlled chardev allocator and use a real cdev instead of a miscdev.
One side effect is to fix the object lifetime by removing the use of devm_kzalloc() for something that contains kobjects, and using proper reference counting.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
4fcdc2d1 |
| 23-Jul-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi: sbefifo: Fix inconsistent use of ffdc mutex
Some of the exit path missed the unlock. Move the mutex to an outer function to avoid the problem completely
Signed-off-by: Benjamin Herrenschmidt <
fsi: sbefifo: Fix inconsistent use of ffdc mutex
Some of the exit path missed the unlock. Move the mutex to an outer function to avoid the problem completely
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
d5c66e61 |
| 12-Jul-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi: sbefifo: Fix checker warning about late NULL check
"dev" is dereferences before it's checked.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Benjamin Herrenschmidt <benh@
fsi: sbefifo: Fix checker warning about late NULL check
"dev" is dereferences before it's checked.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
c00bac88 |
| 03-Jul-2018 |
Eddie James <eajames@linux.vnet.ibm.com> |
fsi: sbefifo: Add missing mutex_unlock
There was no unlock of the FFDC mutex.
Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO") Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com
fsi: sbefifo: Add missing mutex_unlock
There was no unlock of the FFDC mutex.
Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO") Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
29925138 |
| 18-Jun-2018 |
Joel Stanley <joel@jms.id.au> |
fsi: sbefifo: Fix sparse warnings
fsi-sbefifo.c:547:58: warning: incorrect type in argument 2 (different base types) fsi-sbefifo.c:547:58: expected restricted __be32 [usertype] *word fsi-sbefifo.
fsi: sbefifo: Fix sparse warnings
fsi-sbefifo.c:547:58: warning: incorrect type in argument 2 (different base types) fsi-sbefifo.c:547:58: expected restricted __be32 [usertype] *word fsi-sbefifo.c:547:58: got unsigned int *<noident> fsi-sbefifo.c:635:16: warning: incorrect type in assignment (different base types) fsi-sbefifo.c:635:16: expected unsigned int [unsigned] <noident> fsi-sbefifo.c:635:16: got restricted __be32 [usertype] <noident> fsi-sbefifo.c:636:16: warning: incorrect type in assignment (different base types) fsi-sbefifo.c:636:16: expected unsigned int [unsigned] <noident> fsi-sbefifo.c:636:16: got restricted __be32 [usertype] <noident>
Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
show more ...
|
#
a9ef97d0 |
| 14-Jun-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi: sbefifo: Remove unneeded semicolon
Spotted by kbuild-test-bot
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
9f4a8a2d |
| 17-May-2018 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
fsi/sbefifo: Add driver for the SBE FIFO
This driver provides an in-kernel and a user API for accessing the command FIFO of the SBE (Self Boot Engine) of the POWER9 processor, via the FSI bus.
It p
fsi/sbefifo: Add driver for the SBE FIFO
This driver provides an in-kernel and a user API for accessing the command FIFO of the SBE (Self Boot Engine) of the POWER9 processor, via the FSI bus.
It provides an in-kernel interface to submit command and receive responses, along with a helper to locate and analyse the response status block. It's a simple synchronous submit() type API.
The user interface uses the write/read interface that an earlier version of this driver already provided, however it has some specific limitations in order to keep the driver simple and avoid using up a lot of kernel memory:
- The user should perform a single write() with the command and a single read() to get the response (with a buffer big enough to hold the entire response).
- On a write() the command is simply "stored" into a kernel buffer, it is submitted as one operation on the subsequent read(). This allows to have the code write directly from the FIFO into the user buffer and avoid hogging the SBE between the write() and read() syscall as it's critical that the SBE be freed asap to respond to the host. An extra write() will simply replace the previously written command.
- A write of a single 4 bytes containing the value 0x52534554 in big endian will trigger a reset request. No read is necessary, the write() call will return when the reset has been acknowledged or times out.
- The command is limited to 4K bytes.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: Joel Stanley <joel@jms.id.au> ---
show more ...
|