[PATCH v2 2/2] fsi: sbefifo: implement FSI_SBEFIFO_READ_TIMEOUT ioctl

[Joel Stanley]

Hi Greg,

On Thu, 16 Dec 2021 at 08:04, Greg KH <gregkh at linuxfoundation.org> wrote:
>
> On Thu, Dec 16, 2021 at 05:24:05PM +1100, Amitay Isaacs wrote:
> > FSI_SBEFIFO_READ_TIMEOUT ioctl sets the read timeout (in seconds) for
> > the response received by sbefifo device from sbe.  The timeout affects
> > only the read operation on sbefifo device fd.
> >
> > Certain SBE operations can take long time to complete and the default
> > timeout of 10 seconds might not be sufficient to start receiving
> > response from SBE.  In such cases, allow the timeout to be set to the
> > maximum of 120 seconds.
> >
> > Signed-off-by: Amitay Isaacs <amitay at ozlabs.org>
> > ---
> >  drivers/fsi/fsi-sbefifo.c | 44 +++++++++++++++++++++++++++++++++++++++
> >  include/uapi/linux/fsi.h  | 14 +++++++++++++
> >  2 files changed, 58 insertions(+)

I'm taking over this patch series on behalf of Amitay.

> Where is the userspace tool that uses this new ioctl?

The userspace is a library called 'libpdbg'. Amitay has some patches
prepared that use this new ioctl here:

 https://github.com/amitay/pdbg/commits/ioctl

> And again, why does it have to be an ioctl?  Where is this now
> documented?  What are the units of the value?

We need a way for userspace to tell the driver that subsequent
operations (writes to the chardev, that cause the driver to send data
to a microcontroller over a fsi link) are expected to take a longer
time, so the kernel should wait longer before declaring the operation
timed out.

The kernel driver doesn't know about the specific operation, and we
don't want to have that policy in the kernel, so userspace will set
the timeout appropriately.

I'll send a new version, as Amitay wants to remove the one-shot nature
of the configuration, and instead have it persist. I'll update the
patch to make it clear what the units are.

Where do we usually stick documentation for ioctls such as this one?

Cheers,

Joel