Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik <jeff@garzik.org>]

Michael Buesch wrote:
> On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
>> Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
>> grepping for udelay in bcm43xx_radio.c shows some of the worst 
>> offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
>> both look like candidates for using msleep() rather than udelay().
> 
> This is _all_ at initialization time.
> select_channel.... How often do you select a channel?

That question is irrelevant, because you have no idea what -else- is 
going on in the system, at the point when bcm43xx chooses to spin the 
CPU heavily.

Initialization time means you are definitely not in a hot path, and can 
therefore sleep.


> I recently reworked the periodically exectuted workhandlers,
> so that they are preemptible.

Major classes of users run their kernels without preempt.  Please don't 
depend on that to avoid bad behavior.


> mac_suspend():
> It is always called in atomic context with IRQs disabled.
> We need to wait for the device here to signal "OK, MAC is down
> now and you can count on it". This takes a few usecs. I guess
> it sends out all queued packets, or whatever. We don't know
> really.
> I can actually measure how long it takes, if you really desire
> it.
> We _need_ to wait there. It is something like synchronize_irq(), or
> whatever. It is a synchronizing function and we need it to be
> synchronizing.
> And I don't think it is worth the pain to insert a preemption
> point there (or doing even fancier things with workqueues and
> completions).
> 
> Overall, I don't think bcm43xx is still so bad at
> wasting CPU. Maybe we should still insert some voluntary
> preemption points, if the bcm43xx user does not run a fully
> preemptible kernel. But if a fully preemptible kernel is run,
> I think it is all OK.

Never assume a preemptible kernel will clean up problems for you :)

	Jeff