sbefifo userspace api

[Brad Bishop]

Hi Venkatesh

If we put all the chip ops in the kernel then I would agree with you.

However, a number of others have expressed concern with putting the chip ops in the kernel.

Joel/Alistair - can you elaborate on your concerns with this approach of putting the chip-ops in the kernel?

thx - brad



> On Feb 20, 2017, at 12:05 AM, Venkatesh Sainath <vsainath at linux.vnet.ibm.com> wrote:
> 
> Hi Brad,
> 
> I am not sure why we need a user-space api for SBE FIFO driver. Even the pdbg and cronus apps have to go through the SBEI protocol driver in order to construct the packets according to the SBEI interface spec which is done by the SBEI protocol driver only. I think only an in-kernel api is sufficient for the SBE FIFO driver.
> 
> However, for the SBEI protocol driver, we would need both in-kernel ( for use by OCC hwmon ) and user-space api ( for use by pdbg, cronus and rest apis ).
> 
> Thanks
> 
> With regards
> Venkatesh
> 
> On 20/02/17 8:17 AM, Brad Bishop wrote:
>> Thanks Jeremy for the reply.  I’ve added participants from this thread:
>> 
>> https://lists.ozlabs.org/pipermail/openbmc/2017-February/006563.html
>> 
>> in an attempt to consolidate the whole sbefifo design discussion to a single thread.
>> 
>>> Hi Brad,
>>> 
>>>> Looking to start a discussion around possible user space and kernel
>>>> APIs for the POWER9 sbefifo driver.
>>>> 
>>>> There exists today an “alternate" sbefifo driver :-) that provides a
>>>> single submit ioctl.  Applications submit a request and get a reply in
>>>> single system call.
>>>> 
>>>> Is something like that the best approach for an upstream driver?  Or
>>>> should we try something more "pipe like" with read/write interfaces?
>>> It probably depends on the functionality there; ioctl() is useful in
>>> that (as you say) we can handle request and response in a single
>>> syscall, read() / write() may be more appropriate if ordering can be
>>> handled in userspace.
>>> 
>>> Can you add a little description about the functionality we're exposing?
>>> That may suggest a particular API.
>> In terms of hardware its pretty simple.  sbefifo is just two 8-word queues for sending/receiving messages to/from the SBE.  Each queue entry has a single ‘end of transfer’ flag to let the other side know the message is done.
>> 
>> In terms of data flowing through it, there is an SBEI protocol that covers encoding operations (like getscom, getmem, etc.. aka chip-ops) and the SBE response.
>> 
>> For users there seems to be two classes:
>> 
>> 1 - user space wanting to do chip-ops (pdbg, cronus).
>> 2 - device drivers wanting to do chip-ops (occ-hwmon).
>> 
>> If it weren’t for occ-hwmon, it doesn’t seem like there would be any need for the kernel to have any knowledge of the data flowing through the fifo (at the moment anyway).  An sbe-scom driver has been suggested but I wonder what the point of that driver would be, if userspace could simply encode a get/putscom chip-op and use the fifo directly.
>> 
>>>> Would the in-kernel API be the same as the user space API?
>>> Probably not :)
>> I realize they wouldn’t be _exactly_ the same if thats why I got the smiley face :-) ...
>> 
>> But I would have figured they’d at least be similar - meaning if we were go the ‘submit’ route for a UAPI..the kernel
>> would probably not have a split read/write API or vise versa.
>> 
>> So to rephrase the question - would the chardev fops implementation simply be something like this:
>> 
>> sbe-uapi-fops(chardev)
>>    data = copy to/from user space;
>>    sbedev = from_chardev(chardev);
>>    kernel-api(sbedev, data);
>> 
>> Or are the other things to consider here?
>> 
>> -thx
>> 
>> brad
>> 
>>> Cheers,
>>> 
>>> 
>>> Jeremy