[PATCH 0/28] rt2x00:

[PATCH 0/28] rt2x00:

[Ivo van Doorn]

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

Re: [PATCH 0/28] rt2x00:

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Wed, 2007-02-28 at 15:07 +0100, Ivo van Doorn wrote:

> Here is the patch series to bring rt2x00 up to date.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH 0/28] rt2x00:

[Ivo van Doorn]

On Wednesday 28 February 2007 17:57, Johannes Berg wrote:
> On Wed, 2007-02-28 at 15:07 +0100, Ivo van Doorn wrote:
> 
> > Here is the patch series to bring rt2x00 up to date.
> 
> 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.

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

Re: [PATCH 0/28] rt2x00:

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Wed, 2007-02-28 at 18:07 +0100, Ivo van Doorn wrote:

> 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.

Yeah, I see that.

> Merging rt2400pci and rt2500pci doesn't sound like a good idea to me,
> once rt2x00lib has been optimally used most duplicate code is out,

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

> 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.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH 0/28] rt2x00:

[Ivo van Doorn]

On Wednesday 28 February 2007 18:16, Johannes Berg wrote:
> On Wed, 2007-02-28 at 18:07 +0100, Ivo van Doorn wrote:
> 
> > 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.
> 
> Yeah, I see that.
> 
> > Merging rt2400pci and rt2500pci doesn't sound like a good idea to me,
> > once rt2x00lib has been optimally used most duplicate code is out,
> 
> Well you'll still have a lot of the registration code etc. duplicated.

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.

> > 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.
> 
> 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.
 
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

Re: [PATCH 0/28] rt2x00:

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On Wed, 2007-02-28 at 19:24 +0100, Ivo van Doorn wrote:

> 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. 

Sounds good to me.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]