| Message ID | 20210319061952.145040-1-andrew@aj.id.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | ipmi: Allow raw access to KCS devices | expand |
On Fri, Mar 19, 2021 at 01:19:30AM CDT, Andrew Jeffery wrote: >Hello, > >This series is a bit of a mix of things, but its primary purpose is to >expose BMC KCS IPMI devices to userspace in a way that enables userspace >to talk to host firmware using protocols that are not IPMI. > >v1 can be found here: > >https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew@aj.id.au/ > >Changes in v2 include: > >* A rebase onto v5.12-rc2 >* Incorporation of off-list feedback on SerIRQ configuration from > Chiawei >* Further validation on hardware for ASPEED KCS devices 2, 3 and 4 >* Lifting the existing single-open constraint of the IPMI chardev >* Fixes addressing Rob's feedback on the conversion of the ASPEED KCS > binding to dt-schema >* Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts > property definition for the ASPEED KCS binding > >A new chardev device is added whose implementation exposes the Input >Data Register (IDR), Output Data Register (ODR) and Status Register >(STR) via read() and write(), and implements poll() for event >monitoring. > >The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in >a way which encoded the IPMI protocol in its behaviour. However, as >LPC[0] KCS devices give us bi-directional interrupts between the host >and a BMC with both a data and status byte, they are useful for purposes >beyond IPMI. > >As a concrete example, libmctp[1] implements a vendor-defined MCTP[2] >binding using a combination of LPC Firmware cycles for bulk data >transfer and a KCS device via LPC IO cycles for out-of-band protocol >control messages[3]. This gives a throughput improvement over the >standard KCS binding[4] while continuing to exploit the ease of setup of >the LPC bus for early boot firmware on the host processor. > >The series takes a bit of a winding path to achieve its aim: > >1. It begins with patches 1-5 put together by Chia-Wei, which I've >rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other >non-KCS LPC-related ASPEED device drivers in a way that enables the >SerIRQ patches at the end of the series. With Joel's review I'm hoping >these 5 can go through the aspeed tree, and that the rest can go through >the IPMI tree. > >2. Next, patches 6-13 fairly heavily refactor the KCS support in the >IPMI part of the tree, re-architecting things such that it's possible to >support multiple chardev implementations sitting on top of the ASPEED >and Nuvoton device drivers. However, the KCS code didn't really have >great separation of concerns as it stood, so even if we disregard the >multiple-chardev support I think the cleanups are worthwhile. > >3. Patch 14 adds some interrupt management capabilities to the KCS >device drivers in preparation for patch 16, which introduces the new >"raw" KCS device interface. I'm not stoked about the device name/path, >so if people are looking to bikeshed something then feel free to lay >into that. > >4. The remaining patches switch the ASPEED KCS devicetree binding to >dt-schema, add a new interrupt property to describe the SerIRQ behaviour >of the device and finally clean up Serial IRQ support in the ASPEED KCS >driver. > >Rob: The dt-binding patches still come before the relevant driver >changes, I tried to keep the two close together in the series, hence the >bindings changes not being patches 1 and 2. > >I've exercised the series under qemu with the rainier-bmc machine plus >additional patches for KCS support[5]. I've also substituted this series in >place of a hacky out-of-tree driver that we've been using for the >libmctp stack and successfully booted the host processor under our >internal full-platform simulation tools for a Rainier system. > >Note that this work touches the Nuvoton driver as well as ASPEED's, but >I don't have the capability to test those changes or the IPMI chardev >path. Tested-by tags would be much appreciated if you can exercise one >or both. > >Please review! > >Andrew > After rebasing the series onto the OpenBMC dev-5.10 kernel (with only a tiny conflict for the addition of the ast2600 entry in ast_kcs_bmc_match) and enabling CONFIG_IPMI_KCS_BMC_CDEV_IPMI, my e3c246d4i system booted healthily and handled some basic ipmitool operations as expected. Tested-by: Zev Weiss <zweiss@equinix.com> Zev
Hi Corey, On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote: > Hello, > > This series is a bit of a mix of things, but its primary purpose is to > expose BMC KCS IPMI devices to userspace in a way that enables userspace > to talk to host firmware using protocols that are not IPMI. > > v1 can be found here: > > https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew@aj.id.au/ > > Changes in v2 include: > > * A rebase onto v5.12-rc2 > * Incorporation of off-list feedback on SerIRQ configuration from > Chiawei > * Further validation on hardware for ASPEED KCS devices 2, 3 and 4 > * Lifting the existing single-open constraint of the IPMI chardev > * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS > binding to dt-schema > * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts > property definition for the ASPEED KCS binding > > A new chardev device is added whose implementation exposes the Input > Data Register (IDR), Output Data Register (ODR) and Status Register > (STR) via read() and write(), and implements poll() for event > monitoring. > > The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in > a way which encoded the IPMI protocol in its behaviour. However, as > LPC[0] KCS devices give us bi-directional interrupts between the host > and a BMC with both a data and status byte, they are useful for purposes > beyond IPMI. > > As a concrete example, libmctp[1] implements a vendor-defined MCTP[2] > binding using a combination of LPC Firmware cycles for bulk data > transfer and a KCS device via LPC IO cycles for out-of-band protocol > control messages[3]. This gives a throughput improvement over the > standard KCS binding[4] while continuing to exploit the ease of setup of > the LPC bus for early boot firmware on the host processor. > > The series takes a bit of a winding path to achieve its aim: > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other > non-KCS LPC-related ASPEED device drivers in a way that enables the > SerIRQ patches at the end of the series. With Joel's review I'm hoping > these 5 can go through the aspeed tree, and that the rest can go through > the IPMI tree. > > 2. Next, patches 6-13 fairly heavily refactor the KCS support in the > IPMI part of the tree, re-architecting things such that it's possible to > support multiple chardev implementations sitting on top of the ASPEED > and Nuvoton device drivers. However, the KCS code didn't really have > great separation of concerns as it stood, so even if we disregard the > multiple-chardev support I think the cleanups are worthwhile. > > 3. Patch 14 adds some interrupt management capabilities to the KCS > device drivers in preparation for patch 16, which introduces the new > "raw" KCS device interface. I'm not stoked about the device name/path, > so if people are looking to bikeshed something then feel free to lay > into that. > > 4. The remaining patches switch the ASPEED KCS devicetree binding to > dt-schema, add a new interrupt property to describe the SerIRQ behaviour > of the device and finally clean up Serial IRQ support in the ASPEED KCS > driver. > > Rob: The dt-binding patches still come before the relevant driver > changes, I tried to keep the two close together in the series, hence the > bindings changes not being patches 1 and 2. > > I've exercised the series under qemu with the rainier-bmc machine plus > additional patches for KCS support[5]. I've also substituted this series in > place of a hacky out-of-tree driver that we've been using for the > libmctp stack and successfully booted the host processor under our > internal full-platform simulation tools for a Rainier system. > > Note that this work touches the Nuvoton driver as well as ASPEED's, but > I don't have the capability to test those changes or the IPMI chardev > path. Tested-by tags would be much appreciated if you can exercise one > or both. > > Please review! Unfortunately the cover letter got detached from the rest of the series. Any chance you can take a look at the patches? https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ Cheers, Andrew
On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > Hi Corey, > > On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote: > > Hello, > > > > This series is a bit of a mix of things, but its primary purpose is to > > expose BMC KCS IPMI devices to userspace in a way that enables userspace > > to talk to host firmware using protocols that are not IPMI. > > > > v1 can be found here: > > > > https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew@aj.id.au/ > > > > Changes in v2 include: > > > > * A rebase onto v5.12-rc2 > > * Incorporation of off-list feedback on SerIRQ configuration from > > Chiawei > > * Further validation on hardware for ASPEED KCS devices 2, 3 and 4 > > * Lifting the existing single-open constraint of the IPMI chardev > > * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS > > binding to dt-schema > > * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts > > property definition for the ASPEED KCS binding > > > > A new chardev device is added whose implementation exposes the Input > > Data Register (IDR), Output Data Register (ODR) and Status Register > > (STR) via read() and write(), and implements poll() for event > > monitoring. > > > > The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in > > a way which encoded the IPMI protocol in its behaviour. However, as > > LPC[0] KCS devices give us bi-directional interrupts between the host > > and a BMC with both a data and status byte, they are useful for purposes > > beyond IPMI. > > > > As a concrete example, libmctp[1] implements a vendor-defined MCTP[2] > > binding using a combination of LPC Firmware cycles for bulk data > > transfer and a KCS device via LPC IO cycles for out-of-band protocol > > control messages[3]. This gives a throughput improvement over the > > standard KCS binding[4] while continuing to exploit the ease of setup of > > the LPC bus for early boot firmware on the host processor. > > > > The series takes a bit of a winding path to achieve its aim: > > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other > > non-KCS LPC-related ASPEED device drivers in a way that enables the > > SerIRQ patches at the end of the series. With Joel's review I'm hoping > > these 5 can go through the aspeed tree, and that the rest can go through > > the IPMI tree. > > > > 2. Next, patches 6-13 fairly heavily refactor the KCS support in the > > IPMI part of the tree, re-architecting things such that it's possible to > > support multiple chardev implementations sitting on top of the ASPEED > > and Nuvoton device drivers. However, the KCS code didn't really have > > great separation of concerns as it stood, so even if we disregard the > > multiple-chardev support I think the cleanups are worthwhile. > > > > 3. Patch 14 adds some interrupt management capabilities to the KCS > > device drivers in preparation for patch 16, which introduces the new > > "raw" KCS device interface. I'm not stoked about the device name/path, > > so if people are looking to bikeshed something then feel free to lay > > into that. > > > > 4. The remaining patches switch the ASPEED KCS devicetree binding to > > dt-schema, add a new interrupt property to describe the SerIRQ behaviour > > of the device and finally clean up Serial IRQ support in the ASPEED KCS > > driver. > > > > Rob: The dt-binding patches still come before the relevant driver > > changes, I tried to keep the two close together in the series, hence the > > bindings changes not being patches 1 and 2. > > > > I've exercised the series under qemu with the rainier-bmc machine plus > > additional patches for KCS support[5]. I've also substituted this series in > > place of a hacky out-of-tree driver that we've been using for the > > libmctp stack and successfully booted the host processor under our > > internal full-platform simulation tools for a Rainier system. > > > > Note that this work touches the Nuvoton driver as well as ASPEED's, but > > I don't have the capability to test those changes or the IPMI chardev > > path. Tested-by tags would be much appreciated if you can exercise one > > or both. > > > > Please review! > > Unfortunately the cover letter got detached from the rest of the series. > > Any chance you can take a look at the patches? There were some minor concerns that were unanswered, and there really was no review by others for many of the patches. I would like this patch set, it makes some good cleanups. But I would like some more review and testing by others, if possible. I'm fairly sure it has already been done, it just needs to be documented. -corey > > https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ > > Cheers, > > Andrew
On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote: > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > > Hi Corey, > > > > On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote: > > > Hello, > > > > > > This series is a bit of a mix of things, but its primary purpose is to > > > expose BMC KCS IPMI devices to userspace in a way that enables userspace > > > to talk to host firmware using protocols that are not IPMI. > > > > > > v1 can be found here: > > > > > > https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew@aj.id.au/ > > > > > > Changes in v2 include: > > > > > > * A rebase onto v5.12-rc2 > > > * Incorporation of off-list feedback on SerIRQ configuration from > > > Chiawei > > > * Further validation on hardware for ASPEED KCS devices 2, 3 and 4 > > > * Lifting the existing single-open constraint of the IPMI chardev > > > * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS > > > binding to dt-schema > > > * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts > > > property definition for the ASPEED KCS binding > > > > > > A new chardev device is added whose implementation exposes the Input > > > Data Register (IDR), Output Data Register (ODR) and Status Register > > > (STR) via read() and write(), and implements poll() for event > > > monitoring. > > > > > > The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in > > > a way which encoded the IPMI protocol in its behaviour. However, as > > > LPC[0] KCS devices give us bi-directional interrupts between the host > > > and a BMC with both a data and status byte, they are useful for purposes > > > beyond IPMI. > > > > > > As a concrete example, libmctp[1] implements a vendor-defined MCTP[2] > > > binding using a combination of LPC Firmware cycles for bulk data > > > transfer and a KCS device via LPC IO cycles for out-of-band protocol > > > control messages[3]. This gives a throughput improvement over the > > > standard KCS binding[4] while continuing to exploit the ease of setup of > > > the LPC bus for early boot firmware on the host processor. > > > > > > The series takes a bit of a winding path to achieve its aim: > > > > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've > > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other > > > non-KCS LPC-related ASPEED device drivers in a way that enables the > > > SerIRQ patches at the end of the series. With Joel's review I'm hoping > > > these 5 can go through the aspeed tree, and that the rest can go through > > > the IPMI tree. > > > > > > 2. Next, patches 6-13 fairly heavily refactor the KCS support in the > > > IPMI part of the tree, re-architecting things such that it's possible to > > > support multiple chardev implementations sitting on top of the ASPEED > > > and Nuvoton device drivers. However, the KCS code didn't really have > > > great separation of concerns as it stood, so even if we disregard the > > > multiple-chardev support I think the cleanups are worthwhile. > > > > > > 3. Patch 14 adds some interrupt management capabilities to the KCS > > > device drivers in preparation for patch 16, which introduces the new > > > "raw" KCS device interface. I'm not stoked about the device name/path, > > > so if people are looking to bikeshed something then feel free to lay > > > into that. > > > > > > 4. The remaining patches switch the ASPEED KCS devicetree binding to > > > dt-schema, add a new interrupt property to describe the SerIRQ behaviour > > > of the device and finally clean up Serial IRQ support in the ASPEED KCS > > > driver. > > > > > > Rob: The dt-binding patches still come before the relevant driver > > > changes, I tried to keep the two close together in the series, hence the > > > bindings changes not being patches 1 and 2. > > > > > > I've exercised the series under qemu with the rainier-bmc machine plus > > > additional patches for KCS support[5]. I've also substituted this series in > > > place of a hacky out-of-tree driver that we've been using for the > > > libmctp stack and successfully booted the host processor under our > > > internal full-platform simulation tools for a Rainier system. > > > > > > Note that this work touches the Nuvoton driver as well as ASPEED's, but > > > I don't have the capability to test those changes or the IPMI chardev > > > path. Tested-by tags would be much appreciated if you can exercise one > > > or both. > > > > > > Please review! > > > > Unfortunately the cover letter got detached from the rest of the series. > > > > Any chance you can take a look at the patches? > > There were some minor concerns that were unanswered, and there really > was no review by others for many of the patches. Right; I was planning to clean up the minor concerns once I'd received some more feedback. I could have done a better job of communicating that :) > > I would like this patch set, it makes some good cleanups. But I would > like some more review and testing by others, if possible. No worries. I'm trying to rope some others in to take a look. Thanks for the response. Andrew
On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew@aj.id.au> wrote: > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote: > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've > > > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other > > > > non-KCS LPC-related ASPEED device drivers in a way that enables the > > > > SerIRQ patches at the end of the series. With Joel's review I'm hoping > > > > these 5 can go through the aspeed tree, and that the rest can go through > > > > the IPMI tree. > > > > > > > > Please review! > > > > > > Unfortunately the cover letter got detached from the rest of the series. > > > > > > Any chance you can take a look at the patches? > > > > There were some minor concerns that were unanswered, and there really > > was no review by others for many of the patches. > > Right; I was planning to clean up the minor concerns once I'd received > some more feedback. I could have done a better job of communicating > that :) I'll merge the first five through the aspeed tree this coming merge window. We have acks from the relevant maintainers. Arnd: would you prefer that this come as it's own pull request, or as part of the device tree branch? Andrew, Corey: once I've got my pull requests out I'll look at reviewing the rest of the series. Perhaps it would pay to re-send that hunk of patches Andrew with the nits fixed? Cheers, Joel
On Fri, 9 Apr 2021, at 13:37, Joel Stanley wrote: > On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew@aj.id.au> wrote: > > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote: > > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > > > > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've > > > > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other > > > > > non-KCS LPC-related ASPEED device drivers in a way that enables the > > > > > SerIRQ patches at the end of the series. With Joel's review I'm hoping > > > > > these 5 can go through the aspeed tree, and that the rest can go through > > > > > the IPMI tree. > > > > > > > > > > > Please review! > > > > > > > > Unfortunately the cover letter got detached from the rest of the series. > > > > > > > > Any chance you can take a look at the patches? > > > > > > There were some minor concerns that were unanswered, and there really > > > was no review by others for many of the patches. > > > > Right; I was planning to clean up the minor concerns once I'd received > > some more feedback. I could have done a better job of communicating > > that :) > > I'll merge the first five through the aspeed tree this coming merge > window. We have acks from the relevant maintainers. > > Arnd: would you prefer that this come as it's own pull request, or as > part of the device tree branch? > > Andrew, Corey: once I've got my pull requests out I'll look at > reviewing the rest of the series. Perhaps it would pay to re-send that > hunk of patches Andrew with the nits fixed? Yep; Zev has done some reviews for me so I'll address those, rebase on your tree once you've sent out the pull-req and send out a v3. Corey: Are you okay with that for now? Cheers, Andrew
On Fri, Apr 9, 2021 at 6:09 AM Joel Stanley <joel@jms.id.au> wrote: > On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew@aj.id.au> wrote: > > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote: > > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote: > > > There were some minor concerns that were unanswered, and there really > > > was no review by others for many of the patches. > > > > Right; I was planning to clean up the minor concerns once I'd received > > some more feedback. I could have done a better job of communicating > > that :) > > I'll merge the first five through the aspeed tree this coming merge > window. We have acks from the relevant maintainers. > > Arnd: would you prefer that this come as it's own pull request, or as > part of the device tree branch? When you are unsure, it's almost never wrong to go for a separate branch, which gives you a chance to have a concise description of the contents in the tag. This would be particularly helpful if there are incompatible changes to the DT binding that require a justification. If you are only adding a few DT nodes to existing files, then merging these through the regular branch is probably easier. Arnd
Hello, This series is a bit of a mix of things, but its primary purpose is to expose BMC KCS IPMI devices to userspace in a way that enables userspace to talk to host firmware using protocols that are not IPMI. v1 can be found here: https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew@aj.id.au/ Changes in v2 include: * A rebase onto v5.12-rc2 * Incorporation of off-list feedback on SerIRQ configuration from Chiawei * Further validation on hardware for ASPEED KCS devices 2, 3 and 4 * Lifting the existing single-open constraint of the IPMI chardev * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS binding to dt-schema * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts property definition for the ASPEED KCS binding A new chardev device is added whose implementation exposes the Input Data Register (IDR), Output Data Register (ODR) and Status Register (STR) via read() and write(), and implements poll() for event monitoring. The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in a way which encoded the IPMI protocol in its behaviour. However, as LPC[0] KCS devices give us bi-directional interrupts between the host and a BMC with both a data and status byte, they are useful for purposes beyond IPMI. As a concrete example, libmctp[1] implements a vendor-defined MCTP[2] binding using a combination of LPC Firmware cycles for bulk data transfer and a KCS device via LPC IO cycles for out-of-band protocol control messages[3]. This gives a throughput improvement over the standard KCS binding[4] while continuing to exploit the ease of setup of the LPC bus for early boot firmware on the host processor. The series takes a bit of a winding path to achieve its aim: 1. It begins with patches 1-5 put together by Chia-Wei, which I've rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other non-KCS LPC-related ASPEED device drivers in a way that enables the SerIRQ patches at the end of the series. With Joel's review I'm hoping these 5 can go through the aspeed tree, and that the rest can go through the IPMI tree. 2. Next, patches 6-13 fairly heavily refactor the KCS support in the IPMI part of the tree, re-architecting things such that it's possible to support multiple chardev implementations sitting on top of the ASPEED and Nuvoton device drivers. However, the KCS code didn't really have great separation of concerns as it stood, so even if we disregard the multiple-chardev support I think the cleanups are worthwhile. 3. Patch 14 adds some interrupt management capabilities to the KCS device drivers in preparation for patch 16, which introduces the new "raw" KCS device interface. I'm not stoked about the device name/path, so if people are looking to bikeshed something then feel free to lay into that. 4. The remaining patches switch the ASPEED KCS devicetree binding to dt-schema, add a new interrupt property to describe the SerIRQ behaviour of the device and finally clean up Serial IRQ support in the ASPEED KCS driver. Rob: The dt-binding patches still come before the relevant driver changes, I tried to keep the two close together in the series, hence the bindings changes not being patches 1 and 2. I've exercised the series under qemu with the rainier-bmc machine plus additional patches for KCS support[5]. I've also substituted this series in place of a hacky out-of-tree driver that we've been using for the libmctp stack and successfully booted the host processor under our internal full-platform simulation tools for a Rainier system. Note that this work touches the Nuvoton driver as well as ASPEED's, but I don't have the capability to test those changes or the IPMI chardev path. Tested-by tags would be much appreciated if you can exercise one or both. Please review! Andrew [0] https://www.intel.com/content/dam/www/program/design/us/en/documents/low-pin-count-interface-specification.pdf [1] https://github.com/openbmc/libmctp/ [2] https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.1.pdf [3] https://github.com/openbmc/libmctp/blob/master/docs/bindings/vendor-astlpc.md [4] https://www.dmtf.org/sites/default/files/standards/documents/DSP0254_1.0.0.pdf [5] https://lore.kernel.org/qemu-devel/20210309131641.2709380-1-clg@kaod.org/ Andrew Jeffery (16): ipmi: kcs_bmc_aspeed: Use of match data to extract KCS properties ipmi: kcs_bmc: Make status update atomic ipmi: kcs_bmc: Rename {read,write}_{status,data}() functions ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmi ipmi: kcs_bmc: Turn the driver data-structures inside-out ipmi: kcs_bmc: Split headers into device and client ipmi: kcs_bmc: Strip private client data from struct kcs_bmc ipmi: kcs_bmc: Decouple the IPMI chardev from the core ipmi: kcs_bmc: Allow clients to control KCS IRQ state ipmi: kcs_bmc: Don't enforce single-open policy in the kernel ipmi: kcs_bmc: Add a "raw" character device interface dt-bindings: ipmi: Convert ASPEED KCS binding to schema dt-bindings: ipmi: Add optional SerIRQ property to ASPEED KCS devices ipmi: kcs_bmc_aspeed: Implement KCS SerIRQ configuration ipmi: kcs_bmc_aspeed: Fix IBFIE typo from datasheet ipmi: kcs_bmc_aspeed: Optionally apply status address Chia-Wei, Wang (5): dt-bindings: aspeed-lpc: Remove LPC partitioning ARM: dts: Remove LPC BMC and Host partitions ipmi: kcs: aspeed: Adapt to new LPC DTS layout pinctrl: aspeed-g5: Adapt to new LPC device tree layout soc: aspeed: Adapt to new LPC device tree layout Documentation/ABI/testing/dev-raw-kcs | 25 + .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 106 +++ .../bindings/ipmi/aspeed-kcs-bmc.txt | 33 - .../devicetree/bindings/mfd/aspeed-lpc.txt | 100 +-- arch/arm/boot/dts/aspeed-g4.dtsi | 70 +- arch/arm/boot/dts/aspeed-g5.dtsi | 121 ++-- arch/arm/boot/dts/aspeed-g6.dtsi | 123 ++-- drivers/char/ipmi/Kconfig | 30 + drivers/char/ipmi/Makefile | 2 + drivers/char/ipmi/kcs_bmc.c | 534 ++++---------- drivers/char/ipmi/kcs_bmc.h | 94 +-- drivers/char/ipmi/kcs_bmc_aspeed.c | 663 +++++++++++++----- drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 570 +++++++++++++++ drivers/char/ipmi/kcs_bmc_cdev_raw.c | 443 ++++++++++++ drivers/char/ipmi/kcs_bmc_client.h | 47 ++ drivers/char/ipmi/kcs_bmc_device.h | 20 + drivers/char/ipmi/kcs_bmc_npcm7xx.c | 97 ++- drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 17 +- drivers/soc/aspeed/aspeed-lpc-ctrl.c | 20 +- drivers/soc/aspeed/aspeed-lpc-snoop.c | 23 +- 20 files changed, 2132 insertions(+), 1006 deletions(-) create mode 100644 Documentation/ABI/testing/dev-raw-kcs create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_ipmi.c create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c create mode 100644 drivers/char/ipmi/kcs_bmc_client.h create mode 100644 drivers/char/ipmi/kcs_bmc_device.h