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)?
Konrad
