* pull-request: iwlwifi 2017-11-19
@ 2017-11-20 11:02 Luca Coelho
2017-11-20 15:47 ` Kalle Valo
2017-11-21 9:30 ` Sedat Dilek
0 siblings, 2 replies; 13+ messages in thread
From: Luca Coelho @ 2017-11-20 11:02 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi Kalle,
Here is my first set of fixes for 4.15. More details in the tag
description.
I have based it on wireless-drivers-next.git, because you didn't update
wireless-drivers.git yet. Let me know if you want me to rebase once
you update.
I have sent this out before and kbuildbot didn't find any issues.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit fdd0bd88ceaecf729db103ac8836af5805dd2dc1:
brcmfmac: add CLM download support (2017-11-11 03:04:09 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2017-11-19
for you to fetch changes up to c2c48ddfc8b03b9ecb51d2832b586497b37531bc:
iwlwifi: fix firmware names for 9000 and A000 series hw (2017-11-16 10:40:15 +0200)
----------------------------------------------------------------
iwlwifi: first set of fixes for 4.15
* Support new FW API version of scan cmd (used in FW version 34);
* Add a bunch of PCI IDs and fix configuration structs for A000
devices;
* Fix the exported firmware name strings for 9000 and A000 devices;
----------------------------------------------------------------
Luca Coelho (2):
iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command
iwlwifi: fix PCI IDs and configuration mapping for 9000 series
Thomas Backlund (1):
iwlwifi: fix firmware names for 9000 and A000 series hw
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++-------
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 10 ++++----
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 59 +++++++++++++++++++++++++++++++++++----------
drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 ++++
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 +++++
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++----------------
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
8 files changed, 296 insertions(+), 76 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: pull-request: iwlwifi 2017-11-19 2017-11-20 11:02 pull-request: iwlwifi 2017-11-19 Luca Coelho @ 2017-11-20 15:47 ` Kalle Valo 2017-11-21 9:30 ` Sedat Dilek 1 sibling, 0 replies; 13+ messages in thread From: Kalle Valo @ 2017-11-20 15:47 UTC (permalink / raw) To: Luca Coelho; +Cc: linux-wireless, linuxwifi Luca Coelho <luca@coelho.fi> writes: > Here is my first set of fixes for 4.15. More details in the tag > description. > > I have based it on wireless-drivers-next.git, because you didn't update > wireless-drivers.git yet. Let me know if you want me to rebase once > you update. No need to rebase, you did the right thing. And now I have fast forwarded wireless-drivers to latest net tree. > I have sent this out before and kbuildbot didn't find any issues. > Please let me know if there are any issues. > > Cheers, > Luca. > > > The following changes since commit fdd0bd88ceaecf729db103ac8836af5805dd2dc1: > > brcmfmac: add CLM download support (2017-11-11 03:04:09 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2017-11-19 Pulled, thanks. -- Kalle Valo ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-20 11:02 pull-request: iwlwifi 2017-11-19 Luca Coelho 2017-11-20 15:47 ` Kalle Valo @ 2017-11-21 9:30 ` Sedat Dilek 2017-11-21 10:10 ` Luca Coelho 1 sibling, 1 reply; 13+ messages in thread From: Sedat Dilek @ 2017-11-21 9:30 UTC (permalink / raw) To: Luca Coelho; +Cc: kvalo, linux-wireless, linuxwifi On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> wrote: [..] > ---------------------------------------------------------------- > iwlwifi: first set of fixes for 4.15 > > * Support new FW API version of scan cmd (used in FW version 34); While seeing this... I have here a iwlwifi-8265 hardware and have seen a recently uploaded FW-version 34 in iwlwifi-firmware Git. Can you explain the dependence of iwlwifi firmware-version / Linux kernel-release and especially probing? Currently, I am using Linux v4.14 from Debian/experimental. - Sedat - P.S.: From my logs [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-8265-34.ucode (-2) [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8265-34.ucode failed with error -2 [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-8265-33.ucode (-2) [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8265-33.ucode failed with error -2 [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-8265-32.ucode (-2) [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8265-32.ucode failed with error -2 [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading firmware iwlwifi-8265-31.ucode [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-21 9:30 ` Sedat Dilek @ 2017-11-21 10:10 ` Luca Coelho 2017-11-21 10:42 ` Kalle Valo 2017-11-29 7:51 ` Sedat Dilek 0 siblings, 2 replies; 13+ messages in thread From: Luca Coelho @ 2017-11-21 10:10 UTC (permalink / raw) To: sedat.dilek; +Cc: kvalo, linux-wireless, linuxwifi On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: > On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> wrote: > [..] > > ---------------------------------------------------------------- > > iwlwifi: first set of fixes for 4.15 > > > > * Support new FW API version of scan cmd (used in FW version 34); > > While seeing this... > I have here a iwlwifi-8265 hardware and have seen a recently uploaded > FW-version 34 in iwlwifi-firmware Git. > Can you explain the dependence of iwlwifi firmware-version / Linux > kernel-release and especially probing? > Currently, I am using Linux v4.14 from Debian/experimental. Mostly for backwards-compatibility, the driver is able to work with a range of firmware versions. It only uses one of them at a time (i.e. the highest supported version it finds). The driver in v4.14 support version 34 and below. So it starts looking for that one and, if not found, falls back to the next lower version (i.e. 33) and so on, until it finds one. > [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load > iwlwifi-8265-34.ucode (-2) > [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for > iwlwifi-8265-34.ucode failed with error -2 > [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load > iwlwifi-8265-33.ucode (-2) > [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for > iwlwifi-8265-33.ucode failed with error -2 > [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load > iwlwifi-8265-32.ucode (-2) > [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for > iwlwifi-8265-32.ucode failed with error -2 > [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading > firmware > iwlwifi-8265-31.ucode > [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version > 31.532993.0 op_mode iwlmvm This is an unfortunate side-effect of the way firmwares are loaded. There is currently no way to prevent these error messages by making some files optional... But you can ignore them. Or, even better, upgrade your firmware to the latest version the driver supports. :) -- Cheers, Luca. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-21 10:10 ` Luca Coelho @ 2017-11-21 10:42 ` Kalle Valo 2017-11-21 11:37 ` Luca Coelho 2017-11-29 7:51 ` Sedat Dilek 1 sibling, 1 reply; 13+ messages in thread From: Kalle Valo @ 2017-11-21 10:42 UTC (permalink / raw) To: Luca Coelho; +Cc: sedat.dilek, linux-wireless, linuxwifi Luca Coelho <luca@coelho.fi> writes: >> [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load >> iwlwifi-8265-34.ucode (-2) >> [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for >> iwlwifi-8265-34.ucode failed with error -2 >> [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load >> iwlwifi-8265-33.ucode (-2) >> [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for >> iwlwifi-8265-33.ucode failed with error -2 >> [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load >> iwlwifi-8265-32.ucode (-2) >> [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for >> iwlwifi-8265-32.ucode failed with error -2 >> [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading >> firmware >> iwlwifi-8265-31.ucode >> [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version >> 31.532993.0 op_mode iwlmvm > > This is an unfortunate side-effect of the way firmwares are loaded. > There is currently no way to prevent these error messages by making > some files optional... But you can ignore them. Or, even better, > upgrade your firmware to the latest version the driver supports. :) Or even better that we improve request_firmware()&co to make it possible not to print an error message :) In ath10k we are also (again) suffering about the same problem due to: ath10k: activate user space firmware loading again https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 -- Kalle Valo ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-21 10:42 ` Kalle Valo @ 2017-11-21 11:37 ` Luca Coelho 2017-11-22 19:46 ` Luis R. Rodriguez 0 siblings, 1 reply; 13+ messages in thread From: Luca Coelho @ 2017-11-21 11:37 UTC (permalink / raw) To: Kalle Valo, mcgrof; +Cc: sedat.dilek, linux-wireless, linuxwifi On Tue, 2017-11-21 at 12:42 +0200, Kalle Valo wrote: > Luca Coelho <luca@coelho.fi> writes: > > > > [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load > > > iwlwifi-8265-34.ucode (-2) > > > [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for > > > iwlwifi-8265-34.ucode failed with error -2 > > > [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load > > > iwlwifi-8265-33.ucode (-2) > > > [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for > > > iwlwifi-8265-33.ucode failed with error -2 > > > [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load > > > iwlwifi-8265-32.ucode (-2) > > > [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for > > > iwlwifi-8265-32.ucode failed with error -2 > > > [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading > > > firmware > > > iwlwifi-8265-31.ucode > > > [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version > > > 31.532993.0 op_mode iwlmvm > > > > This is an unfortunate side-effect of the way firmwares are > > loaded. > > There is currently no way to prevent these error messages by making > > some files optional... But you can ignore them. Or, even better, > > upgrade your firmware to the latest version the driver supports. :) > > Or even better that we improve request_firmware()&co to make it > possible > not to print an error message :) The last time we discussed this, Luis was working on changes to the firmware subsystem APIs, but I stopped following and have no idea what happened with those patches... -- Cheers, Luca. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-21 11:37 ` Luca Coelho @ 2017-11-22 19:46 ` Luis R. Rodriguez 2017-11-22 20:50 ` Luca Coelho 0 siblings, 1 reply; 13+ messages in thread From: Luis R. Rodriguez @ 2017-11-22 19:46 UTC (permalink / raw) To: Luca Coelho; +Cc: Kalle Valo, mcgrof, sedat.dilek, linux-wireless, linuxwifi On Tue, Nov 21, 2017 at 01:37:40PM +0200, Luca Coelho wrote: > On Tue, 2017-11-21 at 12:42 +0200, Kalle Valo wrote: > > Luca Coelho <luca@coelho.fi> writes: > > > > > > [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load > > > > iwlwifi-8265-34.ucode (-2) > > > > [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for > > > > iwlwifi-8265-34.ucode failed with error -2 > > > > [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load > > > > iwlwifi-8265-33.ucode (-2) > > > > [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for > > > > iwlwifi-8265-33.ucode failed with error -2 > > > > [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load > > > > iwlwifi-8265-32.ucode (-2) > > > > [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for > > > > iwlwifi-8265-32.ucode failed with error -2 > > > > [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading > > > > firmware > > > > iwlwifi-8265-31.ucode > > > > [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version > > > > 31.532993.0 op_mode iwlmvm > > > > > > This is an unfortunate side-effect of the way firmwares are > > > loaded. > > > There is currently no way to prevent these error messages by making > > > some files optional... But you can ignore them. Or, even better, > > > upgrade your firmware to the latest version the driver supports. :) > > > > Or even better that we improve request_firmware()&co to make it > > possible > > not to print an error message :) > > The last time we discussed this, Luis was working on changes to the > firmware subsystem APIs, but I stopped following and have no idea what > happened with those patches... You guys dropped the ball on this but I don't blame you, the state of affairs of evolving anything on the firmware API has been a pain in the ass for ages. I nose dived last time a "no warn" patch for async was porposed, I particularly looked into how ath10k firmware loads [0], someone should really consider making docs out of that email for ath10k... anyway I *confirmed* that both iwlwifi and ath10k share the same intent: "do not warn if firmware is missing" But they do this for an API revision series. So rather its: "Lookup for firmware API start=x, end=y, and only warn if nothing is found" The good news is that the code is implemented, however it was for the "driver data API" and I had only ported iwlwifi [1] [2] (look at use of DRIVER_DATA_API() macros). In fact the iwlwifi firmware use for api revision uses recursion, I modified my solution to not use it, making it deterministic as well, but that code was written for the driver data API. As soon as we decide on a path forward on *how* to evolve the firmware API we can consider adding such solution or extensions in. Whether that be the simple "do not warn" on async calls or the full "look for these revisions for me, and don't warn". Both are things I have already implemented, its just then a matter of how to merge. The thing *stalling* firmware API progress was a technical debate on whether or not the firmware API should evolve through: a) Functional driven API b) Data driven API Greg put his foot down on a) and I finally came to agree with him. We seem to have reached a consensus on how to proceed forward slowly and this means a cleanup without the data driven API. So *other good news* is that last week I worked and published two patch sets to help in this direction. One is a set of fixes [3], and the other is a set of cleanups for the firmware API which paves the way for a way to consider evolving the API without the whole hated driver data crap approach [4], for consideration for v4.16. I have these two patch sets in a git tree branch, just ignore the last commit there for now [6], as it was taking the old data driven API approach to the firmware API. Note that this *may* still be a good approach forward, however it does not matter. Once the cleanup is merged, it should be fairly easy to decide on a path forward to evolve the API as that would be the *only* thing left to decide on. If someone wants to be proactive, they can look at this branch, ignore the last patch ("firmware: add extensible firmware params") and see how they can nicely come up something like the DRIVER_DATA_API() macro stuff I did earlier, that or just the "no warn" flag. Please note that I did want to clearly split private Vs public flags. Public flags should be for functionality exposed, private for internal hacks. I could just be a simple matter of adding a public "No warn" flag first, and only later add the "api revision" functionality. [0] https://lkml.kernel.org/r/20170810170539.GC27873@wotan.suse.de [1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170605-driver-data&id=8a2b582b9938f74827bbffb98a2f95c967c8ccde [2] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170605-driver-data&id=6cd4c6c8f93fac692ad0014792f1fd410742a1da [3] https://lkml.kernel.org/r/20171120174535.27000-1-mcgrof@kernel.org [4] https://lkml.kernel.org/r/20171120182409.27348-1-mcgrof@kernel.org [5] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20171117-firmware-flexible [6] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20171117-firmware-flexible&id=9cc12e4c4483c38cf46a71f3c37af9ace67e3e4d Luis ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-22 19:46 ` Luis R. Rodriguez @ 2017-11-22 20:50 ` Luca Coelho 2017-11-23 19:08 ` Luis R. Rodriguez 0 siblings, 1 reply; 13+ messages in thread From: Luca Coelho @ 2017-11-22 20:50 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Kalle Valo, sedat.dilek, linux-wireless, linuxwifi On Wed, 2017-11-22 at 20:46 +0100, Luis R. Rodriguez wrote: > On Tue, Nov 21, 2017 at 01:37:40PM +0200, Luca Coelho wrote: > > On Tue, 2017-11-21 at 12:42 +0200, Kalle Valo wrote: > > > Luca Coelho <luca@coelho.fi> writes: > > > > > > > > [ 10.630285] iwlwifi 0000:04:00.0: firmware: failed to load > > > > > iwlwifi-8265-34.ucode (-2) > > > > > [ 10.630331] iwlwifi 0000:04:00.0: Direct firmware load for > > > > > iwlwifi-8265-34.ucode failed with error -2 > > > > > [ 10.630454] iwlwifi 0000:04:00.0: firmware: failed to load > > > > > iwlwifi-8265-33.ucode (-2) > > > > > [ 10.630479] iwlwifi 0000:04:00.0: Direct firmware load for > > > > > iwlwifi-8265-33.ucode failed with error -2 > > > > > [ 10.630486] iwlwifi 0000:04:00.0: firmware: failed to load > > > > > iwlwifi-8265-32.ucode (-2) > > > > > [ 10.630510] iwlwifi 0000:04:00.0: Direct firmware load for > > > > > iwlwifi-8265-32.ucode failed with error -2 > > > > > [ 10.636423] iwlwifi 0000:04:00.0: firmware: direct-loading > > > > > firmware > > > > > iwlwifi-8265-31.ucode > > > > > [ 10.637463] iwlwifi 0000:04:00.0: loaded firmware version > > > > > 31.532993.0 op_mode iwlmvm > > > > > > > > This is an unfortunate side-effect of the way firmwares are > > > > loaded. > > > > There is currently no way to prevent these error messages by > > > > making > > > > some files optional... But you can ignore them. Or, even > > > > better, > > > > upgrade your firmware to the latest version the driver > > > > supports. :) > > > > > > Or even better that we improve request_firmware()&co to make it > > > possible > > > not to print an error message :) > > > > The last time we discussed this, Luis was working on changes to the > > firmware subsystem APIs, but I stopped following and have no idea > > what > > happened with those patches... > > You guys dropped the ball on this but I don't blame you, the state of > affairs > of evolving anything on the firmware API has been a pain in the ass > for ages. Luis, I really appreciate your work on this, don't get me wrong. But I don't think we dropped the ball. We still need the small feature (not sure if it can be done with a small *change*, though) of not warning when a firmware is not found. Nothing changed here. The problem, and the reason why you see it as my having dropped the ball, is that the change we needed grew into a massive refactoring of the entire firmware loading mechanism, with the addition of driver data, lots of advanced options etc. You certainly remember that I even reviewed the first patchset, but then it all snowballed into discussions that led to literally *hundreds* of emails going back and forth and I just didn't have the time to follow anymore... In a selfish way, if I only think about the iwlwifi and ath10k drivers, I don't care *how* the "no warning" feature is implemented. If it is implemented with the "load from a range", a new concept of "driver data", a "functional API" or just a simple "optional" flag, it doesn't matter. The driver can implement the range search, as it does now. The only thing the driver *can't* do at the moment is to get rid of the warnings. But, personally, I'm not in a hurry. It's a bit annoying to get reports repeatedly from the community about those warnings and having to explain how things work, but I can live with that. I'd be happy to help with anything that doesn't involve following hundreds of emails and reviewing massive refactors in code I'm not completely familiar with. ;) Let me know. -- Cheers, Luca. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-22 20:50 ` Luca Coelho @ 2017-11-23 19:08 ` Luis R. Rodriguez 0 siblings, 0 replies; 13+ messages in thread From: Luis R. Rodriguez @ 2017-11-23 19:08 UTC (permalink / raw) To: Luca Coelho Cc: Luis R. Rodriguez, Kalle Valo, sedat.dilek, linux-wireless, linuxwifi On Wed, Nov 22, 2017 at 10:50:51PM +0200, Luca Coelho wrote: > The problem, and the reason why you see it as my having dropped the > ball, is that the change we needed grew into a massive refactoring of > the entire firmware loading mechanism, with the addition of driver > data, lots of advanced options etc. Yeah I noted that, I don't blame you :) > You certainly remember that I even reviewed the first patchset, but > then it all snowballed into discussions that led to literally > *hundreds* of emails going back and forth and I just didn't have the > time to follow anymore... Like I said, I don't blame you. Hopefully for v4.16 things will fly better. > But, personally, I'm not in a hurry. It's a bit annoying to get > reports repeatedly from the community about those warnings and having > to explain how things work, but I can live with that. > > I'd be happy to help with anything that doesn't involve following > hundreds of emails and reviewing massive refactors in code I'm not > completely familiar with. ;) Let me know. Let's shoot to get something in for v4.16, for both ath10k and iwlwifi, but first we need the cleanup to get merged. If you have time some Reviewed-by's would be nice of the last posted patches. I'll bounce you copies. Luis ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-21 10:10 ` Luca Coelho 2017-11-21 10:42 ` Kalle Valo @ 2017-11-29 7:51 ` Sedat Dilek 2017-11-29 8:20 ` Luca Coelho 1 sibling, 1 reply; 13+ messages in thread From: Sedat Dilek @ 2017-11-29 7:51 UTC (permalink / raw) To: Luca Coelho; +Cc: kvalo, linux-wireless, linuxwifi On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> wrote: > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: >> On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> wrote: >> [..] >> > ---------------------------------------------------------------- >> > iwlwifi: first set of fixes for 4.15 >> > >> > * Support new FW API version of scan cmd (used in FW version 34); >> >> While seeing this... >> I have here a iwlwifi-8265 hardware and have seen a recently uploaded >> FW-version 34 in iwlwifi-firmware Git. >> Can you explain the dependence of iwlwifi firmware-version / Linux >> kernel-release and especially probing? >> Currently, I am using Linux v4.14 from Debian/experimental. > > Mostly for backwards-compatibility, the driver is able to work with a > range of firmware versions. It only uses one of them at a time (i.e. > the highest supported version it finds). > > The driver in v4.14 support version 34 and below. So it starts looking > for that one and, if not found, falls back to the next lower version > (i.e. 33) and so on, until it finds one. > Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new features in v34 firmware? "iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command" commit dac4df1c5f2c34903f61b1bc4fc722e31b4199e7 upstream. - Sedat - [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-4.14.y&id=930929379cc8f92275675fb27e572c4d539f6b8a ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-29 7:51 ` Sedat Dilek @ 2017-11-29 8:20 ` Luca Coelho 2017-12-19 13:52 ` Sedat Dilek 0 siblings, 1 reply; 13+ messages in thread From: Luca Coelho @ 2017-11-29 8:20 UTC (permalink / raw) To: sedat.dilek; +Cc: kvalo, linux-wireless, linuxwifi On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote: > On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> wrote: > > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: > > > On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> > > > wrote: > > > [..] > > > > ------------------------------------------------------------- > > > > --- > > > > iwlwifi: first set of fixes for 4.15 > > > > > > > > * Support new FW API version of scan cmd (used in FW version > > > > 34); > > > > > > While seeing this... > > > I have here a iwlwifi-8265 hardware and have seen a recently > > > uploaded > > > FW-version 34 in iwlwifi-firmware Git. > > > Can you explain the dependence of iwlwifi firmware-version / > > > Linux > > > kernel-release and especially probing? > > > Currently, I am using Linux v4.14 from Debian/experimental. > > > > Mostly for backwards-compatibility, the driver is able to work with > > a > > range of firmware versions. It only uses one of them at a time > > (i.e. > > the highest supported version it finds). > > > > The driver in v4.14 support version 34 and below. So it starts > > looking > > for that one and, if not found, falls back to the next lower > > version > > (i.e. 33) and so on, until it finds one. > > > > Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new > features in v34 firmware? Yes, it is. But this was a bug and we can't go back and fix v4.14.0-2, right? So it's the best we can do and whoever is using v4.14, should update to v4.14.3 when it comes out to be able to use version 34 of the firmware. -- Cheers, Luca. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-11-29 8:20 ` Luca Coelho @ 2017-12-19 13:52 ` Sedat Dilek 2017-12-19 15:13 ` Luca Coelho 0 siblings, 1 reply; 13+ messages in thread From: Sedat Dilek @ 2017-12-19 13:52 UTC (permalink / raw) To: Luca Coelho; +Cc: kvalo, linux-wireless, linuxwifi On Wed, Nov 29, 2017 at 9:20 AM, Luca Coelho <luca@coelho.fi> wrote: > On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote: >> On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> wrote: >> > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: >> > > On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi> >> > > wrote: >> > > [..] >> > > > ------------------------------------------------------------- >> > > > --- >> > > > iwlwifi: first set of fixes for 4.15 >> > > > >> > > > * Support new FW API version of scan cmd (used in FW version >> > > > 34); >> > > >> > > While seeing this... >> > > I have here a iwlwifi-8265 hardware and have seen a recently >> > > uploaded >> > > FW-version 34 in iwlwifi-firmware Git. >> > > Can you explain the dependence of iwlwifi firmware-version / >> > > Linux >> > > kernel-release and especially probing? >> > > Currently, I am using Linux v4.14 from Debian/experimental. >> > >> > Mostly for backwards-compatibility, the driver is able to work with >> > a >> > range of firmware versions. It only uses one of them at a time >> > (i.e. >> > the highest supported version it finds). >> > >> > The driver in v4.14 support version 34 and below. So it starts >> > looking >> > for that one and, if not found, falls back to the next lower >> > version >> > (i.e. 33) and so on, until it finds one. >> > >> >> Isn't Linux v4.14.3 (here: -rc1) minimum to completely support new >> features in v34 firmware? > > Yes, it is. But this was a bug and we can't go back and fix v4.14.0-2, > right? So it's the best we can do and whoever is using v4.14, should > update to v4.14.3 when it comes out to be able to use version 34 of the > firmware. > Thanks for the confirmation. I have added the patch from v4.14.3 to latest Debian-kernel v4.14.2 and rebuild the corresponding iwlwifi kernel-modules. v34 firmware works fine now. # dmesg | egrep iwlwifi [ 21.178769] iwlwifi: loading out-of-tree module taints kernel. [ 21.184459] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002) [ 21.217170] iwlwifi 0000:04:00.0: firmware: direct-loading firmware iwlwifi-8265-34.ucode [ 21.218061] iwlwifi 0000:04:00.0: loaded firmware version 34.0.1 op_mode iwlmvm [ 21.271000] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230 [ 21.340242] iwlwifi 0000:04:00.0: base HW address: bc:a8:a6:d1:3f:49 [ 21.432118] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0 - Sedat - ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pull-request: iwlwifi 2017-11-19 2017-12-19 13:52 ` Sedat Dilek @ 2017-12-19 15:13 ` Luca Coelho 0 siblings, 0 replies; 13+ messages in thread From: Luca Coelho @ 2017-12-19 15:13 UTC (permalink / raw) To: sedat.dilek; +Cc: kvalo, linux-wireless, linuxwifi On Tue, 2017-12-19 at 14:52 +0100, Sedat Dilek wrote: > On Wed, Nov 29, 2017 at 9:20 AM, Luca Coelho <luca@coelho.fi> wrote: > > On Wed, 2017-11-29 at 08:51 +0100, Sedat Dilek wrote: > > > On Tue, Nov 21, 2017 at 11:10 AM, Luca Coelho <luca@coelho.fi> > > > wrote: > > > > On Tue, 2017-11-21 at 10:30 +0100, Sedat Dilek wrote: > > > > > On Mon, Nov 20, 2017 at 12:02 PM, Luca Coelho <luca@coelho.fi > > > > > > > > > > > wrote: > > > > > [..] > > > > > > --------------------------------------------------------- > > > > > > ---- > > > > > > --- > > > > > > iwlwifi: first set of fixes for 4.15 > > > > > > > > > > > > * Support new FW API version of scan cmd (used in FW > > > > > > version > > > > > > 34); > > > > > > > > > > While seeing this... > > > > > I have here a iwlwifi-8265 hardware and have seen a recently > > > > > uploaded > > > > > FW-version 34 in iwlwifi-firmware Git. > > > > > Can you explain the dependence of iwlwifi firmware-version / > > > > > Linux > > > > > kernel-release and especially probing? > > > > > Currently, I am using Linux v4.14 from Debian/experimental. > > > > > > > > Mostly for backwards-compatibility, the driver is able to work > > > > with > > > > a > > > > range of firmware versions. It only uses one of them at a time > > > > (i.e. > > > > the highest supported version it finds). > > > > > > > > The driver in v4.14 support version 34 and below. So it starts > > > > looking > > > > for that one and, if not found, falls back to the next lower > > > > version > > > > (i.e. 33) and so on, until it finds one. > > > > > > > > > > Isn't Linux v4.14.3 (here: -rc1) minimum to completely support > > > new > > > features in v34 firmware? > > > > Yes, it is. But this was a bug and we can't go back and fix > > v4.14.0-2, > > right? So it's the best we can do and whoever is using v4.14, > > should > > update to v4.14.3 when it comes out to be able to use version 34 of > > the > > firmware. > > > > Thanks for the confirmation. > > I have added the patch from v4.14.3 to latest Debian-kernel v4.14.2 > and rebuild the corresponding iwlwifi kernel-modules. > v34 firmware works fine now. > > # dmesg | egrep iwlwifi > [ 21.178769] iwlwifi: loading out-of-tree module taints kernel. > [ 21.184459] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002) > [ 21.217170] iwlwifi 0000:04:00.0: firmware: direct-loading > firmware > iwlwifi-8265-34.ucode > [ 21.218061] iwlwifi 0000:04:00.0: loaded firmware version 34.0.1 > op_mode iwlmvm > [ 21.271000] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band > Wireless AC 8265, REV=0x230 > [ 21.340242] iwlwifi 0000:04:00.0: base HW address: > bc:a8:a6:d1:3f:49 > [ 21.432118] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0 Great! Thanks for confirming. -- Luca. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2017-12-19 15:14 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-20 11:02 pull-request: iwlwifi 2017-11-19 Luca Coelho 2017-11-20 15:47 ` Kalle Valo 2017-11-21 9:30 ` Sedat Dilek 2017-11-21 10:10 ` Luca Coelho 2017-11-21 10:42 ` Kalle Valo 2017-11-21 11:37 ` Luca Coelho 2017-11-22 19:46 ` Luis R. Rodriguez 2017-11-22 20:50 ` Luca Coelho 2017-11-23 19:08 ` Luis R. Rodriguez 2017-11-29 7:51 ` Sedat Dilek 2017-11-29 8:20 ` Luca Coelho 2017-12-19 13:52 ` Sedat Dilek 2017-12-19 15:13 ` Luca Coelho
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).