Users of SBE FIFO kernel driver

[Christopher Bostic]

On 2/1/17 10:48 PM, Venkatesh Sainath wrote:
> I believe there are 2 drivers here. SBE FIFO driver and SBEI protocol 
> driver. The SBEI protocol driver is the only user for the submit 
> operation of SBE FIFO driver (as it requires the protocol knowledge to 
> communicate with SBE). The SBEI protocol driver will be used by OCC 
> and any user-space application that may want to perform a direct HW 
> access over FSI  ( for eg any scom operation).
>
If I understand then the lowest level device driver in the kernel is the 
sbe_fifo driver running on OpenFSI.
The only thing that should have direct access to this is the sbei 
protocol driver - via sbe_fifo submit operations.

Any other code wishing to access the SBE FIFO engine must go through the 
sbei protocol driver.  This would include
OCC hwmon driver, SCOM device driver, as well as any user space 
applications like host debugger/chip ops (potentially boot sequence if 
in fact sbe fifo access is required).

sbei protocol driver must then provide a means for user space to access it.

Where do we stand with the sbei protocol device driver?  Who owns this 
and is it complete?

>
> On 02/02/17 8:59 AM, Joel Stanley wrote:
>> Hi Chris,
>>
>> On Thu, Feb 2, 2017 at 5:58 AM, Christopher Bostic
>> <cbostic at linux.vnet.ibm.com> wrote:
>>> I've not seen this discussed in the group but if this has already been
>>> determined than any pointers to the latest documentation would be
>>> appreciated.
>>>
>>> Who are all the potential users of the OpenBMC SBE FIFO device 
>>> driver?   I
>>> understand it will need to export its general submit interface to other
>>> kernel drivers.  Only one I know of for sure would be the OCC driver 
>>> Eddie
>>> James is working on.
>> In addition to Eddie's driver, in userspace we will have the code that
>> performs the power on sequence.
>>
>>> Any others?
>>>
>>> What about user space access of the SBE FIFO engine?  What apps would
>>> require it?  Cronus I assume will need some means to directly access 
>>> it.
>> We want userspace API and an in-kernel API.
>>
>> The driver you design will need to take into account that there will
>> be multiple users from each of these APIs. For instance, there will be
>> Eddie's OCC hwmon driver and the userspace code that kicks off the
>> boot sequence.
>>
>> Cheers,
>>
>> Joel
>> _______________________________________________
>> openbmc mailing list
>> openbmc at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
>
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc