From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Cyril Bur <cyrilbur@gmail.com>, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org, mikey@neuling.org, joel@jms.id.au,
openbmc@lists.ozlabs.org
Subject: Re: [PATCH v6] drivers/misc: Add Aspeed LPC control driver
Date: Fri, 17 Feb 2017 17:44:57 +1100 [thread overview]
Message-ID: <1487313897.23576.122.camel@kernel.crashing.org> (raw)
In-Reply-To: <20170217032849.23994-1-cyrilbur@gmail.com>
On Fri, 2017-02-17 at 14:28 +1100, Cyril Bur wrote:
> In order to manage server systems, there is typically another
> processor
> known as a BMC (Baseboard Management Controller) which is responsible
> for powering the server and other various elements, sometimes fans,
> often the system flash.
.../...
> It is important to note that due to the way the Aspeed chip lets the
> kernel configure the mapping between host LPC addresses and BMC ram
> addresses the offset within the window must be a multiple of size.
> Not doing so will fragment the accessible space rather than simply
> moving 'zero' upwards. This is caused by the nature of HICR8 being a
> mask and the way host LPC addresses are translated.
>
> Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Greg, quick Q for you:
We will need to also add a mechanism to poke at a few registers
in the same LPC controllers from userspace.
Mostly those are "scratch" registers that the BMC is supposed to set to
specific values to indicates features it supports etc... (or to enable
the host BIOS to run in some kind of verbose debug mode).
Think of it as a communication channel between the BMC and the BIOS
running on the host.
The BMC userspace needs to set them to various platform specific
values as appropriate for a given vendor/system (userspace policy
from the BMC perspective) during boot and/or change them as the result
of some user actions (enable debug mode) etc...
The question here is read/write or sysfs files attached to the
sysfs node ?
The former means userspace needs to "seek" to the right magic
offset to write to one of them which is non-trivial to do from
simple shell scripts but is a more natural interface.
It also means the owner/permissions of the /dev entry as set
by uboot apply which can be nice.
The latter can expose each register by its name which provides
a nice way to echo in/out of them from a shell script.
The drawback is that pretty much restricts access to root.
What do you recommend ?
Cheers,
Ben.
next prev parent reply other threads:[~2017-02-17 6:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-17 3:28 [PATCH v6] drivers/misc: Add Aspeed LPC control driver Cyril Bur
2017-02-17 3:42 ` Joel Stanley
2017-02-17 6:44 ` Benjamin Herrenschmidt [this message]
2017-03-16 8:08 ` Greg KH
2017-02-22 5:11 ` Suraj Jitindar Singh
2017-03-02 1:01 ` Cyril Bur
2017-03-08 1:15 ` Suraj Jitindar Singh
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=1487313897.23576.122.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=cyrilbur@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=mikey@neuling.org \
--cc=openbmc@lists.ozlabs.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).