rt2x00: Add debugfs support
PATCH 2/28 rt2x00: Add debugfs support
Add support for debugfs file creation.
This will allow the CSR, EEPROM and BBP registers
of each device to be read and written.
---
drivers/net/wireless/mac80211/rt2x00/Kconfig +8 -0
@@ -81,3 +81,11 @@ config RT73USB_DEBUG depends on RT73USB ---help--- Enable debugging output. + +config RT2X00_DEBUGFS + tristate "Ralink debugfs support" + depends on RT2X00 && DEBUG_FS + ---help--- + Enable creation of debugfs files for the rt2x00 drivers. + These debugfs files support both reading and writing of the + most important register types of the rt2x00 devices.
drivers/net/wireless/mac80211/rt2x00/Makefile +1 -0
@@ -3,3 +3,4 @@ obj-$(CONFIG_RT2500PCI) += rt2500pci.o obj-$(CONFIG_RT61PCI) += rt61pci.o obj-$(CONFIG_RT2500USB) += rt2500usb.o obj-$(CONFIG_RT73USB) += rt73usb.o +obj-$(CONFIG_RT2X00_DEBUGFS) += rt2x00debug.o
drivers/net/wireless/mac80211/rt2x00/rt2400pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2400pci.h +1 -0
@@ -50,6 +50,7 @@#define CSR_REG_SIZE 0x014c#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0020/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2500pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2500pci.h +1 -0
@@ -61,6 +61,7 @@#define CSR_REG_SIZE 0x0174#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0200 +#define BBP_SIZE 0x0040/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2500usb.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2500usb.h +1 -0
@@ -54,6 +54,7 @@#define CSR_REG_SIZE 0x0100#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x006a +#define BBP_SIZE 0x0060/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2x00.h +12 -0
@@ -28,6 +28,11 @@#ifndef RT2X00_H #define RT2X00_H +#if defined(CONFIG_RT2X00_DEBUGFS ) || defined(CONFIG_RT2X00_DEBUGFS_MODULE ) +#define CONFIG_RT2X00_DEBUGFS +#include "rt2x00debug.h" +#endif /* CONFIG_RT2X00_DEBUGFS */ +/* * Module information. */
@@ -953,6 +958,13 @@ struct rt2x00_dev {void __iomem *csr_addr;/* +* If enabled, the structure for the debugfs files. +*/ +#ifdef CONFIG_RT2X00_DEBUGFS +struct rt2x00debug debug; +#endif /* CONFIG_RT2X00_DEBUGFS */ + +/* * Queue for deferred work. */ struct workqueue_struct *workqueue;
drivers/net/wireless/mac80211/rt2x00/rt61pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt61pci.h +1 -0
@@ -54,6 +54,7 @@#define CSR_REG_SIZE 0x04b0#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0080/* * PCI registers.
drivers/net/wireless/mac80211/rt2x00/rt73usb.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt73usb.h +1 -0
@@ -52,6 +52,7 @@#define CSR_REG_SIZE 0x04b0#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0080/* * USB registers.
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c new file +406 -0
406 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.h new file +84 -0
84 lines not on this page · raw message
Johannes Berg
maintainerdrivers/net/wireless/mac80211/rt2x00/rt2x00debug.c line 108
Quoted 5 lines · Ivo van Doorn
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c new file +5
-0+#if LINUX_VERSION_CODE >=KERNEL_VERSION (2 ,6 ,19 ) + file->private_data = inode->i_private; +#else + file->private_data = inode->u.generic_ip; +#endif
Bzzt.
johannes
Johannes Berg
maintainerQuoted 1 line · Ivo van Doorn
+MODULE_VERSION("CVS");
Umm, that's just wrong. And it would really help too if you worked the other way around, work in wireless-dev (by submitting patches often) and maintain old driver versions in CVS.
johannes
Quoted 7 lines · Johannes Berg
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c line 108
Quoted 5 lines · Ivo van Doorn
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c new file +5
-0+#if LINUX_VERSION_CODE >=KERNEL_VERSION (2 ,6 ,19 ) + file->private_data = inode->i_private; +#else + file->private_data = inode->u.generic_ip; +#endif
Ouch.. :(
I'll resend this patch without KERNEL_VERSION stuff in it.
Ivo
Quoted 7 lines · Johannes Berg
Quoted 1 line · Ivo van Doorn
+MODULE_VERSION("CVS");
Umm, that's just wrong. And it would really help too if you worked the other way around, work in wireless-dev (by submitting patches often) and maintain old driver versions in CVS.
Well at the moment the cfg80211/nl80211 updates have had a great impact on our CVS tree. So it is starting to look like we are going to drop our CVS version if we don't find a backwards compatibility for vanilla kernels for it.
Working the other way around will have a negative (But as mentioned above a probably unescapable) side effect. 90% of our testers use the CVS against vanilla kernels, and I cannot see them swicthing to the wireless-dev tree. So I could switch (it is already under consideration) but it will cost us a lot of testers.. :(
Anyway, with the updated debugfs patch I'll have the versioning removed.
Ivo
Johannes Berg
maintainerQuoted 3 lines · Ivo van Doorn
Well at the moment the cfg80211/nl80211 updates have had a great impact on our CVS tree. So it is starting to look like we are going to drop our CVS version if we don't find a backwards compatibility for vanilla kernels for it.
Well, we had to start looking forward somewhere. I wish we'd gotten our cfg80211 wext-compat hooks into mainline but unfortunately that isn't so.
Quoted 5 lines
Working the other way around will have a negative (But as mentioned above a probably unescapable) side effect. 90% of our testers use the CVS against vanilla kernels, and I cannot see them swicthing to the wireless-dev tree.. So I could switch (it is already under consideration) but it will cost us a lot of testers.. :(
Intel is providing snapshots for this stuff and I think James is still trying to figure out if there's any chance to provide cfg80211 w/o patches to mainline, which may just work until critical functionality mac80211 is moved over to cfg80211 instead of wext.
johannes
Quoted 7 lines
Quoted 3 lines
Well at the moment the cfg80211/nl80211 updates have had a great impact on our CVS tree. So it is starting to look like we are going to drop our CVS version if we don't find a backwards compatibility for vanilla kernels for it.
Well, we had to start looking forward somewhere. I wish we'd gotten our cfg80211 wext-compat hooks into mainline but unfortunately that isn't so.
True, and I was expecting problems like this when I decided to keep supporting vanilla kernels. But at the moment i am just considering what the best options for rt2x00 would be.
Quoted 10 lines
Quoted 5 lines
Working the other way around will have a negative (But as mentioned above a probably unescapable) side effect. 90% of our testers use the CVS against vanilla kernels, and I cannot see them swicthing to the wireless-dev tree. So I could switch (it is already under consideration) but it will cost us a lot of testers.. :(
Intel is providing snapshots for this stuff and I think James is still trying to figure out if there's any chance to provide cfg80211 w/o patches to mainline, which may just work until critical functionality mac80211 is moved over to cfg80211 instead of wext.
I have seen that package, James is as far with backwards compatibility as we are in rt2x00. But we are apparently hitting against the same problem. But there is some progress I believe, Robin seems to have managed to compile cfg80211 now against a 2.6.20 kernel. So we probably need some research now to add older kernels to the supported list. ;)
Ivo
Johannes Berg
maintainerQuoted 2 lines · Ivo van Doorn
But there is some progress I believe, Robin seems to have managed to compile cfg80211 now against a 2.6.20 kernel.
Guys, why do we know nothing about this? Could you *please* come out of your hole?
johannes
Quoted 7 lines · Johannes Berg
Quoted 2 lines · Ivo van Doorn
But there is some progress I believe, Robin seems to have managed to compile cfg80211 now against a 2.6.20 kernel.
Guys, why do we know nothing about this? Could you *please* come out of your hole?
Perhaps because Robin told it to me 5 minutes before I send that mail? ;) He is still struggling a bit with the Makefile, but at least some progress has been made.
I have added Robin to the CC list, so he can explain the current status himself. :)
Ivo
This patch will add debugfs support to rt2x00.
It will add these files into the debugfs directory that has been created by the wiphy handler.
This patch also has the MODULE_VERSION() and the LINUX_VERSION_CODE removed.
---
drivers/net/wireless/mac80211/rt2x00/Kconfig +8 -0
@@ -81,3 +81,11 @@ config RT73USB_DEBUG depends on RT73USB ---help--- Enable debugging output. + +config RT2X00_DEBUGFS + tristate "Ralink debugfs support" + depends on RT2X00 && DEBUG_FS + ---help--- + Enable creation of debugfs files for the rt2x00 drivers. + These debugfs files support both reading and writing of the + most important register types of the rt2x00 devices.
drivers/net/wireless/mac80211/rt2x00/Makefile +1 -0
@@ -3,3 +3,4 @@ obj-$(CONFIG_RT2500PCI) += rt2500pci.o obj-$(CONFIG_RT61PCI) += rt61pci.o obj-$(CONFIG_RT2500USB) += rt2500usb.o obj-$(CONFIG_RT73USB) += rt73usb.o +obj-$(CONFIG_RT2X00_DEBUGFS) += rt2x00debug.o
drivers/net/wireless/mac80211/rt2x00/rt2400pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2400pci.h +1 -0
@@ -50,6 +50,7 @@#define CSR_REG_SIZE 0x014c#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0020/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2500pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2500pci.h +1 -0
@@ -61,6 +61,7 @@#define CSR_REG_SIZE 0x0174#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0200 +#define BBP_SIZE 0x0040/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2500usb.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2500usb.h +1 -0
@@ -54,6 +54,7 @@#define CSR_REG_SIZE 0x0100#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x006a +#define BBP_SIZE 0x0060/* * Control/Status Registers(CSR).
drivers/net/wireless/mac80211/rt2x00/rt2x00.h +12 -0
@@ -28,6 +28,11 @@#ifndef RT2X00_H #define RT2X00_H +#if defined(CONFIG_RT2X00_DEBUGFS ) || defined(CONFIG_RT2X00_DEBUGFS_MODULE ) +#define CONFIG_RT2X00_DEBUGFS +#include "rt2x00debug.h" +#endif /* CONFIG_RT2X00_DEBUGFS */ +/* * Module information. */
@@ -953,6 +958,13 @@ struct rt2x00_dev {void __iomem *csr_addr;/* +* If enabled, the structure for the debugfs files. +*/ +#ifdef CONFIG_RT2X00_DEBUGFS +struct rt2x00debug debug; +#endif /* CONFIG_RT2X00_DEBUGFS */ + +/* * Queue for deferred work. */ struct workqueue_struct *workqueue;
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.c new file +372 -0
372 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt2x00debug.h new file +84 -0
84 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt61pci.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt61pci.h +1 -0
@@ -54,6 +54,7 @@#define CSR_REG_SIZE 0x04b0#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0080/* * PCI registers.
drivers/net/wireless/mac80211/rt2x00/rt73usb.c +84 -0
102 lines not on this page · raw message
drivers/net/wireless/mac80211/rt2x00/rt73usb.h +1 -0
@@ -52,6 +52,7 @@#define CSR_REG_SIZE 0x04b0#define EEPROM_BASE 0x0000#define EEPROM_SIZE 0x0100 +#define BBP_SIZE 0x0080/* * USB registers.
Quoted 6 lines · Ivo van Doorn
Quoted 5 lines · Johannes Berg
Quoted 2 lines · Ivo van Doorn
But there is some progress I believe, Robin seems to have managed to compile cfg80211 now against a 2.6.20 kernel.
Quoted 7 lines
Quoted 2 lines
Guys, why do we know nothing about this? Could you *please* come out of your hole?
Perhaps because Robin told it to me 5 minutes before I send that mail? ;) He is still struggling a bit with the
Makefile, but at least some progress has been made.I have added Robin to the CC list, so he can explain the current status himself. :)
Hi guys,
Ok status is as follows.
d80211 and cfg80211 will compile against a 2.6.20 kernel (i believe 2.6.18 or better will do).
I have achieved this starting with the d80211 and cfg80211 code from wireless-dev.git, and applying some of the intel patches from the d80211 subsystem package and a couple of other pointer cast fixes. I have not made a patch set yet as I am still experimenting.
The problem i am up against is now i must disable the existing wireless extensions in the kernel and this can only be done with a kernel rebuild. I have not tried this yet as I am not sure there is a lot of point continuing on this route as its not possible to completely out of kernel build the cfg80211 modules, which was the target for my experimentation.
Signature · 2 lines
Robin Cornelius http://www.byteme.org.uk
Johannes Berg
maintainerHi Robin,
Quoted 2 lines
d80211 and cfg80211 will compile against a 2.6.20 kernel (i believe 2.6.18 or better will do).
Cool.
Quoted 4 lines
I have achieved this starting with the d80211 and cfg80211 code from wireless-dev.git, and applying some of the intel patches from the d80211 subsystem package and a couple of other pointer cast fixes. I have not made a patch set yet as I am still experimenting.
Yeah, mac80211 should work pretty much.
Quoted 6 lines
The problem i am up against is now i must disable the existing wireless extensions in the kernel and this can only be done with a kernel rebuild. I have not tried this yet as I am not sure there is a lot of point continuing on this route as its not possible to completely out of kernel build the cfg80211 modules, which was the target for my experimentation.
Right. I was thinking that it ought to be possible to create a stripped cfg80211 that doesn't include wext compat (which is possible now) and compile that against old kernels. That way, until mac80211 is converted to use more cfg80211 operations, it should continue to work fine.
johannes
Johannes Berg
maintainerQuoted 2 lines · Robin Cornelius
d80211 and cfg80211 will compile against a 2.6.20 kernel (i believe 2.6.18 or better will do).
I just got cfg80211 to compile against 2.6.19 on my brothers laptop. With James's changes to build mac80211 against older kernels, this should enable us to actually build the current code against older kernels.
There will currently be two restrictions:
* no nl80211
* no wiphy renaming
The second isn't a problem at all, users just have a bit less convenience then. The first will become more and more of a problem as mac80211 will migrate towards cfg80211, but since it hasn't yet this will allow us some time.
To build, I used this sed script first:
sed 's/\([a-z0-9_]*\)->ieee80211_ptr/((struct wireless_dev*)(\1->ax25_ptr))/' -i *.c
to fix the ieee80211_ptr thing (using ax25_ptr as James did), and then applied the attached patch. Then I built the whole thing with the attached Makefile and loaded the module. I couldn't really test it since I don't have mac80211 building against that right now.
johannes
core.c +4 -2
@@ -146,6 +146,8 @@ {int idx, taken =-1 , result; +return -EOPNOTSUPP ; +/* prohibit calling the thing phy%d when %d is not its number */ sscanf (newname,PHY_NAME "%n" , &idx, &taken);if (taken ==strlen (newname) && idx != rdev->idx)
@@ -281,7 +283,7 @@case NETDEV_REGISTER :mutex_lock (&rdev->devlist_mtx);list_add (&((struct wireless_dev *)(dev->ax25_ptr))->list, &rdev->netdev_list); -if (sysfs_create_link (&dev->dev.kobj, &rdev->wiphy.dev.kobj, +if (sysfs_create_link (&dev->class_dev.kobj, &rdev->wiphy.dev.kobj,"phy80211" )) {printk (KERN_ERR "wireless: failed to add phy80211 symlink to netdev!\n" ); }
@@ -290,7 +292,7 @@break ;case NETDEV_UNREGISTER :mutex_lock (&rdev->devlist_mtx); -sysfs_remove_link (&dev->dev.kobj,"phy80211" ); +sysfs_remove_link (&dev->class_dev.kobj,"phy80211" );list_del (&((struct wireless_dev *)(dev->ax25_ptr))->list);mutex_unlock (&rdev->devlist_mtx);break ;
KVER := $(shell uname -r)
KDIR ?= /lib/modules/$(KVER)/build
MODPATH := $(DESTDIR)/lib/modules/$(KVER)/kernel/net/wireless/
ifneq ($(KERNELRELEASE),)
CONFIG_CFG80211=m
CFLAGS+=-I $(PWD) '-Dieee80211_ptr=ax25_ptr'
obj-$(CONFIG_CFG80211) += cfg80211.o
cfg80211-y += core.o sysfs.o
else
PWD := $(shell pwd)
module:
$(MAKE) -C $(KDIR) M=$(PWD) modules
endif
Johannes Berg
maintainerQuoted 2 lines · Johannes Berg
CFLAGS+=-I $(PWD) '-Dieee80211_ptr=ax25_ptr'
The -D... part is of course bogus since I did the sed script. Tried this way first but that doesn't work since ieee80211_ptr isn't void* any more and we actually do -> on it.
johannes