[announce] new rt2800 drivers for Ralink wireless & project tree

[announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

Hi,

The following patch series (against wireless-next) addresses issues raised
during code review and subsequently rejected by rt2x00/wireless/networking
maintainers.


Namely, it:

- Adds abstraction of chipset register access for chipsets connected to
  different buses by using new structure (struct rt2800_ops) which contains
  all needed register access methods.

  [ It is a prerequisite for fixing code duplication between rt2800usb.c
    and rt2800pci.c drivers. ]

- Fixes code duplication in rt2800usb.h and rt2800pci.h header files by
  using new shared rt2800.h header (almost 1800 LOC gone).

  Updated debugging scripts are located here:

      http://www.kernel.org/pub/linux/kernel/people/bart/rt2800/scripts/

  (they also work fine with older drivers)

- Adds rt2800 library containing common code for PCI and USB versions
  of rt2800 chipsets.  This removes over 1300 LOC and allows us to save
  a lot of maintenance burden in the future. 


It also fixes two real bugs (one in rt2800pci and one in rt2800usb) found
as a direct result of the code de-duplication:

- Fix rt2800usb driver to write the rfcsr read request into RF_CSR_CFG
  register and not BBP_CSR_CFG one in rt2800usb_rfcsr_read().

- Use the correct encryption key index for TX frames in rt2800pci (this is
  based on rt2800usb patch from Benoit PAPILLAULT already in Linus' tree,
  unfortunately the fix was not ported over to rt2800pci).

  [ There are also some minor code rt2x00 infrastructure fixes and improvements
     here and there... ]


All in all over 3100 LOC are gone and rt2800pci specific code is:

 1685 drivers/net/wireless/rt2x00/rt2800pci.c
  180 drivers/net/wireless/rt2x00/rt2800pci.h
 1865 total

instead of:

  3323 drivers/net/wireless/rt2x00/rt2800pci.c
  1960 drivers/net/wireless/rt2x00/rt2800pci.h
  5283 total

  (wireless-next and net-next trees)

which means decrease of the code needed for rt2800pci by 65% (this in turn
translates to 31% decrease for rt2800 specific code and 9% for whole rt2x00
infrastructure).

The rewrite was quite conservative and there is still a room for improvement
but it should serve as a good starting base for all future work on rt2800
drivers, and there is a lot to do there (both drivers are still practically
non-functional).

Comments and patches are welcomed.


The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
  Juuso Oikarinen (1):
        wl1271: Generalize command response reading

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800

Bartlomiej Zolnierkiewicz (40):
      rt2800usb: fix rt2800usb_rfcsr_read()
      rt2800pci: fix crypto in TX frame
      rt2800pci: fix comment about register access
      rt2800pci: fix comment about IV/EIV fields
      rt2x00: fix rt2x00usb_register_read() comment
      rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
      rt2800usb: add rt2800_register_[read,write]() wrappers
      rt2800pci: add rt2800_register_[read,write]() wrappers
      rt2800usb: add rt2800_register_multi[read,write]() wrappers
      rt2800pci: add rt2800_register_multi[read,write]() wrappers
      rt2800usb: add rt2800_regbusy_read() wrapper
      rt2800pci: add rt2800_regbusy_read() wrapper
      rt2800usb: add rt2800_bbp_[read,write]() wrappers
      rt2800pci: add rt2800_bbp_[read,write]() wrappers
      rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
      rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
      rt2800usb: add rt2800_rf_[read,write]() wrappers
      rt2800pci: add rt2800_rf_[read,write]() wrappers
      rt2800usb: add rt2800_mcu_request() wrapper
      rt2800pci: add rt2800_mcu_request() wrapper
      rt2x00: add driver private field to struct rt2x00_dev
      rt2800usb: convert to use struct rt2800_ops methods
      rt2800pci: convert to use struct rt2800_ops methods
      rt2x00: fix rt2x00usb_register_multiwrite() arguments
      rt2x00: fix rt2x00usb_regbusy_read() arguments
      rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
      rt2800: add rt2800lib.h
      rt2800usb: fix comments in rt2800usb.h
      rt2800usb: add RXINFO_DESC_SIZE definition
      rt2800: fix duplication in header files
      rt2800: fix comments in rt2800.h
      rt2x00: add support for different chipset interfaces
      rt2800: prepare for rt2800lib addition
      rt2800: add rt2800lib (part one)
      rt2x00: remove needless ifdefs from rt2x00leds.h
      rt2800: add rt2800lib (part two)
      rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
      rt2800: add rt2800lib (part three)
      rt2800: add rt2800lib (part four)
      MAINTAINERS: add rt2800 entry

 MAINTAINERS                              |    7 +
 drivers/net/wireless/rt2x00/Kconfig      |    5 +
 drivers/net/wireless/rt2x00/Makefile     |    1 +
 drivers/net/wireless/rt2x00/rt2800.h     | 1816 ++++++++++++++++++++++++++++
 drivers/net/wireless/rt2x00/rt2800lib.c  | 1817 ++++++++++++++++++++++++++++
 drivers/net/wireless/rt2x00/rt2800lib.h  |  134 +++
 drivers/net/wireless/rt2x00/rt2800pci.c  | 1908 +++---------------------------
 drivers/net/wireless/rt2x00/rt2800pci.h  | 1780 ----------------------------
 drivers/net/wireless/rt2x00/rt2800usb.c  | 1828 ++---------------------------
 drivers/net/wireless/rt2x00/rt2800usb.h  | 1818 +----------------------------
 drivers/net/wireless/rt2x00/rt2x00.h     |   33 +
 drivers/net/wireless/rt2x00/rt2x00leds.h |    4 -
 drivers/net/wireless/rt2x00/rt2x00pci.h  |   24 +-
 drivers/net/wireless/rt2x00/rt2x00usb.c  |    2 +-
 drivers/net/wireless/rt2x00/rt2x00usb.h  |   17 +-
 15 files changed, 4036 insertions(+), 7158 deletions(-)
 create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
 create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
 create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> The following patch series (against wireless-next) addresses issues raised
> during code review and subsequently rejected by rt2x00/wireless/networking
> maintainers.

Really stop reading only the half of emails, try reading it entirely (or at least don't
stop at the second word in a sentence). It really starts the bug me to repeat
myself over and over again because you refuse to read.

Your comments during code review were ACCEPTED with the only remark that
it shouldn't be done right here and now.

[snip]

> The rewrite was quite conservative and there is still a room for improvement
> but it should serve as a good starting base for all future work on rt2800
> drivers, and there is a lot to do there (both drivers are still practically
> non-functional).

Hence the reason I can use my rt2800usb device as long as I don't connect to
a 11n AP. But since everybody in the world has 11n devices, the rt2800usb device
is not capable of doing anything...

> Comments and patches are welcomed.
> 
> 
> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
>   Juuso Oikarinen (1):
>         wl1271: Generalize command response reading
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> 
> Bartlomiej Zolnierkiewicz (40):
>       rt2800usb: fix rt2800usb_rfcsr_read()
>       rt2800pci: fix crypto in TX frame
>       rt2800pci: fix comment about register access
>       rt2800pci: fix comment about IV/EIV fields
>       rt2x00: fix rt2x00usb_register_read() comment
>       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
[.. snip..]
>       rt2800usb: fix comments in rt2800usb.h
>       rt2800usb: add RXINFO_DESC_SIZE definition
[..snip..]
>       rt2800: fix comments in rt2800.h
[..snip..]
>       rt2x00: remove needless ifdefs from rt2x00leds.h

These 10 patches look sane enough. Please send them as patch series
to linux-wireless.

>       rt2x00: add support for different chipset interfaces

Not needed, you can determine exactly what chipset you have
by looking at the other fields. So extending the structure to
repeat the same information isn't needed.

>       MAINTAINERS: add rt2800 entry

I see you decided to take over the maintainership?
Doesn't that need the current maintainer to move away, or was this part
of the "going over other peoples head" plan?

>       rt2800usb: add rt2800_register_[read,write]() wrappers
>       rt2800pci: add rt2800_register_[read,write]() wrappers
>       rt2800usb: add rt2800_register_multi[read,write]() wrappers
>       rt2800pci: add rt2800_register_multi[read,write]() wrappers
>       rt2800usb: add rt2800_regbusy_read() wrapper
>       rt2800pci: add rt2800_regbusy_read() wrapper
>       rt2800usb: add rt2800_bbp_[read,write]() wrappers
>       rt2800pci: add rt2800_bbp_[read,write]() wrappers
>       rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800usb: add rt2800_rf_[read,write]() wrappers
>       rt2800pci: add rt2800_rf_[read,write]() wrappers
>       rt2800usb: add rt2800_mcu_request() wrapper
>       rt2800pci: add rt2800_mcu_request() wrapper
>       rt2x00: add driver private field to struct rt2x00_dev
>       rt2800usb: convert to use struct rt2800_ops methods
>       rt2800pci: convert to use struct rt2800_ops methods
>       rt2x00: fix rt2x00usb_register_multiwrite() arguments
>       rt2x00: fix rt2x00usb_regbusy_read() arguments
>       rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
>       rt2800: add rt2800lib.h
>       rt2800: fix duplication in header files
>       rt2800: prepare for rt2800lib addition
>       rt2800: add rt2800lib (part one)
>       rt2800: add rt2800lib (part two)
>       rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
>       rt2800: add rt2800lib (part three)
>       rt2800: add rt2800lib (part four)

These are too much (and too big) patches for me to review at once, I'll look at
them later.

Ivo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Tuesday 03 November 2009 22:00:03 Ivo van Doorn wrote:
> On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> > 
> > Hi,
> > 
> > The following patch series (against wireless-next) addresses issues raised
> > during code review and subsequently rejected by rt2x00/wireless/networking
> > maintainers.
> 
> Really stop reading only the half of emails, try reading it entirely (or at least don't
> stop at the second word in a sentence). It really starts the bug me to repeat
> myself over and over again because you refuse to read.
> 
> Your comments during code review were ACCEPTED with the only remark that
> it shouldn't be done right here and now.

Please stop this bullshit.  We have some standards for the upstream code
and by being maintainer you have to live up to this standards and make sure
that they are respected instead of watering them down yourself..

You were not interested even in fixing the headers duplication (it turned
out debugging scripts needed only 25 lines of code to be able to work with
fixed headers -- 25 LOC in bash scripts used only for debugging instead
of 1800 LOC of kernel code).

Also: I've mostly heard that I can fix the code myself.  Which I did.

> > The rewrite was quite conservative and there is still a room for improvement
> > but it should serve as a good starting base for all future work on rt2800
> > drivers, and there is a lot to do there (both drivers are still practically
> > non-functional).
> 
> Hence the reason I can use my rt2800usb device as long as I don't connect to
> a 11n AP. But since everybody in the world has 11n devices, the rt2800usb device
> is not capable of doing anything...

I use 11bg AP but mine rt2800usb device is RT3070 (which is quite popular
nowadays) and it simply doesn't even work with rt2800usb currently.

> > Comments and patches are welcomed.
> > 
> > 
> > The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
> >   Juuso Oikarinen (1):
> >         wl1271: Generalize command response reading
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> > 
> > Bartlomiej Zolnierkiewicz (40):
> >       rt2800usb: fix rt2800usb_rfcsr_read()
> >       rt2800pci: fix crypto in TX frame
> >       rt2800pci: fix comment about register access
> >       rt2800pci: fix comment about IV/EIV fields
> >       rt2x00: fix rt2x00usb_register_read() comment
> >       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
> [.. snip..]
> >       rt2800usb: fix comments in rt2800usb.h
> >       rt2800usb: add RXINFO_DESC_SIZE definition
> [..snip..]
> >       rt2800: fix comments in rt2800.h
> [..snip..]
> >       rt2x00: remove needless ifdefs from rt2x00leds.h
> 
> These 10 patches look sane enough. Please send them as patch series
> to linux-wireless.

I'll re-post later whole patch series to linux-wireless to ease the review.

> >       rt2x00: add support for different chipset interfaces
> 
> Not needed, you can determine exactly what chipset you have
> by looking at the other fields. So extending the structure to
> repeat the same information isn't needed.

It is a better to have a single field always indicating this since:
- combining information from other fields is complex and error-prone
- the situation may change in the future

However I would love to be proven wrong with the patch.

> >       MAINTAINERS: add rt2800 entry
> 
> I see you decided to take over the maintainership?

This is my kernel tree after all. :)

> Doesn't that need the current maintainer to move away, or was this part
> of the "going over other peoples head" plan?

I just do what is the best to get working drivers in the foreseeable future.

-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

> > > The following patch series (against wireless-next) addresses issues raised
> > > during code review and subsequently rejected by rt2x00/wireless/networking
> > > maintainers.
> > 
> > Really stop reading only the half of emails, try reading it entirely (or at least don't
> > stop at the second word in a sentence). It really starts the bug me to repeat
> > myself over and over again because you refuse to read.
> > 
> > Your comments during code review were ACCEPTED with the only remark that
> > it shouldn't be done right here and now.
> 
> Please stop this bullshit.  We have some standards for the upstream code
> and by being maintainer you have to live up to this standards and make sure
> that they are respected instead of watering them down yourself..
> 
> You were not interested even in fixing the headers duplication (it turned
> out debugging scripts needed only 25 lines of code to be able to work with
> fixed headers -- 25 LOC in bash scripts used only for debugging instead
> of 1800 LOC of kernel code).

Yeah I know that. But like I said, I still needed to get around to do that,
and I am very happy you were interested in fixing it.

> Also: I've mostly heard that I can fix the code myself.  Which I did.

And thats good.

> > > The rewrite was quite conservative and there is still a room for improvement
> > > but it should serve as a good starting base for all future work on rt2800
> > > drivers, and there is a lot to do there (both drivers are still practically
> > > non-functional).
> > 
> > Hence the reason I can use my rt2800usb device as long as I don't connect to
> > a 11n AP. But since everybody in the world has 11n devices, the rt2800usb device
> > is not capable of doing anything...
> 
> I use 11bg AP but mine rt2800usb device is RT3070 (which is quite popular
> nowadays) and it simply doesn't even work with rt2800usb currently.

Mine devices are plain rt2870 chips.

> > > Comments and patches are welcomed.
> > > 
> > > 
> > > The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
> > >   Juuso Oikarinen (1):
> > >         wl1271: Generalize command response reading
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> > > 
> > > Bartlomiej Zolnierkiewicz (40):
> > >       rt2800usb: fix rt2800usb_rfcsr_read()
> > >       rt2800pci: fix crypto in TX frame
> > >       rt2800pci: fix comment about register access
> > >       rt2800pci: fix comment about IV/EIV fields
> > >       rt2x00: fix rt2x00usb_register_read() comment
> > >       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
> > [.. snip..]
> > >       rt2800usb: fix comments in rt2800usb.h
> > >       rt2800usb: add RXINFO_DESC_SIZE definition
> > [..snip..]
> > >       rt2800: fix comments in rt2800.h
> > [..snip..]
> > >       rt2x00: remove needless ifdefs from rt2x00leds.h
> > 
> > These 10 patches look sane enough. Please send them as patch series
> > to linux-wireless.
> 
> I'll re-post later whole patch series to linux-wireless to ease the review.

Make them 2 series, the above can be the real [PATCH] (which I will ack directly),
and the others can be RFC's which can be reviewed/discussed further.

> > >       rt2x00: add support for different chipset interfaces
> > 
> > Not needed, you can determine exactly what chipset you have
> > by looking at the other fields. So extending the structure to
> > repeat the same information isn't needed.
> 
> It is a better to have a single field always indicating this since:
> - combining information from other fields is complex and error-prone
> - the situation may change in the future
> 
> However I would love to be proven wrong with the patch.

Well something that looks like this (as function in rt2800lib.h)

static inline is_rt2800pci(__chip)
{
	return
		(__chip->rt & 0xFF00) == 0x0600 ||
		(__chip->rt & 0xFF00) == 0x0700 ||
		__chip->rt == 0x2880 ||
		__chip->rt == RT3052;
}

You might even go a bit shorter by checking for USB instead:

static inline is_rt2800usb(__chip)
{
	return __chip->rt == RT2870
}

In rt2800lib you already know __chip->rt is part of
the rt2800 family, the is_rt2800usb() (or whatever name
you are going to give that function) is sufficient to know
if you are using PCI or USB.

And when that is not good enough, then please change the
field to only indicate PCI or USB. That way the field could be
used for other things in the future.

> > >       MAINTAINERS: add rt2800 entry
> > 
> > I see you decided to take over the maintainership?
> 
> This is my kernel tree after all. :)

Fine, but please keep this patch in your tree then. ;)

> > Doesn't that need the current maintainer to move away, or was this part
> > of the "going over other peoples head" plan?
> 
> I just do what is the best to get working drivers in the foreseeable future.

Thanks,

Ivo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Tuesday 03 November 2009 23:01:32 Ivo van Doorn wrote:
> > > > The following patch series (against wireless-next) addresses issues raised
> > > > during code review and subsequently rejected by rt2x00/wireless/networking
> > > > maintainers.
> > > 
> > > Really stop reading only the half of emails, try reading it entirely (or at least don't
> > > stop at the second word in a sentence). It really starts the bug me to repeat
> > > myself over and over again because you refuse to read.
> > > 
> > > Your comments during code review were ACCEPTED with the only remark that
> > > it shouldn't be done right here and now.
> > 
> > Please stop this bullshit.  We have some standards for the upstream code
> > and by being maintainer you have to live up to this standards and make sure
> > that they are respected instead of watering them down yourself..
> > 
> > You were not interested even in fixing the headers duplication (it turned
> > out debugging scripts needed only 25 lines of code to be able to work with
> > fixed headers -- 25 LOC in bash scripts used only for debugging instead
> > of 1800 LOC of kernel code).
> 
> Yeah I know that. But like I said, I still needed to get around to do that,
> and I am very happy you were interested in fixing it.

Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.

I'm not in slightest interested in wasting my time on such
things and educating some maintainers about basics.

[ Code duplication is bad, mmm'okay?  Just say no, mmm'okay? ]

> > Also: I've mostly heard that I can fix the code myself.  Which I did.
> 
> And thats good.
> 
> > > > The rewrite was quite conservative and there is still a room for improvement
> > > > but it should serve as a good starting base for all future work on rt2800
> > > > drivers, and there is a lot to do there (both drivers are still practically
> > > > non-functional).
> > > 
> > > Hence the reason I can use my rt2800usb device as long as I don't connect to
> > > a 11n AP. But since everybody in the world has 11n devices, the rt2800usb device
> > > is not capable of doing anything...
> > 
> > I use 11bg AP but mine rt2800usb device is RT3070 (which is quite popular
> > nowadays) and it simply doesn't even work with rt2800usb currently.
> 
> Mine devices are plain rt2870 chips.
> 
> > > > Comments and patches are welcomed.
> > > > 
> > > > 
> > > > The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
> > > >   Juuso Oikarinen (1):
> > > >         wl1271: Generalize command response reading
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> > > > 
> > > > Bartlomiej Zolnierkiewicz (40):
> > > >       rt2800usb: fix rt2800usb_rfcsr_read()
> > > >       rt2800pci: fix crypto in TX frame
> > > >       rt2800pci: fix comment about register access
> > > >       rt2800pci: fix comment about IV/EIV fields
> > > >       rt2x00: fix rt2x00usb_register_read() comment
> > > >       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
> > > [.. snip..]
> > > >       rt2800usb: fix comments in rt2800usb.h
> > > >       rt2800usb: add RXINFO_DESC_SIZE definition
> > > [..snip..]
> > > >       rt2800: fix comments in rt2800.h
> > > [..snip..]
> > > >       rt2x00: remove needless ifdefs from rt2x00leds.h
> > > 
> > > These 10 patches look sane enough. Please send them as patch series
> > > to linux-wireless.
> 
> > I'll re-post later whole patch series to linux-wireless to ease the review.
> 
> Make them 2 series, the above can be the real [PATCH] (which I will ack directly),
> and the others can be RFC's which can be reviewed/discussed further.

Please at least read all patches before even starting making such comments:

i.e. "rt2800: fix comments in rt2800.h" depends on
"rt2800: fix duplication in header files"

and redoing it would be plain waste of time.

Besides for now I'm more interested in working on improving drivers further
than making artificial patch splits.

> > > >       rt2x00: add support for different chipset interfaces
> > > 
> > > Not needed, you can determine exactly what chipset you have
> > > by looking at the other fields. So extending the structure to
> > > repeat the same information isn't needed.
> > 
> > It is a better to have a single field always indicating this since:
> > - combining information from other fields is complex and error-prone
> > - the situation may change in the future
> > 
> > However I would love to be proven wrong with the patch.
> 
> Well something that looks like this (as function in rt2800lib.h)
> 
> static inline is_rt2800pci(__chip)
> {
> 	return
> 		(__chip->rt & 0xFF00) == 0x0600 ||
> 		(__chip->rt & 0xFF00) == 0x0700 ||
> 		__chip->rt == 0x2880 ||
> 		__chip->rt == RT3052;
> }
> 
> You might even go a bit shorter by checking for USB instead:
> 
> static inline is_rt2800usb(__chip)
> {
> 	return __chip->rt == RT2870
> }

Which can turn into maintenance nightmare as might need update
each time new chipset version is added and is error-prone.

Setting chipset interface from the driver itself is much more
maintainer friendly.

> In rt2800lib you already know __chip->rt is part of
> the rt2800 family, the is_rt2800usb() (or whatever name
> you are going to give that function) is sufficient to know
> if you are using PCI or USB.
> 
> And when that is not good enough, then please change the
> field to only indicate PCI or USB. That way the field could be
> used for other things in the future.

Please explain what do you mean by that.  The field in question is enum:

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] rt2x00: add support for different chipset interfaces

[ Impact: rt2x00 infrastructure enhancement ]

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/net/wireless/rt2x00/rt2x00.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Index: b/drivers/net/wireless/rt2x00/rt2x00.h
===================================================================
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -144,6 +144,11 @@ struct avg_val {
 	int avg_weight;
 };
 
+enum rt2x00_chip_intf {
+	RT2X00_CHIP_INTF_PCI,
+	RT2X00_CHIP_INTF_USB,
+};
+
 /*
  * Chipset identification
  * The chipset on the device is composed of a RT and RF chip.
@@ -169,6 +174,8 @@ struct rt2x00_chip {
 
 	u16 rf;
 	u32 rev;
+
+	enum rt2x00_chip_intf intf;
 };
 
 /*
@@ -937,6 +944,18 @@ static inline bool rt2x00_check_rev(cons
 	return ((chipset->rev & mask) == rev);
 }
 
+static inline void rt2x00_set_chip_intf(struct rt2x00_dev *rt2x00dev,
+					enum rt2x00_chip_intf intf)
+{
+	rt2x00dev->chip.intf = intf;
+}
+
+static inline bool rt2x00_intf(const struct rt2x00_chip *chipset,
+			       enum rt2x00_chip_intf intf)
+{
+	return (chipset->intf == intf);
+}
+
 /**
  * rt2x00queue_map_txskb - Map a skb into DMA for TX purposes.
  * @rt2x00dev: Pointer to &struct rt2x00_dev.


-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Gertjan van Wingerde]

On Tue, Nov 3, 2009 at 11:34 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
> On Tuesday 03 November 2009 23:01:32 Ivo van Doorn wrote:
>> > > > The following patch series (against wireless-next) addresses issues raised
>> > > > during code review and subsequently rejected by rt2x00/wireless/networking
>> > > > maintainers.
>> > >
>> > > Really stop reading only the half of emails, try reading it entirely (or at least don't
>> > > stop at the second word in a sentence). It really starts the bug me to repeat
>> > > myself over and over again because you refuse to read.
>> > >
>> > > Your comments during code review were ACCEPTED with the only remark that
>> > > it shouldn't be done right here and now.
>> >
>> > Please stop this bullshit.  We have some standards for the upstream code
>> > and by being maintainer you have to live up to this standards and make sure
>> > that they are respected instead of watering them down yourself..
>> >
>> > You were not interested even in fixing the headers duplication (it turned
>> > out debugging scripts needed only 25 lines of code to be able to work with
>> > fixed headers -- 25 LOC in bash scripts used only for debugging instead
>> > of 1800 LOC of kernel code).
>>
>> Yeah I know that. But like I said, I still needed to get around to do that,
>> and I am very happy you were interested in fixing it.
>
> Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
>
> I'm not in slightest interested in wasting my time on such
> things and educating some maintainers about basics.
>
> [ Code duplication is bad, mmm'okay?  Just say no, mmm'okay? ]
>

Bart,

Are you really interested in working with us (the rt2x00 project) in
getting the rt2800{pci,usb}
drivers in a better shape, or do you just want to continue your
ramblings on how bad you
think the rt2x00 maintainers, wireless maintainer, and networking
maintainer are in your view?

Just continuing these discussions doesn't help a bit as Ivo, John, and
David said they disagreed
with you on this topic.

If you just want to continue with a hostile take-over of the rt2800
maintainership, then please
let us know that, so that we stop spending time on useless
discussions, and let John Linville
decide how he wants to handle this situation. It would be a shame of
the good patches and work
you did, but if that's the case, than that's it.

Otherwise, please focus on the technical contents of the patches and
work with us to get
these drivers in a better shape.

---
Gertjan.


,

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Wednesday 04 November 2009 00:09:02 Gertjan van Wingerde wrote:
> On Tue, Nov 3, 2009 at 11:34 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> > On Tuesday 03 November 2009 23:01:32 Ivo van Doorn wrote:
> >> > > > The following patch series (against wireless-next) addresses issues raised
> >> > > > during code review and subsequently rejected by rt2x00/wireless/networking
> >> > > > maintainers.
> >> > >
> >> > > Really stop reading only the half of emails, try reading it entirely (or at least don't
> >> > > stop at the second word in a sentence). It really starts the bug me to repeat
> >> > > myself over and over again because you refuse to read.
> >> > >
> >> > > Your comments during code review were ACCEPTED with the only remark that
> >> > > it shouldn't be done right here and now.
> >> >
> >> > Please stop this bullshit.  We have some standards for the upstream code
> >> > and by being maintainer you have to live up to this standards and make sure
> >> > that they are respected instead of watering them down yourself..
> >> >
> >> > You were not interested even in fixing the headers duplication (it turned
> >> > out debugging scripts needed only 25 lines of code to be able to work with
> >> > fixed headers -- 25 LOC in bash scripts used only for debugging instead
> >> > of 1800 LOC of kernel code).
> >>
> >> Yeah I know that. But like I said, I still needed to get around to do that,
> >> and I am very happy you were interested in fixing it.
> >
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> >
> > I'm not in slightest interested in wasting my time on such
> > things and educating some maintainers about basics.
> >
> > [ Code duplication is bad, mmm'okay?  Just say no, mmm'okay? ]
> >
> 
> Bart,
> 
> Are you really interested in working with us (the rt2x00 project) in
> getting the rt2800{pci,usb}
> drivers in a better shape, or do you just want to continue your
> ramblings on how bad you
> think the rt2x00 maintainers, wireless maintainer, and networking
> maintainer are in your view?
> 
> Just continuing these discussions doesn't help a bit as Ivo, John, and
> David said they disagreed
> with you on this topic.

I tried explain many times that it is not about what is in MAINTAINERS
file or what somebody says.

> If you just want to continue with a hostile take-over of the rt2800
> maintainership, then please
> let us know that, so that we stop spending time on useless

I fail to see why you see it as a hostile takeover.

I just did what should have been done in the first place (+ I'm going
to push drivers further in this direction in my tree) and I was always
pretty clear that once staging drivers become sufficiently cleaned up
I would start re-basing my efforts on in kernel drivers.

I will be glad to cooperate with you or anyone else from rt2x00 project.
However I will not spin in some stupid bureaucracy when I see that things
can be done more effectively.

> discussions, and let John Linville
> decide how he wants to handle this situation. It would be a shame of
> the good patches and work
> you did, but if that's the case, than that's it.

John can just pull my tree in right now since it is based on his tree
and it would be an immediate improvement over what its in his tree.

It is up to him, or Ivo can also pull my patches into his tree.

You can also decide to throw up my patches completely or re-do them
for some silly reasons.  I won't be making much noise about it since
I'll be already on some next patches..

> Otherwise, please focus on the technical contents of the patches and
> work with us to get
> these drivers in a better shape.

This is what I'm focused on, if you have any technical arguments w.r.t.
my patches I'm willing to listen and address them in sensible time
(if they are valid).  I would also be happy to work with people with any
patches that they are working on currently.

Thanks.
-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Julian Calaby]

On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> If you just want to continue with a hostile take-over of the rt2800
>> maintainership, then please
>> let us know that, so that we stop spending time on useless
>
> I fail to see why you see it as a hostile takeover.

Updating MAINTAINERS to replace the current developers with yourself
can be considered to be a hostile act.

If you want this for your own personal tree, then keep the patch
private - don't include it in pull requests, patch listings etc.

And if you genuinely want the maintainership of the rt28xx drivers,
then updating MAINTAINERS should be done as an afterthought after
clearly proving that you are capable of maintaining the driver and
working with the maintainers of the rt2x00 and wireless subsystems.

> I will be glad to cooperate with you or anyone else from rt2x00 project.
> However I will not spin in some stupid bureaucracy when I see that things
> can be done more effectively.

It's not "stupid bureaucracy" it's *how* *it's* *done*.

If I was going to submit a patch to the Marvell TOPDOG driver to add
support for another related chipset, I'd be going out of my way to
make sure that *everyone* involved was 100% happy so that the patch
can get out to the people who matter: the users.

Everyone has to do this, from big corporations like Intel, to you and
me. For example, I recall the Intel IWL developers being smacked down
a few months ago by John and David over exactly what constitutes a
post-merge window "bugfix".

The rules apply to everyone, just because you don't like them doesn't
mean you can ignore them.

Thanks,

-- 

Julian Calaby

Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Julian Calaby]

On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> If you just want to continue with a hostile take-over of the rt2800
>> maintainership, then please
>> let us know that, so that we stop spending time on useless
>
> I fail to see why you see it as a hostile takeover.

Updating MAINTAINERS to replace the current developers with yourself
can be considered to be a hostile act.

If you want this for your own personal tree, then keep the patch
private - don't include it in pull requests, patch listings etc.

And if you genuinely want the maintainership of the rt28xx drivers,
then updating MAINTAINERS should be done as an afterthought after
clearly proving that you are capable of maintaining the driver and
working with the maintainers of the rt2x00 and wireless subsystems.

> I will be glad to cooperate with you or anyone else from rt2x00 project.
> However I will not spin in some stupid bureaucracy when I see that things
> can be done more effectively.

It's not "stupid bureaucracy" it's *how* *it's* *done*.

If I was going to submit a patch to the Marvell TOPDOG driver to add
support for another related chipset, I'd be going out of my way to
make sure that *everyone* involved was 100% happy so that the patch
can get out to the people who matter: the users.

Everyone has to do this, from big corporations like Intel, to you and
me. For example, I recall the Intel IWL developers being smacked down
a few months ago by John and David over exactly what constitutes a
post-merge window "bugfix".

The rules apply to everyone, just because you don't like them doesn't
mean you can ignore them.

Thanks,

-- 

Julian Calaby

Email: julian.calaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
.Plan: http://sites.google.com/site/juliancalaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Wednesday 04 November 2009 02:33:52 Julian Calaby wrote:
> On Wed, Nov 4, 2009 at 10:46, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> If you just want to continue with a hostile take-over of the rt2800
> >> maintainership, then please
> >> let us know that, so that we stop spending time on useless
> >
> > I fail to see why you see it as a hostile takeover.
> 
> Updating MAINTAINERS to replace the current developers with yourself
> can be considered to be a hostile act.
> 
> If you want this for your own personal tree, then keep the patch
> private - don't include it in pull requests, patch listings etc.

This is not pull request etc. but since the change in question has been
stirring needless controversies and distracting people from reading patches
it has been dropped for now.

-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Alan Cox]

> > Yeah I know that. But like I said, I still needed to get around to do that,
> > and I am very happy you were interested in fixing it.
> 
> Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.

Really - you have a service and support contract with Ivo.. no i thought
not.

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Alan Cox]

> > Yeah I know that. But like I said, I still needed to get around to do that,
> > and I am very happy you were interested in fixing it.
> 
> Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.

Really - you have a service and support contract with Ivo.. no i thought
not.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > and I am very happy you were interested in fixing it.
> > 
> > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> 
> Really - you have a service and support contract with Ivo.. no i thought
> not.

Just today I got PM from somebody complaining to me about non-working
pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
I fixed some bug there some time ago....

Problems are publicly know -- do you want bz# from Debian, SuSE or Red Hat?

Wait.. unfortunately I also don't have support contract with you..

-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Alan Cox]

On Wed, 4 Nov 2009 00:52:28 +0100
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > and I am very happy you were interested in fixing it.
> > > 
> > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> > 
> > Really - you have a service and support contract with Ivo.. no i thought
> > not.
> 
> Just today I got PM from somebody complaining to me about non-working
> pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> I fixed some bug there some time ago....

And didn't bother committing a patch to both sets of code bec

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Wednesday 04 November 2009 01:40:15 Alan Cox wrote:
> On Wed, 4 Nov 2009 00:52:28 +0100
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> 
> > On Wednesday 04 November 2009 00:48:35 Alan Cox wrote:
> > > > > Yeah I know that. But like I said, I still needed to get around to do that,
> > > > > and I am very happy you were interested in fixing it.
> > > > 
> > > > Lets make one thing clear: YOU SHOULD BE THE ONE FIXING IT.
> > > 
> > > Really - you have a service and support contract with Ivo.. no i thought
> > > not.
> > 
> > Just today I got PM from somebody complaining to me about non-working
> > pata_pdc2026x_old (pdc202xx_old works fine for him) simply because
> > I fixed some bug there some time ago....
> 
> And didn't bother committing a patch to both sets of code bec

You misread my mail.

Because I also fixed bug in the PATA code though I was IDE Maintainer.

Also:

Did you have a service & support contract with me when you were complaining
about IDE to me?  [ and I would strongly suggest you not to go there.. ]

Or reversing the initial question:

Does Ivo have a contract with me to contribute to rt2x00 project?

So please stop idiotic arguments.

-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ingo Molnar]

* Ivo van Doorn <ivdoorn@gmail.com> wrote:

> >       MAINTAINERS: add rt2800 entry
> 
> I see you decided to take over the maintainership? Doesn't that need 
> the current maintainer to move away, or was this part of the "going 
> over other peoples head" plan?
>
> [...]
>
> These are too much (and too big) patches for me to review at once, 
> I'll look at them later.

Frankly, having read through the recent discussions related to the 
rt2800pci/usb drivers, the subtle (and largely undeserved) group 
violence and abuse you are inflicting on Bart is stomach-turning.

The non-working rt2800pci driver has been pending in your private tree 
for how long, 1.5 _years_?

Look at the diffstat of Bart's driver:

   15 files changed, 4036 insertions(+), 7158 deletions(-)

He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_ 
driver.

And _still_ your complaint about Bart's series is that he updated the 
MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should 
update it, he is the one doing the hard work of trying to bring it to 
users, trying to clean up a messy driver space, trying to turn crap into 
gold.

The thing is, if you dont have the time or interest to listen to and act 
upon review feedback, be constructive about it and fix (obvious) 
structural problems in your rt2800 code, you should just step aside and 
let Bart maintain what he is apparently more capable of maintaining than 
you are.

What you are doing here is a thinly veiled land-grab: you did a minimal 
token driver for rt2800 that doesnt work, kept it in your private tree 
for _1.5 years_, and the moment someone _else_ came along and did 
something better and more functional in drivers/staging/, you discovered 
your sudden interest for it and moved the crappy driver upstream at 
lightning's speed (it is already in net-next AFAICS, despite negative 
test and review feedback) - ignoring and throwing away all the work that 
Bart has done.

Such behavior wouldnt fly in _any_ other Linux subsystem, but apparently 
there is one set of rules for upstream kernel maintainers and then 
there's another, different set of rules for upstream wireless driver 
maintainers.

Really, you should listen to contrary opinion and _you_ should work 
_hard_ to integrate Bart socially and open up your close circle of 
wireless insiders instead of fighting his 'outsider' contributions every 
which way. We dont care if people are rough, express displeasure and 
show strong opinion about crappy code - but the moment you are 
_excluding_ capable people and playing petty office politics (like you 
are very clearly doing it with Bart here) everyone loses.

Guys, show some minimal amount of honesty, openness and critical 
thinking please ...

	Ingo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Wed, Nov 04, 2009 at 09:37:37AM +0100, Ingo Molnar wrote:

<snip>

> Really, you should listen to contrary opinion and _you_ should work 
> _hard_ to integrate Bart socially and open up your close circle of 
> wireless insiders instead of fighting his 'outsider' contributions every 
> which way. We dont care if people are rough, express displeasure and 
> show strong opinion about crappy code - but the moment you are 
> _excluding_ capable people and playing petty office politics (like you 
> are very clearly doing it with Bart here) everyone loses.

Ivo almost immediately ACKed 10 of Bart's patches (despite Bart's
failure to post them to the mailing list directly per convention),
so you criticize Ivo for saying he needed time to review the rest?
And you accuse him of excluding Bart's contributions when they have
only just arrived?

> Guys, show some minimal amount of honesty, openness and critical 
> thinking please ...

I would ask the same of you, Ingo.  You have burst onto the scene
only recently, full of accusations and blame for one side and
apparently unable to recognize the faults of the other.  You fail to
recognize that this set of patches is essentially the _first_ time
Bart has actually made any attempt to work on the rt2x00 drivers.
Your partisanship is clear.

At least Bart has finally made some rt2x00 patches available.  That is
how things get done.  You continuing to defend him as some sort of
martyr is completely unhelpful.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Wed, Nov 04, 2009 at 09:37:37AM +0100, Ingo Molnar wrote:

<snip>

> Really, you should listen to contrary opinion and _you_ should work 
> _hard_ to integrate Bart socially and open up your close circle of 
> wireless insiders instead of fighting his 'outsider' contributions every 
> which way. We dont care if people are rough, express displeasure and 
> show strong opinion about crappy code - but the moment you are 
> _excluding_ capable people and playing petty office politics (like you 
> are very clearly doing it with Bart here) everyone loses.

Ivo almost immediately ACKed 10 of Bart's patches (despite Bart's
failure to post them to the mailing list directly per convention),
so you criticize Ivo for saying he needed time to review the rest?
And you accuse him of excluding Bart's contributions when they have
only just arrived?

> Guys, show some minimal amount of honesty, openness and critical 
> thinking please ...

I would ask the same of you, Ingo.  You have burst onto the scene
only recently, full of accusations and blame for one side and
apparently unable to recognize the faults of the other.  You fail to
recognize that this set of patches is essentially the _first_ time
Bart has actually made any attempt to work on the rt2x00 drivers.
Your partisanship is clear.

At least Bart has finally made some rt2x00 patches available.  That is
how things get done.  You continuing to defend him as some sort of
martyr is completely unhelpful.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

On Wednesday 04 November 2009, Ingo Molnar wrote:
> 
> * Ivo van Doorn <ivdoorn@gmail.com> wrote:
> 
> > >       MAINTAINERS: add rt2800 entry
> > 
> > I see you decided to take over the maintainership? Doesn't that need 
> > the current maintainer to move away, or was this part of the "going 
> > over other peoples head" plan?
> >
> > [...]
> >
> > These are too much (and too big) patches for me to review at once, 
> > I'll look at them later.
> 
> Frankly, having read through the recent discussions related to the 
> rt2800pci/usb drivers, the subtle (and largely undeserved) group 
> violence and abuse you are inflicting on Bart is stomach-turning.
> 
> The non-working rt2800pci driver has been pending in your private tree 
> for how long, 1.5 _years_?

Something like that.

> Look at the diffstat of Bart's driver:
> 
>    15 files changed, 4036 insertions(+), 7158 deletions(-)
> 
> He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_ 
> driver.

Bullshit, read the mails again.
I have acked a portion of fixes because those were small and obviously
correct. There are some minor bugfixes in them but none of them would
magically make the card work for everybody. So the number of lines is
decreased but the status of the driver is the same.

Some people actually require sleep during the night, perhaps that you don't need
that and can hence review 41 patches which changes thousands of lines on the
same day the patches were submitted.

> And _still_ your complaint about Bart's series is that he updated the 
> MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should 
> update it, he is the one doing the hard work of trying to bring it to 
> users, trying to clean up a messy driver space, trying to turn crap into 
> gold.

So if I want to focus on something different in the kernel, I just send 1 patch,
and a second to claim the maintainership of it even though there is an active
maintainer available?

> The thing is, if you dont have the time or interest to listen to and act 
> upon review feedback, be constructive about it and fix (obvious) 
> structural problems in your rt2800 code, you should just step aside and 
> let Bart maintain what he is apparently more capable of maintaining than 
> you are.
>
> What you are doing here is a thinly veiled land-grab: you did a minimal 
> token driver for rt2800 that doesnt work, kept it in your private tree 
> for _1.5 years_, and the moment someone _else_ came along and did 
> something better and more functional in drivers/staging/, you discovered 
> your sudden interest for it and moved the crappy driver upstream at 
> lightning's speed (it is already in net-next AFAICS, despite negative 
> test and review feedback) - ignoring and throwing away all the work that 
> Bart has done.

Get your facts straight, the bullshit level in your mail is staggering.

You have no fucking clue who wrote the rt2800 driver which is in drivers/staging/,
you have no clue why it was added, and you don't even know what the intention
was for that driver from day 1 (which was clearly communicated!)

You even are missing the point _why_ the rt2x00 driver was 1.5 years in development,
but I'll highlight that part for you:

	Because a lot of people prefer looking from the sideline, contributing _nothing_
	and then after a year complain that the development is going too slowly and they
	could have done better. Apparently that is the style you prefer, but that is most
	definately _not_ how I think Open Source should work.

As for "throwing away that work" I ACKED 10 of his patches, and said I would review
the rest later! But like I said, apparently it is a bad habit for people to sleep during
the night.

> Such behavior wouldnt fly in _any_ other Linux subsystem, but apparently 
> there is one set of rules for upstream kernel maintainers and then 
> there's another, different set of rules for upstream wireless driver 
> maintainers.

So non-wireless maintainers don't need to review patches before giving their Ack?
Well that makes the Acked-by and Signed-off rules completely meaningless,
I wonder why everybody is demanding it before patches are merged...

Ivo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Wed, Nov 04, 2009 at 10:51:22PM +0100, Ivo van Doorn wrote:

> Get your facts straight, the bullshit level in your mail is staggering.

Please, enough!

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Wed, Nov 04, 2009 at 10:51:22PM +0100, Ivo van Doorn wrote:

> Get your facts straight, the bullshit level in your mail is staggering.

Please, enough!

-- 
John W. Linville		Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org			might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Pavel Machek]

> > Look at the diffstat of Bart's driver:
> > 
> >    15 files changed, 4036 insertions(+), 7158 deletions(-)
> > 
> > He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_ 
> > driver.
> 
> Bullshit, read the mails again.

This was uncalled for, right?

...
> Some people actually require sleep during the night, perhaps that you don't need
> that and can hence review 41 patches which changes thousands of lines on the
> same day the patches were submitted.

If you lack time, "Really start reading my mails" sentence you used at
the start of email is *not* user-friendly way to say that.

> > And _still_ your complaint about Bart's series is that he updated the 
> > MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should 
> > update it, he is the one doing the hard work of trying to bring it to 
> > users, trying to clean up a messy driver space, trying to turn crap into 
> > gold.
> 
> So if I want to focus on something different in the kernel, I just send 1 patch,
> and a second to claim the maintainership of it even though there is an active
> maintainer available?

What about listing yourself as a maintainer for a start?

> > The thing is, if you dont have the time or interest to listen to and act 
> > upon review feedback, be constructive about it and fix (obvious) 
> > structural problems in your rt2800 code, you should just step aside and 
> > let Bart maintain what he is apparently more capable of maintaining than 
> > you are.
> >
> > What you are doing here is a thinly veiled land-grab: you did a minimal 
> > token driver for rt2800 that doesnt work, kept it in your private tree 
> > for _1.5 years_, and the moment someone _else_ came along and did 
> > something better and more functional in drivers/staging/, you discovered 
> > your sudden interest for it and moved the crappy driver upstream at 
> > lightning's speed (it is already in net-next AFAICS, despite negative 
> > test and review feedback) - ignoring and throwing away all the work that 
> > Bart has done.
> 
> Get your facts straight, the bullshit level in your mail is staggering.
> 
> You have no fucking clue who wrote the rt2800 driver which is in
> drivers/staging/,

Perhaps you should not be a maintainer if you can't behave yourself?

> 	Because a lot of people prefer looking from the sideline,
> contributing _nothing_

Given your behaviour, I'm not suprised people are not too eager to
work with you.

> As for "throwing away that work" I ACKED 10 of his patches, and said I would review
> the rest later! But like I said, apparently it is a bad habit for people to sleep during
> the night.

Read your email again. It was quite far from 'acked 10, asked for
time'. You flamed him first.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Pavel Machek]

> > Look at the diffstat of Bart's driver:
> > 
> >    15 files changed, 4036 insertions(+), 7158 deletions(-)
> > 
> > He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_ 
> > driver.
> 
> Bullshit, read the mails again.

This was uncalled for, right?

...
> Some people actually require sleep during the night, perhaps that you don't need
> that and can hence review 41 patches which changes thousands of lines on the
> same day the patches were submitted.

If you lack time, "Really start reading my mails" sentence you used at
the start of email is *not* user-friendly way to say that.

> > And _still_ your complaint about Bart's series is that he updated the 
> > MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should 
> > update it, he is the one doing the hard work of trying to bring it to 
> > users, trying to clean up a messy driver space, trying to turn crap into 
> > gold.
> 
> So if I want to focus on something different in the kernel, I just send 1 patch,
> and a second to claim the maintainership of it even though there is an active
> maintainer available?

What about listing yourself as a maintainer for a start?

> > The thing is, if you dont have the time or interest to listen to and act 
> > upon review feedback, be constructive about it and fix (obvious) 
> > structural problems in your rt2800 code, you should just step aside and 
> > let Bart maintain what he is apparently more capable of maintaining than 
> > you are.
> >
> > What you are doing here is a thinly veiled land-grab: you did a minimal 
> > token driver for rt2800 that doesnt work, kept it in your private tree 
> > for _1.5 years_, and the moment someone _else_ came along and did 
> > something better and more functional in drivers/staging/, you discovered 
> > your sudden interest for it and moved the crappy driver upstream at 
> > lightning's speed (it is already in net-next AFAICS, despite negative 
> > test and review feedback) - ignoring and throwing away all the work that 
> > Bart has done.
> 
> Get your facts straight, the bullshit level in your mail is staggering.
> 
> You have no fucking clue who wrote the rt2800 driver which is in
> drivers/staging/,

Perhaps you should not be a maintainer if you can't behave yourself?

> 	Because a lot of people prefer looking from the sideline,
> contributing _nothing_

Given your behaviour, I'm not suprised people are not too eager to
work with you.

> As for "throwing away that work" I ACKED 10 of his patches, and said I would review
> the rest later! But like I said, apparently it is a bad habit for people to sleep during
> the night.

Read your email again. It was quite far from 'acked 10, asked for
time'. You flamed him first.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

Hi,

> > > Look at the diffstat of Bart's driver:
> > > 
> > >    15 files changed, 4036 insertions(+), 7158 deletions(-)
> > > 
> > > He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_ 
> > > driver.
> > 
> > Bullshit, read the mails again.
> 
> This was uncalled for, right?

The way I said it, yes.

But I was frustrated by Ingo with his comment that the driver was magically fixed,
while even Bartlomiej indicated that was not the case. With these comments,
and those were he were his ignorance about the Ralink drivers in the kernel
was apparent, he managed to get me completely upset because I really
got the impression I was talking to a wall or something and overreacted.

> > > And _still_ your complaint about Bart's series is that he updated the 
> > > MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should 
> > > update it, he is the one doing the hard work of trying to bring it to 
> > > users, trying to clean up a messy driver space, trying to turn crap into 
> > > gold.
> > 
> > So if I want to focus on something different in the kernel, I just send 1 patch,
> > and a second to claim the maintainership of it even though there is an active
> > maintainer available?
> 
> What about listing yourself as a maintainer for a start?

The rt2x00 project is listed as maintainer for everything in the
drivers/net/wireless/rt2x00 folder.

> > > The thing is, if you dont have the time or interest to listen to and act 
> > > upon review feedback, be constructive about it and fix (obvious) 
> > > structural problems in your rt2800 code, you should just step aside and 
> > > let Bart maintain what he is apparently more capable of maintaining than 
> > > you are.
> > >
> > > What you are doing here is a thinly veiled land-grab: you did a minimal 
> > > token driver for rt2800 that doesnt work, kept it in your private tree 
> > > for _1.5 years_, and the moment someone _else_ came along and did 
> > > something better and more functional in drivers/staging/, you discovered 
> > > your sudden interest for it and moved the crappy driver upstream at 
> > > lightning's speed (it is already in net-next AFAICS, despite negative 
> > > test and review feedback) - ignoring and throwing away all the work that 
> > > Bart has done.
> > 
> > Get your facts straight, the bullshit level in your mail is staggering.
> > 
> > You have no fucking clue who wrote the rt2800 driver which is in
> > drivers/staging/,
> 
> Perhaps you should not be a maintainer if you can't behave yourself?

Ok let me explain clearer then:

drivers/net/staging/rt28{6,7}0 was developed by Ralink and I acked
the merged for those drivers after the asurance that it was only merged
to please the users so developers could focus on the rt2x00 version of
the driver.

Anyway, I'll do what John requested and go back into my hole since I
have absolutely no desire to continue this flamewar.

Ivo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Friday 06 November 2009 18:58:56 Ivo van Doorn wrote:

> drivers/net/staging/rt28{6,7}0 was developed by Ralink and I acked

The original vendor drivers were:
- rt2860
- rt2870
- rt3070
- rt3090

Each weighting ~100 KLOC.

The current staging drivers (rt2860 w/ RT3090 support and rt2870 w/ RT3070
support) are the result of my work on getting staging drivers under control
(+ trying some new strategies of dealing with ugly code) and weight ~75 KLOC
_together_ (they share the wireless stack code).

> the merged for those drivers after the asurance that it was only merged
> to please the users so developers could focus on the rt2x00 version of
> the driver.

Could somebody please explain me (in the public or in the private) what is
the reason behind whole affair about staging drivers because all the time
I feel like I'm missing some important detail here.  It would a lot more
productive than all the things that I could hear about my agenda, my work
or my intellectual abilities in the past.

[ Like I said before I got only interested into them in April this year
  while doing casual staging cleanups and I'm not affiliated with any
  distribution vendor. ]

Thanks.
-- 
Bartlomiej Zolnierkiewicz

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Bartlomiej Zolnierkiewicz]

On Friday 06 November 2009 18:58:56 Ivo van Doorn wrote:

> drivers/net/staging/rt28{6,7}0 was developed by Ralink and I acked

The original vendor drivers were:
- rt2860
- rt2870
- rt3070
- rt3090

Each weighting ~100 KLOC.

The current staging drivers (rt2860 w/ RT3090 support and rt2870 w/ RT3070
support) are the result of my work on getting staging drivers under control
(+ trying some new strategies of dealing with ugly code) and weight ~75 KLOC
_together_ (they share the wireless stack code).

> the merged for those drivers after the asurance that it was only merged
> to please the users so developers could focus on the rt2x00 version of
> the driver.

Could somebody please explain me (in the public or in the private) what is
the reason behind whole affair about staging drivers because all the time
I feel like I'm missing some important detail here.  It would a lot more
productive than all the things that I could hear about my agenda, my work
or my intellectual abilities in the past.

[ Like I said before I got only interested into them in April this year
  while doing casual staging cleanups and I'm not affiliated with any
  distribution vendor. ]

Thanks.
-- 
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Fri, Nov 06, 2009 at 07:30:13PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Friday 06 November 2009 18:58:56 Ivo van Doorn wrote:

> > the merged for those drivers after the asurance that it was only merged
> > to please the users so developers could focus on the rt2x00 version of
> > the driver.
> 
> Could somebody please explain me (in the public or in the private) what is
> the reason behind whole affair about staging drivers because all the time
> I feel like I'm missing some important detail here.

I'm not 100% sure what you are asking, but I think you want to know
the basis for general objections from the people that hang-out on
linux-wireless and/or the rt2x00 team specifically?

I don't think anyone[1] has overwhelming objections to drivers in
staging for devices that have no other driver available.  The main
objection is that drivers/staging steals users and (and often
developers) from the non-staging drivers, reducing the amount of
testing and development they get.  In the effort to help some users,
drivers/staging effectively prolongs the amount of time those users
have to go without properly supported drivers.  Much worse, none of
the wireless drivers in drivers/staging seem to have generated an
actual mergeable[2] wireless driver.

Further, the wireless drivers in drivers/staging are completely
isolated from the wireless infrastructure developments we've been
making over the past few years.  The longer they live, the longer
wireless extensions will linger, the longer custom rfkill solutions
persist, and the longer we have multiple 802.11 stack implementations.

Finally, bug reports from drivers/staging are an unwelcome distraction
in bugzilla and the wireless mailing lists.  Not only do those drivers
generate (often wierd) bugs, we get the privilege of looking like
jerks for refusing to deal with those reports even though we objected
to including the drivers in the first place.

It is little wonder to me why the linux-wireless folks oppose
drivers/staging...

Hth!

John

[1] Actually, I _know_ there are people who object to all of
drivers/staging, but few of those are actively and vigorously objecting
to it.

[2] A mergeable driver should respect and/or utilize existing wireless
infrastructure rather than duplicating it, as well as meeting general
standards of maintainability.  Preferably it would have someone to
stand behind it as a maintainer as well.
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Pavel Machek]

Hi!

> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> > > and a second to claim the maintainership of it even though there is an active
> > > maintainer available?
> > 
> > What about listing yourself as a maintainer for a start?
> 
> The rt2x00 project is listed as maintainer for everything in the
> drivers/net/wireless/rt2x00 folder.

Yes, but that tells very little. I don't know who the 'rt2x00 project'
is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
list real names of maintainers...      	     	  Pavel 

-- (english)
http://www.livejournal.com/~pavelmachek (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Pavel Machek]

Hi!

> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> > > and a second to claim the maintainership of it even though there is an active
> > > maintainer available?
> > 
> > What about listing yourself as a maintainer for a start?
> 
> The rt2x00 project is listed as maintainer for everything in the
> drivers/net/wireless/rt2x00 folder.

Yes, but that tells very little. I don't know who the 'rt2x00 project'
is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
list real names of maintainers...      	     	  Pavel 

-- (english)
http://www.livejournal.com/~pavelmachek (cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Luis Correia]

Pavel,

On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > > So if I want to focus on something different in the kernel, I just send 1 patch,
>> > > and a second to claim the maintainership of it even though there is an active
>> > > maintainer available?
>> >
>> > What about listing yourself as a maintainer for a start?
>>
>> The rt2x00 project is listed as maintainer for everything in the
>> drivers/net/wireless/rt2x00 folder.
>
> Yes, but that tells very little. I don't know who the 'rt2x00 project'
> is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
> list real names of maintainers...                 Pavel

the answer is (and always was available) here:

http://rt2x00.serialmonkey.com/wiki/index.php/Developers

Luis Correia
rt2x00 project admin

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

On Saturday 07 November 2009, Luis Correia wrote:
> Pavel,
> 
> On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> >> > > and a second to claim the maintainership of it even though there is an active
> >> > > maintainer available?
> >> >
> >> > What about listing yourself as a maintainer for a start?
> >>
> >> The rt2x00 project is listed as maintainer for everything in the
> >> drivers/net/wireless/rt2x00 folder.
> >
> > Yes, but that tells very little. I don't know who the 'rt2x00 project'
> > is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
> > list real names of maintainers...                 Pavel
> 
> the answer is (and always was available) here:
> 
> http://rt2x00.serialmonkey.com/wiki/index.php/Developers

True, but I agree with Pavel that the MAINTAINERS file should
be instantly clear about who the maintainer is.

I've already send a patch to add update the entry.

Ivo

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Ivo van Doorn]

On Saturday 07 November 2009, Luis Correia wrote:
> Pavel,
> 
> On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> wrote:
> > Hi!
> >
> >> > > So if I want to focus on something different in the kernel, I just send 1 patch,
> >> > > and a second to claim the maintainership of it even though there is an active
> >> > > maintainer available?
> >> >
> >> > What about listing yourself as a maintainer for a start?
> >>
> >> The rt2x00 project is listed as maintainer for everything in the
> >> drivers/net/wireless/rt2x00 folder.
> >
> > Yes, but that tells very little. I don't know who the 'rt2x00 project'
> > is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
> > list real names of maintainers...                 Pavel
> 
> the answer is (and always was available) here:
> 
> http://rt2x00.serialmonkey.com/wiki/index.php/Developers

True, but I agree with Pavel that the MAINTAINERS file should
be instantly clear about who the maintainer is.

I've already send a patch to add update the entry.

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Luis R. Rodriguez]

On Sat, Nov 7, 2009 at 10:12 AM, Luis Correia <luis.f.correia@gmail.com> wrote:
> Pavel,
>
> On Sat, Nov 7, 2009 at 17:30, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>> > > So if I want to focus on something different in the kernel, I just send 1 patch,
>>> > > and a second to claim the maintainership of it even though there is an active
>>> > > maintainer available?
>>> >
>>> > What about listing yourself as a maintainer for a start?
>>>
>>> The rt2x00 project is listed as maintainer for everything in the
>>> drivers/net/wireless/rt2x00 folder.
>>
>> Yes, but that tells very little. I don't know who the 'rt2x00 project'
>> is. Perhaps its you? Perhaps its Bart? Maybe its my cat? Please just
>> list real names of maintainers...                 Pavel
>
> the answer is (and always was available) here:
>
> http://rt2x00.serialmonkey.com/wiki/index.php/Developers
>
> Luis Correia
> rt2x00 project admin

BTW is the rt2x00 project a non-profit? If not then that copyright
notice on the files is pretty pointless as it would have no legal
backing.

  Luis

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Gertjan van Wingerde]

Hi,

On 11/03/09 19:51, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> The following patch series (against wireless-next) addresses issues raised
> during code review and subsequently rejected by rt2x00/wireless/networking
> maintainers.
> 

This seems to be a misrepresentation of the situation. The issues raised by
you were acknowledged as being valid, however they were not deemed important
enough to stop inclusion in wireless-next and net-next.

However, it is good to see that you have put effort in providing a patch series
for these issues.

Now, since I believe that it is better to work with people, rather than against
them, would it be possible to post this patch series somewhere as a set of 
separate patches, so that they can be reviewed as such?

---
Gertjan
rt2x00 project developer


> 
> Namely, it:
> 
> - Adds abstraction of chipset register access for chipsets connected to
>   different buses by using new structure (struct rt2800_ops) which contains
>   all needed register access methods.
> 
>   [ It is a prerequisite for fixing code duplication between rt2800usb.c
>     and rt2800pci.c drivers. ]
> 
> - Fixes code duplication in rt2800usb.h and rt2800pci.h header files by
>   using new shared rt2800.h header (almost 1800 LOC gone).
> 
>   Updated debugging scripts are located here:
> 
>       http://www.kernel.org/pub/linux/kernel/people/bart/rt2800/scripts/
> 
>   (they also work fine with older drivers)
> 
> - Adds rt2800 library containing common code for PCI and USB versions
>   of rt2800 chipsets.  This removes over 1300 LOC and allows us to save
>   a lot of maintenance burden in the future. 
> 
> 
> It also fixes two real bugs (one in rt2800pci and one in rt2800usb) found
> as a direct result of the code de-duplication:
> 
> - Fix rt2800usb driver to write the rfcsr read request into RF_CSR_CFG
>   register and not BBP_CSR_CFG one in rt2800usb_rfcsr_read().
> 
> - Use the correct encryption key index for TX frames in rt2800pci (this is
>   based on rt2800usb patch from Benoit PAPILLAULT already in Linus' tree,
>   unfortunately the fix was not ported over to rt2800pci).
> 
>   [ There are also some minor code rt2x00 infrastructure fixes and improvements
>      here and there... ]
> 
> 
> All in all over 3100 LOC are gone and rt2800pci specific code is:
> 
>  1685 drivers/net/wireless/rt2x00/rt2800pci.c
>   180 drivers/net/wireless/rt2x00/rt2800pci.h
>  1865 total
> 
> instead of:
> 
>   3323 drivers/net/wireless/rt2x00/rt2800pci.c
>   1960 drivers/net/wireless/rt2x00/rt2800pci.h
>   5283 total
> 
>   (wireless-next and net-next trees)
> 
> which means decrease of the code needed for rt2800pci by 65% (this in turn
> translates to 31% decrease for rt2800 specific code and 9% for whole rt2x00
> infrastructure).
> 
> The rewrite was quite conservative and there is still a room for improvement
> but it should serve as a good starting base for all future work on rt2800
> drivers, and there is a lot to do there (both drivers are still practically
> non-functional).
> 
> Comments and patches are welcomed.
> 
> 
> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
>   Juuso Oikarinen (1):
>         wl1271: Generalize command response reading
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> 
> Bartlomiej Zolnierkiewicz (40):
>       rt2800usb: fix rt2800usb_rfcsr_read()
>       rt2800pci: fix crypto in TX frame
>       rt2800pci: fix comment about register access
>       rt2800pci: fix comment about IV/EIV fields
>       rt2x00: fix rt2x00usb_register_read() comment
>       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
>       rt2800usb: add rt2800_register_[read,write]() wrappers
>       rt2800pci: add rt2800_register_[read,write]() wrappers
>       rt2800usb: add rt2800_register_multi[read,write]() wrappers
>       rt2800pci: add rt2800_register_multi[read,write]() wrappers
>       rt2800usb: add rt2800_regbusy_read() wrapper
>       rt2800pci: add rt2800_regbusy_read() wrapper
>       rt2800usb: add rt2800_bbp_[read,write]() wrappers
>       rt2800pci: add rt2800_bbp_[read,write]() wrappers
>       rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800usb: add rt2800_rf_[read,write]() wrappers
>       rt2800pci: add rt2800_rf_[read,write]() wrappers
>       rt2800usb: add rt2800_mcu_request() wrapper
>       rt2800pci: add rt2800_mcu_request() wrapper
>       rt2x00: add driver private field to struct rt2x00_dev
>       rt2800usb: convert to use struct rt2800_ops methods
>       rt2800pci: convert to use struct rt2800_ops methods
>       rt2x00: fix rt2x00usb_register_multiwrite() arguments
>       rt2x00: fix rt2x00usb_regbusy_read() arguments
>       rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
>       rt2800: add rt2800lib.h
>       rt2800usb: fix comments in rt2800usb.h
>       rt2800usb: add RXINFO_DESC_SIZE definition
>       rt2800: fix duplication in header files
>       rt2800: fix comments in rt2800.h
>       rt2x00: add support for different chipset interfaces
>       rt2800: prepare for rt2800lib addition
>       rt2800: add rt2800lib (part one)
>       rt2x00: remove needless ifdefs from rt2x00leds.h
>       rt2800: add rt2800lib (part two)
>       rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
>       rt2800: add rt2800lib (part three)
>       rt2800: add rt2800lib (part four)
>       MAINTAINERS: add rt2800 entry
> 
>  MAINTAINERS                              |    7 +
>  drivers/net/wireless/rt2x00/Kconfig      |    5 +
>  drivers/net/wireless/rt2x00/Makefile     |    1 +
>  drivers/net/wireless/rt2x00/rt2800.h     | 1816 ++++++++++++++++++++++++++++
>  drivers/net/wireless/rt2x00/rt2800lib.c  | 1817 ++++++++++++++++++++++++++++
>  drivers/net/wireless/rt2x00/rt2800lib.h  |  134 +++
>  drivers/net/wireless/rt2x00/rt2800pci.c  | 1908 +++---------------------------
>  drivers/net/wireless/rt2x00/rt2800pci.h  | 1780 ----------------------------
>  drivers/net/wireless/rt2x00/rt2800usb.c  | 1828 ++---------------------------
>  drivers/net/wireless/rt2x00/rt2800usb.h  | 1818 +----------------------------
>  drivers/net/wireless/rt2x00/rt2x00.h     |   33 +
>  drivers/net/wireless/rt2x00/rt2x00leds.h |    4 -
>  drivers/net/wireless/rt2x00/rt2x00pci.h  |   24 +-
>  drivers/net/wireless/rt2x00/rt2x00usb.c  |    2 +-
>  drivers/net/wireless/rt2x00/rt2x00usb.h  |   17 +-
>  15 files changed, 4036 insertions(+), 7158 deletions(-)
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[Gertjan van Wingerde]

Hi,

On 11/03/09 19:51, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> The following patch series (against wireless-next) addresses issues raised
> during code review and subsequently rejected by rt2x00/wireless/networking
> maintainers.
> 

This seems to be a misrepresentation of the situation. The issues raised by
you were acknowledged as being valid, however they were not deemed important
enough to stop inclusion in wireless-next and net-next.

However, it is good to see that you have put effort in providing a patch series
for these issues.

Now, since I believe that it is better to work with people, rather than against
them, would it be possible to post this patch series somewhere as a set of 
separate patches, so that they can be reviewed as such?

---
Gertjan
rt2x00 project developer


> 
> Namely, it:
> 
> - Adds abstraction of chipset register access for chipsets connected to
>   different buses by using new structure (struct rt2800_ops) which contains
>   all needed register access methods.
> 
>   [ It is a prerequisite for fixing code duplication between rt2800usb.c
>     and rt2800pci.c drivers. ]
> 
> - Fixes code duplication in rt2800usb.h and rt2800pci.h header files by
>   using new shared rt2800.h header (almost 1800 LOC gone).
> 
>   Updated debugging scripts are located here:
> 
>       http://www.kernel.org/pub/linux/kernel/people/bart/rt2800/scripts/
> 
>   (they also work fine with older drivers)
> 
> - Adds rt2800 library containing common code for PCI and USB versions
>   of rt2800 chipsets.  This removes over 1300 LOC and allows us to save
>   a lot of maintenance burden in the future. 
> 
> 
> It also fixes two real bugs (one in rt2800pci and one in rt2800usb) found
> as a direct result of the code de-duplication:
> 
> - Fix rt2800usb driver to write the rfcsr read request into RF_CSR_CFG
>   register and not BBP_CSR_CFG one in rt2800usb_rfcsr_read().
> 
> - Use the correct encryption key index for TX frames in rt2800pci (this is
>   based on rt2800usb patch from Benoit PAPILLAULT already in Linus' tree,
>   unfortunately the fix was not ported over to rt2800pci).
> 
>   [ There are also some minor code rt2x00 infrastructure fixes and improvements
>      here and there... ]
> 
> 
> All in all over 3100 LOC are gone and rt2800pci specific code is:
> 
>  1685 drivers/net/wireless/rt2x00/rt2800pci.c
>   180 drivers/net/wireless/rt2x00/rt2800pci.h
>  1865 total
> 
> instead of:
> 
>   3323 drivers/net/wireless/rt2x00/rt2800pci.c
>   1960 drivers/net/wireless/rt2x00/rt2800pci.h
>   5283 total
> 
>   (wireless-next and net-next trees)
> 
> which means decrease of the code needed for rt2800pci by 65% (this in turn
> translates to 31% decrease for rt2800 specific code and 9% for whole rt2x00
> infrastructure).
> 
> The rewrite was quite conservative and there is still a room for improvement
> but it should serve as a good starting base for all future work on rt2800
> drivers, and there is a lot to do there (both drivers are still practically
> non-functional).
> 
> Comments and patches are welcomed.
> 
> 
> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
>   Juuso Oikarinen (1):
>         wl1271: Generalize command response reading
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
> 
> Bartlomiej Zolnierkiewicz (40):
>       rt2800usb: fix rt2800usb_rfcsr_read()
>       rt2800pci: fix crypto in TX frame
>       rt2800pci: fix comment about register access
>       rt2800pci: fix comment about IV/EIV fields
>       rt2x00: fix rt2x00usb_register_read() comment
>       rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
>       rt2800usb: add rt2800_register_[read,write]() wrappers
>       rt2800pci: add rt2800_register_[read,write]() wrappers
>       rt2800usb: add rt2800_register_multi[read,write]() wrappers
>       rt2800pci: add rt2800_register_multi[read,write]() wrappers
>       rt2800usb: add rt2800_regbusy_read() wrapper
>       rt2800pci: add rt2800_regbusy_read() wrapper
>       rt2800usb: add rt2800_bbp_[read,write]() wrappers
>       rt2800pci: add rt2800_bbp_[read,write]() wrappers
>       rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
>       rt2800usb: add rt2800_rf_[read,write]() wrappers
>       rt2800pci: add rt2800_rf_[read,write]() wrappers
>       rt2800usb: add rt2800_mcu_request() wrapper
>       rt2800pci: add rt2800_mcu_request() wrapper
>       rt2x00: add driver private field to struct rt2x00_dev
>       rt2800usb: convert to use struct rt2800_ops methods
>       rt2800pci: convert to use struct rt2800_ops methods
>       rt2x00: fix rt2x00usb_register_multiwrite() arguments
>       rt2x00: fix rt2x00usb_regbusy_read() arguments
>       rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
>       rt2800: add rt2800lib.h
>       rt2800usb: fix comments in rt2800usb.h
>       rt2800usb: add RXINFO_DESC_SIZE definition
>       rt2800: fix duplication in header files
>       rt2800: fix comments in rt2800.h
>       rt2x00: add support for different chipset interfaces
>       rt2800: prepare for rt2800lib addition
>       rt2800: add rt2800lib (part one)
>       rt2x00: remove needless ifdefs from rt2x00leds.h
>       rt2800: add rt2800lib (part two)
>       rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
>       rt2800: add rt2800lib (part three)
>       rt2800: add rt2800lib (part four)
>       MAINTAINERS: add rt2800 entry
> 
>  MAINTAINERS                              |    7 +
>  drivers/net/wireless/rt2x00/Kconfig      |    5 +
>  drivers/net/wireless/rt2x00/Makefile     |    1 +
>  drivers/net/wireless/rt2x00/rt2800.h     | 1816 ++++++++++++++++++++++++++++
>  drivers/net/wireless/rt2x00/rt2800lib.c  | 1817 ++++++++++++++++++++++++++++
>  drivers/net/wireless/rt2x00/rt2800lib.h  |  134 +++
>  drivers/net/wireless/rt2x00/rt2800pci.c  | 1908 +++---------------------------
>  drivers/net/wireless/rt2x00/rt2800pci.h  | 1780 ----------------------------
>  drivers/net/wireless/rt2x00/rt2800usb.c  | 1828 ++---------------------------
>  drivers/net/wireless/rt2x00/rt2800usb.h  | 1818 +----------------------------
>  drivers/net/wireless/rt2x00/rt2x00.h     |   33 +
>  drivers/net/wireless/rt2x00/rt2x00leds.h |    4 -
>  drivers/net/wireless/rt2x00/rt2x00pci.h  |   24 +-
>  drivers/net/wireless/rt2x00/rt2x00usb.c  |    2 +-
>  drivers/net/wireless/rt2x00/rt2x00usb.h  |   17 +-
>  15 files changed, 4036 insertions(+), 7158 deletions(-)
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
>  create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [announce] new rt2800 drivers for Ralink wireless & project tree

[John W. Linville]

On Tue, Nov 03, 2009 at 10:01:09PM +0100, Gertjan van Wingerde wrote:

> However, it is good to see that you have put effort in providing a patch series
> for these issues.

Yes, indeed.  Thanks to Bart for making patches available!

> Now, since I believe that it is better to work with people, rather than against
> them, would it be possible to post this patch series somewhere as a set of 
> separate patches, so that they can be reviewed as such?

I must echo this request.

Thanks!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.