#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|
#
ef25ad57 |
| 22-Jun-2021 |
Andrew Jeffery <andrew@aj.id.au> |
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they prov
ipmi: kcs_bmc: Add a "raw" character device interface
The existing IPMI chardev encodes IPMI behaviours as the name suggests. However, KCS devices are useful beyond IPMI (or keyboards), as they provide a means to generate IRQs and exchange arbitrary data between a BMC and its host system.
Implement a "raw" KCS character device that exposes the IDR, ODR and STR registers to userspace via read() and write() implemented on a character device:
+--------+--------+---------+ | Offset | read() | write() | +--------+--------+---------+ | 0 | IDR | ODR | +--------+--------+---------+ | 1 | STR | STR | +--------+--------+---------+
This interface allows userspace to implement arbitrary (though somewhat inefficient) protocols for exchanging information between a BMC and host firmware. Conceptually the KCS interface can be used as an out-of-band mechanism for interrupt-signaled control messages while bulk data transfers occur over more appropriate interfaces between the BMC and the host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
poll() is provided, which will wait for IBF or OBE conditions for data reads and writes respectively. Reads of STR on its own never blocks, though accessing both offsets in the one system call may block if the data registers are not ready.
OpenBMC-Staging-Count: 3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210623033854.587464-3-andrew@aj.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
show more ...
|