linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benoit PAPILLAULT <benoit.papillault@free.fr>
To: Pavel Roskin <proski@gnu.org>
Cc: lrodriguez@atheros.com, ath5k-devel@lists.ath5k.org,
	linux-wireless@vger.kernel.org, ath9k-devel@lists.ath5k.org
Subject: Re: [ath5k-devel] [PATCH] ath5k/ath9k: Fix 64 bits TSF reads
Date: Sat, 17 Apr 2010 15:27:58 +0200	[thread overview]
Message-ID: <4BC9B75E.9070005@free.fr> (raw)
In-Reply-To: <1271452384.16507.16.camel@mj>

Pavel Roskin a écrit :
> On Fri, 2010-04-16 at 00:07 +0200, Benoit Papillault wrote:
>
>   
>> It follows the logic mentionned by Derek, with only 2 register reads
>> needed at each additional steps instead of 3 (the minimum number of
>> register reads is still 3).
>>     
>
> I would prefer an approach whereas tsf_upper2 or tsf_upper1 is chosen
> based on whether tsf_lower is more or less than 0x80000000 if
> (tsf_upper2 - tsf_upper1) is 1.  If the difference is not 0 or 1, either
> the hardware is broken or the kernel was stuck for so long (71 minutes!)
> that getting the exact tsf should be the least worry.  That's when
> WARN_ON would be appropriate.
>
> The problem with overengineered code is that it doesn't break when it's
> better to break and expose the problem :-)
>
> But it's just a suggestion, not a NACK.  It's better to have some fix
> than no fix at all.
>  
>   
Hello Pavel,

You are considering rollover here, but the TSF can make big jumps as 
well (in case of IBSS merges). This later case can only be handled by 
the above code, to my knowledge. I am seeking consistency first and 
optimization next, not the opposite.

We can even consider the case where only the lower TSF has made a small 
jump before reading the higher part and the lower part. However, such 
case cannot be distinguished from a normal case and the resulting value 
will be consistent anyway (since the higher part has not changed).

In the case where tsf_upper2 = tsf_upper1 + 1, this can happen when a 
rollover occurs. It could also happens in case of IBSS merge, in which 
case, your logic won't work. Let's take an example:

real TSF 0x00000001-ffffffc0 => tsf_upper1 = 1
--- rollover ---
real TSF 0x00000001-ffffffc8 => tsf_lower = 0xffffffc8
real TSF 0x00000002-00000008 => tsf_upper2 = 2

In this case, we assume that TSF = 0x00000001-ffffffc8 (since 0xffffffc8 
 > 0x80000000).

real TSF 0x00000001-10000009 => tsf_upper1 = 1
--- HW IBSS merge ---
real TSF 0x00000002-ffffffc8 => tsf_lower = 0xffffffc8
real TSF 0x00000002-ffffffd0 => tsf_upper2 = 2

In this case, we assume that TSF = 0x00000001-ffffffc8 ... which is wrong!

Did I miss something?

Regards,
Benoit


  reply	other threads:[~2010-04-17 13:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-15 22:07 [PATCH] ath5k/ath9k: Fix 64 bits TSF reads Benoit Papillault
2010-04-16 21:13 ` [ath5k-devel] " Pavel Roskin
2010-04-17 13:27   ` Benoit PAPILLAULT [this message]
2010-04-17 23:02     ` Pavel Roskin
2010-04-17 21:33   ` Derek Smithies

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BC9B75E.9070005@free.fr \
    --to=benoit.papillault@free.fr \
    --cc=ath5k-devel@lists.ath5k.org \
    --cc=ath9k-devel@lists.ath5k.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lrodriguez@atheros.com \
    --cc=proski@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).