rt2x00:

Hi John,

Here is the patch series to bring rt2x00 up to date. The main features this series presents are:
- debugfs support (reading/writing registers)
- rt2x00lib (Move generic code to a seperate module)
- sparse fixes

This series also fixes countless of bugs, although several new ones have been introduced. All rt2x00 drivers should now be far better at supporting master mode. Alhtough rt73usb is no longer capable of receiving any data.

Sparse is not completely silent about rt2x00, except for the rt2x00debug module. sparse simply gives a warning about unnamed initializors in the file_operation structures and then simply crashes. I have been unable to see what the exact cause of the problem is.

For this patch series I have been experimenting with git/cogito a bit, so perhaps next patch series will be a git pull request instead of 30 mails. ;)

Ivo

Unrelated to this particular patchset, but we've long said how rt* drivers are a source of huge amounts of duplicate code.

I just diffed rt2400pci and rt2500pci just for example and noticed that the hardware is basically identical except for the added features. After cutting out spurious changes the diff is about 150 lines so it should be really simple to support the hw in one driver. It'd be great if you could do this, the code duplication currently in there is pretty awkward if we change anything externally and need to update 5 almost-identical drivers.

johannes

That is where rt2x00lib is coming in. This is only a recent addition to rt2x00 so not everything has moved in correctly. So you can expect more to be merged into rt2x00lib.

Merging rt2400pci and rt2500pci doesn't sound like a good idea to me, once rt2x00lib has been optimally used most duplicate code is out, and merging those 2 could make the implementation of hardware encryption for rt2500pci harder. rt2400pci is the only Ralink chip that is not capable of hardware encryption.

In the early days of rt2x00 where work on rewriting the drivers has just begun, those 2 drivers were indeed merged but the checks for which chipset was currently used became more and more complex. The RF chipsets are not unique between RT chips, which made checking for which register should be set and with what value became larger and larger. In the end it appeared simpler to split the 2 apart. Especially when considering that more use should be made of the hardware encryption capabilities of rt2500.

Ivo

Yeah, I see that.

Well you'll still have a lot of the registration code etc. duplicated.

That I don't understand at all; if it's a 2400pci chip you just return early from the set_key() callback and thereby tell mac80211 to use sw crypto.

johannes

Personally I think the amount of duplicated code will not be that bad, but I can make a better comparison when rt2x00lib is better used than currently is the case.

It goes a bit further than that, interrupt handling is done differently as well, and still a lot of checks during register intialization have to be performed about what to do when. Some functions, like channel selection, would have to be implemented twice due to the number of checks for each indivudual RF chipset.

But to be honest, the last time I had looked into rt2400pci and rt2500pci merger was in the early days of rt2x00 when there wasn't a Linux wireless stack yet. Not even Intel had announced its stack yet. (rt2x00 started in 2004) so back then I had to try to extract the stack from the Ralink drivers.

Personally I think that merging the 2 drivers would make the code too obscure to be easily understandable after the implementation of hardware encryption. But I could be wrong, as I haven't worked on the hardware encryption yet (getting things working without HW encryption is hard enough). So I think it is best to reinvestigate merging rt2400pci and rt2500pci, when both modules are working independently and hardware encryption work is being done. That will give the best comparison material for making a better decision.

Ivo

Sounds good to me.

johannes