On Mon, Feb 16, 2026 at 02:36:40PM +0530, Ekansh Gupta wrote:
> On 2/16/2026 8:51 AM, Bjorn Andersson wrote:
> > On Sun, Feb 15, 2026 at 11:51:35PM +0530, Ekansh Gupta wrote:
> >> @@ -1812,6 +1912,30 @@ static int fastrpc_get_info_from_kernel(struct 
> >> fastrpc_ioctl_capability *cap,
> >>    return 0;
> >>  }
> >>  
> >> +static int fastrpc_set_option(struct fastrpc_user *fl, char __user *argp)
> >> +{
> >> +  struct fastrpc_ioctl_set_option opt = {0};
> >> +  int i;
> >> +
> >> +  if (copy_from_user(&opt, argp, sizeof(opt)))
> >> +          return -EFAULT;
> >> +
> >> +  for (i = 0; i < ARRAY_SIZE(opt.reserved); i++) {
> >> +          if (opt.reserved[i] != 0)
> >> +                  return -EINVAL;
> >> +  }
> >> +
> >> +  if (opt.req != FASTRPC_POLL_MODE)
> >> +          return -EINVAL;
> >> +
> >> +  if (opt.value)
> > Would it make sense to allow the caller to affect the poll timeout using
> > the other 31 bits of this value?
> I was planning to bring that control[1], but it's might be difficult for the 
> caller
> 

Skimming through the thread, it seems you're discussing how to determine
if the DSP supports polling or not; that sounds like a separate problem
in my view. Not sure if you settled that discussion, but couldn't that
be handled through FASTRPC_IOCTL_GET_DSP_INFO?

I assume though, this would be subject to firmware changes. How do you
determine downstream if polling should be used or not today?


For my specific question here, I'm merely wondering if the timeout value
should be a boolean or have a unit. We could punt on that question, to
not block this feature from making progress upstream, by defining that
only 0 and 1 are valid values today (all other result in -EINVAL).

This would leave the door open for having 0 == off, 1 == default, > 1
represent the actual timeout in microseconds in the future.

Treating any non-zero value as "the default timeout" means that you
would have to assume that there's userspace who might pass other values
and you can't add additional meaning to the field in the future.

Regards,
Bjorn

> [1] 
> https://lore.kernel.org/all/[email protected]/
> 
> //Ekansh

Reply via email to