From: Kalle Valo <kvalo@codeaurora.org>
To: Amitkumar Karwar <amitkarwar@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Amitkumar Karwar <amit.karwar@redpinesignals.com>,
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>,
Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Subject: Re: [PATCH 01/10] rsi: add support for hardware scan offload
Date: Thu, 15 Mar 2018 11:00:17 +0200 [thread overview]
Message-ID: <871sgl90im.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <CAEhWJFk3CGJ9-QJZJt23-vvrwXgVq9GeY9AhXbPy2=FAUMUnOw@mail.gmail.com> (Amitkumar Karwar's message of "Thu, 15 Mar 2018 12:38:08 +0530")
Amitkumar Karwar <amitkarwar@gmail.com> writes:
> On Tue, Mar 13, 2018 at 8:46 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Amitkumar Karwar <amitkarwar@gmail.com> writes:
>>
>>> From: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>>>
>>> With the current approach of scanning, roaming delays
>>> are observed. Firmware has support for back ground scanning.
>>> To get this advantage, mac80211 hardware scan is implemented.
>>> In this method, foreground scan is performed in driver and
>>> back ground scan is configured to firmware.
>>
>> To me doesn't like a good idea to duplicate scan functionality in the
>> driver.
>
> There is a limitation with our device. We need to configure background
> scan parameters to firmware when device is connected.
Yeah, I guessed that.
> In non-connected state, we can directly dump probe requests received
> from mac80211 as a part of software scan. Some synchronization issues
> are with existing software scan when device is connected. This patch
> implements hw_scan where these issues are no seen, as driver has more
> control on scan state machine
What I don't like here is that you are duplicating functionality already
existing in mac80211 and I hope there is a better way to solve the
problem. Just as a a crazy idea what if the driver returns -EOPNOTSUPP
when hardware scan is not possible and mac80211 falls back to software
scan? But of course this depends on what Johannes thinks.
--
Kalle Valo
next prev parent reply other threads:[~2018-03-15 9:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 14:36 [PATCH 00/10] rsi driver enhancements Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 01/10] rsi: add support for hardware scan offload Amitkumar Karwar
2018-03-13 15:16 ` Kalle Valo
2018-03-13 15:18 ` Kalle Valo
2018-03-15 7:10 ` Amitkumar Karwar
2018-03-15 7:08 ` Amitkumar Karwar
2018-03-15 9:00 ` Kalle Valo [this message]
2018-03-15 9:27 ` Amitkumar Karwar
2018-03-20 22:32 ` Johannes Berg
2018-03-23 14:50 ` Amitkumar Karwar
2018-03-27 13:22 ` Johannes Berg
2018-03-27 14:18 ` Kalle Valo
2018-03-27 14:31 ` Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 02/10] rsi: move xtend_desc structure from rsi_main.h to rsi_mgmt.h Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 03/10] rsi: move descriptor preparation to core Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 04/10] rsi: enable 80MHz clock by default Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 05/10] rsi: roaming enhancements Amitkumar Karwar
2018-03-13 15:24 ` Kalle Valo
2018-03-15 7:29 ` Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 06/10] rsi: add module parameter rsi_reg Amitkumar Karwar
2018-03-13 15:25 ` Kalle Valo
2018-03-15 10:58 ` Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 07/10] rsi: regulatory modifications for 'dlcar' mode Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 08/10] rsi: device disconnect changes Amitkumar Karwar
2018-03-13 15:27 ` Kalle Valo
2018-03-15 11:45 ` Amitkumar Karwar
2018-03-05 14:36 ` [PATCH 09/10] rsi: tx improvements Amitkumar Karwar
2018-03-13 15:29 ` Kalle Valo
2018-03-15 11:46 ` Amitkumar Karwar
2018-03-05 14:37 ` [PATCH 10/10] rsi: drop RX broadcast/multicast packets with invalid PN Amitkumar Karwar
2018-03-13 15:34 ` Kalle Valo
2018-03-20 22:55 ` Johannes Berg
2018-03-23 14:57 ` Amitkumar Karwar
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=871sgl90im.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=amit.karwar@redpinesignals.com \
--cc=amitkarwar@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=prameela.j04cs@gmail.com \
--cc=siva.rebbagondla@redpinesignals.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.