lwn.git/drivers/net/wireless/rt2x00/rt2800pci.c, branch v3.0.95

rt2x00: Fix rfkill polling prior to interface start.

2012-10-02T16:47:37+00:00

commit a396e10019eaf3809b0219c966865aaafec12630 upstream. We need to program the rfkill switch GPIO pin direction to input at device initialization time, not only when the interface is brought up. Doing this only when the interface is brought up could lead to rfkill detecting the switch is turned on erroneously and inability to create the interface and bringing it up. Reported-and-tested-by: Andreas Messer Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2800pci: fix spurious interrupts generation

2012-01-26T01:25:02+00:00

commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream. Same devices can generate interrupt without properly setting bit in INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line will be disabled by interrupts controller driver. We discovered that clearing INT_MASK_CSR stops such behaviour. We previously first read that register, and then clear all know interrupt sources bits and do not touch reserved bits. After this patch, we write to all register content (I believe writing to reserved bits on that register will not cause any problems, I tested that on my rt2800pci device). This fix very bad performance problem, practically making device unusable (since worked without interrupts), reported in: https://bugzilla.redhat.com/show_bug.cgi?id=658451 We previously tried to workaround that issue in commit 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious interrupts", but it was reverted in commit 82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6 as thing, that will prevent to detect real spurious interrupts. Reported-and-tested-by: Amir Hedayaty Signed-off-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2x00: Add device ID for RT539F device.

2011-08-05T04:58:42+00:00

commit 71e0b38c2914018b01f3f08b43ee9e3328197699 upstream. Reported-by: Wim Vander Schelden Signed-off-by: Gertjan van Wingerde Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2x00: Fix optimize register access for rt2800pci

2011-05-02T18:49:17+00:00

The patch rt2x00: Optimize register access in rt2800pci from Helmut Schaa missed one register call, namely the rt2800_register_multiwrite which should be changed to rt2x00pci_register_multiwrite. Signed-off-by: Ivo van Doorn Acked-by: Helmut Schaa Signed-off-by: John W. Linville

rt2x00: Implement get_ringparam callback function

2011-04-19T19:40:04+00:00

With the get_ringparam callback function we can export ring parameters to ethtool through the mac80211 interface. Signed-off-by: Ivo van Doorn Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville

rt2x00: Optimize register access in rt2800pci

2011-04-19T19:39:59+00:00

All register reads/writes in rt2800pci were previously done with rt2800_register_read/rt2800_register_write. These however indirectly call rt2x00pci_register_read/rt2x00pci_register_write which adds an additional overhead of at least one call and several move instructions to each register access. Replacing the calls to rt2800_register_read/rt2800_register_write with direct calls to rt2x00pci_register_read/rt2x00pci_register_write gets rid of quite a number of instructions in the drivers hotpaths (IRQ handling and txdone handling). For consistency replace all references to rt2800_register_read/write with the rt2x00pci_register_read/write variants. Signed-off-by: Helmut Schaa Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville

rt2x00: Allow dynamic addition of PCI/USB IDs.

2011-04-19T19:39:45+00:00

Both USB and PCI drivers allow a system administrator to dynamically add USB/PCI IDs to the device table that a driver supports via the /sys/bus/{usb,pci,pci_express}/drivers//new_id files. However, for the rt2x00 drivers using this method currently crashes the system with a NULL pointer failure. This is due to the set-up of rt2x00 where the probe functions require a rt2x00_ops structure in the driver_info field of the probed device. As this field is empty for the dynamically added devices this fails for these devices. Fix this by introducing driver-specific probe wrappers that do nothing but calling the bus-specific probe functions with the rt2x00_ops structure as an argument, rather than depending on the driver_info field. Signed-off-by: Gertjan van Wingerde Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville

rt2x00: Always inline rt2x00pci_enable_interrupt

2011-04-19T19:39:40+00:00

This allows the compiler to perform the necessary bitfield calculations during compile time instead of run time and thus reduces the number of instructions to run during each tasklet invocation. This should improve performance in the RX hotpath. This comes at the cost of a slight increase in the module size (for example rt2800pci): Before: text data bss dec hex filename 14133 832 4 14969 3a79 drivers/net/wireless/rt2x00/rt2800pci.ko After: text data bss dec hex filename 14149 832 4 14985 3a89 drivers/net/wireless/rt2x00/rt2800pci.ko Signed-off-by: Helmut Schaa Acked-by: Gertjan van Wingerde Signed-off-by: Ivo van Doorn Signed-off-by: John W. Linville

rt2x00: Decrease association time for USB devices

2011-04-19T19:39:37+00:00

When powersaving is enabled, assocaition times are very high (for WPA2 networks, the time can easily be around the 3 seconds). This is caused, because the flushing of the queues takes too much time. Without the flushing callback mac80211 assumes a timeout of 100ms while scanning. Limit all flush waiting loops to the same maximum. We can apply this maximum by passing the drop status to the driver, which makes sure the driver performs extra actions during the waiting for the queue to become empty. After these changes, association times fall within the healthy range of ~0.6 seconds with powersaving enabled. The difference between association time between powersaving enabled and disabled is now only ~0.1 second (which can also be due to the measuring method). Signed-off-by: Ivo van Doorn Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville

rt2x00: Split rt2x00dev->flags

2011-04-19T19:39:11+00:00

The number of flags defined for the rt2x00dev->flags field, has been growing over the years. Currently we are approaching the maximum number of bits which are available in the field. A secondary problem, is that one part of the field are initialized only during boot, because the driver requirements are initialized or device requirements are loaded from the EEPROM. In both cases, the flags are fixed and will not change during device operation. The other flags are the device state, and will change frequently. So far this resulted in the fact that for some flags, the atomic bit accessors are used, while for the others the non-atomic variants are used. By splitting the flags up into a "flags" and "cap_flags" we can put all flags which are fixed inside "cap_flags". This field can then be read non-atomically. In the "flags" field we keep the device state, which is going to be read atomically. This adds more room for more flags in the future, and sanitizes the field access methods. Signed-off-by: Ivo van Doorn Acked-by: Helmut Schaa Signed-off-by: John W. Linville