iwlwifi is not working after doing the reboot by pressing RESET button
Hi Team, I am using intel 8265 NGW wifi card in intel leafhill board. We have enabled the Intel -wifi card in the Leaf_hill platform. After powering on the device, the wifi module is working fine but it doesn't work when we do the reboot by pressing RESET button. We have debug the issue and found that when we do the hard reboot by pressing the RESET key, the wifi module doesn't detected. We have given the lspci command before and after the hard reboot and the module is not listing in the lspci after hard reboot so we are suspecting that wifi module is not in the proper state due to the hard reboot. Could you please help to know what might be the issue. Thanks, Ramesh
[PATCH V2] brcmfmac: specify some features per firmware version
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Most firmwares support monitor interface but only the latest ones
/announce/ it with a "monitor" flag in the "cap" iovar. There isn't any
reliable detection method for older firmwares (BRCMF_C_MONITOR was tried
but "it only indicates the core part of the stack supports").
Similarly support for tagging monitor frames and building radiotap
headers can't be reliably detected for all firmwares.
This commit adds table that allows mapping features to firmware version.
It adds mappings for 43602a1 and 4366b1 firmwares from
linux-firmware.git. Both were confirmed to be passing monitor frames.
Signed-off-by: Rafał Miłecki
Reviewed-by: Arend van Spriel
---
V2: Added "commit" word when specifying SHAs. Thanks Arend!
---
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
index 4db4d07a..8347da632a5b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
@@ -93,6 +93,42 @@ static int brcmf_feat_debugfs_read(struct seq_file *seq,
void *data)
}
#endif /* DEBUG */
+struct brcmf_feat_fwfeat {
+ const char * const fwid;
+ u32 feat_flags;
+};
+
+static const struct brcmf_feat_fwfeat brcmf_feat_fwfeat_map[] = {
+ /* brcmfmac43602-pcie.ap.bin from linux-firmware.git commit
ea1178515b88 */
+ { "01-6cb8e269", BIT(BRCMF_FEAT_MONITOR) },
+ /* brcmfmac4366b-pcie.bin from linux-firmware.git commit 52442afee990 */
+ { "01-c47a91a4", BIT(BRCMF_FEAT_MONITOR) },
+};
+
+static void brcmf_feat_firmware_overrides(struct brcmf_pub *drv)
+{
+ const struct brcmf_feat_fwfeat *e;
+ u32 feat_flags = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(brcmf_feat_fwfeat_map); i++) {
+ e = &brcmf_feat_fwfeat_map[i];
+ if (!strcmp(e->fwid, drv->fwver)) {
+ feat_flags = e->feat_flags;
+ break;
+ }
+ }
+
+ if (!feat_flags)
+ return;
+
+ for (i = 0; i < BRCMF_FEAT_LAST; i++)
+ if (feat_flags & BIT(i))
+ brcmf_dbg(INFO, "enabling firmware feature: %s\n",
+ brcmf_feat_names[i]);
+ drv->feat_flags |= feat_flags;
+}
+
/**
* brcmf_feat_iovar_int_get() - determine feature through iovar query.
*
@@ -253,6 +289,8 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
}
brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_FWSUP, "sup_wpa");
+ brcmf_feat_firmware_overrides(drvr);
+
/* set chip related quirks */
switch (drvr->bus_if->chip) {
case BRCM_CC_43236_CHIP_ID:
--
2.13.7
Re: [PATCH] staging: r8822be: Fix RTL8822be can't find any wireless AP
On Sun, 2018-07-08 at 11:30 -0500, Larry Finger wrote: > On 07/06/2018 12:44 AM, pks...@realtek.com wrote: > > From: Ping-Ke Shih > > > > RTL8822be can't bring up properly on ASUS X530UN, and dmesg says: > > [ 8.591333] r8822be: module is from the staging directory, the quality > > is unknown, you have been warned. > > [ 8.593122] r8822be :02:00.0: enabling device ( -> 0003) > > [ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin > > [ 9.289939] r8822be: rtlwifi: wireless switch is on > > [ 10.056426] r8822be :02:00.0 wlp2s0: renamed from wlan0 > > ... > > [ 11.952534] r8822be: halmac_init_hal failed > > [ 11.955933] r8822be: halmac_init_hal failed > > [ 11.956227] r8822be: halmac_init_hal failed > > [ 22.007942] r8822be: halmac_init_hal failed > > > > Jian-Hong reported it works if turn off ASPM with module parameter aspm=0. > > In order to fix this problem kindly, this commit don't turn off aspm but > > enlarge ASPM L1 latency to 7. > > > > Reported-by: Jian-Hong Pan > > Tested-by: Jian-Hong Pan > > Signed-off-by: Ping-Ke Shih > > This patch definitely needs a Cc for stable. Otherwise I ACK it. > Hi Larry, This patch had been applied by Greg, and CC'ed to stable. Thanks for your reminder. PK
RFkill for Bluetooth hard reset
Hi,
We need an option to reset Bluetooth using GPIO toggle for a Linux product when
BT connected over USB (HCI interface). i.e I need out of band(OOB) signal for
USB to control/reset the BT. hence I opt to add ACPI device in RfKill gpio
driver(rfkill-gpio.c).
localhost /sys/class/rfkill # ls -l
total 0
lrwxrwxrwx. 1 root root 0 Jul 8 14:53 rfkill0 ->
../../devices/platform/INTL6205:00/rfkill/rfkill0
lrwxrwxrwx. 1 root root 0 Jul 8 14:53 rfkill2 ->
../../devices/pci:00/:00:1c.0/:01:00.0/ieee80211/phy0/rfkill2
lrwxrwxrwx. 1 root root 0 Jul 8 15:35 rfkill3 ->
../../devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/bluetooth/hci0/rfkill3
I try to use RFkill soft block option to hold/reset (toggle) GPIO. And changes
in rfkill-gpio.c as follows.
1/ reset pin configured as GPIOD_OUT_LOW, hence HW controller is not out of
reset. I changed to high to work with our controller.
How to configured as Low/High as a generic solution?
2/ As per existing implementation, the Shutdown gpio is mandatory for the
framework to use. I feel we can make it an optional.
3/ Followed by /sys/class/rfkill/rfkill0/soft (1/0) is not in sync with
/sys/class/rfkill/rfkill0/uvent (RFKILL_STATE=0/1)
Please guide me to add an ACPI method to toggle the GPIO to reset the
bluetooth.
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index da6d1cf4c11c..5054694c5b3b 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -112,17 +112,17 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
rfkill->clk = devm_clk_get(&pdev->dev, NULL);
- gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
rfkill->reset_gpio = gpio;
- gpio = devm_gpiod_get_optional(&pdev->dev, "shutdown", GPIOD_OUT_LOW);
- if (IS_ERR(gpio))
- return PTR_ERR(gpio);
+ //gpio = devm_gpiod_get_optional(&pdev->dev, "shutdown", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
- rfkill->shutdown_gpio = gpio;
+ //rfkill->shutdown_gpio = gpio;
/* Make sure at-least one of the GPIO is defined and that
* a name is specified for this instance
@@ -170,6 +170,7 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
static const struct acpi_device_id rfkill_acpi_match[] = {
{ "BCM4752", RFKILL_TYPE_GPS },
{ "LNV4752", RFKILL_TYPE_GPS },
+ { "INTL6205", RFKILL_TYPE_BLUETOOTH },
{ },
Thx & rgds,
Sukumar
Re: [PATCH 00/27] mtd: rawnand: Improve compile-test coverage
Hi Boris, Boris Brezillon wrote on Thu, 5 Jul 2018 11:44:55 +0200: > Hello, > > This is an attempt at adding "depends || COMPILE_TEST" to all NAND > drivers that have no compile-time dependencies on arch > features/headers. > > This will hopefully help us (NAND/MTD maintainers) in detecting build > issues earlier. Unfortunately we still have a few drivers that can't > easily be modified to be arch independent. > > I tried to put all patches that only touch the NAND subsystem first, > so that they can be applied even if other patches are being discussed. > > Don't hesitate to point any missing dependencies when compiled with > COMPILE_TEST. I didn't have any problem when compiling, but that might > be because the dependencies were already selected. > > I have Question for Geert. I know you worked on HAS_DMA removal when > combined with COMPILE_TEST, do you plan to do something similar with > HAS_IOMEM? > > Regards, > > Boris > Thanks for the cleanup. Applied patches 1-4, 6-9, 12-16, 18 and 21 to nand/next. Waiting a v2 for patches 5 (s3c), 10-11 (orion), 17 (fsmc), and acks for the others 19-20, 22-27. Thanks, Miquèl
Re: [PATCH 17/27] mtd: rawnand: fsmc: Allow selection of this driver when COMPILE_TEST=y
On Thu, 5 Jul 2018 11:45:12 +0200 Boris Brezillon wrote: > It just makes NAND maintainers' life easier by allowing them to > compile-test this driver without having PLAT_SPEAR, ARCH_NOMADIK, > ARCH_U8500 or MACH_U300 enabled. > > We also need to add a dependency on HAS_IOMEM to make sure the driver > compiles correctly. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/raw/Kconfig | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index b89bd94a654c..245f1b56b94f 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -502,8 +502,9 @@ config MTD_NAND_JZ4780 > > config MTD_NAND_FSMC > tristate "Support for NAND on ST Micros FSMC" > - depends on OF > - depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300 > + depends on OF && HAS_IOMEM > + depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300 || \ > +COMPILE_TEST Looks like we have a conflict on the PC definition when compiling a MIPS kernel. I'll add a patch suffixing PC with FSMC_ to avoid that. Please don't apply this patch yet. > help > Enables support for NAND Flash chips on the ST Microelectronics > Flexible Static Memory Controller (FSMC)
Hello Beautiful
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships. I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you. Jack.
Re: [PATCH v2] mac80211: Fix wlan freezes under load at rekey
>>> I think easier would be to just disconnect ourselves? At least if we're >>> in managed mode... >>> >> >> I still have much to learn about 802.11, but so far I did not see way to >> directly disconnect a STA. (Maybe spoofing a "signal lost" event or >> something like that, but I fear complications by losing the sync with >> the remote STA.) Is there any call/signal you have in mind I could test? > > ieee80211_set_disassoc(), this can also send a frame out to indicate to > the AP that we're disconnecting instead. > I'll try that, but will probably take another week. My main main work station got severe file system corruption, forcing me to reinstall it from scratch. I suspect it was something in the wireless testing kernel 4.18-rc1 (944ae08d4e71) related to either btrfs or the ssd disk but since I needed the system just started over and avoid to run 4.18 if I do not have a full backup... >> hostapd or wpa_supplicant are "ordering" mac80211 to install a new key >> and are implementing the state machine and are in a good position to >> handle the fallout... at least theoretically. > > Ideally it would even know beforehand that we don't want to handle the > PTK rekeying, and then could reconnect instead of going through the > handshake. > Don't see how we could do that in the kernel, all the relevant information is handled in the state machine. I guess an API extension telling hostap/supplicant if we can handle rekeys or not would tbe he only way to avoid that. >> Instead I get a pop up asking for the PSK. Entering it reconnects >> normally. Cancel the prompt disconnect till a manual reconnect. >> I suspect NetworkManager is handling the rekey like the initial key >> install and then assumes the PSK is wrong. Hardly surprising but also >> highly visible to the users. > > That's pretty awkward. > >> But then only to those using the now broken rekey... > > Yeah, but you don't necessarily control that - i.e. client device and AP > might have different owners :-) > >> Using wpa_supplicant directly reconnects after ~15s. >> It also assumes the key is wrong and seems to rate limit the connection >> attempts. Here a log with wpa_supplicat running in the console and dmesg >> -wT output on top of that: > > So I think we're probably better off accepting the set_key but not > actually using it, and instead disconnecting... even if that's awkward > and should come with a big comment :-) Instead of returning an error I'll change the code to accept the rekey but do nothing with it. (Basically delete the new key and keep the old active). And of course calling ieee80211_set_disassoc() prior to return "success". Let's see how the supplicant will react on a disassoc while doing a rekey... Alexander pEpkey.asc Description: application/pgp-keys
