Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Tue, 13 Apr 2021, at 17:52, Arnd Bergmann wrote: > On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery wrote: > > On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote: > > > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > > > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery > > > > > wrote: > > > > > > > > > > > > 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. > > > > > > > > > > I only noticed the series after Joel asked about the DT changes on > > > > > the arm > > > > > side. One question though: > > > > > > > > > > How does this related to the drivers/input/serio/ framework that also > > > > > talks > > > > > to the keyboard controller for things that are not keyboards? > > > > > > > > I've taken a brief look and I feel they're somewhat closely related. > > > > > > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > > > > KCS drivers move under drivers/input/serio. If you squint, the i8042 > > > > serio device driver has similarities with what the Aspeed and Nuvoton > > > > device drivers are providing to the KCS IPMI stack. > > > > > > After looking some more into it, I finally understood that the two are > > > rather complementary. While the drivers/char/ipmi/kcs_bmc.c > > > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems > > > that the proposed kcs_bmc_cdev_raw.c interface would be > > > what corresponds to the other side of > > > drivers/input/serio/i8042.c+userio.c. > > > > Right. I guess the question is should we be splitting kernel subsystems > > along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe > > we can consolidate in the future if it makes sense? > > We actually have a number of subsystems with somewhat overlapping > functionality. I brought up serio, because it has an abstraction for multiple > things that communicate over the keyboard controller and I thought > the problem you were trying to solve was also related to the keyboard > controller. > It is also one of multiple abstractions that allow you to connect a device > to a uart (along with serdev and tty_ldisc, probably at least one more that > you can nest above or below these). > > Consolidating the kcs_bmc.c interface into something that already > exists would obviously be best, but it's not clear which of these that > should be, that depends on the fundamental properties of the hardware > interface. > > > > Then again, these are also on > > > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC > > > KCS), so they would never actually talk to one another. > > > > Well, sort of I guess. On Power systems we don't use the keyboard > > controller for IPMI or keyboards, so we're just kinda exploiting the > > hardware for our own purposes. > > Can you describe in an abstract form what the hardware interface > can do here and what you want from it? I wonder if it could be > part of a higher-level interface such as drivers/mailbox/ instead. It gives us interrupts each way between the host and BMC when we send some (small amount of) data/metadata. Mailbox is possibly a fit for this? We're (ab)using the keyboard controllers to implement a vendor MCTP binding over LPC[1] and also a simple protocol for the (Power) host to trigger BMC debug data capture in the event of issues with other (more complex) in-band communication stacks. The MCTP binding is what requires access to STR. It's feasible that we could implement the debug capture protocol with the serio_raw interface now that I think about it (as it only makes use of data and not status). What's unclear to me right now is what impact that has on the Aspeed/Nuvoton KCS drivers we have in the IPMI subsystem. If we can do something sensible to service both serio and IPMI with the one driver implementation then I can put together a PoC for the debug data stuff using serio_raw. Regarding the MCTP binding, Jeremy Kerr is working in an in-kernel, socket-based implementation of MCTP. Eventually this will allow us to bury the KCS details in the MCTP subsystem, which removes some of the motivation for the raw interface here. Andrew [1] https://github.com/openbmc/libmctp/blob/master/docs/bindings/vendor-ibm-astlpc.md ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery wrote: > On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote: > > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > > > > > 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. > > > > > > > > I only noticed the series after Joel asked about the DT changes on the > > > > arm > > > > side. One question though: > > > > > > > > How does this related to the drivers/input/serio/ framework that also > > > > talks > > > > to the keyboard controller for things that are not keyboards? > > > > > > I've taken a brief look and I feel they're somewhat closely related. > > > > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > > > KCS drivers move under drivers/input/serio. If you squint, the i8042 > > > serio device driver has similarities with what the Aspeed and Nuvoton > > > device drivers are providing to the KCS IPMI stack. > > > > After looking some more into it, I finally understood that the two are > > rather complementary. While the drivers/char/ipmi/kcs_bmc.c > > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems > > that the proposed kcs_bmc_cdev_raw.c interface would be > > what corresponds to the other side of > > drivers/input/serio/i8042.c+userio.c. > > Right. I guess the question is should we be splitting kernel subsystems > along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe > we can consolidate in the future if it makes sense? We actually have a number of subsystems with somewhat overlapping functionality. I brought up serio, because it has an abstraction for multiple things that communicate over the keyboard controller and I thought the problem you were trying to solve was also related to the keyboard controller. It is also one of multiple abstractions that allow you to connect a device to a uart (along with serdev and tty_ldisc, probably at least one more that you can nest above or below these). Consolidating the kcs_bmc.c interface into something that already exists would obviously be best, but it's not clear which of these that should be, that depends on the fundamental properties of the hardware interface. > > Then again, these are also on > > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC > > KCS), so they would never actually talk to one another. > > Well, sort of I guess. On Power systems we don't use the keyboard > controller for IPMI or keyboards, so we're just kinda exploiting the > hardware for our own purposes. Can you describe in an abstract form what the hardware interface can do here and what you want from it? I wonder if it could be part of a higher-level interface such as drivers/mailbox/ instead. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote: > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > > > 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. > > > > > > I only noticed the series after Joel asked about the DT changes on the arm > > > side. One question though: > > > > > > How does this related to the drivers/input/serio/ framework that also > > > talks > > > to the keyboard controller for things that are not keyboards? > > > > I've taken a brief look and I feel they're somewhat closely related. > > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > > KCS drivers move under drivers/input/serio. If you squint, the i8042 > > serio device driver has similarities with what the Aspeed and Nuvoton > > device drivers are providing to the KCS IPMI stack. > > After looking some more into it, I finally understood that the two are > rather complementary. While the drivers/char/ipmi/kcs_bmc.c > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems > that the proposed kcs_bmc_cdev_raw.c interface would be > what corresponds to the other side of > drivers/input/serio/i8042.c+userio.c. Right. I guess the question is should we be splitting kernel subsystems along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe we can consolidate in the future if it makes sense? > Then again, these are also on > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC > KCS), so they would never actually talk to one another. Well, sort of I guess. On Power systems we don't use the keyboard controller for IPMI or keyboards, so we're just kinda exploiting the hardware for our own purposes. > > > Both the KCS IPMI and raw chardev I've implemented in this patch need > > both read and write access to the status register (STR). serio could > > potentially expose its value through serio_interrupt() using the > > SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this > > sentence. We'd need some extra support for writing STR via the serio > > API. I'm not sure that fits into the abstraction (unless we make > > serio_write() take a flags argument?). > > > > In that vein, the serio_raw interface is close to the functionality > > that the raw chardev provides in this patch, though again serio_raw > > lacks userspace access to STR. Flags are ignored in the ->interrupt() > > callback so all values received via ->interrupt() are exposed as data. > > The result is there's no way to take care of SERIO_OOB_DATA in the > > read() path. Given that, I think we'd have to expose an ioctl() to > > access the STR value after taking care of SERIO_OOB_DATA in > > ->interrupt(). > > > > I'm not sure where that lands us. > > Based on what I looked up, I think you can just forget about my original > question. We have two separate interfaces that use an Intel 8042-style > protocol, but they don't really interact. Right, this is still true given Power doesn't care for keyboards or IPMI via the keyboard controllers; the two still don't interact. Andrew ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > 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. > > > > I only noticed the series after Joel asked about the DT changes on the arm > > side. One question though: > > > > How does this related to the drivers/input/serio/ framework that also talks > > to the keyboard controller for things that are not keyboards? > > I've taken a brief look and I feel they're somewhat closely related. > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > KCS drivers move under drivers/input/serio. If you squint, the i8042 > serio device driver has similarities with what the Aspeed and Nuvoton > device drivers are providing to the KCS IPMI stack. After looking some more into it, I finally understood that the two are rather complementary. While the drivers/char/ipmi/kcs_bmc.c is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems that the proposed kcs_bmc_cdev_raw.c interface would be what corresponds to the other side of drivers/input/serio/i8042.c+userio.c. Then again, these are also on separate ports (0x60 for the keyboard controller, 0xca2 for the BMC KCS), so they would never actually talk to one another. > Both the KCS IPMI and raw chardev I've implemented in this patch need > both read and write access to the status register (STR). serio could > potentially expose its value through serio_interrupt() using the > SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this > sentence. We'd need some extra support for writing STR via the serio > API. I'm not sure that fits into the abstraction (unless we make > serio_write() take a flags argument?). > > In that vein, the serio_raw interface is close to the functionality > that the raw chardev provides in this patch, though again serio_raw > lacks userspace access to STR. Flags are ignored in the ->interrupt() > callback so all values received via ->interrupt() are exposed as data. > The result is there's no way to take care of SERIO_OOB_DATA in the > read() path. Given that, I think we'd have to expose an ioctl() to > access the STR value after taking care of SERIO_OOB_DATA in > ->interrupt(). > > I'm not sure where that lands us. Based on what I looked up, I think you can just forget about my original question. We have two separate interfaces that use an Intel 8042-style protocol, but they don't really interact. Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > 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. > > I only noticed the series after Joel asked about the DT changes on the arm > side. One question though: > > How does this related to the drivers/input/serio/ framework that also talks > to the keyboard controller for things that are not keyboards? I've taken a brief look and I feel they're somewhat closely related. It's plausible that we could wrangle the code so the Aspeed and Nuvoton KCS drivers move under drivers/input/serio. If you squint, the i8042 serio device driver has similarities with what the Aspeed and Nuvoton device drivers are providing to the KCS IPMI stack. Both the KCS IPMI and raw chardev I've implemented in this patch need both read and write access to the status register (STR). serio could potentially expose its value through serio_interrupt() using the SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this sentence. We'd need some extra support for writing STR via the serio API. I'm not sure that fits into the abstraction (unless we make serio_write() take a flags argument?). In that vein, the serio_raw interface is close to the functionality that the raw chardev provides in this patch, though again serio_raw lacks userspace access to STR. Flags are ignored in the ->interrupt() callback so all values received via ->interrupt() are exposed as data. The result is there's no way to take care of SERIO_OOB_DATA in the read() path. Given that, I think we'd have to expose an ioctl() to access the STR value after taking care of SERIO_OOB_DATA in ->interrupt(). I'm not sure where that lands us. Dmitry, any thoughts here? > Are these > separate communication channels on adjacent I/O ports, or does there > need to be some arbitration? As it stands there's no arbitration. Cheers, Andrew ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > 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. I only noticed the series after Joel asked about the DT changes on the arm side. One question though: How does this related to the drivers/input/serio/ framework that also talks to the keyboard controller for things that are not keyboards? Are these separate communication channels on adjacent I/O ports, or does there need to be some arbitration? Arnd ___ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, 9 Apr 2021, at 14:47, Zev Weiss wrote: > On Fri, Mar 19, 2021 at 01:27:47AM CDT, Andrew Jeffery wrote: > >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 > >machanism for interrupt-signaled control messages while bulk data > > Typo ("mechanism") Ack. > > >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. > > > >Signed-off-by: Andrew Jeffery > >--- > > Documentation/ABI/testing/dev-raw-kcs | 25 ++ > > drivers/char/ipmi/Kconfig | 17 + > > drivers/char/ipmi/Makefile| 1 + > > drivers/char/ipmi/kcs_bmc_cdev_raw.c | 443 ++ > > 4 files changed, 486 insertions(+) > > create mode 100644 Documentation/ABI/testing/dev-raw-kcs > > create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c > > > >diff --git a/Documentation/ABI/testing/dev-raw-kcs > >b/Documentation/ABI/testing/dev-raw-kcs > >new file mode 100644 > >index ..06e7e2071562 > >--- /dev/null > >+++ b/Documentation/ABI/testing/dev-raw-kcs > >@@ -0,0 +1,25 @@ > >+What: /dev/raw-kcs* > >+Date: 2021-02-15 > >+KernelVersion: 5.13 > >+Contact:open...@lists.ozlabs.org > >+Contact:openipmi-developer@lists.sourceforge.net > >+Contact:Andrew Jeffery > >+Description:``/dev/raw-kcs*`` exposes to userspace the data and > >+status registers of Keyboard-Controller-Style (KCS) IPMI > >+interfaces via read() and write() syscalls. Direct > >+exposure of the data and status registers enables > >+inefficient but arbitrary protocols to be implemented > >+over the device. A typical approach is to use KCS > >+devices for out-of-band signalling for bulk data > >+transfers over other interfaces between a Baseboard > >+Management Controller and its host. > >+ > >++++-+ > >+| Offset | read() | write() | > >++++-+ > >+| 0| IDR | ODR | > >++++-+ > >+| 1| STR | STR | > >++++-+ > >+ > >+Users: libmctp: https://github.com/openbmc/libmctp > >diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig > >index bc5f81899b62..273ac1a1f870 100644 > >--- a/drivers/char/ipmi/Kconfig > >+++ b/drivers/char/ipmi/Kconfig > >@@ -137,6 +137,23 @@ config IPMI_KCS_BMC_CDEV_IPMI > > This support is also available as a module. The module will be > > called kcs_bmc_cdev_ipmi. > > > >+config IPMI_KCS_BMC_CDEV_RAW > >+depends on IPMI_KCS_BMC > >+tristate "Raw character device interface for BMC KCS devices" > >+help > >+ Provides a BMC-side character device directly exposing the > >+ data and status registers of a KCS device to userspace. While > >+ KCS devices are commonly used to implement IPMI message > >+ passing, they provide a general interface for exchange of > >+ interrupts, data and status information between the BMC and > >+ its host. > >+ > >+ Say YES if you wish to use the KCS devices to implement > >+ protocols that are not IPMI. > >+ > >+ This support is also available as a module. The module will be > >+ called kcs_bmc_cdev_raw. > >+ > > config ASPEED_BT_IPMI_BMC > > depends on ARCH_ASPEED || COMPILE_TEST > > depends on REGMAP && REGMAP_MMIO && MFD_SYSCON > >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile > >index fcfa676afddb..c8cc248ddd90 100644 > >--- a/drivers/char/ipmi/Makefile > >+++ b/drivers/char/ipmi/Makefile > >@@ -24,6 +24,7 @@ obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o > > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o > > obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o > > obj-$(
Re: [Openipmi-developer] [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device interface
On Fri, Mar 19, 2021 at 01:27:47AM CDT, Andrew Jeffery wrote: >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 >machanism for interrupt-signaled control messages while bulk data Typo ("mechanism") >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. > >Signed-off-by: Andrew Jeffery >--- > Documentation/ABI/testing/dev-raw-kcs | 25 ++ > drivers/char/ipmi/Kconfig | 17 + > drivers/char/ipmi/Makefile| 1 + > drivers/char/ipmi/kcs_bmc_cdev_raw.c | 443 ++ > 4 files changed, 486 insertions(+) > create mode 100644 Documentation/ABI/testing/dev-raw-kcs > create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c > >diff --git a/Documentation/ABI/testing/dev-raw-kcs >b/Documentation/ABI/testing/dev-raw-kcs >new file mode 100644 >index ..06e7e2071562 >--- /dev/null >+++ b/Documentation/ABI/testing/dev-raw-kcs >@@ -0,0 +1,25 @@ >+What: /dev/raw-kcs* >+Date: 2021-02-15 >+KernelVersion:5.13 >+Contact: open...@lists.ozlabs.org >+Contact: openipmi-developer@lists.sourceforge.net >+Contact: Andrew Jeffery >+Description: ``/dev/raw-kcs*`` exposes to userspace the data and >+ status registers of Keyboard-Controller-Style (KCS) IPMI >+ interfaces via read() and write() syscalls. Direct >+ exposure of the data and status registers enables >+ inefficient but arbitrary protocols to be implemented >+ over the device. A typical approach is to use KCS >+ devices for out-of-band signalling for bulk data >+ transfers over other interfaces between a Baseboard >+ Management Controller and its host. >+ >+ +++-+ >+ | Offset | read() | write() | >+ +++-+ >+ | 0| IDR | ODR | >+ +++-+ >+ | 1| STR | STR | >+ +++-+ >+ >+Users:libmctp: https://github.com/openbmc/libmctp >diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig >index bc5f81899b62..273ac1a1f870 100644 >--- a/drivers/char/ipmi/Kconfig >+++ b/drivers/char/ipmi/Kconfig >@@ -137,6 +137,23 @@ config IPMI_KCS_BMC_CDEV_IPMI > This support is also available as a module. The module will be > called kcs_bmc_cdev_ipmi. > >+config IPMI_KCS_BMC_CDEV_RAW >+ depends on IPMI_KCS_BMC >+ tristate "Raw character device interface for BMC KCS devices" >+ help >+Provides a BMC-side character device directly exposing the >+data and status registers of a KCS device to userspace. While >+KCS devices are commonly used to implement IPMI message >+passing, they provide a general interface for exchange of >+interrupts, data and status information between the BMC and >+its host. >+ >+Say YES if you wish to use the KCS devices to implement >+protocols that are not IPMI. >+ >+This support is also available as a module. The module will be >+called kcs_bmc_cdev_raw. >+ > config ASPEED_BT_IPMI_BMC > depends on ARCH_ASPEED || COMPILE_TEST > depends on REGMAP && REGMAP_MMIO && MFD_SYSCON >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile >index fcfa676afddb..c8cc248ddd90 100644 >--- a/drivers/char/ipmi/Makefile >+++ b/drivers/char/ipmi/Makefile >@@ -24,6 +24,7 @@ obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o > obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o > obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o >+obj-$(CONFIG_IPMI_KCS_BMC_CDEV_RAW) += kcs_bmc_cdev_raw.o > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o > obj-
[Openipmi-developer] [PATCH v2 16/21] 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 machanism 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. Signed-off-by: Andrew Jeffery --- Documentation/ABI/testing/dev-raw-kcs | 25 ++ drivers/char/ipmi/Kconfig | 17 + drivers/char/ipmi/Makefile| 1 + drivers/char/ipmi/kcs_bmc_cdev_raw.c | 443 ++ 4 files changed, 486 insertions(+) create mode 100644 Documentation/ABI/testing/dev-raw-kcs create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c diff --git a/Documentation/ABI/testing/dev-raw-kcs b/Documentation/ABI/testing/dev-raw-kcs new file mode 100644 index ..06e7e2071562 --- /dev/null +++ b/Documentation/ABI/testing/dev-raw-kcs @@ -0,0 +1,25 @@ +What: /dev/raw-kcs* +Date: 2021-02-15 +KernelVersion: 5.13 +Contact: open...@lists.ozlabs.org +Contact: openipmi-developer@lists.sourceforge.net +Contact: Andrew Jeffery +Description: ``/dev/raw-kcs*`` exposes to userspace the data and + status registers of Keyboard-Controller-Style (KCS) IPMI + interfaces via read() and write() syscalls. Direct + exposure of the data and status registers enables + inefficient but arbitrary protocols to be implemented + over the device. A typical approach is to use KCS + devices for out-of-band signalling for bulk data + transfers over other interfaces between a Baseboard + Management Controller and its host. + + +++-+ + | Offset | read() | write() | + +++-+ + | 0| IDR | ODR | + +++-+ + | 1| STR | STR | + +++-+ + +Users: libmctp: https://github.com/openbmc/libmctp diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig index bc5f81899b62..273ac1a1f870 100644 --- a/drivers/char/ipmi/Kconfig +++ b/drivers/char/ipmi/Kconfig @@ -137,6 +137,23 @@ config IPMI_KCS_BMC_CDEV_IPMI This support is also available as a module. The module will be called kcs_bmc_cdev_ipmi. +config IPMI_KCS_BMC_CDEV_RAW + depends on IPMI_KCS_BMC + tristate "Raw character device interface for BMC KCS devices" + help + Provides a BMC-side character device directly exposing the + data and status registers of a KCS device to userspace. While + KCS devices are commonly used to implement IPMI message + passing, they provide a general interface for exchange of + interrupts, data and status information between the BMC and + its host. + + Say YES if you wish to use the KCS devices to implement + protocols that are not IPMI. + + This support is also available as a module. The module will be + called kcs_bmc_cdev_raw. + config ASPEED_BT_IPMI_BMC depends on ARCH_ASPEED || COMPILE_TEST depends on REGMAP && REGMAP_MMIO && MFD_SYSCON diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile index fcfa676afddb..c8cc248ddd90 100644 --- a/drivers/char/ipmi/Makefile +++ b/drivers/char/ipmi/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o +obj-$(CONFIG_IPMI_KCS_BMC_CDEV_RAW) += kcs_bmc_cdev_raw.o obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o diff --git a/drivers/char/ipmi/kcs_bmc_cdev_raw.c b/drivers/char/ipmi/kcs_bmc_cdev_raw.c new file mode 100644 index