From: Corey Minyard <minyard@acm.org>
To: Quan Nguyen <quan@os.amperecomputing.com>
Cc: devicetree@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
Andrew Jeffery <andrew@aj.id.au>,
openbmc@lists.ozlabs.org,
"Thang Q . Nguyen" <thang@os.amperecomputing.com>,
linux-kernel@vger.kernel.org,
Phong Vo <phong@os.amperecomputing.com>,
Wolfram Sang <wsa@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
openipmi-developer@lists.sourceforge.net,
Open Source Submission <patches@amperecomputing.com>,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2 0/3] Add Aspeed SSIF BMC driver
Date: Wed, 7 Apr 2021 09:28:28 -0500 [thread overview]
Message-ID: <20210407142828.GE7166@minyard.net> (raw)
In-Reply-To: <0e7fceff-4a01-5cb0-72eb-8b47d598f1c3@os.amperecomputing.com>
On Wed, Apr 07, 2021 at 08:09:50PM +0700, Quan Nguyen wrote:
> Hi Corey,
>
> Thank you for reviewing
> I'll put my respond inline below.
>
> -Quan
>
> On 02/04/2021 21:21, Corey Minyard wrote:
> > On Tue, Mar 30, 2021 at 09:10:26PM +0700, Quan Nguyen wrote:
> > > This series add support for the Aspeed specific SSIF BMC driver which
> > > is to perform in-band IPMI communication with the host in management
> > > (BMC) side.
> >
> > I don't have any specific feedback for this, but I'm wondering if it's
> > really necessary.
> >
> > Why can't the BMC just open the I2C device and use it? Is there any
> > functionality that this provides that cannot be accomplished from
> > userland access to the I2C device? I don't see any.
> >
> > If it tied into some existing framework to give abstract access to a BMC
> > slave side interface, I'd be ok with this. But I don't see that.
> >
>
> The SSIF at the BMC side acts as an I2C slave and we think that the kernel
> driver is unavoidable to handle the I2c slave events
> (https://www.kernel.org/doc/html/latest/i2c/slave-interface.html)
>
> And to make it works with existing OpenBMC IPMI stack, a userspace part,
> ssifbridge, is needed (https://github.com/openbmc/ssifbridge). This
> ssifbridge is to connect this driver with the OpenBMC IPMI stack so the IPMI
> stack can communicate via SSIF channel in similar way that was implemented
> with BT and KCS (ie: btbridge/kcsbridge and its corespondent kernel drivers
> (https://github.com/openbmc/btbridge and
> https://github.com/openbmc/kcsbridge))
Dang, I don't know why there's not a generic userland interface for
the slave. And I've made this mistake before :(.
Anyway, you are right, you need a driver. I'll review.
-corey
>
> > Unless there is a big need to have this in the kernel, I'm against
> > including this and would suggest you do all this work in userland.
> > Perhaps write a library. Sorry, but I'm trying to do my part to reduce
> > unnecessary things in the kernel.
> >
> > Thanks,
> >
> > -corey
> >
prev parent reply other threads:[~2021-04-07 14:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 14:10 [PATCH v2 0/3] Add Aspeed SSIF BMC driver Quan Nguyen
2021-03-30 14:10 ` [PATCH v2 1/3] i2c: i2c-core-smbus: Expose PEC calculate function for generic use Quan Nguyen
2021-03-30 14:10 ` [PATCH v2 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver Quan Nguyen
2021-04-02 12:01 ` Philipp Zabel
2021-04-07 7:23 ` Quan Nguyen
2021-04-07 15:50 ` Corey Minyard
2021-04-22 10:49 ` Graeme Gregory
2021-03-30 14:10 ` [PATCH v2 3/3] bindings: ipmi: Add binding for " Quan Nguyen
2021-04-01 17:09 ` Rob Herring
2021-04-02 1:59 ` Quan Nguyen
2021-04-02 14:21 ` [PATCH v2 0/3] Add " Corey Minyard
2021-04-07 13:09 ` Quan Nguyen
2021-04-07 14:28 ` Corey Minyard [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=20210407142828.GE7166@minyard.net \
--to=minyard@acm.org \
--cc=andrew@aj.id.au \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=p.zabel@pengutronix.de \
--cc=patches@amperecomputing.com \
--cc=phong@os.amperecomputing.com \
--cc=quan@os.amperecomputing.com \
--cc=robh+dt@kernel.org \
--cc=thang@os.amperecomputing.com \
--cc=wsa@kernel.org \
/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).