* Re: Please consider reverting 7d930bc33653d5592dc386a76a38f39c2e962344
From: Luis R. Rodriguez @ 2009-11-03 17:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Marcel Holtmann, Dmitry Torokhov, David Miller,
johannes, linville, linux-kernel, linux-wireless
In-Reply-To: <alpine.LFD.2.01.0911030930130.31845@localhost.localdomain>
On Tue, Nov 3, 2009 at 9:37 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Tue, 3 Nov 2009, Luis R. Rodriguez wrote:
>>
>> How this sort of issue is dealt with is subjective and it is up to
>> maintainers to deal with.
>
> Not when they then complain when others hit the same issue several days
> later.
>
>> Having more information on the patch and better communication about
>> the issue it solved, and the issues that reverting it would have
>> caused would certainly have helped maintainers make a better call at a
>> regression caused by it but knowing Johannes he'd probably cook up a
>> followup fix ASAP and that is exactly what he did.
>
> He may have cooked it up, but he didn't send it to me, and he didn't even
> bother to post it as a response to people who complained about the same
> commit.
>
> The fact that people on the wireless mailing lists may have known about
> this just makes things _worse_, I think. It shows that we really _need_ to
> go around maintainers, when not going around them seems to result in days
> of delays and total waste of time for everybody.
Well I wouldn't quite say that. Me and Johannes know about it, I
cannot say everyone else who reads linux-wireless understood the
issue. I was trying to explain that the root cause of this whole issue
was non-obvious and even when I found a fix that worked for me it
turned out that wasn't the "proper" solution. So in reality the only
one who probably really understood this issue inside out and backwards
was Johannes.
Luis
^ permalink raw reply
* Re: ath5k and ".local" dropout
From: John W. Linville @ 2009-11-03 18:00 UTC (permalink / raw)
To: CSights; +Cc: linux-wireless
In-Reply-To: <200911021907.16271.csights@fastmail.fm>
On Mon, Nov 02, 2009 at 07:07:16PM -0500, CSights wrote:
> Hello,
> I'm having a problem with the ath5k module found in kernel 2.6.31.5 and
> accessing ".local" addresses on the network.
> What I've observed so far is that when I first boot the computer I can
> successfully access (e.g. ping) other .local computers. If the computer with
> the ath5k card sits for a few minutes I can no longer access .local
> computers. (Trying to ping, ping returns "ping: unknown host") Also, other
> computers on the network can no longer ping the ath5k computer (also "ping:
> unknown host")
> Pinging the .local computers by their IP address (e.g. 192.168.1.3) does
> work.
> Access to computers "on the internet" (e.g. www.case.edu) also works.
Curious...if you ping a .local address before the failure, it is
still accessible after other .local addresses become unavailable?
I'm wondering if mdns results might be cached...
The .local address relationship suggests multicast DNS, which suggests
that ath5k might have a problem where it stops receiving multicast
frames. Does this "ring any bells" for anyone?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: ath5k and ".local" dropout
From: Bob Copeland @ 2009-11-03 18:54 UTC (permalink / raw)
To: John W. Linville; +Cc: CSights, linux-wireless
In-Reply-To: <20091103180055.GC4839@tuxdriver.com>
On Tue, Nov 3, 2009 at 1:00 PM, John W. Linville <linville@tuxdriver.com> wrote:
>
> The .local address relationship suggests multicast DNS, which suggests
> that ath5k might have a problem where it stops receiving multicast
> frames. Does this "ring any bells" for anyone?
Yeah in fact I posted a patch to ath5k-devel but forgot to copy
linux-wireless. :)
We zero out the mcast filter for some reason, I'm not sure why. Maybe missing
tildes in front of the zeroes or something.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k and ".local" dropout
From: John W. Linville @ 2009-11-03 19:01 UTC (permalink / raw)
To: Bob Copeland; +Cc: CSights, linux-wireless
In-Reply-To: <b6c5339f0911031054g13443c17ma925014fb9b16ab8@mail.gmail.com>
On Tue, Nov 03, 2009 at 01:54:10PM -0500, Bob Copeland wrote:
> On Tue, Nov 3, 2009 at 1:00 PM, John W. Linville <linville@tuxdriver.com> wrote:
> >
> > The .local address relationship suggests multicast DNS, which suggests
> > that ath5k might have a problem where it stops receiving multicast
> > frames. Does this "ring any bells" for anyone?
>
> Yeah in fact I posted a patch to ath5k-devel but forgot to copy
> linux-wireless. :)
>
> We zero out the mcast filter for some reason, I'm not sure why. Maybe missing
> tildes in front of the zeroes or something.
Any feedback on that patch? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: ath5k and ".local" dropout
From: Bob Copeland @ 2009-11-03 19:25 UTC (permalink / raw)
To: John W. Linville; +Cc: CSights, linux-wireless
In-Reply-To: <20091103190149.GE4839@tuxdriver.com>
On Tue, Nov 03, 2009 at 02:01:49PM -0500, John W. Linville wrote:
> > We zero out the mcast filter for some reason, I'm not sure why. Maybe
> > missing tildes in front of the zeroes or something.
>
> Any feedback on that patch? :-)
Positive, so far. Saving CSights the trouble of requoting :) I'll push it
unless C pops up with "any other problem"...
> > diff --git a/drivers/net/wireless/ath/ath5k/base.c
> > b/drivers/net/wireless/ath/ath5k/base.c index 1287ded..1e6e0b6 100644
> > --- a/drivers/net/wireless/ath/ath5k/base.c
> > +++ b/drivers/net/wireless/ath/ath5k/base.c
> > @@ -1125,7 +1125,6 @@ ath5k_mode_setup(struct ath5k_softc *sc)
> > /* configure operational mode */
> > ath5k_hw_set_opmode(ah);
> >
> > - ath5k_hw_set_mcast_filter(ah, 0, 0);
> > ATH5K_DBG(sc, ATH5K_DEBUG_MODE, "RX filter 0x%x\n", rfilt);
> > }
>
> YES!
> At least I am able to ping for longer than 2 minutes. :) I'll keep
> running the modified code and see if any other problem crops up.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k AP issues
From: Bob Copeland @ 2009-11-03 19:27 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez,
ath9k-devel
In-Reply-To: <40f31dec0911021336l45d185fewa5ce1ffb88f7db97@mail.gmail.com>
On Mon, Nov 02, 2009 at 11:36:22PM +0200, Nick Kossifidis wrote:
> Well let's enable them both :P
>
> I still think that ready-time thing is evil, we should use a more accurate
> way.
I don't follow, you want to try both DBA and BCN_SENT to see what happens
(with/without ready-time)?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 18:51 UTC (permalink / raw)
To: linux-wireless
Cc: linux-kernel, netdev, Ivo van Doorn, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
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
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 19:59 UTC (permalink / raw)
To: Ivo van Doorn
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911021943.12069.IvDoorn@gmail.com>
On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> Well and then another rt2x00 developer discovered this nice little
> fight about rt2x00 on the mailinglists...
>
> First for the record, because at the start people where talking about the
> maintainership of rt2x00, one thing needs to be straight:
>
> As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> drivers/net/wireless/rt2x00 folder.
>
> At this time I am hold the position within the rt2x00 team which is making the
> decisions about the rt2x00 code and design.
rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
This is not how things work here, sorry.
> I am also the one that is (N)Acks the patches from others when they are send
> to the rt2x00-users or linux-wireless mailinglist.
If you are not willing to stand behind your own patches, how do you expect
others to trust your judgment?
> As for my behavior in discussions:
>
> I am doing my best to listen to all complains regarding the rt2x00 code and design and
> improve it if the complainer has a valid point. However, obviously I can disagree with
> the complainer and in that case I will explain to that person _why_ I disagree. It is up
> to the complainer to convince me that he is right, agree with my response, or whine.
>
> Now as for more specific responses:
>
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > rt2800 drivers have their maintainers and I would like to know what they
> > are doing besides complaining about users and staging tree..
>
> Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> But I guess you mean rt2x00 specific work?
> Well that list consists of:
> - Listening to people complain
> - Responding to those people, because otherwise they complain that they are being ignored.
> - Following bug reports, and request testing or additional information if required
> - Bugfixing
> - Reviewing patches from contributors
> - Applying patches from contributors
> - Discussing improvements over patches from contributors
>
> Well nothing of this list should be new to you, but apparently you needed some confirmation.
I meant rt2800 support specifically, sorry if this was not clear.
The work on rt2800 drivers was started in the beginning of 2008 and after
few months you were already behind deadlines that you had set yourself:
http://markmail.org/message/a753dws6tqytb3a4
During almost two years rt2x00 project didn't manage to produce working
support for rt2800.. in the meantime the world has moved on and we have
another chipset generation (rt30x0) to worry about, and also rt33xx one
on the horizon..
> On Thursday 29 October 2009, Johannes Berg wrote:
> > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> >
> > > In case you're concerned, I actually agree with John and others
> > > on this issue, and disagree with your position.
> >
> > In this particular case, I think it makes more sense to duplicate the
> > code _especially_ because it's not working yet. That frees people
> > hacking on it of having to worry about breaking other devices.
>
> Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> in the previous discussion.
Nope, it just adds needles development/maintenance burden since it will
make people lose fixes already applied to the working code, please see my
other mail.
> On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > I find it rather disappointing that all my review comments regarding
> > rt2800pci support were just completely ignored and then the initial
> > patch was merged just as it was..
>
> Your code review comments were commented upon with my reasons
> why this code duplication exists. I even admitted that when the time is
> ready I will remove the code duplication.
The right time was two years ago when you were starting working on those
drivers. IOW It shouldn't have happened in the first place.
I also have serious questions about transparency of the process and cannot
understand why it takes so long for the code to be pushed upstream.
commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
tree back in September (you're re-basing rt2x00 tree at random moments so it
is impossible to track the status of patches that you are handling).
rt2800pci patch itself has been getting dust in your tree since at least
April (it hasn't received any bigger updates since then)..
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > Quite the contrary, I'm pretty confident that addressing my review concerns
> > would result in better RT28x00 / RT30x0 support in the very near future.
>
> The review concerns regarding the duplicate code would only reduce the
> amount of code. It would not magically fix bugs (at least the chance of that
> would be quite small).
Please see my other mail.
> So far rt2800usb performs better then rt2800pci, and the difference gets
> only bigger when I use the exact same register initialization from rt2800usb
> in rt2800pci.
>
> But Bartjmoiej knows that the register initialization can be exactly the same,
> from his experience with the staging drivers.
> So far hasn't been interested in sharing the knowledge in what must be
> changed in rt2800pci/usb to make them both work with the same register
> initialization.
The knowledge is all in your local copy of linux-next (I don't memorize
things like chipset initialization sequences) and in the review comments
that you have happily dismissed.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-03 20:18 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-usb, linux-wireless
In-Reply-To: <1257193115.1027.24.camel@localhost.localdomain>
Dan Williams schrieb:
> On Mon, 2009-11-02 at 21:10 +0100, Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
>>>
>>>> Josua Dietze schrieb:
>>>>
>>>>> Frank Schaefer schrieb:
>>>>>
>>>>>
>>>>>> I really think the mode-switching should be done in the kernel and not
>>>>>> in user-space for reasons of usability.
>>>>>>
>>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>>> command line tool work as well?
>>>>>
>>>> It returns an error but the device is ejected.
>>>> But do you really want the users to open a terminal window and call
>>>> "eject" each time they plug their device in ;) ?
>>>>
>>> If 'eject' worked, then why not use a simple udev entry? That way nobody
>>> has to call anything by hand...
>>>
>>> Matt
>>>
>> And who will create this udev-entry ;) ? How can you make sure that this
>> is done on all systems ?
>>
>
> You can't. The distros have to make sure it works.
Right, and here the trouble begins.
The driver and the mode-switch needed to use it must come from the same
source.
Otherwise we will always have inconsistencies.
> Personally, I think
> these should all be in the kernel, but the kernel doesn't contain
> policy. And unfortunately, for some devices (3G modems specifically)
> ejecting the driver CD thing *is* policy.
Hmm, policy...
Talking about the large group of devices with a driver-disk-mode only:
Isn't an installed driver for the device the policy itself, because it
makes the driver-disk obsolete !?
> Option for example protested
> mightily when I sent a patch to auto-eject their driver CD, because they
> apparently do use the driver CD thing to send Linux drivers and software
> to a few clients. But by and large, the driver CD is completely
> useless.
>
> Devices with fake driver CDs and how they are handled currently:
>
> Zydas WLAN - kernel
> Huawei 3G - kernel (unusual_devs entry)
> Sierra 3G - kernel (drivers/usb/serial/sierra.c)
> Option 3G - udev rules, 'rezero', or usb_modeswitch
> ZTE 3G - udev rules, simple 'eject'
>
> Dan
>
I can't see any real problems having device-(group-)specific policies
and switching-solutions.
Of course, it would be nice to have a common solution for all, but the
devices are too different.
Therefore the compromises we have to make should be individual (to a
certain degree).
Frank
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-03 20:32 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911032059.23409.bzolnier@gmail.com>
On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> > Well and then another rt2x00 developer discovered this nice little
> > fight about rt2x00 on the mailinglists...
> >
> > First for the record, because at the start people where talking about the
> > maintainership of rt2x00, one thing needs to be straight:
> >
> > As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> > for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> > drivers/net/wireless/rt2x00 folder.
> >
> > At this time I am hold the position within the rt2x00 team which is making the
> > decisions about the rt2x00 code and design.
>
> rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
You really have problems reading mails, haven't you? Or at least you
only want to read what you want to read...
Please READ the paragraph again.
I will highlight the thing again:
"about the rt2x00 code and design"
I am not talking about Ralink support I am talking about RT2X00 support.
If you feel that the maintainer of a particular driver has no say about the driver
he wrote himself, then I am not seeing the point of having maintainers. We can
then all just randomly hack in all drivers without any form of structure.
> > I am also the one that is (N)Acks the patches from others when they are send
> > to the rt2x00-users or linux-wireless mailinglist.
>
> If you are not willing to stand behind your own patches, how do you expect
> others to trust your judgment?
Ehm, please explain? I am sending patches upstream, but apparently I don't stand behind them?
Then why the f*** am I sending them?
> > As for my behavior in discussions:
> >
> > I am doing my best to listen to all complains regarding the rt2x00 code and design and
> > improve it if the complainer has a valid point. However, obviously I can disagree with
> > the complainer and in that case I will explain to that person _why_ I disagree. It is up
> > to the complainer to convince me that he is right, agree with my response, or whine.
> >
> > Now as for more specific responses:
> >
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > rt2800 drivers have their maintainers and I would like to know what they
> > > are doing besides complaining about users and staging tree..
> >
> > Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> > But I guess you mean rt2x00 specific work?
> > Well that list consists of:
> > - Listening to people complain
> > - Responding to those people, because otherwise they complain that they are being ignored.
> > - Following bug reports, and request testing or additional information if required
> > - Bugfixing
> > - Reviewing patches from contributors
> > - Applying patches from contributors
> > - Discussing improvements over patches from contributors
> >
> > Well nothing of this list should be new to you, but apparently you needed some confirmation.
>
> I meant rt2800 support specifically, sorry if this was not clear.
>
> The work on rt2800 drivers was started in the beginning of 2008 and after
> few months you were already behind deadlines that you had set yourself:
>
> http://markmail.org/message/a753dws6tqytb3a4
>
> During almost two years rt2x00 project didn't manage to produce working
> support for rt2800.. in the meantime the world has moved on and we have
> another chipset generation (rt30x0) to worry about, and also rt33xx one
> on the horizon..
And thank you for your valuable effort in assisting in the driver development
during those 2 years. I am really happy about people looking from the sideline
and complaining things are not moving as fast as they would like it.
If you cared about the slow progress, then you had the past 2 years to help out,
but apparently that is too much to ask. Unfortunately a lot of people think like
you, which means that during those 2 years dozens of people have complained
about the lack of progress without any of them helping out (and I am not talking
about users only, I am also talking about people who have programming skills).
If you look at the Signed-off list of the rt2800pci/usb patches you will see that
only a handfull of people actually helped.
> > On Thursday 29 October 2009, Johannes Berg wrote:
> > > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> > >
> > > > In case you're concerned, I actually agree with John and others
> > > > on this issue, and disagree with your position.
> > >
> > > In this particular case, I think it makes more sense to duplicate the
> > > code _especially_ because it's not working yet. That frees people
> > > hacking on it of having to worry about breaking other devices.t initialization sequences) and in the review
> >
> > Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> > in the previous discussion.
>
> Nope, it just adds needles development/maintenance burden since it will
> make people lose fixes already applied to the working code, please see my
> other mail.
As mentioned in my mail, there were differences in the drivers during development,
and I had a working rt2800usb driver as base. But with the same settings the rt2800pci
couldn't get to work.
With the merged drivers you would constantly need to check if it works for rt2800pci,
but also if you haven't broken rt2800usb in the meantime. This way rt2800usb was
able to be merged months before rt2800pci because there was no common code.
Once both drivers are solid working, then there are no problems with merging them,
I wonder how many times I have to repeat that...
> > On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > I find it rather disappointing that all my review comments regarding
> > > rt2800pci support were just completely ignored and then the initial
> > > patch was merged just as it was..
> >
> > Your code review comments were commented upon with my reasons
> > why this code duplication exists. I even admitted that when the time is
> > ready I will remove the code duplication.
>
> The right time was two years ago when you were starting working on those
> drivers. IOW It shouldn't have happened in the first place.
Please see my other mail, please read my above comment, and thank you again
for participating in the rt2800 development of those 2 years.
> I also have serious questions about transparency of the process and cannot
> understand why it takes so long for the code to be pushed upstream.
So you start looking now, and complain you can't see the process of the last 2 years?
There have been dozens of status reports regarding rt2800, and the number of responses
in general have always been limited.
But now I reread that last sentence, you are complaining that rt2800pci wasn't pushed
upstream earlier? While this whole discussion is about that merging rt2800pci was a bad
idea?
> commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
> tree back in September (you're re-basing rt2x00 tree at random moments so it
> is impossible to track the status of patches that you are handling).
I'm missing the point here.
> rt2800pci patch itself has been getting dust in your tree since at least
> April (it hasn't received any bigger updates since then)..
And how many times do I have to repeat the reason?
I think that after dozens of mails, the message should have been clear, especially
to somebody who apparently has been monitoring and worrying about the development
process for the last 2 years....
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > Quite the contrary, I'm pretty confident that addressing my review concerns
> > > would result in better RT28x00 / RT30x0 support in the very near future.
> >
> > The review concerns regarding the duplicate code would only reduce the
> > amount of code. It would not magically fix bugs (at least the chance of that
> > would be quite small).
>
> Please see my other mail.
And did your patches make rt2800pci work better?
Does rt2800usb suddenly work for 11n networks?
> > So far rt2800usb performs better then rt2800pci, and the difference gets
> > only bigger when I use the exact same register initialization from rt2800usb
> > in rt2800pci.
> >
> > But Bartjmoiej knows that the register initialization can be exactly the same,
> > from his experience with the staging drivers.
> > So far hasn't been interested in sharing the knowledge in what must be
> > changed in rt2800pci/usb to make them both work with the same register
> > initialization.
>
> The knowledge is all in your local copy of linux-next (I don't memorize
> things like chipset initialization sequences) and in the review comments
> that you have happily dismissed.
Your review comments were regarding _moving_ code to a generic stack
for rt2800pci and rt2800usb while I already indicated that would not improve
the status of rt2800pci (instead it would make it worse, since I already tested
if those settings would work). But apparently merging the code is better then
fixing the code.
Ivo
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-03 20:22 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-usb, linux-wireless
In-Reply-To: <1257198359.1027.67.camel@localhost.localdomain>
Dan Williams schrieb:
> ...
> Maybe there's a better way as I said a bit lower in the thread; could we
> put the logic for ejection into the driver (and not usb_modeswitch or
> whatever) but put the decision into userspace in udev?
>
> Right now the kernel drivers know what hardware they support, and that's
> a great place to also put how to eject the fake driver CD. So the
> mechanism could live in the kernel still (instead of in usb_modeswitch
> in userspace) while the actual decision still gets made in userspace
> with udev rules. The rules would say something like "if this USB
> storage device has an 'fakecd' attribute, then touch the 'ejectmeharder'
> attribute" instead of complex rules to run usb_modeswitch that duplicate
> all the device IDs in userspace. If you need to rummage around on the
> driver CD for whatever reason, you disable the udev rule. Maybe?
> ...
That would make system-configuration much easier and would also reduce
the work for the distros.
Mode-switch-tools would be much easier to maintain, too.
How do you want to implement this policy-hint ?
Frank
^ permalink raw reply
* Re: ath5k AP issues
From: Nick Kossifidis @ 2009-11-03 20:44 UTC (permalink / raw)
To: Bob Copeland
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez,
ath9k-devel
In-Reply-To: <20091103192735.GA11145@hash.localnet>
2009/11/3 Bob Copeland <me@bobcopeland.com>:
> On Mon, Nov 02, 2009 at 11:36:22PM +0200, Nick Kossifidis wrote:
>> Well let's enable them both :P
>>
>> I still think that ready-time thing is evil, we should use a more accurate
>> way.
>
> I don't follow, you want to try both DBA and BCN_SENT to see what happens
> (with/without ready-time)?
>
Yup, without ready-time.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-03 20:33 UTC (permalink / raw)
To: Matthew Dharm, linux-wireless, linux-usb
In-Reply-To: <20091102211001.GH24436@one-eyed-alien.net>
Matthew Dharm schrieb:
> On Mon, Nov 02, 2009 at 09:07:20PM +0100, Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> I am thinking about the users. Do you really think someone who has
>>> difficulty installing a new udev rule (probably a line or two of text
>>> copied from a google search) or installing a new version of usb_modeswitch
>>> (probably one or two commands to the distro package manager) will have an
>>> easier time doing a custom kernel-compile and update?
>>>
>> I think users should not need to do ANY of these things ! That's called
>> usability.
>>
>
> So, new hardware should "magically" work? When you can write software to
> support hardware that doesn't exist yet, let me know.
>
I can make nothing of that.
It really doesn't make sense to discuss about mode-switches for devices
for which we not even have a driver.
>> Which users do you think know how to create udev-rules and how to
>> compile a kernel ?
>> Of course you and me and likely all others on this mailing-list and
>> maybe you think Linux should be for them, only.
>>
>> I think we should do as much as possible to improve Linux-usability for
>> "normal" and even "less experienced" users.
>>
>
> Okay, let's talk about "less experienced" users. Suppose you are one of
> these users. You get a new device, and you want to use it. You do some
> web searching, and discover either:
>
> (a) you need to download and recompile your kernel
> (b) you need to cut-and-paste some text from a web page into a file
>
> Which do you think is easier?
>
It's easier to let the driver/kernel do the mode-switch automatically if
it makes sense !
That's perfect Plug'N Play and (a) and (b) are dispensable.
Apart from that, I think that "just cut-and-paste some text from a web
page into a file" is an illusion.
Starts with the right key-words you need for the search and continues
with the quality of the documentation.
It's not that easy to create universal and especially complete manuals
(we all love documentation-work right !? ;) ).
For example: what's udev ? Of course, WE know, but ...
> And, the situation above pre-supposes that the requisite changes (kernel or
> userspace) haven't already been picked up by a distro maintainer.
>
>
>> And in this case, it would be really easy.
>>
>>> Updates in userspace are universally easier; on users, on kernel deves, and
>>> on distro devs.
>>>
>>>
>> Why ? Of course, the benfit for kernel-developers is that the work is
>> done by others...
>> But for the distros it makes life much more difficult in many respects.
>>
>
> I highly doubt this. Distros must very carefully test all the kernel
> changes they decide to pull in. Each and every change in a kernel-layer is
> a high-risk change for them. Changing userspace packages is much
> lower-risk, and thus consumes correspondingly fewer resources.
>
>
And they don't have to test userspace-software carefully, too ???
Especially sysconfig-software ?
I can't see a significant difference here.
>> And users are in the somehow insane situation that they have to keep the
>> driver (kernel) AND the "key to be able to use it" up-to-date.
>> That's not only a problem because they both things from different
>> sources/directions !
>>
>
> I think you may have missed part of an earlier discussion, wherein we
> discussed such devices which would NOT need ANY kernel changes. The idea
> was that udev could "eject" the fake-USB device, then add the device IDs to
> the serial/cdc_amc/whatever driver dynamically, at runtime. Thus, no need
> to make any kernel updates at all.
>
> And, that system works *today* with the existing kernel code.
>
> Matt
>
You didn't understand me right. No problem.
I was talking about inconsistencies we get when driver and the
mode-switch-part come from different sources.
That's one of the main problems in Unix-world, maybe that's the price we
have to pay for thinking more modular (packages) than in products like
in M$-world.
But we shouldn't pay that price needlessly because of splitting things
at the wrong position.
Frank
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ivo van Doorn @ 2009-11-03 21:00 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911031951.05235.bzolnier@gmail.com>
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
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-03 20:42 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, linux-wireless
In-Reply-To: <Pine.LNX.4.44L0.0911031001470.10778-100000@netrider.rowland.org>
Alan Stern schrieb:
> On Mon, 2 Nov 2009, Dan Williams wrote
>> In userspace, usb_modeswitch is the place to put all this logic. Then
>> you tie it together with udev rules using some bubble-gum and duct-tape,
>> and maybe it works. Of course, there's massive duplication of data
>> between usb_modeswitch and the kernel drivers, because the there's
>> simply no communication between the two.
>>
> The only reason for this "massive" duplication is that nobody has
> bothered to remove from the kernel the parts that usb_modeswitch can
> handle. Adding yet more switching code into the kernel, thereby
> _increasing_ the amount of duplication, seems like a bad idea.
>
Or the other way around ;) .
Of course, we all don't want any duplicate code. We need a kernelspace
OR a userspace-solution.
But we should make pragmatic and device-(group-)specific decisions.
The hardware itself and the context in which it is used (=>
switch-policy) are too different.
...
> ... Jobs that can be handled
> in userspace _should_ be handled there.
>
> Alan Stern
>
Basically, I have no problem to agree here.
But what's the price we pay for this solution(s) in this case (and most
other devices with windows-driver-disc-mode) ?
You should not ignore the problems coming-up with the discussed
userspace-solutions.
This is not ONLY about technical aspects. We already discussed usability
and maintanance. Think about the whole product, not only the kernel-part.
Then, please, make a list of ALL pros and cons a make a pragmatic decision.
Frank
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Gertjan van Wingerde @ 2009-11-03 21:01 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, linux-kernel, netdev, Ivo van Doorn, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911031951.05235.bzolnier@gmail.com>
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
>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 21:04 UTC (permalink / raw)
To: Ivo van Doorn
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911032132.31533.IvDoorn@gmail.com>
On Tuesday 03 November 2009 21:32:30 Ivo van Doorn wrote:
> > rt2800pci patch itself has been getting dust in your tree since at least
> > April (it hasn't received any bigger updates since then)..
>
> And how many times do I have to repeat the reason?
> I think that after dozens of mails, the message should have been clear, especially
> to somebody who apparently has been monitoring and worrying about the development
> process for the last 2 years....
Just for the record:
I got only interested in rt2x00 support around April this year (while I was
doing major staging cleanups everywhere) and I was hearing back then that
rt2800pci will be merged "really soon" and that the project is making "great
progress"..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 21:44 UTC (permalink / raw)
To: Ivo van Doorn
Cc: linux-wireless, linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911032200.04516.IvDoorn@gmail.com>
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
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ivo van Doorn @ 2009-11-03 22:01 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911032244.11946.bzolnier@gmail.com>
> > > 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
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 22:34 UTC (permalink / raw)
To: Ivo van Doorn
Cc: linux-wireless, linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911032301.32907.IvDoorn@gmail.com>
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
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Alan Stern @ 2009-11-03 22:47 UTC (permalink / raw)
To: Oliver Neukum
Cc: Dan Williams, Matthew Dharm, Frank Schaefer, linux-wireless,
linux-usb
In-Reply-To: <200911031729.26463.oliver@neukum.org>
On Tue, 3 Nov 2009, Oliver Neukum wrote:
> > I'm with Matt Dharm and Josua Dietze on this. Jobs that can be handled
> > in userspace _should_ be handled there.
>
> There is the inconvenient problem of hibernation. And, if more systems
> start cutting power to USB in STR, the problem of STR. I am inclined
> to declare that hibernation is a problem of those pesky misdesigns.
> But dare we say that also about STR?
If power is turned off, there's nothing we can do about it. Once that
happens, it doesn't make much difference whether the mode switch occurs
in usb-storage or from a userspace program. The old device instance
will go away and a new one will appear.
Alan Stern
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Gertjan van Wingerde @ 2009-11-03 23:09 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Ivo van Doorn, linux-wireless, linux-kernel, netdev, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911032334.40547.bzolnier@gmail.com>
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.
,
^ permalink raw reply
* Re: [Bugme-new] [Bug 14450] New: [2.6.31] Network interfaces are dead with 2.6.31 (iwlagn and sky2)
From: Andrew Morton @ 2009-11-03 23:21 UTC (permalink / raw)
To: orion.linbug
Cc: bugzilla-daemon, bugme-daemon, netdev, linux-acpi,
Rafael J. Wysocki, linux-wireless
In-Reply-To: <bug-14450-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 21 Oct 2009 07:30:12 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14450
>
> Summary: [2.6.31] Network interfaces are dead with 2.6.31
> (iwlagn and sky2)
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.31
Rafael, this is a 2.6.30->2.6.31 regression.
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: orion.linbug@gmail.com
> Regression: Yes
>
>
> My wireless and ethernet networks are dead with the kernel 2.6.31. All work
> very fine with the 2.6.30 and older. I have a Toshiba laptop wich uses the
> iwlagn module for wireless and the sky2 for ethernet. I have tested with
> acpi=off in the grub kernel line but it freezes the system on boot...
> ifconfig gets only the lo interface. ifconfig eth0 or wlan0 up gets something
> like "the interface doesn't exist".
>
> lspci shows:
> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
> Controller Hub (rev 07)
> 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express
> Graphics Port (rev 07)
> 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #4 (rev 03)
> 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #5 (rev 03)
> 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #6 (rev 03)
> 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #2 (rev 03)
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1
> (rev 03)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2
> (rev 03)
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4
> (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
> Controller #3 (rev 03)
> 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
> Controller #1 (rev 03)
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
> 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev
> 03)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
> 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD
> 4500 Series]
> 01:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000
> Series]
> 02:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
> 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040T PCI-E Fast
> Ethernet Controller (rev 12)
> 0a:01.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
> 0a:01.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev
> 02)
> 0a:01.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller
> (rev 01)
>
> Dmesg shows errors on sky2 and iwlagn driver:
> iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks2009-10-13
> 17:57:36
> iwlagn: Copyright(c) 2003-2009 Intel Corporation2009-10-13 17:57:36
> iwlagn 0000:02:00.0: enabling device (0000 -> 0002)2009-10-13 17:57:36
> iwlagn 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 162009-10-13
> 17:57:36
> iwlagn 0000:02:00.0: Detected Intel Wireless WiFi Link 5100AGN
> REV=0xFFFFFFFF2009-10-13 17:57:36
> Clocksource tsc unstable (delta = -212055894 ns)2009-10-13 17:57:36
> iwlagn 0000:02:00.0: Failed, HW not ready2009-10-13 17:57:36
> iwlagn 0000:02:00.0: PCI INT A disabled2009-10-13 17:57:36
>
> sky2 driver version 1.232009-10-13 17:50:48
> sky2 0000:03:00.0: enabling device (0000 -> 0003)2009-10-13 17:50:48
> sky2 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 172009-10-13
> 17:50:48
> sky2 0000:03:00.0: PCI INT A disabled2009-10-13 17:50:48
> sky2: probe of 0000:03:00.0 failed with error -952009-10-13 17:50:48
Given that both the wired and wireless interfaces failed, I'd assume
that something went wrong at the bus level. Perhaps due to an ACPI
change.
Could the sky2, iwlagn and ACPI developers please take a look, offer an
opinion as to where we should be looking?
Thanks.
^ permalink raw reply
* Possible fix for rtl8187: kernel oops when leds enabled
From: Larry Finger @ 2009-11-03 23:22 UTC (permalink / raw)
To: Richard Farina; +Cc: wireless, Hin-Tak Leung, Herton Ronaldo Krzesinski
In-Reply-To: <4AE5CDCB.8090400@gmail.com>
Rick,
Does this patch fix your problem? I tried to bisect this problem as it
looked like a regression; however, the problem was sometimes a little
flakey. On one boot of a given kernel, it might run for 3-400 cycles
without failing, then fail immediately after rebooting. I suspect that
the random contents of some memory location would control that.
This patch was inspired by the code in p54usb, which does not have the
problem.
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_
/* turn the LED off before exiting */
ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
- cancel_delayed_work_sync(&priv->led_off);
- cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
rtl8187_unregister_led(&priv->led_tx);
+ cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
}
#endif /* def CONFIG_RTL8187_LED */
Thanks for testing,
Larry
^ permalink raw reply
* iwlwifi connection troubles, maybe aggregation related
From: Andrew Lutomirski @ 2009-11-03 23:38 UTC (permalink / raw)
To: linux-wireless, ilw
Hi all-
My laptop (Intel 5350) has trouble using the wireless networks here.
I'm at MIT, which has a bunch of Cisco 1250 AP's (dual-band, MIMO,
etc). Running Windows, everything works perfectly. On Linux
(2.6.31-rc5, but I've seen problems with other, older kernels as
well), it sometimes works, but I frequently find the network almost
completely unusable. I can associate and ping just fine, but, as soon
as I try to send any significant amount of data, I can no longer
transmit. I can still receive both broadcast and unicast frames, but
the network doesn't see anything I send. An older laptop (presumably
with 4965,
This seems to be correlated with a line like:
iwlagn 0000:03:00.0: iwl_tx_agg_start on ra = 00:21:d8:49:4a:52 tid = 0
appearing in dmesg.
Running "iw dev wlan0 disconnect" will make the connection start
working until I try to send data again (presumably because either NM
or wpa_supplicant will reassociate).
Turning on or off power management and fiddling with
no_sleep_autoadjust makes no difference. Setting tx_agg_tid_enable to
zero in debugfs while the connection was working seemed to make it a
little more reliable (it lasted long enough to do "git pull" but not
much longer).
After running "iw dev wlan0 disconnect" a few times, I start to get
errors like this:
[18078.209635] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
[18078.313461] iwlagn 0000:03:00.0: No space for Tx
[18078.313467] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
enqueue_hcmd failed: -28
[18078.313470] iwlagn 0000:03:00.0: SENSITIVITY_CMD failed
[18078.522409] iwlagn 0000:03:00.0: No space for Tx
[18078.522414] iwlagn 0000:03:00.0: Error sending SENSITIVITY_CMD:
enqueue_hcmd failed: -28
The driver doesn't recover until I do "echo 1 >
/sys/kernel/debug/ieee80211/phy0/reset" Oddly enough, after resetting
just now, I couldn't trigger the failure again, even though it was
100% reproducible before resetting.
Thanks,
Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox