Hi,
For chip sets that set
IEEE80211_HW_CONNECTION_MONITOR
hw_scan
the hardware does the scan and maintains the
connection.
So some HW's might drop the probe responses and
beacons as they are not required by the mac80211.
In those scenarios, the rate control module minstrel_ht called from
prep_connection throws a warning (in rate_control_send_low)
because "supp_rates" is not set, since scan results are updated
through "cfg8011_bss_inform_frame" which doesn't call
"ieee80211_bss_info_update'.
How do we handle such scenarios? Does the cfg80211 need to
update the bss information in mac80211?
--
Thanks,
Regards,
Chaitanya T K.
On Sun, Nov 17, 2013 at 2:46 PM, Johannes Berg
<[email protected]> wrote:
> On Sat, 2013-11-16 at 01:19 +0530, Krishna Chaitanya wrote:
>
>> In those scenarios, the rate control module minstrel_ht called from
>> prep_connection throws a warning (in rate_control_send_low)
>> because "supp_rates" is not set, since scan results are updated
>> through "cfg8011_bss_inform_frame" which doesn't call
>> "ieee80211_bss_info_update'.
>>
>> How do we handle such scenarios? Does the cfg80211 need to
>> update the bss information in mac80211?
>
> No. What are you smoking?
>
> You're not supposed to even call cfg80211_bss_inform_frame() from a
> mac80211-based driver. Just report the RX frame properly.
>
Ours is a partial Full MAC driver which still uses mac80211 but mostly with
offloads to HW.
With mac80211 + hw_scan if we just report the RX frames, then we are just
eliminating the SCAN SM from mac80211, is this just to reduce the host
cycles? (apart from speeding up the channel switch)
On Sun, 2013-11-17 at 18:43 +0530, Krishna Chaitanya wrote:
> > You're not supposed to even call cfg80211_bss_inform_frame() from a
> > mac80211-based driver. Just report the RX frame properly.
> Ours is a partial Full MAC driver which still uses mac80211 but mostly with
> offloads to HW.
>
> With mac80211 + hw_scan if we just report the RX frames, then we are just
> eliminating the SCAN SM from mac80211, is this just to reduce the host
> cycles? (apart from speeding up the channel switch)
When you post the driver for upstream we can talk about it. I have no
interest in it otherwise - but
(a) you can't call cfg80211 from the driver and then have cfg80211 call
mac80211
- that's a gross layering violation
(b) if you're offloading much, you're probably not using a lot of
mac80211 and
should come with a proposal to refactor the code
johannes
On Sat, 2013-11-16 at 01:19 +0530, Krishna Chaitanya wrote:
> In those scenarios, the rate control module minstrel_ht called from
> prep_connection throws a warning (in rate_control_send_low)
> because "supp_rates" is not set, since scan results are updated
> through "cfg8011_bss_inform_frame" which doesn't call
> "ieee80211_bss_info_update'.
>
> How do we handle such scenarios? Does the cfg80211 need to
> update the bss information in mac80211?
No. What are you smoking?
You're not supposed to even call cfg80211_bss_inform_frame() from a
mac80211-based driver. Just report the RX frame properly.
johannes
On Mon, Nov 18, 2013 at 6:31 PM, Johannes Berg
<[email protected]> wrote:
> On Sun, 2013-11-17 at 18:43 +0530, Krishna Chaitanya wrote:
>
>> > You're not supposed to even call cfg80211_bss_inform_frame() from a
>> > mac80211-based driver. Just report the RX frame properly.
>
>> Ours is a partial Full MAC driver which still uses mac80211 but mostly with
>> offloads to HW.
>>
>> With mac80211 + hw_scan if we just report the RX frames, then we are just
>> eliminating the SCAN SM from mac80211, is this just to reduce the host
>> cycles? (apart from speeding up the channel switch)
>
> When you post the driver for upstream we can talk about it. I have no
> interest in it otherwise - but
>
May not be possible.
> (a) you can't call cfg80211 from the driver and then have cfg80211 call
> mac80211
> - that's a gross layering violation
That was not my intention either.
> (b) if you're offloading much, you're probably not using a lot of
> mac80211 and
> should come with a proposal to refactor the code
If we want to truly offload the SCAN to HW then we should have some
way to update scan_results without ever sending the probe responses
and beacons up (saves lots of host cycles, assuming Connection
Monitoring is also offloaded).
For now, will change the driver to pass the beacons/probes up for
updating scan results.
Thanks.