On Wed, Feb 18, 2026 at 03:38:28PM +0100, Konrad Dybcio wrote:
>
>
> On 18-Feb-26 15:36, Bjorn Andersson wrote:
> > 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
>
> Giving '1' a special non-numerical meaning sounds odd.. maybe 0:default,
> -1:off (or the opposite)?
>
I guess it comes down to the question of how big the likelihood that you
would want a different value than the default. We should provide sane
defaults and avoid sprinkling unergonomic knobs throughout the system,
but [0,1] and the rest of the bits reserved would leave the door open
for future use of the upper 31 bits.
I find 0 == "enabled" to be unintuitive...
And using -1 means that the bits aren't reserved for future use.
Regards,
Bjorn
> Konrad
