All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: Mohammed Shafi <mshajakhan@atheros.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Luis Rodriguez <Luis.Rodriguez@Atheros.com>
Subject: Re: [PATCH] ath9k: make use of slot time macros
Date: Mon, 14 Feb 2011 15:29:17 +0100	[thread overview]
Message-ID: <4D593C3D.4050905@openwrt.org> (raw)
In-Reply-To: <4D5935EF.1060302@atheros.com>

On 2011-02-14 3:02 PM, Mohammed Shafi wrote:
> On Monday 14 February 2011 07:18 PM, Felix Fietkau wrote:
>> On 2011-02-14 5:46 AM, Mohammed Shafi wrote:
>>    
>>> On Monday 14 February 2011 10:11 AM, Mohammed Shafi wrote:
>>>      
>>>> On Friday 11 February 2011 09:59 PM, John W. Linville wrote:
>>>>        
>>>>> On Fri, Feb 11, 2011 at 05:21:06PM +0100, Felix Fietkau wrote:
>>>>>          
>>>>>> On 2011-02-11 5:15 PM, John W. Linville wrote:
>>>>>>            
>>>>>>> On Fri, Feb 11, 2011 at 01:52:23PM +0100, Felix Fietkau wrote:
>>>>>>>              
>>>>>>>> On 2011-02-11 8:01 AM, Mohammed Shafi Shajakhan wrote:
>>>>>>>>                
>>>>>>>>> From: Mohammed Shafi Shajakhan<mshajakhan@atheros.com>
>>>>>>>>>
>>>>>>>>> Instead of using raw numbers to assign slot time it would be
>>>>>>>>> better to
>>>>>>>>> make use of predefined slot time macros
>>>>>>>>>                  
>>>>>>>> How does this make it better?
>>>>>>>>                
>>>>>>> Maybe if it was ATH9K_SHORT_SLOT_TIME it would make more sense?
>>>>>>>              
>>>>>> Well, neither the unit of this variable, nor the values that can be
>>>>>> used
>>>>>> are ath9k specific.
>>>>>>            
>>> Felix  then I don't know why these macros are used here and I followed
>>> the same thing:
>>>
>>> htc_drv_beacon.c 242 if (ah->slottime == ATH9K_SLOT_TIME_20)
>>> init.c           517 sc->beacon.slottime = ATH9K_SLOT_TIME_9;
>>>      
>> Just because the macros are there doesn't mean that it was a good idea
>> to use them. As far as I know, these were simply inherited from the
>> Atheros codebase that ath9k was based on.
>> I actually consider the code more readable without the redundant
>> "ATH9K_SLOT_TIME_" part.
>>    
> Felix I agree the first part, but I could still see no harm in using 
> these macros.
> Initially we  using these values 6,9,20(no other values) for the slot 
> time and there are macros defined for them. If we are using some other 
> values I would agree that its wrong.
> Why not make use of it ?
> IMHO if we use these macros it will at least people who are reading the 
> code there are three standard values 6,9 and 20
How is 6 a standard value? And why use driver specific defines when it's
really an 802.11 standard thing?

Using something like this would make the code more readable:
#define IEEE80211_SHORT_SLOT_TIME	9
#define IEEE80211_LONG_SLOT_TIME	20

ATH9K_SLOT_TIME_9 or ATH9K_SLOT_TIME_20? Not so much...

> I am sure it would help us to debug issues easily(just like Fair beacon 
> distribution thing).
I really don't see how this is helpful in any way.
The main reason why I object to stuff like this is because I think that
"other code is like that" is not a good reason for repeating it,
especially if what was done on the other code never made much sense to
begin with. In this case I think it's more of a reason to clean up the
other code first and then make things more consistent :)

- Felix

  reply	other threads:[~2011-02-14 14:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11  7:01 [PATCH] ath9k: make use of slot time macros Mohammed Shafi Shajakhan
2011-02-11 12:52 ` Felix Fietkau
2011-02-11 16:15   ` John W. Linville
2011-02-11 16:21     ` Felix Fietkau
2011-02-11 16:29       ` John W. Linville
2011-02-14  4:41         ` Mohammed Shafi
2011-02-14  4:46           ` Mohammed Shafi
2011-02-14 13:48             ` Felix Fietkau
2011-02-14 14:02               ` Mohammed Shafi
2011-02-14 14:29                 ` Felix Fietkau [this message]
2011-02-14 14:36                   ` Mohammed Shafi
2011-02-14 20:14           ` John W. Linville
2011-02-15  6:07             ` Mohammed Shafi
2011-02-14  4:35     ` Mohammed Shafi
2011-02-14  4:31   ` Mohammed Shafi

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=4D593C3D.4050905@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=Luis.Rodriguez@Atheros.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mshajakhan@atheros.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.