On Wed, Mar 21, 2018 at 4:02 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2018-03-15 at 14:57 +0530, Amitkumar Karwar wrote: >> >> > 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. >> >> Currently mac80211 offloads scan to driver if "ops->hw_scan" is >> implemented. Otherwise falls back to software scan. >> I can see below vendors have already implemented hw_scan with their >> own scan state machine. This patch does the same thing. >> Let me know if I missed anything here. > > I think the argument is that at least it looks like you're implementing > the timing etc. in software in the driver again, which others don't do, > they do it in firmware. Which is just software again, but we don't see > it ;-) Understood. Timing logic is either is hardware or mac80211 for others. > But maybe that's not really true at all? At least in one case it seems > you just kick off something called "bgscan". Yes. We have different scan implementations for device is connected and non-connected cases. In connected case, firmware will take care of timings when driver configures bgscan parameters due to power save and coex restrictions. In non-connected state, driver is taking care of it. I found hardware scan in mac80211 more suitable for our device. Regards, Amitkumar Karwar
