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@xxxxxxxxxxxxxxxxxx> wrote: > > >> From: "Edward A. James"<eajames@xxxxxxxxxx> > >> > >> 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:
signature.asc
Description: This is a digitally signed message part
