Users of SBE FIFO kernel driver

[Alistair Popple]

Hi,

On Wed, 1 Feb 2017 11:26:42 PM Patrick Williams wrote:
> On Thu, Feb 02, 2017 at 03:48:02PM +1100, Alistair Popple wrote:
> > On Thu, 2 Feb 2017 01:59:08 PM Joel Stanley wrote:
> > > On Thu, Feb 2, 2017 at 5:58 AM, Christopher Bostic
> > > <cbostic at linux.vnet.ibm.com> wrote:
> > > In addition to Eddie's driver, in userspace we will have the code that
> > > performs the power on sequence.
> > 
> > Yep. For example as Ben mentioned the chip-ops also use the SBE FIFO. 
However 
> > we certainly don't want to put chip-ops directly in the kernel. It makes 
more 
> > sense to use a userspace SBE FIFO API to do the chips-ops, power on 
sequence 
> > etc. from userspace.
> 
> What is being referred to here as the "power on sequence" that goes over
> the SBE FIFO?  We do putcfams to start the power on sequence and there
> is no interaction with the FIFO to the best of my knowledge.
> 
> On another topic, when we are under secureboot, get/putscom operations
> need to go through the SBE FIFO.  Should there be a kernel driver for
> SCOM with the same userspace API no matter which path we should go?

I'd be inclined to expose both the SBE-FIFO and direct SCOM access to 
userspace using different instances of the same API (eg. /dev/scomsbe 
/dev/scomdirect - although I'm sure there are better names). That way 
userspace programs can choose which method if required.

> This certainly makes an application like pdbg easier.  One hang-up I can
> think of is I am not sure how we are suppose to know and inform the
> kernel if we can do direct SCOM or SBE-FIFO SCOM.  Maybe we always do
> SBE-FIFO SCOM.

Exactly - everything can just use /dev/scomsbe by default as that should 
always work, secure boot or not. If tools like cronus or pdbg need direct 
access they can just switch to using /dev/scomdirect if needed/configured to.

- Alistair