[PATCH] staging: wilc1000: fix undefined reference to `__this_module' compilation error
wilc_debug.o object file is included for both SDIO and SPI module. When
anyone(either SDIO or SPI) module is compiled as loaded module and another
as buildin module then below compilation error occurs.
"drivers/staging/wilc1000/wilc_debugfs.o:(.data+0x10): undefined
reference to `__this_module'"
Moved the declaration of file_operation variable in SDIO/SPI files and
pass this as parameter to wilc_debugfs_init().
Refactor wilc_debugfs_init() as its not required to maintain
'wilc_debugfs_info_t' in debugfs_info[] array. Also modified file
permission from 0666 to 0600 & use 'data' field as 'NULL' in
debugfs_create_file() call.
Fixes: 9abc44ba4e2f("staging: wilc1000: fix TODO to compile spi and sdio
components in single module")
Reported-by: kbuild test robot
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/linux_wlan.c | 1 -
drivers/staging/wilc1000/wilc_debugfs.c | 50 +++--
drivers/staging/wilc1000/wilc_sdio.c| 7 +
drivers/staging/wilc1000/wilc_spi.c | 7 +
drivers/staging/wilc1000/wilc_wlan_if.h | 7 -
5 files changed, 30 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 01cf4bd..37885ad 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1062,7 +1062,6 @@ int wilc_netdev_init(struct wilc **wilc, struct device
*dev, int io_type,
if (!wl)
return -ENOMEM;
- wilc_debugfs_init();
*wilc = wl;
wl->io_type = io_type;
wl->hif_func = ops;
diff --git a/drivers/staging/wilc1000/wilc_debugfs.c
b/drivers/staging/wilc1000/wilc_debugfs.c
index edc7287..cb02859 100644
--- a/drivers/staging/wilc1000/wilc_debugfs.c
+++ b/drivers/staging/wilc1000/wilc_debugfs.c
@@ -20,8 +20,8 @@ static struct dentry *wilc_dir;
#define DBG_LEVEL_ALL (DEBUG | INFO | WRN | ERR)
static atomic_t WILC_DEBUG_LEVEL = ATOMIC_INIT(ERR);
-static ssize_t wilc_debug_level_read(struct file *file, char __user *userbuf,
-size_t count, loff_t *ppos)
+ssize_t wilc_debug_level_read(struct file *file, char __user *userbuf,
+ size_t count, loff_t *ppos)
{
char buf[128];
int res = 0;
@@ -36,9 +36,8 @@ static ssize_t wilc_debug_level_read(struct file *file, char
__user *userbuf,
return simple_read_from_buffer(userbuf, count, ppos, buf, res);
}
-static ssize_t wilc_debug_level_write(struct file *filp,
- const char __user *buf, size_t count,
- loff_t *ppos)
+ssize_t wilc_debug_level_write(struct file *filp, const char __user *buf,
+ size_t count, loff_t *ppos)
{
int flag = 0;
int ret;
@@ -63,44 +62,15 @@ static ssize_t wilc_debug_level_write(struct file *filp,
return count;
}
-#define FOPS(_open, _read, _write, _poll) { \
- .owner = THIS_MODULE, \
- .open = (_open), \
- .read = (_read), \
- .write = (_write), \
- .poll = (_poll), \
-}
-
-struct wilc_debugfs_info_t {
- const char *name;
- int perm;
- unsigned int data;
- const struct file_operations fops;
-};
-
-static struct wilc_debugfs_info_t debugfs_info[] = {
- {
- "wilc_debug_level",
- 0666,
- (DEBUG | ERR),
- FOPS(NULL, wilc_debug_level_read, wilc_debug_level_write, NULL),
- },
-};
-
-int wilc_debugfs_init(void)
+int wilc_debugfs_init(const struct file_operations *fops)
{
- int i;
- struct wilc_debugfs_info_t *info;
-
wilc_dir = debugfs_create_dir("wilc_wifi", NULL);
- for (i = 0; i < ARRAY_SIZE(debugfs_info); i++) {
- info = &debugfs_info[i];
- debugfs_create_file(info->name,
- info->perm,
- wilc_dir,
- &info->data,
- &info->fops);
+ if (IS_ERR_OR_NULL(wilc_dir)) {
+ pr_err("Error creating debugfs\n");
+ return -EFAULT;
}
+ debugfs_create_file("wilc_debug_level", 0600, wilc_dir, NULL, fops);
+
return 0;
}
diff --git a/drivers/staging/wilc1000/wilc_sdio.c
b/drivers/staging/wilc1000/wilc_sdio.c
index b2080d8..c1573f5 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -103,6 +103,12 @@ static int wilc_sdio_cmd53(struct wilc *wilc, struct
sdio_cmd53 *cmd)
return ret;
}
+static const struct file_operations sdio_debug_fops = {
+ .owner = THIS_MODULE,
+ .read = wilc_debug_level_read,
+ .write = wilc_debug_level_write,
+};
+
static int linux_sdio_probe(struct sdio_func *func,
const struct sdio_de
Re: wireless dongle causing entire machine to hang
On 8 August 2018 at 21:14, Arend van Spriel wrote: > On 8/8/2018 7:58 PM, Randy Oostdyk wrote: >> >> Good day all, > > > Hi Randy > >> I'm writing to report an issue with the linux kernel, and I'm hoping >> this is the right place to report it. (short aside: I tried to ask in >> the #linux-wireless IRC channel, but wasn't permitted to speak!) > > > uhm. why? There was (and still is) a lot of link spamming recently on freenode in #linux-wireless (and several other open [source] channels) from unregistered clients; to prevent further disruptions unregistered clients were prevented from writing to the channel for now. Quite likely this was/is Randys issue. Registering helps, not sure how easy it is to give individual unregistered users the right to talk. Regards Jonas
Re: wireless dongle causing entire machine to hang
On 8/8/2018 7:58 PM, Randy Oostdyk wrote: Good day all, Hi Randy I'm writing to report an issue with the linux kernel, and I'm hoping this is the right place to report it. (short aside: I tried to ask in the #linux-wireless IRC channel, but wasn't permitted to speak!) uhm. why? I'm aware that this is a USB protocol issue, and so this may be the wrong place to report the bug, but the warning seems to be generated by the wireless driver, and that appears to be the key issue here. My USB wifi dongle is on the end of a very long USB cable, and was connected to a USB hub. On two different occasions (after hours or days of use), the machine it was attached to (Raspberry Pi 3) stopped responding. I was unable to SSH in, even over ethernet. After a hard reboot, I found that the following error was repeated **many thousands of times per second** in three different log files: I assume that USB is powered, right? Now probably asking the obvious, but you did not write it down so here it is: did you try with a very short USB cable? I guess you read this already [1] Rpi kernel: [857011.857581] ieee80211 phy1: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 So this -EPROTO. The usb host controller of the RPi3 can be found here: https://github.com/raspberrypi/linux/tree/rpi-4.18.y/drivers/usb/host/dwc_otg Not sure it that tells us anything though. Regards, Arend [1] https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md
Re: wireless dongle causing entire machine to hang
On 08/08/2018 12:58 PM, Randy Oostdyk wrote: Good day all, I'm writing to report an issue with the linux kernel, and I'm hoping this is the right place to report it. (short aside: I tried to ask in the #linux-wireless IRC channel, but wasn't permitted to speak!) I'm aware that this is a USB protocol issue, and so this may be the wrong place to report the bug, but the warning seems to be generated by the wireless driver, and that appears to be the key issue here. My USB wifi dongle is on the end of a very long USB cable, and was connected to a USB hub. On two different occasions (after hours or days of use), the machine it was attached to (Raspberry Pi 3) stopped responding. I was unable to SSH in, even over ethernet. After a hard reboot, I found that the following error was repeated **many thousands of times per second** in three different log files: Rpi kernel: [857011.857581] ieee80211 phy1: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 As the machine continued in that state for hours, those log files had grown to several gigabytes in size each! (/var/log/syslog, /var/log/kern.log, and /var/log/messages) It appears to be a very similar (if not same) bug referenced here: https://www.spinics.net/lists/linux-wireless/msg150555.html He resolved the "soft lockup" issue with some changes to the driver (diff included in that thread), so I'm hoping this is the right place to bring this issue up. Output of uname -a: Linux RCBLpi 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux My browsing shows that error 71 (EPROTO) is some kind of protocol error. Was the one you noted the first, or had others been logged? If that was the first, that infrequent an error will be hard to find. I suspect some subtle USB timing issue. Is that very long cable within specs of 5 meters for USB2 or 3 for USB3? Was the hub powered? If your setup permits, you might try with a shorter cable. Larry
wireless dongle causing entire machine to hang
Good day all, I'm writing to report an issue with the linux kernel, and I'm hoping this is the right place to report it. (short aside: I tried to ask in the #linux-wireless IRC channel, but wasn't permitted to speak!) I'm aware that this is a USB protocol issue, and so this may be the wrong place to report the bug, but the warning seems to be generated by the wireless driver, and that appears to be the key issue here. My USB wifi dongle is on the end of a very long USB cable, and was connected to a USB hub. On two different occasions (after hours or days of use), the machine it was attached to (Raspberry Pi 3) stopped responding. I was unable to SSH in, even over ethernet. After a hard reboot, I found that the following error was repeated **many thousands of times per second** in three different log files: Rpi kernel: [857011.857581] ieee80211 phy1: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 As the machine continued in that state for hours, those log files had grown to several gigabytes in size each! (/var/log/syslog, /var/log/kern.log, and /var/log/messages) It appears to be a very similar (if not same) bug referenced here: https://www.spinics.net/lists/linux-wireless/msg150555.html He resolved the "soft lockup" issue with some changes to the driver (diff included in that thread), so I'm hoping this is the right place to bring this issue up. Output of uname -a: Linux RCBLpi 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux If any further details are needed, feel free to email me directly, as I haven't subscribed to this list.
Re: [PATCH] iw: scan: fix crash when driver doesn't report frame type
> If driver does not know what kind of frame has been received from BSS, > then it is possible to specify CFG80211_BSS_FTYPE_UNKNOWN > in cfg80211_inform_bss[_width]. > > In this case neither NL80211_BSS_BEACON_IES nor NL80211_BSS_PRESP_DATA > will be reported to userspace. The fix is for iw tool, so the patch title is a bit confusing. It should have been something like this: [PATCH] iw: scan: fix crash when driver doesn't report frame type Regards, Sergey
