Messages in this thread | | | Subject | Re: [PATCH 2/2] fsi: sbefifo: implement FSI_SBEFIFO_READ_TIMEOUT ioctl | From | Amitay Isaacs <> | Date | Wed, 15 Dec 2021 17:06:13 +1100 |
| |
Hi Andrew,
On Wed, 2021-12-15 at 16:13 +1030, Andrew Jeffery wrote: > Hi Amitay, > > On Wed, 15 Dec 2021, at 11:28, Amitay Isaacs wrote: > > FSI_SBEFIFO_READ_TIMEOUT ioctl sets the read timeout (in seconds) > > for > > the response to *the next* chip-op sent to sbe. The timeout value > > is > > reset to default after the chip-op. > > For the user? Why reset it automatically? To avoid unexpected > surprises in existing code?
Ideally I would prefer the timeout as an argument for the read() call, so it's specific to that read call and nothing else. Of course, this simplifies the user-space code that needs to issue only a single ioctl before the "long" chip-ops.
I am fine with using the ioctl to just set the timeout value also.
> > > The timeout affects only the read() > > operation on sbefifo device fd. > > > > Signed-off-by: Amitay Isaacs <amitay@ozlabs.org> > > --- > > drivers/fsi/fsi-sbefifo.c | 42 > > +++++++++++++++++++++++++++++++++++++++ > > include/uapi/linux/fsi.h | 6 ++++++ > > 2 files changed, 48 insertions(+) > > > > diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c > > index 9188161f440c..b2654b143b85 100644 > > --- a/drivers/fsi/fsi-sbefifo.c > > +++ b/drivers/fsi/fsi-sbefifo.c > > @@ -32,6 +32,8 @@ > > #include <linux/vmalloc.h> > > #include <linux/mm.h> > > > > +#include <uapi/linux/fsi.h> > > + > > /* > > * The SBEFIFO is a pipe-like FSI device for communicating with > > * the self boot engine on POWER processors. > > @@ -134,6 +136,7 @@ struct sbefifo_user { > > void *cmd_page; > > void *pending_cmd; > > size_t pending_len; > > + uint32_t read_timeout_ms; > > }; > > > > static DEFINE_MUTEX(sbefifo_ffdc_mutex); > > @@ -796,6 +799,7 @@ static int sbefifo_user_open(struct inode > > *inode, > > struct file *file) > > return -ENOMEM; > > } > > mutex_init(&user->file_lock); > > + user->read_timeout_ms = SBEFIFO_TIMEOUT_START_RSP; > > > > return 0; > > } > > @@ -838,7 +842,11 @@ static ssize_t sbefifo_user_read(struct file > > *file, char __user *buf, > > rc = mutex_lock_interruptible(&sbefifo->lock); > > if (rc) > > goto bail; > > + sbefifo->timeout_start_rsp_ms = user->read_timeout_ms; > > rc = __sbefifo_submit(sbefifo, user->pending_cmd, cmd_len, > > &resp_iter); > > + /* Reset the read timeout after a single chip-op */ > > + sbefifo->timeout_start_rsp_ms = SBEFIFO_TIMEOUT_START_RSP; > > + user->read_timeout_ms = SBEFIFO_TIMEOUT_START_RSP; > > I guess I was querying this one > > > mutex_unlock(&sbefifo->lock); > > if (rc < 0) > > goto bail; > > @@ -847,6 +855,7 @@ static ssize_t sbefifo_user_read(struct file > > *file, > > char __user *buf, > > rc = len - iov_iter_count(&resp_iter); > > bail: > > sbefifo_release_command(user); > > + user->read_timeout_ms = 0; > > mutex_unlock(&user->file_lock); > > return rc; > > } > > @@ -928,12 +937,45 @@ static int sbefifo_user_release(struct inode > > *inode, struct file *file) > > return 0; > > } > > > > +static int sbefifo_read_timeout(struct sbefifo_user *user, void > > __user > > **argp) > > +{ > > + uint32_t timeout; > > + > > + if (get_user(timeout, (__u32 __user *)argp)) > > Hmm > > > + return -EFAULT; > > + if (timeout < 10 || timeout > 120) > > + return -EINVAL; > > + > > + user->read_timeout_ms = timeout * 1000; /* user timeout is > > in sec */ > > + return 0; > > +} > > + > > +static long sbefifo_user_ioctl(struct file *file, unsigned int > > cmd, > > unsigned long arg) > > +{ > > + struct sbefifo_user *user = file->private_data; > > + void __user **argp = (void __user *)arg; > > Why are we doing strange things with the pointer types?
That's what the ioctl implementation for fsi does. (Monkey see, monkey copy!) :-)
> > Andrew > > > + int rc = -ENOTTY; > > + > > + if (!user) > > + return -EINVAL; > > + > > + mutex_lock(&user->file_lock); > > + switch (cmd) { > > + case FSI_SBEFIFO_READ_TIMEOUT: > > + rc = sbefifo_read_timeout(user, argp); > > + break; > > + } > > + mutex_unlock(&user->file_lock); > > + return rc; > > +} > > + > > static const struct file_operations sbefifo_fops = { > > .owner = THIS_MODULE, > > .open = sbefifo_user_open, > > .read = sbefifo_user_read, > > .write = sbefifo_user_write, > > .release = sbefifo_user_release, > > + .unlocked_ioctl = sbefifo_user_ioctl, > > }; > > > > static void sbefifo_free(struct device *dev) > > diff --git a/include/uapi/linux/fsi.h b/include/uapi/linux/fsi.h > > index da577ecd90e7..3e00874ace22 100644 > > --- a/include/uapi/linux/fsi.h > > +++ b/include/uapi/linux/fsi.h > > @@ -55,4 +55,10 @@ struct scom_access { > > #define FSI_SCOM_WRITE _IOWR('s', 0x02, struct scom_access) > > #define FSI_SCOM_RESET _IOW('s', 0x03, __u32) > > > > +/* > > + * /dev/sbefifo* ioctl interface > > + */ > > + > > +#define FSI_SBEFIFO_READ_TIMEOUT _IOW('s', 0x00, __u32) > > + > > #endif /* _UAPI_LINUX_FSI_H */ > > -- > > 2.33.1
Amitay. --
There will always be rocks in the road ahead of you. They will be stumbling blocks or stepping stones; It all depends on how you use them
| |