* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pavel Machek @ 2017-01-27 12:03 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Kalle Valo, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127101043.GD24223@pali>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi!
> > You are probably saying that on your platform you can not remove
> > anything from /lib/firmware, right? I don't see how you come from "it is
> > part of firmware package" to "removing is not possible". Trying to
> > understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
> > >> Like we discussed earlier, the default nvs file should not be used by
> > >> normal users.
> > >
> > > But already is and we need to deal with this fact.
> >
> > Why?
>
> Because everybody has already installed it.
>
> > Are there other platforms that use the default nvs file and have a
> > working wifi.
>
> I do not know.
>
> > So your "removing is not possible" would be about
> > regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
Yes, wifi somehow works on N900. .. depending on userspace and kernel
versions.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 11:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus7mfk.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> >> So
> >> for those other platforms there will be a delay waiting for user-mode
> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >
> > Yes, there will be. But there is no easy way to fix this problem that
> > kernel is trying to use default/example NVS data...
>
> Kernel is doing correctly and requesting NVS data as expected, the
> problem here is that linux-firmware claims that the example NVS data is
> real calibration data (which it is not). Distros should not use that,
> only developers for testing purposes. We should not courage users using
> example calibration data.
>
> The simple fix is to rename the NVS file in linux-firmware to something
> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> you send a patch to linux-firmware I'm happy to ack that.
I agree with rename and fact that default/example data should not be
used.
But...
1) Kernel should not read device/model specific data from VFS where
are stored not-device-specific files preinstalled by linux
distributions.
And linux distributions are already putting files into VFS and kernel
cannot enforce userspace to not do that (as they are already doing it).
2) It was already tested that example NVS data can be used for N900 e.g.
for SSH connection. If real correct data are not available it is better
to use at least those example (and probably log warning message) so user
can connect via SSH and start investigating where is problem.
3) If we do rename *now* we will totally break wifi support on Nokia
N900.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-01-27 11:27 UTC (permalink / raw)
To: Arend Van Spriel, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <a36abf1d-5d4b-4c37-e325-a69166663a04@broadcom.com>
> I actually have two dependent brcmfmac patches. Do you expect
> conflict if Kalle takes all?
Not really, if that's somehow easier we can do that.
johannes
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 11:49 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127103408.GG24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>> So
>> for those other platforms there will be a delay waiting for user-mode
>> helper to fail, before trying to get nvs file from /lib/firmware.
>
> Yes, there will be. But there is no easy way to fix this problem that
> kernel is trying to use default/example NVS data...
Kernel is doing correctly and requesting NVS data as expected, the
problem here is that linux-firmware claims that the example NVS data is
real calibration data (which it is not). Distros should not use that,
only developers for testing purposes. We should not courage users using
example calibration data.
The simple fix is to rename the NVS file in linux-firmware to something
like wl1251-nvs.bin.example, no need to workaround this in kernel. If
you send a patch to linux-firmware I'm happy to ack that.
--=20
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-01-26
From: Kalle Valo @ 2017-01-27 11:24 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1485462650.26003.11.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here's my first pull-request intended for v4.11. It has a bunch of
> fixes, cleanups and improvements here and there, as well as a few new
> features. More details in the tag description.
>
> 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 106e0deca1ac6ac627a10617fe77a95200cb01a7:
>
> rtlwifi: rtl8192cu: Convert driver to use common macros (2017-01-20 12:06:10 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-01-26
>
> for you to fetch changes up to 758c98e089389e90732fe45087fdee3177493a81:
>
> iwlwifi: mvm: cleanup redundant assignment (2017-01-26 09:39:02 +0200)
>
> ----------------------------------------------------------------
> Some improvements, bugfixes and new features:
> * A bunch of cleanups here and there;
> * A few simple bugfixes;
> * Some more work in preparation for A000 family support;
> * Add support for radiotap timestamps;
> * Some work on our firmware debugging capabilities;
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-01-27 11:29 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <1485516428.5851.6.camel@sipsolutions.net>
On 27-1-2017 12:27, Johannes Berg wrote:
>
>> I actually have two dependent brcmfmac patches. Do you expect
>> conflict if Kalle takes all?
>
> Not really, if that's somehow easier we can do that.
Will do. I checked the other drivers. All those supporting wowl
netdetect did provide max_nd_matchsets except for brcmfmac.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Arend Van Spriel @ 2017-01-27 11:25 UTC (permalink / raw)
To: Johannes Berg, Luca Coelho; +Cc: linux-wireless
In-Reply-To: <13d1e654-6928-39e7-4751-fb90d3da7a54@broadcom.com>
On 24-1-2017 12:28, Arend Van Spriel wrote:
> On 24-1-2017 9:57, Johannes Berg wrote:
>> On Thu, 2017-01-19 at 14:08 +0100, Arend Van Spriel wrote:
>>>
>>> On 19-1-2017 13:00, Luca Coelho wrote:
>>>> On Thu, 2017-01-19 at 10:01 +0000, Arend van Spriel wrote:
>>>>> For wowlan netdetect a separate limit is defined for the number
>>>>> of
>>>>> matchsets. Currently, this limit is ignored and the regular limit
>>>>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets,
>>>>> is
>>>>> used for the net-detect case as well.
>>>>>
>>>>> Cc: Luciano Coelho <luciano.coelho@intel.com>
>>>>> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>>>>> ---
>>>>
>>>> What?! You don't have the same number of matchsets for both? :P
>>>
>>> Actually I have, but your comment mentioned they do not have to be
>>> the
>>> same. brcmfmac actually did not set max_nd_match_sets so I was
>>> surprised
>>> it worked. That said this patch will result in regression in brcmfmac
>>> :-p Not sure about other drivers supporting net-detect.
>>
>> So do you want to submit a patch to brcmfmac first, and then I'll apply
>> this later? I can apply it and break it, but now that we already know
>> ...?
>
> I have a brcmfmac patch in the queue. I will look at the other scheduled
> scan supporting drivers.
Hi Johannes,
I actually have two dependent brcmfmac patches. Do you expect conflict
if Kalle takes all?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 10:34 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <f60cf2c0-bc1e-3a5f-991c-dc6c95a656af@broadcom.com>
On Friday 27 January 2017 11:19:25 Arend Van Spriel wrote:
> On 27-1-2017 11:10, Pali Rohár wrote:
> > On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> >> On 27-1-2017 10:43, Pali Rohár wrote:
> >>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >>>> Pali Rohár <pali.rohar@gmail.com> writes:
> >>>>
> >>>>> NVS calibration data for wl1251 are model specific. Every one device with
> >>>>> wl1251 chip has different and calibrated in factory.
> >>>>>
> >>>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> >>>>> in that case there is no "standard" place. Every device has stored them on
> >>>>> different place (some in rootfs file, some in dedicated nand partition,
> >>>>> some in another proprietary structure).
> >>>>>
> >>>>> Kernel wl1251 driver cannot support every one different storage decided by
> >>>>> device manufacture so it will use request_firmware_prefer_user() call for
> >>>>> loading NVS calibration data and userspace helper will be responsible to
> >>>>> prepare correct data.
> >>>>>
> >>>>> In case userspace helper fails request_firmware_prefer_user() still try to
> >>>>> load data file directly from VFS as fallback mechanism.
> >>>>>
> >>>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> >>>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> >>>>> devices.
> >>>>>
> >>>>> With this patch it is finally possible to load correct model specific NVS
> >>>>> calibration data for Nokia N900.
> >>>>>
> >>>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >>>>> ---
> >>>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> >>>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> >>>>> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> index 7142ccf..affe154 100644
> >>>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> >>>>> @@ -2,6 +2,7 @@ config WL1251
> >>>>> tristate "TI wl1251 driver support"
> >>>>> depends on MAC80211
> >>>>> select FW_LOADER
> >>>>> + select FW_LOADER_USER_HELPER
> >>>>> select CRC7
> >>>>> ---help---
> >>>>> This will enable TI wl1251 driver support. The drivers make
> >>>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> >>>>> index 208f062..24f8866 100644
> >>>>> --- a/drivers/net/wireless/ti/wl1251/main.c
> >>>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
> >>>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> >>>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
> >>>>> int ret;
> >>>>>
> >>>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> >>>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
> >>>>
> >>>> I don't see the need for this. Just remove the default nvs file from
> >>>> filesystem and the fallback user helper will be always used, right?
> >>>
> >>> It is part of linux-firmware repository. And already part of all
> >>> previous versions of linux-firmware packages in lot of linux
> >>> distributions. So removing it is not possible...
> >>
> >> You are probably saying that on your platform you can not remove
> >> anything from /lib/firmware, right? I don't see how you come from "it is
> >> part of firmware package" to "removing is not possible". Trying to
> >> understand this and it makes no sense.
> >
> > It is already in linux distribution packages. If I remove that file from
> > file system it will be placed there again by package management or it it
> > will throw error message about system integrity (missing file, etc...).
> >
> > Also that file is already in linux-firmware git and so is propagated to
> > /lib/firmware by anybody who is using linux-firmware.
> >
> >>>> Like we discussed earlier, the default nvs file should not be used by
> >>>> normal users.
> >>>
> >>> But already is and we need to deal with this fact.
> >>
> >> Why?
> >
> > Because everybody has already installed it.
> >
> >> Are there other platforms that use the default nvs file and have a
> >> working wifi.
> >
> > I do not know.
> >
> >> So your "removing is not possible" would be about
> >> regression for those?
> >
> > Yes, that is possible.
> >
> > Also you can use wifi on Nokia N900 with this default file. Yes it is
> > not recommended and probably has performance problems... but more people
> > use it for SSH and it is working. Pavel could confirm this.
> >
> > So yes, if you remove that file *now* there is regression for Nokia N900
> > when you are using SSH over wifi.
>
> So you are changing the behavior for all platforms using wl1251, but the
> user-helper preference is (probably) only applicable for N900, right?
No. Some wl1251 chips have internal EEPROM where is stored MAC address
and NVS data. And kernel driver already can read it. So this change is
only for platforms without internal EEPROM.
And all platforms without internal EEPROM should use userspace helper to
provide correct NVS data (and ideally also MAC address).
Except Nokia N900 I know just Pandora who has also wl1251 chip. But
Pandora has EEPROM.
Grepping linux source code... and I see only defines for Nokia N900 and
Pandora. There can be also another user with external DTS file, but what
is reality? Is there still really any other user of wl1251 chip with
upstream kernel? If yes, we can prepare userspace helper if he does not
have NVS stored in EEPROM...
> So
> for those other platforms there will be a delay waiting for user-mode
> helper to fail, before trying to get nvs file from /lib/firmware.
Yes, there will be. But there is no easy way to fix this problem that
kernel is trying to use default/example NVS data...
When helper is not available this patch just adds delay, but
functionality is still there and same. With helper support will be
finally fixed.
And I have no idea if those default NVS data are somehow usable on other
platforms...
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 10:19 UTC (permalink / raw)
To: Pali Rohár
Cc: Kalle Valo, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127101043.GD24223@pali>
On 27-1-2017 11:10, Pali Rohár wrote:
> On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
>> On 27-1-2017 10:43, Pali Rohár wrote:
>>> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>>
>>>>> NVS calibration data for wl1251 are model specific. Every one device with
>>>>> wl1251 chip has different and calibrated in factory.
>>>>>
>>>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>>>>> in that case there is no "standard" place. Every device has stored them on
>>>>> different place (some in rootfs file, some in dedicated nand partition,
>>>>> some in another proprietary structure).
>>>>>
>>>>> Kernel wl1251 driver cannot support every one different storage decided by
>>>>> device manufacture so it will use request_firmware_prefer_user() call for
>>>>> loading NVS calibration data and userspace helper will be responsible to
>>>>> prepare correct data.
>>>>>
>>>>> In case userspace helper fails request_firmware_prefer_user() still try to
>>>>> load data file directly from VFS as fallback mechanism.
>>>>>
>>>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>>>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>>>>> devices.
>>>>>
>>>>> With this patch it is finally possible to load correct model specific NVS
>>>>> calibration data for Nokia N900.
>>>>>
>>>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>>>> ---
>>>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>>>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>>>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> index 7142ccf..affe154 100644
>>>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>>>>> @@ -2,6 +2,7 @@ config WL1251
>>>>> tristate "TI wl1251 driver support"
>>>>> depends on MAC80211
>>>>> select FW_LOADER
>>>>> + select FW_LOADER_USER_HELPER
>>>>> select CRC7
>>>>> ---help---
>>>>> This will enable TI wl1251 driver support. The drivers make
>>>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>>>>> index 208f062..24f8866 100644
>>>>> --- a/drivers/net/wireless/ti/wl1251/main.c
>>>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>>>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>>>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>>>>> int ret;
>>>>>
>>>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>>>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>>>>
>>>> I don't see the need for this. Just remove the default nvs file from
>>>> filesystem and the fallback user helper will be always used, right?
>>>
>>> It is part of linux-firmware repository. And already part of all
>>> previous versions of linux-firmware packages in lot of linux
>>> distributions. So removing it is not possible...
>>
>> You are probably saying that on your platform you can not remove
>> anything from /lib/firmware, right? I don't see how you come from "it is
>> part of firmware package" to "removing is not possible". Trying to
>> understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
>>>> Like we discussed earlier, the default nvs file should not be used by
>>>> normal users.
>>>
>>> But already is and we need to deal with this fact.
>>
>> Why?
>
> Because everybody has already installed it.
>
>> Are there other platforms that use the default nvs file and have a
>> working wifi.
>
> I do not know.
>
>> So your "removing is not possible" would be about
>> regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
>
> So yes, if you remove that file *now* there is regression for Nokia N900
> when you are using SSH over wifi.
So you are changing the behavior for all platforms using wl1251, but the
user-helper preference is (probably) only applicable for N900, right? So
for those other platforms there will be a delay waiting for user-mode
helper to fail, before trying to get nvs file from /lib/firmware.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 10:10 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <def4c357-64c0-0681-a5d5-f49a6cb84a92@broadcom.com>
On Friday 27 January 2017 11:05:32 Arend Van Spriel wrote:
> On 27-1-2017 10:43, Pali Rohár wrote:
> > On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >>> NVS calibration data for wl1251 are model specific. Every one device with
> >>> wl1251 chip has different and calibrated in factory.
> >>>
> >>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
> >>> in that case there is no "standard" place. Every device has stored them on
> >>> different place (some in rootfs file, some in dedicated nand partition,
> >>> some in another proprietary structure).
> >>>
> >>> Kernel wl1251 driver cannot support every one different storage decided by
> >>> device manufacture so it will use request_firmware_prefer_user() call for
> >>> loading NVS calibration data and userspace helper will be responsible to
> >>> prepare correct data.
> >>>
> >>> In case userspace helper fails request_firmware_prefer_user() still try to
> >>> load data file directly from VFS as fallback mechanism.
> >>>
> >>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> >>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> >>> devices.
> >>>
> >>> With this patch it is finally possible to load correct model specific NVS
> >>> calibration data for Nokia N900.
> >>>
> >>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >>> ---
> >>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> >>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> >>> 2 files changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> >>> index 7142ccf..affe154 100644
> >>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> >>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> >>> @@ -2,6 +2,7 @@ config WL1251
> >>> tristate "TI wl1251 driver support"
> >>> depends on MAC80211
> >>> select FW_LOADER
> >>> + select FW_LOADER_USER_HELPER
> >>> select CRC7
> >>> ---help---
> >>> This will enable TI wl1251 driver support. The drivers make
> >>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> >>> index 208f062..24f8866 100644
> >>> --- a/drivers/net/wireless/ti/wl1251/main.c
> >>> +++ b/drivers/net/wireless/ti/wl1251/main.c
> >>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> >>> struct device *dev = wiphy_dev(wl->hw->wiphy);
> >>> int ret;
> >>>
> >>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> >>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
> >>
> >> I don't see the need for this. Just remove the default nvs file from
> >> filesystem and the fallback user helper will be always used, right?
> >
> > It is part of linux-firmware repository. And already part of all
> > previous versions of linux-firmware packages in lot of linux
> > distributions. So removing it is not possible...
>
> You are probably saying that on your platform you can not remove
> anything from /lib/firmware, right? I don't see how you come from "it is
> part of firmware package" to "removing is not possible". Trying to
> understand this and it makes no sense.
It is already in linux distribution packages. If I remove that file from
file system it will be placed there again by package management or it it
will throw error message about system integrity (missing file, etc...).
Also that file is already in linux-firmware git and so is propagated to
/lib/firmware by anybody who is using linux-firmware.
> >> Like we discussed earlier, the default nvs file should not be used by
> >> normal users.
> >
> > But already is and we need to deal with this fact.
>
> Why?
Because everybody has already installed it.
> Are there other platforms that use the default nvs file and have a
> working wifi.
I do not know.
> So your "removing is not possible" would be about
> regression for those?
Yes, that is possible.
Also you can use wifi on Nokia N900 with this default file. Yes it is
not recommended and probably has performance problems... but more people
use it for SSH and it is working. Pavel could confirm this.
So yes, if you remove that file *now* there is regression for Nokia N900
when you are using SSH over wifi.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Pali Rohár @ 2017-01-27 9:05 UTC (permalink / raw)
To: Kalle Valo
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87inp1ndgm.fsf@codeaurora.org>
On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > In case there is no valid MAC address kernel generates random one. This
> > patch propagate this generated MAC address back to NVS data which will be
> > uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> > uses.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> Why? What issue does this fix?
Send permanent MAC address to wl1251 chip, same what is doing wl12xx
driver.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 10:05 UTC (permalink / raw)
To: Pali Rohár, Kalle Valo
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127094342.GC24223@pali>
On 27-1-2017 10:43, Pali Rohár wrote:
> On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
>> Pali Rohár <pali.rohar@gmail.com> writes:
>>
>>> NVS calibration data for wl1251 are model specific. Every one device with
>>> wl1251 chip has different and calibrated in factory.
>>>
>>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>>> in that case there is no "standard" place. Every device has stored them on
>>> different place (some in rootfs file, some in dedicated nand partition,
>>> some in another proprietary structure).
>>>
>>> Kernel wl1251 driver cannot support every one different storage decided by
>>> device manufacture so it will use request_firmware_prefer_user() call for
>>> loading NVS calibration data and userspace helper will be responsible to
>>> prepare correct data.
>>>
>>> In case userspace helper fails request_firmware_prefer_user() still try to
>>> load data file directly from VFS as fallback mechanism.
>>>
>>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>>> devices.
>>>
>>> With this patch it is finally possible to load correct model specific NVS
>>> calibration data for Nokia N900.
>>>
>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>> ---
>>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>>> index 7142ccf..affe154 100644
>>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>>> @@ -2,6 +2,7 @@ config WL1251
>>> tristate "TI wl1251 driver support"
>>> depends on MAC80211
>>> select FW_LOADER
>>> + select FW_LOADER_USER_HELPER
>>> select CRC7
>>> ---help---
>>> This will enable TI wl1251 driver support. The drivers make
>>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>>> index 208f062..24f8866 100644
>>> --- a/drivers/net/wireless/ti/wl1251/main.c
>>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>>> int ret;
>>>
>>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>>
>> I don't see the need for this. Just remove the default nvs file from
>> filesystem and the fallback user helper will be always used, right?
>
> It is part of linux-firmware repository. And already part of all
> previous versions of linux-firmware packages in lot of linux
> distributions. So removing it is not possible...
You are probably saying that on your platform you can not remove
anything from /lib/firmware, right? I don't see how you come from "it is
part of firmware package" to "removing is not possible". Trying to
understand this and it makes no sense.
>> Like we discussed earlier, the default nvs file should not be used by
>> normal users.
>
> But already is and we need to deal with this fact.
Why? Are there other platforms that use the default nvs file and have a
working wifi. So your "removing is not possible" would be about
regression for those?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 9:43 UTC (permalink / raw)
To: Kalle Valo
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87tw8lnei3.fsf@codeaurora.org>
On Friday 27 January 2017 09:33:40 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > NVS calibration data for wl1251 are model specific. Every one device with
> > wl1251 chip has different and calibrated in factory.
> >
> > Not all wl1251 chips have own EEPROM where are calibration data stored. And
> > in that case there is no "standard" place. Every device has stored them on
> > different place (some in rootfs file, some in dedicated nand partition,
> > some in another proprietary structure).
> >
> > Kernel wl1251 driver cannot support every one different storage decided by
> > device manufacture so it will use request_firmware_prefer_user() call for
> > loading NVS calibration data and userspace helper will be responsible to
> > prepare correct data.
> >
> > In case userspace helper fails request_firmware_prefer_user() still try to
> > load data file directly from VFS as fallback mechanism.
> >
> > On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
> > in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> > devices.
> >
> > With this patch it is finally possible to load correct model specific NVS
> > calibration data for Nokia N900.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> > drivers/net/wireless/ti/wl1251/main.c | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
> > index 7142ccf..affe154 100644
> > --- a/drivers/net/wireless/ti/wl1251/Kconfig
> > +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> > @@ -2,6 +2,7 @@ config WL1251
> > tristate "TI wl1251 driver support"
> > depends on MAC80211
> > select FW_LOADER
> > + select FW_LOADER_USER_HELPER
> > select CRC7
> > ---help---
> > This will enable TI wl1251 driver support. The drivers make
> > diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
> > index 208f062..24f8866 100644
> > --- a/drivers/net/wireless/ti/wl1251/main.c
> > +++ b/drivers/net/wireless/ti/wl1251/main.c
> > @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> > struct device *dev = wiphy_dev(wl->hw->wiphy);
> > int ret;
> >
> > - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
> > + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>
> I don't see the need for this. Just remove the default nvs file from
> filesystem and the fallback user helper will be always used, right?
It is part of linux-firmware repository. And already part of all
previous versions of linux-firmware packages in lot of linux
distributions. So removing it is not possible...
> Like we discussed earlier, the default nvs file should not be used by
> normal users.
But already is and we need to deal with this fact.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Kalle Valo @ 2017-01-27 9:30 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127090538.GB24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 09:56:09 Kalle Valo wrote:
>> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>>=20
>> > In case there is no valid MAC address kernel generates random one. This
>> > patch propagate this generated MAC address back to NVS data which will=
be
>> > uploaded to wl1251 chip. So HW would have same MAC address as linux ke=
rnel
>> > uses.
>> >
>> > Signed-off-by: Pali Roh=C3=A1r <pali.rohar@gmail.com>
>>=20
>> Why? What issue does this fix?
>
> Send permanent MAC address to wl1251 chip, same what is doing wl12xx
> driver.
Ok, so this doesn't change functionality in any way and you are adding
it only because wl12xx does the same? You should document that in the
the commit log.
If there's no change I don't really see the point of this. But if
there's harm, hopefully, I guess it's ok.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 8:58 UTC (permalink / raw)
To: Kalle Valo, Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <87tw8lnei3.fsf@codeaurora.org>
On 27-1-2017 8:33, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
>> NVS calibration data for wl1251 are model specific. Every one device with
>> wl1251 chip has different and calibrated in factory.
>>
>> Not all wl1251 chips have own EEPROM where are calibration data stored. And
>> in that case there is no "standard" place. Every device has stored them on
>> different place (some in rootfs file, some in dedicated nand partition,
>> some in another proprietary structure).
>>
>> Kernel wl1251 driver cannot support every one different storage decided by
>> device manufacture so it will use request_firmware_prefer_user() call for
>> loading NVS calibration data and userspace helper will be responsible to
>> prepare correct data.
>>
>> In case userspace helper fails request_firmware_prefer_user() still try to
>> load data file directly from VFS as fallback mechanism.
>>
>> On Nokia N900 device which has wl1251 chip, NVS calibration data are stored
>> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
>> devices.
>>
>> With this patch it is finally possible to load correct model specific NVS
>> calibration data for Nokia N900.
>>
>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> ---
>> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
>> drivers/net/wireless/ti/wl1251/main.c | 2 +-
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireless/ti/wl1251/Kconfig
>> index 7142ccf..affe154 100644
>> --- a/drivers/net/wireless/ti/wl1251/Kconfig
>> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
>> @@ -2,6 +2,7 @@ config WL1251
>> tristate "TI wl1251 driver support"
>> depends on MAC80211
>> select FW_LOADER
>> + select FW_LOADER_USER_HELPER
>> select CRC7
>> ---help---
>> This will enable TI wl1251 driver support. The drivers make
>> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c
>> index 208f062..24f8866 100644
>> --- a/drivers/net/wireless/ti/wl1251/main.c
>> +++ b/drivers/net/wireless/ti/wl1251/main.c
>> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
>> struct device *dev = wiphy_dev(wl->hw->wiphy);
>> int ret;
>>
>> - ret = request_firmware(&fw, WL1251_NVS_NAME, dev);
>> + ret = request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
>
> I don't see the need for this. Just remove the default nvs file from
> filesystem and the fallback user helper will be always used, right?
Indeed. The only remaining issue would be that an error message is
logged. Also note the fallback is only used if selected in Kconfig.
> Like we discussed earlier, the default nvs file should not be used by
> normal users.
Yup.
Regards,
Arend
^ permalink raw reply
* [PATCH] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Felix Fietkau @ 2017-01-27 8:34 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, sgruszka, vishalthanki
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 3 ---
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 8fcbc8dc94c1..75f838405344 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1436,14 +1436,11 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
-#if IS_ENABLED(CONFIG_RT2X00_LIB_USB)
if (rt2x00_is_usb(rt2x00dev)) {
- usb_kill_anchored_urbs(rt2x00dev->anchor);
hrtimer_cancel(&rt2x00dev->txstatus_timer);
cancel_work_sync(&rt2x00dev->rxdone_work);
cancel_work_sync(&rt2x00dev->txdone_work);
}
-#endif
if (rt2x00dev->workqueue)
destroy_workqueue(rt2x00dev->workqueue);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 838ca58d2dd6..be5beaacf4f0 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -858,11 +858,13 @@ void rt2x00usb_disconnect(struct usb_interface *usb_intf)
{
struct ieee80211_hw *hw = usb_get_intfdata(usb_intf);
struct rt2x00_dev *rt2x00dev = hw->priv;
+ struct usb_anchor *anchor = rt2x00dev->anchor;
/*
* Free all allocated data.
*/
rt2x00lib_remove_dev(rt2x00dev);
+ usb_kill_anchored_urbs(anchor);
rt2x00usb_free_reg(rt2x00dev);
ieee80211_free_hw(hw);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 6/6] wl1251: Set generated MAC address back to NVS data
From: Kalle Valo @ 2017-01-27 7:56 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-7-git-send-email-pali.rohar@gmail.com>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> In case there is no valid MAC address kernel generates random one. This
> patch propagate this generated MAC address back to NVS data which will be
> uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> uses.
>
> Signed-off-by: Pali Roh=C3=A1r <pali.rohar@gmail.com>
Why? What issue does this fix?
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5/6] wl1251: Parse and use MAC address from supplied NVS data
From: Kalle Valo @ 2017-01-27 7:54 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-6-git-send-email-pali.rohar@gmail.com>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> This patch implements parsing MAC address from NVS data which are sent to
> wl1251 chip. Calibration NVS data could contain valid MAC address and it
> will be used instead randomly generated.
>
> This patch also move code for requesting NVS data from userspace to driver
> initialization code to make sure that NVS data will be there at time when
> permanent MAC address is needed.
>
> Calibration NVS data for wl1251 are model specific. Every one device with
> wl1251 chip should have been calibrated in factory and needs to provide o=
wn
> calibration data.
>
> Default example wl1251-nvs.bin data found in linux-firmware repository and
> contains MAC address 00:00:20:07:03:09. So this MAC address is marked as
> invalid as it is not real device specific address, just example one.
>
> Format of calibration NVS data can be found at:
> http://notaz.gp2x.de/misc/pnd/wl1251/nvs_map.txt
>
> Signed-off-by: Pali Roh=C3=A1r <pali.rohar@gmail.com>
[...]
> +static int wl1251_read_nvs_mac(struct wl1251 *wl)
> +{
> + u8 mac[ETH_ALEN];
> + int i;
> +
> + if (wl->nvs_len < 0x24)
> + return -ENODATA;
> +
> + /* length is 2 and data address is 0x546c (mask is 0xfffe) */
> + if (wl->nvs[0x19] !=3D 2 || wl->nvs[0x1a] !=3D 0x6d || wl->nvs[0x1b] !=
=3D 0x54)
> + return -EINVAL;
> +
> + /* MAC is stored in reverse order */
> + for (i =3D 0; i < ETH_ALEN; i++)
> + mac[i] =3D wl->nvs[0x1c + ETH_ALEN - i - 1];
No magic numbers, please. Replace all nvs offsets with proper defines to
make the code more readable.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 7:33 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <1482598381-16513-3-git-send-email-pali.rohar@gmail.com>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> NVS calibration data for wl1251 are model specific. Every one device with
> wl1251 chip has different and calibrated in factory.
>
> Not all wl1251 chips have own EEPROM where are calibration data stored. A=
nd
> in that case there is no "standard" place. Every device has stored them on
> different place (some in rootfs file, some in dedicated nand partition,
> some in another proprietary structure).
>
> Kernel wl1251 driver cannot support every one different storage decided by
> device manufacture so it will use request_firmware_prefer_user() call for
> loading NVS calibration data and userspace helper will be responsible to
> prepare correct data.
>
> In case userspace helper fails request_firmware_prefer_user() still try to
> load data file directly from VFS as fallback mechanism.
>
> On Nokia N900 device which has wl1251 chip, NVS calibration data are stor=
ed
> in CAL nand partition. CAL is proprietary Nokia key/value format for nand
> devices.
>
> With this patch it is finally possible to load correct model specific NVS
> calibration data for Nokia N900.
>
> Signed-off-by: Pali Roh=C3=A1r <pali.rohar@gmail.com>
> ---
> drivers/net/wireless/ti/wl1251/Kconfig | 1 +
> drivers/net/wireless/ti/wl1251/main.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wl1251/Kconfig b/drivers/net/wireles=
s/ti/wl1251/Kconfig
> index 7142ccf..affe154 100644
> --- a/drivers/net/wireless/ti/wl1251/Kconfig
> +++ b/drivers/net/wireless/ti/wl1251/Kconfig
> @@ -2,6 +2,7 @@ config WL1251
> tristate "TI wl1251 driver support"
> depends on MAC80211
> select FW_LOADER
> + select FW_LOADER_USER_HELPER
> select CRC7
> ---help---
> This will enable TI wl1251 driver support. The drivers make
> diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless=
/ti/wl1251/main.c
> index 208f062..24f8866 100644
> --- a/drivers/net/wireless/ti/wl1251/main.c
> +++ b/drivers/net/wireless/ti/wl1251/main.c
> @@ -110,7 +110,7 @@ static int wl1251_fetch_nvs(struct wl1251 *wl)
> struct device *dev =3D wiphy_dev(wl->hw->wiphy);
> int ret;
>=20=20
> - ret =3D request_firmware(&fw, WL1251_NVS_NAME, dev);
> + ret =3D request_firmware_prefer_user(&fw, WL1251_NVS_NAME, dev);
I don't see the need for this. Just remove the default nvs file from
filesystem and the fallback user helper will be always used, right?
Like we discussed earlier, the default nvs file should not be used by
normal users.
--=20
Kalle Valo
^ permalink raw reply
* rtl8187: No multicast
From: Nils Holland @ 2017-01-26 21:25 UTC (permalink / raw)
To: linux-wireless
Hi folks,
recently, a laptop featuring a rtl8187b usb wifi adapter, precisely,
this one:
Bus 001 Device 002: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless Adapter
fell into my hands. I noticed that in my IPv6 enabled home network,
the card would not receive any RAs and thus not acquire an IPv6
address. So I thought I'd have a look at the respective driver code,
with the intention of probably being able to fix this and submit a
patch. However, I have to admit that now I'm stuck and could use some
help. :-)
The relevant section of code, in
linux/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c, is certainly
this here:
static void rtl8187_configure_filter(struct ieee80211_hw *dev,
unsigned int changed_flags,
unsigned int *total_flags,
u64 multicast)
{
struct rtl8187_priv *priv = dev->priv;
if (changed_flags & FIF_FCSFAIL)
priv->rx_conf ^= RTL818X_RX_CONF_FCS;
if (changed_flags & FIF_CONTROL)
priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
if (changed_flags & FIF_OTHER_BSS)
priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
if (*total_flags & FIF_ALLMULTI || multicast > 0)
priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
else
priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
*total_flags = 0;
if (priv->rx_conf & RTL818X_RX_CONF_FCS)
*total_flags |= FIF_FCSFAIL;
if (priv->rx_conf & RTL818X_RX_CONF_CTRL)
*total_flags |= FIF_CONTROL;
if (priv->rx_conf & RTL818X_RX_CONF_MONITOR)
*total_flags |= FIF_OTHER_BSS;
if (priv->rx_conf & RTL818X_RX_CONF_MULTICAST)
*total_flags |= FIF_ALLMULTI;
rtl818x_iowrite32_async(priv, &priv->map->RX_CONF, priv->rx_conf);
}
I believe the card needs to receive multicast data in orde to pick up
RAs, and this seems to be properly set up by setting the
RTL818X_RX_CONF_MULTICAST flag. In fact, I have verified that this
actually gets set in my case, by printk()'ing "multicast" and
verifying that it is indeed > 0, as well as by changing the code to do
priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
unconditionally. Sadly, that didn't help. I also, just out of
cluelessness, fiddled with the RTL818X_RX_CONF_BROADCAST flag which is
not touched in this function, but only set once in rtl8187_start(),
but of course, that didn't make a difference either.
Only one thing seemed to work: Unconditionally putting the card into
monitor mode, by adding
priv->rx_conf |= RTL818X_RX_CONF_MONITOR;
somewhere before the iowrite in the function above. That did in fact
make a difference and my card picked up an RA and IPv6 address.
However, it's probably not really a fix, as having the card run in
monitor mode all the time doesn't sound like too good of an idea.
So ... I have the feeling that the whole multicast filtering stuff of
the card / driver doesn't seem to be working right. And I have no idea
if it's the hardware or the driver. I did indeed find some datasheet
for the card on the web, but either it didn't really contain the info
on how to do this stuff right (or, at all), or I was too stupid to
find / understand it.
I'd really appreciate it if someone has some help or pointers, as I'd
be really glad if I could find a proper way to fix this!
Greetings
Nils
^ permalink raw reply
* pull-request: iwlwifi-next 2017-01-26
From: Luca Coelho @ 2017-01-26 20:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 4822 bytes --]
Hi Kalle,
Here's my first pull-request intended for v4.11. It has a bunch of
fixes, cleanups and improvements here and there, as well as a few new
features. More details in the tag description.
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 106e0deca1ac6ac627a10617fe77a95200cb01a7:
rtlwifi: rtl8192cu: Convert driver to use common macros (2017-01-20 12:06:10 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-01-26
for you to fetch changes up to 758c98e089389e90732fe45087fdee3177493a81:
iwlwifi: mvm: cleanup redundant assignment (2017-01-26 09:39:02 +0200)
----------------------------------------------------------------
Some improvements, bugfixes and new features:
* A bunch of cleanups here and there;
* A few simple bugfixes;
* Some more work in preparation for A000 family support;
* Add support for radiotap timestamps;
* Some work on our firmware debugging capabilities;
----------------------------------------------------------------
Johannes Berg (5):
iwlwifi: mvm: expose device timestamp in radiotap
iwlwifi: mvm: accept arbitrary memory dump TLVs
iwlwifi: mvm: make iwl_dump_prph() void
iwlwifi: allow memory debug TLV to specify the memory type
iwlwifi: mvm: properly check for transport data in dump
Jürg Billeter (1):
iwlwifi: fix MODULE_FIRMWARE for 6030
Kirtika Ruchandani (3):
iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables
iwlwifi: mvm: rs: Remove unused 'mcs' variable
iwlwifi: pcie: trans: Remove unused 'shift_param'
Luca Coelho (7):
iwlwifi: mvm: don't restart HW if suspend fails with unified image
iwlwifi: mvm: bump max API to 28
iwlwifi: mvm: remove unused variable in iwl_mvm_handle_statistics()
iwlwifi: dvm: make rs_tl_get_load() return void
iwlwifi: mvm: remove unused sta_id variable in iwl_mvm_change_queue_owner()
iwlwifi: dvm: remove unused variable compiler warning in debugfs.c
iwlwifi: mvm: mark ret as maybe_unused in iwl_dbgfs_fw_restart_write()
Sara Sharon (9):
iwlwifi: mvm: simplify paging allocation code
iwlwifi: mvm: replace the number of blocks calculation
iwlwifi: enlarge number of ucode sections
iwlwifi: mvm: change iwl_mvm_tx_csum to return value
iwlwifi: mvm: separate rate calculation to a new function
iwlwifi: mvm: support version 2 of stored beacon notification
iwlwifi: pcie: cleanup rfkill checks
iwlwifi: mvm: use mvm_disable_queue instead of sharing logic
iwlwifi: mvm: cleanup redundant assignment
drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/mac80211.c | 2 +-
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 11 +++----
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-6000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +--
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 +--
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 98 +++++++++++++++++++++++++++++++++++--------------------------
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 24 +++++++--------
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 7 +++--
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 13 +++++----
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 6 ++--
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 123 +++++++++++++++++++++++++++++++++++++++++++++++++----------------------------
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 69 ++++++++++++-------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +++++-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 4 +--
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 10 +------
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 2 --
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 31 +++++---------------
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 107 ++++++++++++++++++++++++++++++++++++-------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 14 ++++-----
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 51 ++++++++++++++------------------
26 files changed, 299 insertions(+), 304 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
From: Larry Finger @ 2017-01-26 17:25 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Michael Schenk, Larry Finger, Stable
From: Michael Schenk <michael.schenk@albis-elcon.com>
In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.
Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
Kalle,
This fix should be sent upstream whenever possible.
It is an old bug.
Thanks,
Larry
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 0bca263..4d989b8 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -818,12 +818,30 @@ static void rtl_usb_stop(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
struct rtl_usb *rtlusb = rtl_usbdev(rtl_usbpriv(hw));
+ struct urb *urb;
/* should after adapter start and interrupt enable. */
set_hal_stop(rtlhal);
cancel_work_sync(&rtlpriv->works.fill_h2c_cmd);
/* Enable software */
SET_USB_STOP(rtlusb);
+
+ /* free pre-allocated URBs from rtl_usb_start() */
+ usb_kill_anchored_urbs(&rtlusb->rx_submitted);
+
+ tasklet_kill(&rtlusb->rx_work_tasklet);
+ cancel_work_sync(&rtlpriv->works.lps_change_work);
+
+ flush_workqueue(rtlpriv->works.rtl_wq);
+
+ skb_queue_purge(&rtlusb->rx_queue);
+
+ while ((urb = usb_get_from_anchor(&rtlusb->rx_cleanup_urbs))) {
+ usb_free_coherent(urb->dev, urb->transfer_buffer_length,
+ urb->transfer_buffer, urb->transfer_dma);
+ usb_free_urb(urb);
+ }
+
rtlpriv->cfg->ops->hw_disable(hw);
}
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] wireless: define cipher/AKM suites using a macro
From: Luca Coelho @ 2017-01-26 16:52 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20170126162003.31531-1-johannes@sipsolutions.net>
On Thu, 2017-01-26 at 17:20 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> The spec writes cipher/AKM suites as something like 00-0F-AC:9,
> but the part after the colon isn't hex, it's decimal, so that
> we've already had a few mistakes (in other code, or unmerged
> patches) to e.g. write 0x000FAC10 instead of 0x000FAC0A.
>
> Use a macro to avoid that problem.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
--
Luca.
^ permalink raw reply
* [PATCH] wireless: define cipher/AKM suites using a macro
From: Johannes Berg @ 2017-01-26 16:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The spec writes cipher/AKM suites as something like 00-0F-AC:9,
but the part after the colon isn't hex, it's decimal, so that
we've already had a few mistakes (in other code, or unmerged
patches) to e.g. write 0x000FAC10 instead of 0x000FAC0A.
Use a macro to avoid that problem.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/ieee80211.h | 46 ++++++++++++++++++++++++----------------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 87d1937e4671..02768de209d6 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2324,31 +2324,33 @@ enum ieee80211_sa_query_action {
};
+#define SUITE(oui, id) (((oui) << 8) | (id))
+
/* cipher suite selectors */
-#define WLAN_CIPHER_SUITE_USE_GROUP 0x000FAC00
-#define WLAN_CIPHER_SUITE_WEP40 0x000FAC01
-#define WLAN_CIPHER_SUITE_TKIP 0x000FAC02
-/* reserved: 0x000FAC03 */
-#define WLAN_CIPHER_SUITE_CCMP 0x000FAC04
-#define WLAN_CIPHER_SUITE_WEP104 0x000FAC05
-#define WLAN_CIPHER_SUITE_AES_CMAC 0x000FAC06
-#define WLAN_CIPHER_SUITE_GCMP 0x000FAC08
-#define WLAN_CIPHER_SUITE_GCMP_256 0x000FAC09
-#define WLAN_CIPHER_SUITE_CCMP_256 0x000FAC0A
-#define WLAN_CIPHER_SUITE_BIP_GMAC_128 0x000FAC0B
-#define WLAN_CIPHER_SUITE_BIP_GMAC_256 0x000FAC0C
-#define WLAN_CIPHER_SUITE_BIP_CMAC_256 0x000FAC0D
-
-#define WLAN_CIPHER_SUITE_SMS4 0x00147201
+#define WLAN_CIPHER_SUITE_USE_GROUP SUITE(0x000FAC, 0)
+#define WLAN_CIPHER_SUITE_WEP40 SUITE(0x000FAC, 1)
+#define WLAN_CIPHER_SUITE_TKIP SUITE(0x000FAC, 2)
+/* reserved: SUITE(0x000FAC, 3) */
+#define WLAN_CIPHER_SUITE_CCMP SUITE(0x000FAC, 4)
+#define WLAN_CIPHER_SUITE_WEP104 SUITE(0x000FAC, 5)
+#define WLAN_CIPHER_SUITE_AES_CMAC SUITE(0x000FAC, 6)
+#define WLAN_CIPHER_SUITE_GCMP SUITE(0x000FAC, 8)
+#define WLAN_CIPHER_SUITE_GCMP_256 SUITE(0x000FAC, 9)
+#define WLAN_CIPHER_SUITE_CCMP_256 SUITE(0x000FAC, 10)
+#define WLAN_CIPHER_SUITE_BIP_GMAC_128 SUITE(0x000FAC, 11)
+#define WLAN_CIPHER_SUITE_BIP_GMAC_256 SUITE(0x000FAC, 12)
+#define WLAN_CIPHER_SUITE_BIP_CMAC_256 SUITE(0x000FAC, 13)
+
+#define WLAN_CIPHER_SUITE_SMS4 SUITE(0x001472, 1)
/* AKM suite selectors */
-#define WLAN_AKM_SUITE_8021X 0x000FAC01
-#define WLAN_AKM_SUITE_PSK 0x000FAC02
-#define WLAN_AKM_SUITE_8021X_SHA256 0x000FAC05
-#define WLAN_AKM_SUITE_PSK_SHA256 0x000FAC06
-#define WLAN_AKM_SUITE_TDLS 0x000FAC07
-#define WLAN_AKM_SUITE_SAE 0x000FAC08
-#define WLAN_AKM_SUITE_FT_OVER_SAE 0x000FAC09
+#define WLAN_AKM_SUITE_8021X SUITE(0x000FAC, 1)
+#define WLAN_AKM_SUITE_PSK SUITE(0x000FAC, 2)
+#define WLAN_AKM_SUITE_8021X_SHA256 SUITE(0x000FAC, 5)
+#define WLAN_AKM_SUITE_PSK_SHA256 SUITE(0x000FAC, 6)
+#define WLAN_AKM_SUITE_TDLS SUITE(0x000FAC, 7)
+#define WLAN_AKM_SUITE_SAE SUITE(0x000FAC, 8)
+#define WLAN_AKM_SUITE_FT_OVER_SAE SUITE(0x000FAC, 9)
#define WLAN_MAX_KEY_LEN 32
--
2.9.3
^ permalink raw reply related
* Re: IPv6-UDP 0x0000 checksum
From: Johannes Berg @ 2017-01-26 15:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-wireless
In-Reply-To: <1485444476.5145.136.camel@edumazet-glaptop3.roam.corp.google.com>
On Thu, 2017-01-26 at 07:27 -0800, Eric Dumazet wrote:
>
> if (!uh->check && !udp_sk(sk)->no_check6_rx) {
> udp6_csum_zero_error(skb);
> goto csum_error;
> }
Yeah, I'd found no_check6_rx already, was still trying to figure out this one :)
Looks like we actually check uh->check regardless of anything the
driver said (CHECKSUM_UNNECESSARY, or whatever), so we should be fine
even with the hardware tagging it as good in this case.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox