Re: Adding CMD_SET_CHANNEL for station iftypes

From: Johannes Berg <johannes@sipsolutions.net>
To: James Prestwood <prestwoj@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: Adding CMD_SET_CHANNEL for station iftypes
Date: Thu, 06 Jan 2022 23:01:05 +0100	[thread overview]
Message-ID: <d8250f97a2be736736374974095f219d858acb1e.camel@sipsolutions.net> (raw)
In-Reply-To: <91d38c40a62100dc6355c98e85b8b793ed8890df.camel@gmail.com>

Hi Preston,

Ugh, sorry. I'm way behind on a whole bunch of emails (about 4 dozen to
be honest) ... trying to catch up, but only so many hours a day.

> So the use case here is to become provisioned with DPP, or discover
> another P2P device. For example, you buy a light bulb, plug it in, and
> want to provision it. Going on channel for small amounts of time can
> only be detremental to the user experience since you are bound to miss
> these discovery type frames and delay the provisioning.

Right.

> As far as power goes, for at least the above use case, there really
> isn't an argument. And its a stretch to find a use case of sitting idle
> as something that anyone wants to do at least for an unprovisioned
> device that is looking to be configured.

Fair point.

> Would there even be a noticable difference in power usage between the
> two scenarios?
> 
>  - Sitting offchannel for 2 minutes
>  - Issuing REMAIN_ON_CHANNEL repeatedly for 2 minutes

Probably not :)

> As far as cancelling CMD_SET_CHANNEL I totally agree. If a device wants
> to go idle for whatever reason that should definitely be possible. I
> think a timer could be avoided using SOCKET_OWNER. So if userspace
> really 'forgets' (crashes or what have you) the device could still be
> brought to idle if that socket closes.

Oh, yeah, good point.

However, looking at something like e.g. iwlwifi, there's no way to
actually implement what you want, you can't, without a time event like
one created by remain-on-channel, actually just "sit" on a channel.

So chances are that, even if we implement the API you'd like, it'd end
up being optional and you'd have to support remain-on-channel usage like
before, even for common devices like iwlwifi. (*)

At which point it's probably not really worth it? Emulating it in the
driver by repeatedly issuing time events also seems like a bad idea,
worse even than doing it in the application, since the application could
at least try to synchronise it a bit with whatever it needs to be doing,
whereas the driver can't do that at all.

(*) and I'm not even sure we can do anything else from a firmware
perspective, or at least it'd probably be a complicated fw change

johannes