Message-ID: <47ba74aa23a5c4fb42660d5b40e974c24acf24bf.camel@sipsolutions.net>
Subject: 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>
Date:   Fri, 19 Nov 2021 09:31:47 +0100
In-Reply-To: <2b18f86924c3d64437aa139f6401ee2e7705eeb0.camel@gmail.com>
References: <2b18f86924c3d64437aa139f6401ee2e7705eeb0.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.1 (3.42.1-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 2021-11-18 at 16:11 -0800, James Prestwood wrote:
> Hi,
> 
> I see CMD_SET_CHANNEL is only supported for AP-type iftypes (AP,
> P2P_GO, etc). While this definitely makes sense in most cases,
> protocols like p2p/dpp require going off channel for an undetermined
> amount of time.
> 
> I could go into the exact scenarios but in short your REMAIN_ON_CHANNEL
> could end at very inconvenient times.
> 
> Specifically when a station is not associated to any AP is there any
> harm in allowing CMD_SET_CHANNEL? Is this purely a software limitation
> or do drivers not allow this?
> 
> If this sounds reasonable (and possible)

I don't think this *works* because you don't have a way to say "I want
to now go back to idle". And sitting on a channel arbitrarily can
consume quite a bit of power.

So you'd have to add an API to cancel it again, but then realistically
we'd probably want to be able to cancel it if userspace forgets (ie.
give it a timeout), at which point it's basically equivalent to a
longer-than-you-needed remain-on-channel that you cancel after you're
done?

johannes