Open MrEngman opened 6 years ago
Finially managed to get the driver working with Raspbian kernel 4.14 on a Raspberry Pi.
Using code from port-to-4.13 I deleted the references to the vfs_read and vfs_write symbols using the patch
diff -Naurwb '--exclude=.git' genodeftest-Netgear-A6210/os/linux/rt_linux.c genodeftest-Netgear-A6210-4.14/os/linux/rt_linux.c
--- genodeftest-Netgear-A6210/os/linux/rt_linux.c 2017-12-01 01:32:22.730833865 +0000
+++ genodeftest-Netgear-A6210-4.14/os/linux/rt_linux.c 2017-12-01 01:33:59.010431737 +0000
@@ -701,7 +701,7 @@
mm_segment_t fs = get_fs();
set_fs(get_ds());
- ret = vfs_read(osfd, pDataPtr, readLen, &osfd->f_pos);
+ ret = 0;
set_fs(fs);
return ret;
}
@@ -713,7 +713,7 @@
mm_segment_t oldfs = get_fs();
set_fs(get_ds());
- ret = vfs_write(osfd, pDataPtr, writeLen, &osfd->f_pos);
+ ret = 0;
set_fs(oldfs);
return ret;
}
The driver now compiles without the warning about vfs_read and vfs_write and I have the driver running with an Asus USB-N53_B1 on a Raspberry Pi 2B running Raspbian Stretch kernel 4.14.2
I've no idea what effect the patch may have in the long term but I've had the driver running for several hours without problems so far.
A few related kernel commits: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb031849d52e61d24ba54e9d27553189ff328174 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9725d4cef62229b4ec4c912e0db0761e7d400650 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd8df82be66698042d11e7919e244c8d72b042ca
According to the first one, we should use iov_iter()
instead. According to some websites it has been considered bad practice to use the vfs_write()
and vfs_read()
functions anyway.
This should only be happening if debugging with "DBG" defined. Are you doing so willingly?
/home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../common/rtmp_init.c: In function ‘RTMPAllocAdapterBlock’:
/home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../common/rtmp_init.c:106:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
DBGPRINT(RT_DEBUG_OFF, ("\n=== pAd = %p, size = %lu ===\n\n",
^
This should only be happening if debugging with "DBG" defined. Are you doing so willingly?
/home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../common/rtmp_init.c: In function ‘RTMPAllocAdapterBlock’: /home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../common/rtmp_init.c:106:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘unsigned int’ [-Wformat=] DBGPRINT(RT_DEBUG_OFF, ("\n=== pAd = %p, size = %lu ===\n\n", ^
Anyway, using %zu
instead of %lu
fixes this bug. Fixed in be0b1fb3bf6422721ebf10057aaad99ff2b6cdc8.
/home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../os/linux/sta_ioctl.c: In function ‘rt_ioctl_giwscan’:
/home/pi/wifi-src/genodeftest-Netgear-A6210/os/linux/../../os/linux/sta_ioctl.c:831:14: warning: array subscript is below array bounds [-Warray-bounds]
current_ev = IWE_STREAM_ADD_POINT(info, current_ev, end_buf,&iwe, (char *)pIoctlScan->MainSharedKey[(iwe.u.data.flags & IW_ENCODE_INDEX)-1]);
^
See #90.
Have a look at https://github.com/zfsonlinux/spl/pull/667/files for a better fix for the vfs_read
and vfs_write
problem.
Thanks for all of that @genodeftest although much of it I don't understand as my knowledge of C is very limited.
Seems like most fixes are to the kernel so will have to wait for Debian and the Raspberry Pi kernel, which is based on Debian, to be update.
Re: DBG
Looks like the default in the Makefile is to enable DBG as line 48 is all: debug
and I generally don't edit anything unless it's absolutely necessary to get things working so normally compile using the default code. Changing line 48 to all: release
and DBG is no longer enabled. However, not necessary now as your patch fixes that warning.
Thanks again for taking the time to look at this, regards MrEngman.
Seems like most fixes are to the kernel so will have to wait for Debian and the Raspberry Pi kernel, which is based on Debian, to be update.
No, the fixes here are merely for making it up to the kernel, but they are fixes against this kernel module.
Re: DBG
When I compile the code, I don't get the printk warning. And DBG != DEBUG, so I'm not 100% sure this is true.
Seems like most fixes are to the kernel so will have to wait for Debian and the Raspberry Pi kernel, which is based on Debian, to be update.
No, the fixes here are merely for making it up to the kernel, but they are fixes against this kernel module.
Just shows you how much I understand about C code, although it appeared that some of the patches you linked to were for kernel include files.
Re: DBG
When I compile the code, I don't get the printk warning. And DBG != DEBUG, so I'm not 100% sure this is true.
The default Makefile includes
all: debug
release:
@echo ""
@echo "*** Building driver without debug messages ***"
@echo ""
cp -f os/linux/Makefile.6 $(RT28xx_DIR)/os/linux/Makefile
$(MAKE) -C $(LINUX_SRC) SUBDIRS=$(RT28xx_DIR)/os/linux modules
debug:
export DBGFLAGS
@echo ""
@echo "*** Building driver with debug messages ***"
@echo ""
cp -f os/linux/Makefile.6 $(RT28xx_DIR)/os/linux/Makefile
$(MAKE) -C $(LINUX_SRC) DBGFLAGS=-DDBG SUBDIRS=$(RT28xx_DIR)/os/linux modules
and the debug section which appears to be the default Makefile setting includes DBGFLAGS=-DDBG
which I think is why DBG is enabled. Although I could be wrong.
I compile a number of wifi modules for the Raspberry Pi kernel Raspbian including the mt7612 driver.
I am compiling the drivers on a Pi 3B. The other drivers I compile, 8188eu, 8192eu, 8812/21au and mt7610 compile and run OK after being patched for kernel 4.14. Just the mt7612 is causing issues. All the drivers including the mt7612 compile and run OK on Raspbian kernels 3.18, 4.0, 4.1, 4.4 and 4.9.
Raspbian is being updated to kernel 4.14 and I can no longer get the mt7612 driver to operate, although it compiles, as there are several warnings and the final one stops the driver loading and running.
The final warning when the module is created shows
I have hunted about on the internet and on github to see if I could find a fix for it but have not been able to.
I find the issue rather odd as although the two values are said to be undefined there is no warning while the file they appear in, os/linux/rt_linux.c, is being compiled.
When trying to load the driver I get the following error
and in dmesg
These errors appear to look like the two unknown symbols are being treated as though they are module addresses which seems totally wrong.
Full compiler output