Re: [PATCH v2 0/7] mt76x02: Beacon support for USB

From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Felix Fietkau <nbd@nbd.name>
Cc: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	Kalle Valo <kvalo@codeaurora.org>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 0/7] mt76x02: Beacon support for USB
Date: Wed, 30 Jan 2019 11:07:49 +0100	[thread overview]
Message-ID: <20190130100748.GA5655@redhat.com> (raw)
In-Reply-To: <ae2324b4-e79c-6984-b29e-5fef77ede672@nbd.name>

On Wed, Jan 30, 2019 at 10:16:34AM +0100, Felix Fietkau wrote:
> On 2019-01-30 09:37, Stanislaw Gruszka wrote:
> > On Tue, Jan 29, 2019 at 01:40:57PM +0100, Lorenzo Bianconi wrote:
> >> > Felix Fietkau <nbd@nbd.name> writes:
> >> > 
> >> > > On 2019-01-29 13:07, Kalle Valo wrote:
> >> > >> Felix Fietkau <nbd@nbd.name> writes:
> >> > >> 
> >> > >>> On 2019-01-29 12:47, Kalle Valo wrote:
> >> > >>>> Stanislaw Gruszka <sgruszka@redhat.com> writes:
> >> > >>>> 
> >> > >>>>> We can configure beaconing, but without TBTT interrupt we
> >> > >>>>> can not support PS buffering. This can be added later using
> >> > >>>>> kernel hrtimer, if we can keep it in sycn with device timer.
> >> > >>>>>
> >> > >>>>> I tested AP and IBSS modes.
> >> > >>>> 
> >> > >>>> So how does this work reliably so that there's no packet loss with
> >> > >>>> clients using power save?
> >> > >>>
> >> > >>> There will be multicast packet loss for clients using power save.
> >> > >> 
> >> > >> Isn't that a problem? At least as a normal user I would very frustrated
> >> > >> if sometimes my connection work and sometimes not, for example if I'm
> >> > >> trying discover devices from my network. Hopefully nobody won't use USB
> >> > >> devices for any real AP stuff, but still enabling something which we
> >> > >> know doesn't work realiably is concerning.
> >> > >
> >> > > I agree. Maybe we should leave out the flag for AP mode in this patch
> >> > > until we have PS buffering and leave the rest of the code intact.
> >> > 
> >> > At least for me that sounds good.
> >> 
> >> We can support ps buffering in AP as well using a hrtimer. In this way we
> >> can reuse most of the existing code
> > 
> > Yes, but there is issue to address, since kernel timer and device TBT
> > timer are independed, they possibly can get out of sync after some time,
> > for example few hours or days. So there is need to prevent/fix this
> > somehow.
> We could read the TSF timer value from the hardware and sync the hrtimer
> against that.

Ok then. I'll implement hrtimer solution and repost this set. Patch
6 will no longer be necessery.

Regards
Stanislaw  