linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <larry.finger@lwfinger.net>
To: Stefano Brivio <stefano.brivio@polimi.it>
Cc: John Linville <linville@tuxdriver.com>,
	Michael Buesch <mb@bu3sch.de>,
	Bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev  1 PHYs
Date: Fri, 13 Apr 2007 10:06:00 -0500	[thread overview]
Message-ID: <461F9C58.6050106@lwfinger.net> (raw)
In-Reply-To: <20070413113638.10db9767@localhost>

Stefano Brivio wrote:
> On Wed, 11 Apr 2007 11:08:53 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> 
>> On PPC architecture with phy->rev == 1, machine checks occur during
>> initialization of the "Extended G PHY registers". This problem was
>> also seen on bcm43xx-softmac, and was fixed by conditionally skipping
>> over certain reads/writes of these registers.  The same solution has been
>> applied here with testing by David Woodhouse.  Note: These modifications
>> are not found in the specifications, but are needed for PPC.
> 
> I don't think this patch has to be reverted, but I still think that it's
> better to notice the reverse engineers team about failing operations
> and understand the real problem rather than hiding it. Which works in some
> cases, but sometimes just hide other bugs.
> 
> I'm almost done with rewriting the whole A/G/N setup and init routines,
> following the new v4 specs. This issue could even be related.

I agree that it would be better if we could follow the specs and not have the machine check problem. 
My impression is that early versions of the bcm43xx driver did not have this difficulty, but that it 
appeared after a relatively recent change in the G init specs. BTW, these were the changes that 
greatly improved performance, particularly on the phy->rev = 8 devices. Perhaps the Broadcom 
software abandoned/ignored the phy->rev = 1 units running on PPC hardware, which seems to be the 
only combination that shows the problem. I don't know about MIPS hardware, but the problem is not 
seen on x86 architecture.

I look forward to your rewrite of the setup and init routines. Perhaps they will even let my 4311 
work with mac80211, but I will be very surprised if the PPC machine check problem goes away.

Larry

  reply	other threads:[~2007-04-13 15:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-11 16:08 [PATCH] bcm43xx-mac80211: Fix machine checks on PPC with rev 1 PHYs Larry Finger
2007-04-11 17:22 ` Michael Buesch
2007-04-13  0:09 ` John W. Linville
2007-04-13  0:57   ` Pavel Roskin
2007-04-13  1:22   ` Larry Finger
2007-04-16  1:04     ` David Woodhouse
2007-04-17 17:08     ` Larry Finger
2007-04-13  9:36 ` Stefano Brivio
2007-04-13 15:06   ` Larry Finger [this message]
2007-04-13 15:17     ` Johannes Berg
2007-04-16  0:06       ` David Woodhouse
2007-04-16  0:53         ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=461F9C58.6050106@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=Bcm43xx-dev@lists.berlios.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    --cc=stefano.brivio@polimi.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).