Users of SBE FIFO kernel driver

[Brad Bishop]

Trying to keep this discussion going.

> On Feb 10, 2017, at 1:58 AM, Venkatesh Sainath <vsainath at linux.vnet.ibm.com> wrote:
> 
> 
> 
> On 10/02/17 2:46 AM, Patrick Williams wrote:
>> On Sat, Feb 04, 2017 at 04:35:30PM +0530, Venkatesh Sainath wrote:
>>>> Where do we stand with the sbei protocol device driver?  Who owns this
>>>> and is it complete?
>>>> 
>>> The plan was to port the sbei protocol driver developed on FSP based
>>> systems. Chris: I believe Dhruvaraj discussed with you about this driver
>>> when he was in Austin. I can share the latest version of this driver.
>> Is this "driver" really a driver in the Linux sense or is it a shared
>> library that is used in FSP userspace?  Whatever code we end up using we
>> eventually need it to be upstream-able into the real Linux kernel.
> This is not really a driver in the Linux sense. It is a shared lib in FSP user space. As the OCC driver has to use this SBEI protocol, we  have to implement this as a Linux driver in OpenBMC
>> Is this something that Dhruv can take on or is this going to be left to
>> Chris?  How do we handle divergence between the open-source code and the
>> IBM proprietary version (the one direction is an IBM-internal problem,
>> but I have concern that future development will only be happening on
>> the proprietary one and we'll have to keep playing catch up).
>> 
> The SBE interfaces are open-sourced and there may not be any proprietary implementation here. However, the code architecture between FSP and OpenBMC is different ( FSP - user space and OpenBMC - Linux driver ) and hence we will have to maintain two streams. The HWSV team can implement  it as a Linux driver in OpenBMC and deliver it in stages. Any defect fixes in future can be done by the same team on both streams. I will ask Sachin Gupta to sync up with Chris. As of now, we need only Get/Put Memory, Get/Put Scom and Get/Put SRAM for enabling OCC and HW access.

Are these things what were referred to previously in the thread as ‘chip-ops’ ?

If they are, then an SBEI protocol device driver sounds to me like chip-ops in the kernel but previously there were a number of statements from multiple people along these lines:

> However we certainly don't want to put chip-ops directly in the kernel.
> Agreed. This driver is to control access to the FIFO. We don't want to have to modify the kernel every time a new operation is required.
> The programs sending the messages will know how to encode their own operations, such as pdbg, the occ hwmon driver, etc.

Venkatesh - What role do you see the SBEI protocol driver serving?

Joel/Alistair/Ben - So far for in-kernel users we have scom and OCC.  I’m assuming that list will grow somewhat.  Obviously the sbescom driver will need to encode scom operations…but so does the occ driver.  If both drivers encode their own operations, won’t they be writing the same code twice?  Isn’t that going to happen over and over?

Everyone - please poke holes.

thx

-brad




> We can add the remaining interfaces subsequently. As a user of this SBEI protocol driver, we need OCC driver changes, Rest API to call OCC driver, SCOM drivers and user space app (Rest API / ??) to call the SCOM driver.