From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Corey Minyard" <minyard@acm.org>
Cc: openipmi-developer@lists.sourceforge.net,
openbmc@lists.ozlabs.org, devicetree@vger.kernel.org,
"Tomer Maimon" <tmaimon77@gmail.com>,
linux-aspeed@lists.ozlabs.org,
"Avi Fishman" <avifishman70@gmail.com>,
"Patrick Venture" <venture@google.com>,
linux-kernel@vger.kernel.org,
"Tali Perry" <tali.perry1@gmail.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Chia-Wei, Wang" <chiawei_wang@aspeedtech.com>,
linux-arm-kernel@lists.infradead.org,
"Benjamin Fair" <benjaminfair@google.com>,
"Arnd Bergmann" <arnd@arndb.de>, "Zev Weiss" <zweiss@equinix.com>
Subject: Re: [PATCH v3 00/16] ipmi: Allow raw access to KCS devices
Date: Mon, 24 May 2021 10:06:00 +0930 [thread overview]
Message-ID: <e0803983-a385-4972-9dcb-404b2006f674@www.fastmail.com> (raw)
In-Reply-To: <20210521173616.GK2921206@minyard.net>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-05-25 0:02 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 5:41 [PATCH v3 00/16] ipmi: Allow raw access to KCS devices Andrew Jeffery
2021-05-10 5:41 ` [PATCH v3 01/16] ipmi: kcs_bmc_aspeed: Use of match data to extract KCS properties Andrew Jeffery
2021-05-21 7:17 ` Zev Weiss
2021-05-10 5:41 ` [PATCH v3 02/16] ipmi: kcs_bmc: Make status update atomic Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 03/16] ipmi: kcs_bmc: Rename {read, write}_{status, data}() functions Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 04/16] ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmi Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 05/16] ipmi: kcs_bmc: Turn the driver data-structures inside-out Andrew Jeffery
2021-05-21 17:14 ` Corey Minyard
2021-05-24 0:53 ` Andrew Jeffery
2021-05-24 15:41 ` [Openipmi-developer] " Corey Minyard
2021-05-25 0:12 ` Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 06/16] ipmi: kcs_bmc: Split headers into device and client Andrew Jeffery
2021-05-21 7:18 ` Zev Weiss
2021-05-10 5:42 ` [PATCH v3 07/16] ipmi: kcs_bmc: Strip private client data from struct kcs_bmc Andrew Jeffery
2021-05-21 7:18 ` Zev Weiss
2021-05-10 5:42 ` [PATCH v3 08/16] ipmi: kcs_bmc: Decouple the IPMI chardev from the core Andrew Jeffery
2021-05-21 7:19 ` Zev Weiss
2021-05-10 5:42 ` [PATCH v3 09/16] ipmi: kcs_bmc: Allow clients to control KCS IRQ state Andrew Jeffery
2021-05-21 7:19 ` Zev Weiss
2021-05-10 5:42 ` [PATCH v3 10/16] ipmi: kcs_bmc: Don't enforce single-open policy in the kernel Andrew Jeffery
2021-05-21 17:30 ` Corey Minyard
2021-05-24 0:39 ` Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 11/16] ipmi: kcs_bmc: Add serio adaptor Andrew Jeffery
2021-05-21 7:20 ` Zev Weiss
2021-06-08 0:37 ` Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 12/16] dt-bindings: ipmi: Convert ASPEED KCS binding to schema Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 13/16] dt-bindings: ipmi: Add optional SerIRQ property to ASPEED KCS devices Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 14/16] ipmi: kcs_bmc_aspeed: Implement KCS SerIRQ configuration Andrew Jeffery
2021-05-21 7:21 ` Zev Weiss
2021-06-08 0:41 ` Andrew Jeffery
2021-06-08 0:55 ` Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 15/16] ipmi: kcs_bmc_aspeed: Fix IBFIE typo from datasheet Andrew Jeffery
2021-05-10 5:42 ` [PATCH v3 16/16] ipmi: kcs_bmc_aspeed: Optionally apply status address Andrew Jeffery
2021-05-20 6:51 ` [PATCH v3 00/16] ipmi: Allow raw access to KCS devices Andrew Jeffery
2021-05-20 13:33 ` Corey Minyard
2021-05-21 17:36 ` Corey Minyard
2021-05-24 0:36 ` Andrew Jeffery [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e0803983-a385-4972-9dcb-404b2006f674@www.fastmail.com \
--to=andrew@aj.id.au \
--cc=arnd@arndb.de \
--cc=avifishman70@gmail.com \
--cc=benjaminfair@google.com \
--cc=chiawei_wang@aspeedtech.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
--cc=openbmc@lists.ozlabs.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=robh+dt@kernel.org \
--cc=tali.perry1@gmail.com \
--cc=tmaimon77@gmail.com \
--cc=venture@google.com \
--cc=zweiss@equinix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).