from include/linux/ieee80211.h:274:
#define IEEE80211_HT_CAP_SUP_WIDTH 0x0002
---
! has a higher priority than &
Signed-off-by: Roel Kluin <[email protected]>
---
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index d727de8..6576757 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -4589,7 +4589,7 @@ static u8 iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv,
if (sta_ht_inf) {
if ((!sta_ht_inf->ht_supported) ||
- (!sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH))
+ (!(sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH)))
return 0;
}
On Tue, Mar 25, 2008 at 09:30:58AM -0700, Chatre, Reinette wrote:
> On Tuesday, March 25, 2008 9:04 AM, Roel Kluin wrote:
>
> > from include/linux/ieee80211.h:274:
> > #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 ---
> > ! has a higher priority than &
> >
> > Signed-off-by: Roel Kluin <[email protected]>
> > ---
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> > b/drivers/net/wireless/iwlwifi/iwl-4965.c
> > index d727de8..6576757 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
> > @@ -4589,7 +4589,7 @@ static u8
> > iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv,
> >
> > if (sta_ht_inf) {
> > if ((!sta_ht_inf->ht_supported) ||
> > - (!sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH))
> > + (!(sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH)))
> return 0;
> > }
>
> This patch has already been acked and merged into wireless-testing, and
> afaik already pushed further upstream.
Yes, but FWIW the problem exists in the 2.6.25 stream as well.
I've been holding-back a patch to fix it there, trying to decide if it
is worth creating the merge conflict to fix it there. I'm inclined
to think it is better to let things lay as they are and send that
patch for the -stable series once 2.6.25 ships.
Any thoughts on that?
John
--
John W. Linville
[email protected]
On Tue, Mar 25, 2008 at 8:26 PM, Chatre, Reinette
<[email protected]> wrote:
>
> On Tuesday, March 25, 2008 10:42 AM, John W. Linville wrote:
>
> > On Tue, Mar 25, 2008 at 09:30:58AM -0700, Chatre, Reinette wrote:
> >> On Tuesday, March 25, 2008 9:04 AM, Roel Kluin wrote:
> >>
> >>> from include/linux/ieee80211.h:274:
> >>> #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 ---
> >>> ! has a higher priority than &
> >>>
> >>> Signed-off-by: Roel Kluin <[email protected]>
> >>> ---
> >>> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> >>> b/drivers/net/wireless/iwlwifi/iwl-4965.c
> >>> index d727de8..6576757 100644
> >>> --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
> >>> +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
> >>> @@ -4589,7 +4589,7 @@ static u8
> >>> iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv,
> >>>
> >>> if (sta_ht_inf) {
> >>> if ((!sta_ht_inf->ht_supported) ||
> >>> - (!sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH))
> >>> + (!(sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH)))
> return 0;
> >>> }
> >>
> >> This patch has already been acked and merged into wireless-testing,
> >> and afaik already pushed further upstream.
> >
> > Yes, but FWIW the problem exists in the 2.6.25 stream as well.
> > I've been holding-back a patch to fix it there, trying to decide if it
> > is worth creating the merge conflict to fix it there. I'm inclined
> > to think it is better to let things lay as they are and send that
> > patch for the -stable series once 2.6.25 ships.
> >
> > Any thoughts on that?
>
> I see. The patch is small and I thus assume a merge conflict will be
> easy to resolve. Yet ... I do not know what is really involved in the
> upstream code movements, while I know that you do. If you say it is
> better to wait until stable then I am ok with it.
I have to find the patch but I believe we've published a fix for this
long before this particular patch was born.
Anyhow if HT is enabled in 2.6.25 I would prefer a conflict then a bug.
Thanks
Tomas
On Tuesday, March 25, 2008 9:04 AM, Roel Kluin wrote:
> from include/linux/ieee80211.h:274:
> #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 ---
> ! has a higher priority than &
>
> Signed-off-by: Roel Kluin <[email protected]>
> ---
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> b/drivers/net/wireless/iwlwifi/iwl-4965.c
> index d727de8..6576757 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
> @@ -4589,7 +4589,7 @@ static u8
> iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv,
>
> if (sta_ht_inf) {
> if ((!sta_ht_inf->ht_supported) ||
> - (!sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH))
> + (!(sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH)))
return 0;
> }
This patch has already been acked and merged into wireless-testing, and
afaik already pushed further upstream.
Reinette
On Tuesday, March 25, 2008 10:42 AM, John W. Linville wrote:
> On Tue, Mar 25, 2008 at 09:30:58AM -0700, Chatre, Reinette wrote:
>> On Tuesday, March 25, 2008 9:04 AM, Roel Kluin wrote:
>>
>>> from include/linux/ieee80211.h:274:
>>> #define IEEE80211_HT_CAP_SUP_WIDTH 0x0002 ---
>>> ! has a higher priority than &
>>>
>>> Signed-off-by: Roel Kluin <[email protected]>
>>> ---
>>> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
>>> b/drivers/net/wireless/iwlwifi/iwl-4965.c
>>> index d727de8..6576757 100644
>>> --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
>>> +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
>>> @@ -4589,7 +4589,7 @@ static u8
>>> iwl4965_is_fat_tx_allowed(struct iwl4965_priv *priv,
>>>
>>> if (sta_ht_inf) {
>>> if ((!sta_ht_inf->ht_supported) ||
>>> - (!sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH))
>>> + (!(sta_ht_inf->cap & IEEE80211_HT_CAP_SUP_WIDTH)))
return 0;
>>> }
>>
>> This patch has already been acked and merged into wireless-testing,
>> and afaik already pushed further upstream.
>
> Yes, but FWIW the problem exists in the 2.6.25 stream as well.
> I've been holding-back a patch to fix it there, trying to decide if it
> is worth creating the merge conflict to fix it there. I'm inclined
> to think it is better to let things lay as they are and send that
> patch for the -stable series once 2.6.25 ships.
>
> Any thoughts on that?
I see. The patch is small and I thus assume a merge conflict will be
easy to resolve. Yet ... I do not know what is really involved in the
upstream code movements, while I know that you do. If you say it is
better to wait until stable then I am ok with it.
Thanks
Reinette