History log of /openbmc/linux/drivers/fsi/fsi-sbefifo.c (Results 1376 – 1380 of 1380)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v4.17.9, v4.17.8, v4.17.7
# d5c66e61 11-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

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 ...


Revision tags: v4.17.6, v4.17.5
# 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 <eajame

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 ...


Revision tags: v4.17.4, v4.17.3
# 29925138 17-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: 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 ...


Revision tags: v4.17.2
# a9ef97d0 13-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>


Revision tags: v4.17.1, v4.17
# 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 th

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 ...


1...<<515253545556