This is correct. Why do you think it's a specs bug?
Because
a) The old one made more sense to me.
b) Write MMIO register 0x3? I mean. What is that?
Could this be PHY or radio register 0x3?
Apologies. You are correct that this should be PHY Register 0x3,
not MMIO offset 0x3. I've correc
Michael Buesch wrote:
On Friday 09 February 2007 20:05, Joseph Jezak wrote:
I'll agree to that as long as there is a clear indication of any differences
between V3 and V4 firmware.
That's also part of the problem. With the v4 driver, Broadcom
dropped support for a number of
The specs are unclear at this point:
"Write the value to the offset"
Offset in which register type?
PHY Register. I've clarified it in the specs, I think this was said
before, I made it worse when I cleaned it up.
// Initialization
- if (phy->version == 0) {
+ if (phy->
I'll agree to that as long as there is a clear indication of any differences
between V3 and V4 firmware.
That's also part of the problem. With the v4 driver, Broadcom
dropped support for a number of older BPHY devices (4301/4303 and
some 4306 revisions). Do we still want to support those?
> dprintk(KERN_INFO PFX "Detected PHY: Version: %x, Type %x,
Revision %x\n",
You should change this too, the "Version" text should read "Analog"
instead.
-Joe
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
Well, I don't review the rest until you say to which specs you did the changes.
;)
http://bcm-specs.sipsolutions.net/B5PHY
Larry was working from the old specs, so when I updated it, I only
updated the old specs. I'll fix the v4 specs soon.
-Joe
-
To unsubscribe from this list: send the
> No, that totally avoids my point. Your "otherwise idle machine" test is
> probably nowhere near worst case in the field, for loops that can
> potentially lock the CPU for a long time upon hardware fault. And then
> there are the huge delays in specific functions that I pointed out...
>
> J
The ieee80211softmac_call_events function, when called with event type
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT should pass the network as the
third parameter. This patch does that.
Signed-off-by: Joseph Jezak <[EMAIL PROTECTED]>
---
diff --git a/net/ieee80211/softmac/ieee80211softmac_a
er.
I also added a check to the wx handler to see if we're connecting to a
different network than the one already in progress. This scenario was
causing multiple requests on the same network because the network BSSID
was not being updated despite the fact that the ESSID changed.
Signed-off-b
<[EMAIL PROTECTED]>
> * Joseph Jezak <[EMAIL PROTECTED]>
> * Larry Finger <[EMAIL PROTECTED]>
> * Danny van Dyk <[EMAIL PROTECTED]>
> * Michael Buesch <[EMAIL PROTECTED]>
>
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and nee
11 matches
Mail list logo
