User Details
- User Since
- Aug 29 2014, 12:11 PM (498 w, 3 d)
Fri, Mar 15
Tue, Mar 12
Otherwise looks good to me.
Wed, Mar 6
This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.
Tue, Mar 5
We'll need to adjust that slightly in a different direction ...
@manu can you lend a hand? Probably a lot easier for you than for me.
Mon, Mar 4
Initially I thought we should name some better but the original structs have the same names so all good.
I have not checked if you got all the places but it looks good.
Sat, Mar 2
Great catch! I wonder what else that will help for the other (unconnected) drivers. Thanks!
Here's a second one showing the NONEXIST problem with older firmware https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277432
I think it would be good to sort that before moving people from iwm to iwlwifi by default -- or at least being prepared to handle the fallout.
Thu, Feb 29
Tue, Feb 27
Another thing (apart from man pages) we should probably make sure works out of the box is suspend/resume as that's the other missing bit (and ideally without workarounds). I need to go back and see if @hrs has some USB-DEBUG serial console code (I think he gave a presentation about it a while ago at Euro? but I lost track) and assume he doesn't have any time currently.
Thank you for all the changes. I think we are getting pretty close to getting this in.
Mon, Feb 26
Sat, Feb 24
WOW. Having looked at that logic probably a year ago this is good work; also good catches on the missing unlock and NOACK for the 1 byte!
Sorry this looks a lot but is mostly just white space.
Thu, Feb 22
Wed, Feb 21
I just skimmed them:
One comment: I tested this on a LS1088 in FDT mode and it makes me super happy as I can scan bits (and flawlessly read) now I had problems with on another board (which I should test as well once I can again).
Tue, Feb 20
Have you tested on a pre-22000 card 8xxx/9xxx recently?
I know we have to 2 PRs (well one now, two people) on those and given they use different interfaces within iwlwifi it's possible they do behave different.
Really looking forward to this. Also a step towards getting SFP+ support going..
I'll just pick the first review given they all live in a window here; last time I checked and asked if they were ready for review I was told to hold off for further changes? Have they been addressed, as in, is the stack of wtap changes ready for review?
Mon, Feb 19
Sun, Feb 18
Notes:
(1) (*ic_ampdu_rx_start)() MO dowcalls in LinuxKPI need to unlock the ic lock and lock the LHW lock as done in the state machine updates given the MO calls can sleep.
(2) there may be further work on the node_cleanup -> ieee80211_ht_node_cleanup -> lkpi_ic_ampdu_rx_stop path needed if (1) is not sufficient
(3) A separate change ieee80211_sn_*() is to come.
(4) Need to go and see about packets and rates now likely as well as the RX packets after the BA response is out will not show up with 11n for me, but I can see the first packet (and retry) in monitor mode. I'd need a "sane" AP to test with.