From: Dan Williams <dcbw@redhat.com>
To: Andrew Lunn <andrew.lunn@ascom.ch>
Cc: linux-wireless@vger.kernel.org, Zhu Yi <yi.zhu@intel.com>,
Reinette Chatre <reinette.chatre@intel.com>
Subject: Re: Link Quality stats not updating, recieved_channel
Date: Fri, 22 Feb 2008 17:14:13 -0500 [thread overview]
Message-ID: <1203718453.4422.17.camel@localhost.localdomain> (raw)
In-Reply-To: <20080222212103.GA7771@donkey.ma.tech.ascom.ch>
On Fri, 2008-02-22 at 22:21 +0100, Andrew Lunn wrote:
> > Can you try the attached patch instead? stats.received_channel really
> > should be filled by the hardware driver itself. This patch essentially
> > does what bcm43xx does. Can you test it please?
>
> I can try it, but i suspect it will not work. The firmware in the
> ipw2100 does the scan, not the driver. So priv->channel will not be
> the frequency the probe_resp corresponds to when the firmware is off
> scanning on other frequencies.
Yeah; you're right. I'm not sure there's a good way to do this unless
there's some way the ipw2100 passes back the channel number each frame
was received on. We can't use IPW_ORD_OUR_FREQ because we can't
guarantee that when the interrupt for received frame occurs the frame
the driver is handed was received on the same channel that the card is
now on.
But also ignoring the check in update_network() will cause the signal
strength of networks to be lower than they should be, because the frame
bled over to a different channel.
Intel devs; does the ipw2100 firmware stick the channel into the frame
header anywhere like ipw2200? Perhaps the ipw2100 driver just never got
updated for that feature? If not, is there another way this could be
fixed?
Dan
next prev parent reply other threads:[~2008-02-22 22:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 14:26 Link Quality stats not updating, recieved_channel Andrew Lunn
2008-02-22 21:05 ` Dan Williams
2008-02-22 21:21 ` Andrew Lunn
2008-02-22 22:14 ` Dan Williams [this message]
2008-02-22 23:07 ` Andrew Lunn
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=1203718453.4422.17.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=andrew.lunn@ascom.ch \
--cc=linux-wireless@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=yi.zhu@intel.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.