From: Andrew Jeffery <andrew@aj.id.au>
To: Eddie James <eajames@linux.vnet.ibm.com>, Joel Stanley <joel@jms.id.au>
Cc: Guenter Roeck <linux@roeck-us.net>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
jdelvare@suse.com, corbet@lwn.net,
Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Wolfram Sang <wsa@the-dreams.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Edward A. James" <eajames@us.ibm.com>
Subject: Re: [PATCH linux v7 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations
Date: Mon, 13 Feb 2017 11:42:13 +1030 [thread overview]
Message-ID: <1486948333.3661.1.camel@aj.id.au> (raw)
In-Reply-To: <4224dbab-d48c-be48-154d-5ed14dd5231e@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
On Fri, 2017-02-10 at 15:05 -0600, Eddie James wrote:
> On 02/09/2017 11:31 PM, Joel Stanley wrote:
> > > On Wed, Feb 8, 2017 at 9:40 AM,<eajames@linux.vnet.ibm.com> wrote:
> > >> From: "Edward A. James"<eajames@us.ibm.com>
> >>
> >> Add functions to send SCOM operations over I2C bus. The BMC can
> >> communicate with the Power8 host processor over I2C, but needs to use SCOM
> >> operations in order to access the OCC register space.
> > This doesn't need to be separate from the p8_occ_i2c.c file. You can
> > remove a layer of function calls by merging this in and having these
> > be your getscom putscom bus_ops callbacks.
>
> The purpose of having this separate was so that we could do the scom
> address shift for p8 separately.
Separation was my suggestion. It makes the I2C transport implementation
independent of any P8 details, and having it separate* is no more
abstract than the core performing SCOMs through the FSI interface when
that's available. I feel like it's muddying the waters conceptually to
bury P8 details in the implementation of a SCOM transport layer.
However, in our less abstract world the P8 will be the only system that
uses the I2C transport, so while I don't think merging the functions is
a good idea from an abstraction perspective it won't have a big impact.
Andrew
* Maybe the I2C SCOM transport even deserves to live outside
drivers/hwmon/occ?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-02-13 1:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 23:10 [PATCH linux v7 0/6] drivers: hwmon: Add On-Chip Controller driver eajames
2017-02-07 23:10 ` [PATCH linux v7 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs eajames
2017-02-10 5:31 ` Joel Stanley
2017-02-10 21:02 ` Eddie James
2017-02-14 15:36 ` Eddie James
2017-02-07 23:10 ` [PATCH linux v7 2/6] hwmon: occ: Add sysfs interface eajames
2017-02-10 5:31 ` Joel Stanley
2017-02-07 23:10 ` [PATCH linux v7 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations eajames
2017-02-07 23:10 ` eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
2017-02-10 5:31 ` Joel Stanley
2017-02-10 21:05 ` Eddie James
2017-02-13 1:12 ` Andrew Jeffery [this message]
2017-02-07 23:10 ` [PATCH linux v7 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures eajames
2017-02-10 5:31 ` Joel Stanley
2017-02-13 1:17 ` Andrew Jeffery
2017-02-13 1:17 ` Andrew Jeffery
2017-02-13 17:01 ` Guenter Roeck
2017-02-07 23:10 ` [PATCH linux v7 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC eajames
2017-02-10 5:31 ` Joel Stanley
2017-02-07 23:10 ` [PATCH linux v7 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures eajames
2017-02-10 5:31 ` Joel Stanley
2017-02-13 1:29 ` Andrew Jeffery
2017-02-13 1:29 ` Andrew Jeffery
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=1486948333.3661.1.camel@aj.id.au \
--to=andrew@aj.id.au \
--cc=benh@kernel.crashing.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=eajames@linux.vnet.ibm.com \
--cc=eajames@us.ibm.com \
--cc=jdelvare@suse.com \
--cc=joel@jms.id.au \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=wsa@the-dreams.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.