Re: iwlwifi errors (regression?) on 4.7.0
Hi Andy, Sorry for the really long delay in replying. :( On Sun, 2016-08-07 at 01:54 -0700, Andy Lutomirski wrote: > My Intel 7265 used to work flawlessly, but for the past week or two > it > has seemed to be very unreliable. It's also throwing errors. I see > problems on firmware versions 16 and 21, although I haven't gotten > the > warning and backtrace on firmware 16 yet. > > I have: > > iwlwifi :3a:00.0: enabling device ( -> 0002) > iwlwifi :3a:00.0: Unsupported splx structure > iwlwifi :3a:00.0: loaded firmware version 21.302800.0 op_mode > iwlmvm > iwlwifi :3a:00.0: Detected Intel(R) Dual Band Wireless AC 7265, > REV=0x210 > iwlwifi :3a:00.0: L1 Enabled - LTR Disabled > iwlwifi :3a:00.0: L1 Enabled - LTR Disabled > > > I just got this error on 4.7.0: > > [324188.495734] wlp58s0: associated > [324281.259579] iwlwifi :3a:00.0: Queue 16 stuck for 1 ms. This seems to be a recurring error with the AC-7265. :( We even added an entry about it in our wiki: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_platform_noise > > [324281.263732] iwlwifi :3a:00.0: Start IWL Error Log Dump: > > [324281.263739] iwlwifi :3a:00.0: Status: 0x, count: 6 > > [324281.263745] iwlwifi :3a:00.0: Loaded firmware version: 21.302800.0 > > [324281.263751] iwlwifi :3a:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN We have a bugzilla entry with the queue stuck + NMI trigger: https://bugzilla.kernel.org/show_bug.cgi?id=112931 Unfortunately nothing was found out by our firmware team regarding this yet. > Earlier on the same boot I got: > > [266562.042662] [ cut here ] > [266562.042693] WARNING: CPU: 2 PID: 994 at > drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1377 > iwl_mvm_rx_tx_cmd+0x665/0x870 [iwlmvm] We also have an open bugzilla entry with similar WARNING: https://bugzilla.kernel.org/show_bug.cgi?id=153381 So, first I'd recommend that you follow the recommended workarounds in our wiki. If that doesn't help and you still want to try to help us debug this, please open a bugzilla so we can track it more easily. Sorry for the trouble you're having... -- Cheers, Luca.
[PATCH] rt2x00: add support for mac addr from device tree
The EEPROM used on some CPEs has for every device the same generic
ralink mac in EEPROM and needs to be overridden.
Signed-off-by: Mathias Kresin
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 17 +
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 5 +
8 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 155f343..085c5b4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -1459,10 +1459,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index 2553cdd..9832fd5 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -1585,10 +1585,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 2d64611..cd3ab5a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -1349,10 +1349,7 @@ static int rt2500usb_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index bf3f0a3..59c49af 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -6919,10 +6919,7 @@ static int rt2800_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2800_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2800_eeprom_read(rt2x00dev, EEPROM_NIC_CONF0, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index f68d492..aa3d4cee 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1403,6 +1403,7 @@ static inline void rt2x00debug_dump_frame(struct
rt2x00_dev *rt2x00dev,
*/
u32 rt2x00lib_get_bssidx(struct rt2x00_dev *rt2x00dev,
struct ieee80211_vif *vif);
+void rt2x00lib_set_mac_address(struct rt2x00_dev *rt2x00dev, u8
*eeprom_mac_addr);
/*
* Interrupt context handlers.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 4e0c565..d659250 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#include "rt2x00.h"
#include "rt2x00lib.h"
@@ -931,6 +933,21 @@ static void rt2x00lib_rate(struct ieee80211_rate *entry,
entry->flags |= IEEE80211_RATE_SHORT_PREAMBLE;
}
+void rt2x00lib_set_mac_address(struct rt2x00_dev *rt2x00dev, u8
*eeprom_mac_addr)
+{
+ const char *mac_addr;
+
+ mac_addr = of_get_mac
Re: [PATCH] rt2x00: add support for mac addr from device tree
On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote:
> The EEPROM used on some CPEs has for every device the same generic
> ralink mac in EEPROM and needs to be overridden.
I don't know what is CPE, but even if I would know that, I most likely
sill will not understand that description.
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
> @@ -1459,10 +1459,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev
> *rt2x00dev)
>* Start validation of the data that has been read.
>*/
> mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
> - if (!is_valid_ether_addr(mac)) {
> - eth_random_addr(mac);
> - rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
> - }
> + rt2x00lib_set_mac_address(rt2x00dev, mac);
> +#include
> +#include
>
> #include "rt2x00.h"
> #include "rt2x00lib.h"
> @@ -931,6 +933,21 @@ static void rt2x00lib_rate(struct ieee80211_rate *entry,
> entry->flags |= IEEE80211_RATE_SHORT_PREAMBLE;
> }
>
> +void rt2x00lib_set_mac_address(struct rt2x00_dev *rt2x00dev, u8
> *eeprom_mac_addr)
> +{
> + const char *mac_addr;
> +
> + mac_addr = of_get_mac_address(rt2x00dev->dev->of_node);
Shouldn't use dev_of_node(&rt2x00dev->dev) and check against NULL ?
> + if (mac_addr)
> + ether_addr_copy(eeprom_mac_addr, mac_addr);
Why we do not read MAC from EEPROM if fail to get it from of_node?
Thanks
Stanislaw
Re: pull request: iwlwifi 2016-04-12
On Sun, 2016-08-07 at 07:38 +0300, Emmanuel Grumbach wrote: > On Sun, Aug 7, 2016 at 7:35 AM, Grumbach, Emmanuel > wrote: > > > > > > Hi Kalle, > > > > Here is a pull request for 4.6. I have here a patch that was merged > > to > > -next already, but clearly, it should have been routed through the > > current cycle's trees. Sorry about that. > > The patch is: > > > Wow.. I knew evolution was sometimes stupid, but this is new to me.. Which evolution are you blaming here? The email client or the evolution of species? :D -- Luca.
rtl8192ce
Hello, The RTL8192CE device seems to work fine without any firmware, so you may make it fully optional, removing dependency on FW_LOADER. Of course that require some patching, but if I understood the driver internals correctly, simple complete(&rtlpriv->firmware_loading_complete); would be enough when firmware loading machinery is unavailable, that is, when request_firmware_nowait returns -EINVAL (currently that may only happen in improperly configured or patched kernels, like Linux-libre; see attached messages for more information) Of course I will try to fix Linux-libre “deblobbing” technique, as it should never break anything that may work without a firmware. But anyway, if a device and its driver may work without a certain kernel feature, that feature should not be selected, I think. Lobachevskii Vitalii --- Begin Message --- The rtl8192ce driver as present in linux-libre don’t work for me at all. However, after I made it to ignore the EINVAL error from the reject_firmware_nowait function (in drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine. I could send you the patch, but don’t think that’s the right solution. Really, are there any reasons for reject_firmware_nowait to return -EINVAL? Original function, request_firmware_nowait, returns non-zero only in extreme conditions, like out-of-memory or module being unloaded. Unlike request_firmware, it doesn’t fail when firmware is absent. So shouldn’t the reject_firmware_nowait function behave as if the requested firmware merely absent? --- End Message --- --- Begin Message --- Hi, Thanks for your report! On Aug 13, 2016, number Zero wrote: > However, after I made it to ignore the EINVAL error from the > reject_firmware_nowait function (in > drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine. Interesting. Can you check that this remains true even after a full power cycle, as in, that it's not a blob loaded by a previous blobbed kernel that remains it to work in your setting? (if you never had the blob around, or never used a blobbed kernel, just say so, and I'll be happy enough about the conclusion ;-) > Really, are there any reasons for reject_firmware_nowait to return > -EINVAL? Yes. It the error code to indicate to the caller that the firmware loading functionality is not avaialble. It indicates the callback supplied by the caller will not be called, so the caller itself should take care of e.g. returning any temporary memory the callback would have released. If the driver works even if request_firmware_nowait returns such an error, then it ought to tolerate this return code. > So shouldn’t the reject_firmware_nowait function behave as if the > requested firmware merely absent? Given the multiple cases in which drivers were "surprised" by this return code, I guess we could try to rework reject_firmware_nowait so as to actually call the callback, signalling the unsuccessful completion of the request. Would you like to give that a try? Or perhaps you'd prefer to report the bug to the rtl8192ce maintainers, so that they could fix their driver so as to work (as it should) even when the firmware loading configuration option is disabled? Thanks, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer --- End Message ---
Re: [PATCH] rt2x00: add support for mac addr from device tree
2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka :
>
> On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote:
> > The EEPROM used on some CPEs has for every device the same generic
> > ralink mac in EEPROM and needs to be overridden.
>
> I don't know what is CPE, but even if I would know that, I most likely
> sill will not understand that description.
Well, seams to me the commit message can be improved. If a v2 is
required or a v2 is required because of the commit message, I'll take
care of it.
CPE = Customer Premises Equipment or the small plastic box from your
ISP at home. The whole point of the patch is that the MAC stored in
the wifi EEPROM might not be unique and need to be overridden. I'm
aware of three different "home router", where each model has the same
generic ralink MAC address stored in the wifi EEPROM. This can cause
nasty issues.
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
> > @@ -1459,10 +1459,7 @@ static int rt2400pci_validate_eeprom(struct
> > rt2x00_dev *rt2x00dev)
> >* Start validation of the data that has been read.
> >*/
> > mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
> > - if (!is_valid_ether_addr(mac)) {
> > - eth_random_addr(mac);
> > - rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
> > - }
> > + rt2x00lib_set_mac_address(rt2x00dev, mac);
>
> > +#include
> > +#include
> >
> > #include "rt2x00.h"
> > #include "rt2x00lib.h"
> > @@ -931,6 +933,21 @@ static void rt2x00lib_rate(struct ieee80211_rate
> > *entry,
> > entry->flags |= IEEE80211_RATE_SHORT_PREAMBLE;
> > }
> >
> > +void rt2x00lib_set_mac_address(struct rt2x00_dev *rt2x00dev, u8
> > *eeprom_mac_addr)
> > +{
> > + const char *mac_addr;
> > +
> > + mac_addr = of_get_mac_address(rt2x00dev->dev->of_node);
>
> Shouldn't use dev_of_node(&rt2x00dev->dev) and check against NULL ?
Not sure if dev_of_node() is meant to be used by every driver. Or at
least the function is only used by base stuff and not by any driver.
The NULL check doesn't seam to me required. The of_node is finally
passed to __of_find_property which does the NULL check before using
of_node.
Mathias
Re: brcmfmac43430-sdio.bin in linux-firmware
Hi Arend, On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel wrote: >> Is this something you could help? > > I could, but this is handled by Cypress now. I have asked for firmware > release tag so I can release it. Excellent, thanks for your help!
Re: rtl8192ce
Lobachevskii Vitalii writes: > Hello, > > The RTL8192CE device seems to work fine without any firmware, so you may > make it fully optional, removing dependency on FW_LOADER. Of course that > require some patching, but if I understood the driver internals > correctly, simple complete(&rtlpriv->firmware_loading_complete); would > be enough when firmware loading machinery is unavailable, that is, when > request_firmware_nowait returns -EINVAL (currently that may only happen > in improperly configured or patched kernels, like Linux-libre; see > attached messages for more information) > > Of course I will try to fix Linux-libre “deblobbing” technique, as it > should never break anything that may work without a firmware. But > anyway, if a device and its driver may work without a certain kernel > feature, that feature should not be selected, I think. The realtek devices all require firmwere to operate correctly, including the 8192c series. There are a bunch of commands flying back and forth between the driver and the firmware. If your device happens to work without loading the firmware then you have an old firmware blob loaded. At least this is the case for the USB version of the device, and I find it highly unlikely the PCIe version is any different. Trying to remove the firmware loading error is just plain silly. Jes
Re: [PATCH] rt2x00: add support for mac addr from device tree
On Thu, Aug 25, 2016 at 01:12:22PM +0200, Mathias Kresin wrote: > 2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka : > > > > On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote: > > > The EEPROM used on some CPEs has for every device the same generic > > > ralink mac in EEPROM and needs to be overridden. > > > > I don't know what is CPE, but even if I would know that, I most likely > > sill will not understand that description. > > Well, seams to me the commit message can be improved. If a v2 is > required or a v2 is required because of the commit message, I'll take > care of it. Please do. > CPE = Customer Premises Equipment or the small plastic box from your > ISP at home. The whole point of the patch is that the MAC stored in > the wifi EEPROM might not be unique and need to be overridden. I'm > aware of three different "home router", where each model has the same > generic ralink MAC address stored in the wifi EEPROM. This can cause > nasty issues. I think we still want MAC from EEPROM instead of random one on systems without OF. Otherwise we could just use random MAC every time, but this does not seems lika a good idea. Can we check against that particular MAC that repeats on those CPEs and if it match use random one ? Or use some other identification to find out that EEPROM MAC is not good ? > > Shouldn't use dev_of_node(&rt2x00dev->dev) and check against NULL ? > > Not sure if dev_of_node() is meant to be used by every driver. Or at > least the function is only used by base stuff and not by any driver. > > The NULL check doesn't seam to me required. The of_node is finally > passed to __of_find_property which does the NULL check before using > of_node. Ok. Thanks Stanislaw
Re: rtl8192ce
On 08/25/2016 08:17 AM, Jes Sorensen wrote: Lobachevskii Vitalii writes: Hello, The RTL8192CE device seems to work fine without any firmware, so you may make it fully optional, removing dependency on FW_LOADER. Of course that require some patching, but if I understood the driver internals correctly, simple complete(&rtlpriv->firmware_loading_complete); would be enough when firmware loading machinery is unavailable, that is, when request_firmware_nowait returns -EINVAL (currently that may only happen in improperly configured or patched kernels, like Linux-libre; see attached messages for more information) Of course I will try to fix Linux-libre “deblobbing” technique, as it should never break anything that may work without a firmware. But anyway, if a device and its driver may work without a certain kernel feature, that feature should not be selected, I think. The realtek devices all require firmwere to operate correctly, including the 8192c series. There are a bunch of commands flying back and forth between the driver and the firmware. If your device happens to work without loading the firmware then you have an old firmware blob loaded. At least this is the case for the USB version of the device, and I find it highly unlikely the PCIe version is any different. Trying to remove the firmware loading error is just plain silly. I have not bothered my Realtek contacts with such a question, but I have a plausible explanation. If an RTL8192CE functions without loading external firmware, it is because the device has minimal function built in the default firmware. Mostly this rudimentary firmware is used to boot the device and to download the firmware for complex wireless communication. Rudimentary wifi functions would be needed for wake-on-lan operations. The fact that Realtek has never implemented WOL for the 8192C chips is highly suggestive that they do not function very well in that capacity. If the RTL8192CE actually runs without loading external firmware, then I am quite sure that it will be restricted to 802.11g at the most, and more likely 802.11b. If it handles any 802.11n capabilities, then that firmware will certainly not have any of the bug fixes applied to the firmware since the earliest release. You are certainly allowed to configure your system any way you want, but please do not send any such "fixes" to the kernel sources. They will NEVER be accepted! Configuring a kernel without firmware loading capacity is indeed silly. Larry
Re: [PATCH] rt2x00: add support for mac addr from device tree
2016-08-25 15:19 GMT+02:00 Stanislaw Gruszka : > On Thu, Aug 25, 2016 at 01:12:22PM +0200, Mathias Kresin wrote: >> 2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka : >> > On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote: >> CPE = Customer Premises Equipment or the small plastic box from your >> ISP at home. The whole point of the patch is that the MAC stored in >> the wifi EEPROM might not be unique and need to be overridden. I'm >> aware of three different "home router", where each model has the same >> generic ralink MAC address stored in the wifi EEPROM. This can cause >> nasty issues. > > I think we still want MAC from EEPROM instead of random one on systems > without OF. Otherwise we could just use random MAC every time, but this > does not seems lika a good idea. Either I got you wrong, the code does something different than I intended/tested or you misread the code. The mac address stored in the EEPROM is only overridden in case: a) a mac address is defined in the device tree. b) invalid/no mac stored in EEPROM => random one If none of the above is true, the EEPROM mac will be used. What I've added is a). Everything else is the same as before. > Can we check against that particular MAC that repeats on those CPEs and > if it match use random one ? Or use some other identification to find > out that EEPROM MAC is not good ? IMHO this would be a wonky approach. I had a look at the EEPROM MACs from two of the affected devices and spotted just now a coherence with the used wifi chip: VGV7510KW22 (RT3062F): 00:0C:43:30:62:00 ARV7506 (RT3060F): 00:0C:43:30:60:00 IMHO, it would be reckless to assume that it's the same for other affected models. You know, ODMs doing silly things. Personally I prefer to deal with the issue in device tree rather than forcing a random MAC address. This way I can set the MAC used with the stock firmware to fix the issue. Mathias
[PATCH 3/3] mwifiex: do not print dot when downloading FW
Printing about 3000 lines like this [ 20.691850] mwifiex_pcie :02:00.0: . [ 20.693466] mwifiex_pcie :02:00.0: . is not useful. If FW downloading will be interrupted, we will get proper error message about that. Signed-off-by: Stanislaw Gruszka --- drivers/net/wireless/marvell/mwifiex/pcie.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c index 2f555b0..50a6a53 100644 --- a/drivers/net/wireless/marvell/mwifiex/pcie.c +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c @@ -1956,8 +1956,6 @@ static int mwifiex_prog_fw_w_helper(struct mwifiex_adapter *adapter, if (firmware_len - offset < txlen) txlen = firmware_len - offset; - mwifiex_dbg(adapter, INFO, "."); - tx_blocks = (txlen + card->pcie.blksz_fw_dl - 1) / card->pcie.blksz_fw_dl; -- 1.8.3.1
Re: rtl8192ce
Larry Finger writes: > On 08/25/2016 08:17 AM, Jes Sorensen wrote: >> Lobachevskii Vitalii writes: >> The realtek devices all require firmwere to operate correctly, >> including the 8192c series. There are a bunch of commands flying back >> and forth between the driver and the firmware. >> >> If your device happens to work without loading the firmware then you >> have an old firmware blob loaded. >> >> At least this is the case for the USB version of the device, and I find >> it highly unlikely the PCIe version is any different. >> >> Trying to remove the firmware loading error is just plain silly. > > I have not bothered my Realtek contacts with such a question, but I > have a plausible explanation. If an RTL8192CE functions without > loading external firmware, it is because the device has minimal > function built in the default firmware. Mostly this rudimentary > firmware is used to boot the device and to download the firmware for > complex wireless communication. Rudimentary wifi functions would be > needed for wake-on-lan operations. The fact that Realtek has never > implemented WOL for the 8192C chips is highly suggestive that they do > not function very well in that capacity. > > If the RTL8192CE actually runs without loading external firmware, then > I am quite sure that it will be restricted to 802.11g at the most, and > more likely 802.11b. If it handles any 802.11n capabilities, then that > firmware will certainly not have any of the bug fixes applied to the > firmware since the earliest release. > > You are certainly allowed to configure your system any way you want, > but please do not send any such "fixes" to the kernel sources. They > will NEVER be accepted! > > Configuring a kernel without firmware loading capacity is indeed silly. Makes perfect sense, but as you also correctly point out, it means the device actually is running some firmware, but we have no idea what state or version it is. Trying to run a device with this level of firmware is both risky and makes it hard to rely on correct operation. Of course it also makes this whole ostrich process even more pointless, since the device is in fact running firmware - pretending it isn't is just silly. One more thing, yes you can apply this patch to your own degraded kernel, but if you ship it, kindle remove ALL email addresses of any driver authors in it. None of us wants to waste our time on bug reports because of this. If you truly want to run your system without firmware, I hear there are great bargains for NE2000 and 3c501 cards on ebay :) Jes
Re: [PATCH] rt2x00: add support for mac addr from device tree
On Thu, Aug 25, 2016 at 05:03:06PM +0200, Mathias Kresin wrote: > 2016-08-25 15:19 GMT+02:00 Stanislaw Gruszka : > > On Thu, Aug 25, 2016 at 01:12:22PM +0200, Mathias Kresin wrote: > >> 2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka : > >> > On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote: > > >> CPE = Customer Premises Equipment or the small plastic box from your > >> ISP at home. The whole point of the patch is that the MAC stored in > >> the wifi EEPROM might not be unique and need to be overridden. I'm > >> aware of three different "home router", where each model has the same > >> generic ralink MAC address stored in the wifi EEPROM. This can cause > >> nasty issues. > > > > I think we still want MAC from EEPROM instead of random one on systems > > without OF. Otherwise we could just use random MAC every time, but this > > does not seems lika a good idea. > > Either I got you wrong, the code does something different than I > intended/tested or you misread the code. I misread the patch. It's ok (except the changelog). Thanks Stanislaw
[PATCH 2/3] mwifiex: print status of FW ready event
For debugging purpose print content of reg->fw_status register and other
variables values when waiting for firmware ready event.
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 8abbbfe..2f555b0 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2043,6 +2043,10 @@ mwifiex_check_fw_status(struct mwifiex_adapter *adapter,
u32 poll_num)
ret = -1;
else
ret = 0;
+
+ mwifiex_dbg(adapter, INFO, "Try %d if FW is ready <%d,%#x>",
+ tries, ret, firmware_stat);
+
if (ret)
continue;
if (firmware_stat == FIRMWARE_READY_PCIE) {
--
1.8.3.1
[PATCH 1/3] mwifiex: make "PCI-E is not the winner" print more informative
Printing ret and adapter->winner do not provide any useful information
as those are always 0 at point where the massage is printed. Print value
read from reg->fw_status register instead.
Stanislaw Gruszka
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 453ab6a..8abbbfe 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2074,8 +2074,7 @@ mwifiex_check_winner_status(struct mwifiex_adapter
*adapter)
adapter->winner = 1;
} else {
mwifiex_dbg(adapter, ERROR,
- "PCI-E is not the winner <%#x,%d>, exit dnld\n",
- ret, adapter->winner);
+ "PCI-E is not the winner <%#x>", winner);
}
return ret;
--
1.8.3.1
[PATCH 0/3] mwifiex: FW downloading debug printing improvements
3 small patches that make FW downloading prints more informative Stanislaw Gruszka (3): mwifiex: make "PCI-E is not the winner" print more informative mwifiex: print status of FW ready event mwifiex: do not print dot when downloading FW drivers/net/wireless/marvell/mwifiex/pcie.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- 1.8.3.1
Re: [PATCH] wlcore: mesh: add zone time sync support
On Sun, 2016-08-21 at 10:13 +, Mishol, Guy wrote: > Kalle/Thomas, > Thanks for your feedback. > > This time sync support is different from the one that mac80211 maintains with > mesh peers. > This time sync is mostly used by upper layers for several applications (like > audio). > In this case we allow the user to configure for each zone who will be the > synchronizer. > You can refer to the following Application Report (chapter 6) for more > information: http://www.ti.com/lit/an/swaa166/swaa166.pdf So it breaks regular mesh synchronization? Power Save, and in the future possibly DFS and MCCA rely on this to work. It sounds like you want some absolute TSF time synchronized within 20us. Mesh TSF synchronization can provide this, it's just a little more complicated as you'll need to compute at the application level using the per-sta offsets. Mesh synchronization accuracy was pretty good IIRC, unfortunately I don't have any test data to share :( thomas
[PATCH] nl80211: initialize state.filter_wiphy in nl80211_dump_interface()
In nl80211_dump_interface() the filter_wiphy variable was set to -1.
However, that does not help as message may not contain wiphy or wdev
attribute. Instead initialize state.filter_wiphy as is done in
nl80211_dump_wiphy().
Fixes: 2d75da13fbb9 ("nl80211: Allow GET_INTERFACE dumps to be filtered")
Signed-off-by: Arend van Spriel
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 95d55d2..681c689 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2525,7 +2525,7 @@ static int nl80211_dump_interface(struct sk_buff *skb,
struct netlink_callback *
int if_idx = 0;
int wp_start = cb->args[0];
int if_start = cb->args[1];
- int filter_wiphy = -1;
+ int filter_wiphy;
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
@@ -2534,6 +2534,7 @@ static int nl80211_dump_interface(struct sk_buff *skb,
struct netlink_callback *
struct nl80211_dump_wiphy_state state = {};
int ret;
+ state.filter_wiphy = -1;
ret = nl80211_dump_wiphy_parse(skb, cb, &state);
if (ret)
return ret;
--
1.9.1
Re: [PATCH 4/4] ath10k: fix spurious tx/rx during boot
On 08/24/2016 11:18 PM, Michal Kazior wrote: I was looking at firmware to make sure that I fixed what I could there From what I can tell, 10.4 should not have this bug. Did you see this only on 10.1/10.2 firmware? It is of course possible that I am mis-understanding 10.4 I did see it on 10.1 and 10.2. Don't recall seeing it on 10.4 though. If you didn't see warnings on 10.4 even after adding msleep() as per commit log then I guess it doesn't suffer from the bug. I can still occasionally see that message with a 15000 ms sleep. Based on debugging, it seems my firmware is now setting the mac-mask properly. But, as you mention, the rxfilter is enabled very early. So, probably it is still possible to see packets early if they are multicast, bcast, etc. I don't think it is worth re-working the entire rx-filter calc in the concurrency logic properly for 10.1 firmware, so I'm going to figure my fix is good enough as is as long as it sets the mac-mask properly. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
[PATCH] nl80211: Fix unfiltered GET_INTERFACE dumps
dump_wiphy_parse only assigns filter_wiphy if one of the supported
NL80211 attributes is present. So for unfiltered dumps, filter_wiphy
was always initialized to 0, and only interface 0 was dumped.
This was introduced in commit 2d75da13fbb957e955d212555b91101cef36f0ce.
Reported-by: Arend Van Spriel
Signed-off-by: Denis Kenzior
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 95d55d2..ddc994a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2534,6 +2534,7 @@ static int nl80211_dump_interface(struct sk_buff *skb,
struct netlink_callback *
struct nl80211_dump_wiphy_state state = {};
int ret;
+ state.filter_wiphy = -1;
ret = nl80211_dump_wiphy_parse(skb, cb, &state);
if (ret)
return ret;
--
2.7.3
Re: [PATCH] nl80211: Fix unfiltered GET_INTERFACE dumps
Hi Arend,
On 08/25/2016 04:35 PM, Arend van Spriel wrote:
On 25-08-16 22:44, Denis Kenzior wrote:
dump_wiphy_parse only assigns filter_wiphy if one of the supported
NL80211 attributes is present. So for unfiltered dumps, filter_wiphy
was always initialized to 0, and only interface 0 was dumped.
This was introduced in commit 2d75da13fbb957e955d212555b91101cef36f0ce.
Reported-by: Arend Van Spriel
Actually sent a patch for this issue a little earlier. I should have
Cc'ed you explicitly, I guess.
Whoops. I saw your regression report and didn't look to see if you
fixed it :)
Looking at your patch, I'm worried that
- int filter_wiphy = -1;
+ int filter_wiphy;
might still break things, since Johannes used:
if (!cb->args[2]) {
...
} else if (cb->args[2] > 0) {
filter_wiphy = cb->args[2] - 1;
}
So for unfiltered dumps, filter_wiphy would not be initialized properly
for the second & onward call of nl80211_dump_interface. Right?
Regards,
-Denis
Re: [PATCH] nl80211: Fix unfiltered GET_INTERFACE dumps
On 25-08-16 23:52, Denis Kenzior wrote:
> Hi Arend,
>
> On 08/25/2016 04:35 PM, Arend van Spriel wrote:
>> On 25-08-16 22:44, Denis Kenzior wrote:
>>> dump_wiphy_parse only assigns filter_wiphy if one of the supported
>>> NL80211 attributes is present. So for unfiltered dumps, filter_wiphy
>>> was always initialized to 0, and only interface 0 was dumped.
>>>
>>> This was introduced in commit 2d75da13fbb957e955d212555b91101cef36f0ce.
>>>
>>> Reported-by: Arend Van Spriel
>>
>> Actually sent a patch for this issue a little earlier. I should have
>> Cc'ed you explicitly, I guess.
>>
>
> Whoops. I saw your regression report and didn't look to see if you
> fixed it :)
I wanted to avoid having to revert so I decided to take a closer look.
> Looking at your patch, I'm worried that
>
> -int filter_wiphy = -1;
> +int filter_wiphy;
>
> might still break things, since Johannes used:
>
> if (!cb->args[2]) {
> ...
Maybe my look was not close enough. In this branch cb->args[2] is set to
-1. So indeed that would make filter_wiphy uninitialized in subsequent
call(s). Thanks for catching that.
Regards,
Arend
> } else if (cb->args[2] > 0) {
> filter_wiphy = cb->args[2] - 1;
> }
>
> So for unfiltered dumps, filter_wiphy would not be initialized properly
> for the second & onward call of nl80211_dump_interface. Right?
>
> Regards,
> -Denis
Re: [PATCH] nl80211: Fix unfiltered GET_INTERFACE dumps
On 25-08-16 22:44, Denis Kenzior wrote:
> dump_wiphy_parse only assigns filter_wiphy if one of the supported
> NL80211 attributes is present. So for unfiltered dumps, filter_wiphy
> was always initialized to 0, and only interface 0 was dumped.
>
> This was introduced in commit 2d75da13fbb957e955d212555b91101cef36f0ce.
>
> Reported-by: Arend Van Spriel
Actually sent a patch for this issue a little earlier. I should have
Cc'ed you explicitly, I guess.
Regards,
Arend
> Signed-off-by: Denis Kenzior
> ---
> net/wireless/nl80211.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 95d55d2..ddc994a 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -2534,6 +2534,7 @@ static int nl80211_dump_interface(struct sk_buff *skb,
> struct netlink_callback *
> struct nl80211_dump_wiphy_state state = {};
> int ret;
>
> + state.filter_wiphy = -1;
> ret = nl80211_dump_wiphy_parse(skb, cb, &state);
> if (ret)
> return ret;
>
