pull-request: iwlwifi 2017-11-19

pull-request: iwlwifi 2017-11-19

[Luca Coelho]

[-- 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 --]

Re: pull-request: iwlwifi 2017-11-19

[Kalle Valo]

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

Re: pull-request: iwlwifi 2017-11-19

[Sedat Dilek]

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

Re: pull-request: iwlwifi 2017-11-19

[Luca Coelho]

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.

Re: pull-request: iwlwifi 2017-11-19

[Kalle Valo]

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

Re: pull-request: iwlwifi 2017-11-19

[Luca Coelho]

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.

Re: pull-request: iwlwifi 2017-11-19

[Luis R. Rodriguez]

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

Re: pull-request: iwlwifi 2017-11-19

[Luca Coelho]

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.

Re: pull-request: iwlwifi 2017-11-19

[Luis R. Rodriguez]

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

Re: pull-request: iwlwifi 2017-11-19

[Sedat Dilek]

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

Re: pull-request: iwlwifi 2017-11-19

[Luca Coelho]

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.

Re: pull-request: iwlwifi 2017-11-19

[Sedat Dilek]

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 -

Re: pull-request: iwlwifi 2017-11-19

[Luca Coelho]

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.