| Message ID | 20210510054213.1610760-1-andrew@aj.id.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | ipmi: Allow raw access to KCS devices | expand |
Hi Corey, On Mon, 10 May 2021, at 15:11, Andrew Jeffery wrote: > Hello, > > This is the 3rd spin of the series refactoring the keyboard-controller-style > device drivers in the IPMI subsystem. > > v2 can be found (in two parts because yay patch workflow mistakes) at: > > Cover letter: > https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew@aj.id.au/ > > Patches: > https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ > > Several significant changes in v3: > > 1. The series is rebased onto v5.13-rc1 > > 2. v5.13-rc1 includes Chiawei's patches reworking the LPC devicetree bindings, > so they're no-longer required in the series. > > 3. After some discussion with Arnd[1] and investigating the serio subsystem, > I've replaced the "raw" KCS driver (patch 16/21 in v2) with a serio adaptor > (patch 11/16 in this series). The adaptor allows us to take advantage of the > existing chardevs provided by serio. > > [1] > https://lore.kernel.org/linux-arm-kernel/37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com/ > > Finally, I've also addressed Zev Weiss' review comments where I thought it was > required. These comments covered a lot of minor issues across (almost) all the > patches, so it's best to review from a clean slate rather than attempt to review > the differences between spins. I backported this series for OpenBMC and posting those patches provoked some feedback: * A bug identified in patch 9/18 for the Nuvoton driver where we enable the OBE interrupt: https://lore.kernel.org/openbmc/HK2PR03MB4371F006185ADBBF812A5892AE509@HK2PR03MB4371.apcprd03.prod.outlook.com/ * A discussion on patch 10/18 about lifting the single-open constraint https://lore.kernel.org/openbmc/CAPnigKku-EjOnV9gsmnXzH=XZxSU78iLeccNbsK8k2_4b4UwSg@mail.gmail.com/ I need to do a v4 to fix the bug in the Nuvoton driver. Did you have any feedback for the remaining patches or thoughts on the discussions linked above? I'd like to incorporate whatever I can into the series before respinning. Cheers, Andrew
On Thu, May 20, 2021 at 04:21:31PM +0930, Andrew Jeffery wrote: > Hi Corey, > > On Mon, 10 May 2021, at 15:11, Andrew Jeffery wrote: > > Hello, > > > > This is the 3rd spin of the series refactoring the keyboard-controller-style > > device drivers in the IPMI subsystem. > > > > v2 can be found (in two parts because yay patch workflow mistakes) at: > > > > Cover letter: > > https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew@aj.id.au/ > > > > Patches: > > https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ > > > > Several significant changes in v3: > > > > 1. The series is rebased onto v5.13-rc1 > > > > 2. v5.13-rc1 includes Chiawei's patches reworking the LPC devicetree bindings, > > so they're no-longer required in the series. > > > > 3. After some discussion with Arnd[1] and investigating the serio subsystem, > > I've replaced the "raw" KCS driver (patch 16/21 in v2) with a serio adaptor > > (patch 11/16 in this series). The adaptor allows us to take advantage of the > > existing chardevs provided by serio. > > > > [1] > > https://lore.kernel.org/linux-arm-kernel/37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com/ > > > > Finally, I've also addressed Zev Weiss' review comments where I thought it was > > required. These comments covered a lot of minor issues across (almost) all the > > patches, so it's best to review from a clean slate rather than attempt to review > > the differences between spins. > > I backported this series for OpenBMC and posting those patches provoked > some feedback: > > * A bug identified in patch 9/18 for the Nuvoton driver where we enable > the OBE interrupt: > > https://lore.kernel.org/openbmc/HK2PR03MB4371F006185ADBBF812A5892AE509@HK2PR03MB4371.apcprd03.prod.outlook.com/ > > * A discussion on patch 10/18 about lifting the single-open constraint > > https://lore.kernel.org/openbmc/CAPnigKku-EjOnV9gsmnXzH=XZxSU78iLeccNbsK8k2_4b4UwSg@mail.gmail.com/ > > I need to do a v4 to fix the bug in the Nuvoton driver. Did you have any > feedback for the remaining patches or thoughts on the discussions linked > above? I'd like to incorporate whatever I can into the series before > respinning. This will take a little while to review, but I'll try to get to it today. Thanks, -corey > > Cheers, > > Andrew
On Mon, May 10, 2021 at 03:11:57PM +0930, Andrew Jeffery wrote: > Hello, > > This is the 3rd spin of the series refactoring the keyboard-controller-style > device drivers in the IPMI subsystem. This is a nice set of cleanups outside of just allowing raw access. I'll let you handle Zev's comments and a few of mine. I almost hate to ask this, but would there be value in allowing the BT driver to use this abstract interface? Or maybe it would be just too hard to get a common abstraction, more work than it's worth. It's surprising that more people don't want BT as it's vastly superior to KCS. Just a thought for now. I guess there's SMIC, but hopefully nobody wants that. -corey > > v2 can be found (in two parts because yay patch workflow mistakes) at: > > Cover letter: > https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew@aj.id.au/ > > Patches: > https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ > > Several significant changes in v3: > > 1. The series is rebased onto v5.13-rc1 > > 2. v5.13-rc1 includes Chiawei's patches reworking the LPC devicetree bindings, > so they're no-longer required in the series. > > 3. After some discussion with Arnd[1] and investigating the serio subsystem, > I've replaced the "raw" KCS driver (patch 16/21 in v2) with a serio adaptor > (patch 11/16 in this series). The adaptor allows us to take advantage of the > existing chardevs provided by serio. > > [1] https://lore.kernel.org/linux-arm-kernel/37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com/ > > Finally, I've also addressed Zev Weiss' review comments where I thought it was > required. These comments covered a lot of minor issues across (almost) all the > patches, so it's best to review from a clean slate rather than attempt to review > the differences between spins. > > Previously: > > 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 > > Please test and review! > > Andrew > > 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 serio adaptor > 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 > > .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 106 +++ > .../bindings/ipmi/aspeed-kcs-bmc.txt | 33 - > drivers/char/ipmi/Kconfig | 27 + > drivers/char/ipmi/Makefile | 2 + > drivers/char/ipmi/kcs_bmc.c | 526 ++++----------- > drivers/char/ipmi/kcs_bmc.h | 92 +-- > drivers/char/ipmi/kcs_bmc_aspeed.c | 635 +++++++++++++----- > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 568 ++++++++++++++++ > drivers/char/ipmi/kcs_bmc_client.h | 48 ++ > drivers/char/ipmi/kcs_bmc_device.h | 22 + > drivers/char/ipmi/kcs_bmc_npcm7xx.c | 94 ++- > drivers/char/ipmi/kcs_bmc_serio.c | 151 +++++ > 12 files changed, 1582 insertions(+), 722 deletions(-) > 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_client.h > create mode 100644 drivers/char/ipmi/kcs_bmc_device.h > create mode 100644 drivers/char/ipmi/kcs_bmc_serio.c > > -- > 2.27.0 >
Hi Corey, On Sat, 22 May 2021, at 03:06, Corey Minyard wrote: > On Mon, May 10, 2021 at 03:11:57PM +0930, Andrew Jeffery wrote: > > Hello, > > > > This is the 3rd spin of the series refactoring the keyboard-controller-style > > device drivers in the IPMI subsystem. > > This is a nice set of cleanups outside of just allowing raw access. > I'll let you handle Zev's comments and a few of mine. Thanks for taking the time to review the series. I'll address the comments from you both in v4. > > I almost hate to ask this, but would there be value in allowing the BT > driver to use this abstract interface? Hmm. Possibly, but it's not something I've looked at yet. If we did want to go down that path I don't think it would be too difficult, but I don't have a need to touch the BT side of it right now. > Or maybe it would be just too > hard to get a common abstraction, more work than it's worth. It's > surprising that more people don't want BT as it's vastly superior to > KCS. For bulk data, certainly. However for the use-cases I have I'm using the KCS interface as a control channel that isn't data intensive. Interrupts, a small command set (256 values are more than enough) and a status byte are all I'm really after, so BT is more than I need. Plus for the systems I'm working on we're still using BT for in-band IPMI while we transition to MCTP/PLDM. The current BT implementation is working fine for that :) Cheers, Andrew
Hello, This is the 3rd spin of the series refactoring the keyboard-controller-style device drivers in the IPMI subsystem. v2 can be found (in two parts because yay patch workflow mistakes) at: Cover letter: https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew@aj.id.au/ Patches: https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew@aj.id.au/ Several significant changes in v3: 1. The series is rebased onto v5.13-rc1 2. v5.13-rc1 includes Chiawei's patches reworking the LPC devicetree bindings, so they're no-longer required in the series. 3. After some discussion with Arnd[1] and investigating the serio subsystem, I've replaced the "raw" KCS driver (patch 16/21 in v2) with a serio adaptor (patch 11/16 in this series). The adaptor allows us to take advantage of the existing chardevs provided by serio. [1] https://lore.kernel.org/linux-arm-kernel/37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com/ Finally, I've also addressed Zev Weiss' review comments where I thought it was required. These comments covered a lot of minor issues across (almost) all the patches, so it's best to review from a clean slate rather than attempt to review the differences between spins. Previously: 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 Please test and review! Andrew 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 serio adaptor 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 .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 106 +++ .../bindings/ipmi/aspeed-kcs-bmc.txt | 33 - drivers/char/ipmi/Kconfig | 27 + drivers/char/ipmi/Makefile | 2 + drivers/char/ipmi/kcs_bmc.c | 526 ++++----------- drivers/char/ipmi/kcs_bmc.h | 92 +-- drivers/char/ipmi/kcs_bmc_aspeed.c | 635 +++++++++++++----- drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 568 ++++++++++++++++ drivers/char/ipmi/kcs_bmc_client.h | 48 ++ drivers/char/ipmi/kcs_bmc_device.h | 22 + drivers/char/ipmi/kcs_bmc_npcm7xx.c | 94 ++- drivers/char/ipmi/kcs_bmc_serio.c | 151 +++++ 12 files changed, 1582 insertions(+), 722 deletions(-) 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_client.h create mode 100644 drivers/char/ipmi/kcs_bmc_device.h create mode 100644 drivers/char/ipmi/kcs_bmc_serio.c