linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Green <andy@warmcat.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: Larry Finger <larry.finger@lwfinger.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org, johannes@sipsolutions.net
Subject: Re: [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel
Date: Fri, 20 Jul 2007 18:48:20 +0100	[thread overview]
Message-ID: <46A0F564.2090607@warmcat.com> (raw)
In-Reply-To: <200707201936.41078.mb@bu3sch.de>

Somebody in the thread at some point said:
> On Friday 20 July 2007 18:58:24 Larry Finger wrote:
>> Andy Green wrote:
>>> Understood, that is why I consider it a bad thing that functionality
>>> that can be done in the mac80211 driver is pushed into the binary-only
>>> firmware when there is a choice (otherwise known as "paranoia", apparently).
>> Unfortunately, that is a necessary result of this type of reverse-engineering. If Broadcom put some 
>> function in the firmware, we have to leave it there as we have no idea what would break.
>>
>>> However you stripped some quoting from Michael:
>>>
>>> ''But it is actually no problem in reality, as the use-it-or-die
>>> firmware doesn't have this problem. So if someone uses another
>>> firmware than the one we suggest, he will probably run into more
>>> problems, as well.
>>> The fix is called: Use the correct firmware.
>>> For now, at least.''
>>>
>>> I would summarize this that Michael is telling me one pariticular
>>> version of firmware - "use it or die firmware" - is especially
>>> blessed/correct.  It might be an idea to let people know they have
>>> strayed from the dependency of the required firmware version in dmesg if
>>> indeed there is an effective dependency of the driver on it.
>> It isn't that it is blessed or correct, but that it has been tested. Your version has not. Who knows 
>> what else might have changed? Once we know the version with the different behavior, a warning 
>> message can be prepared. I don't think anyone knew about this problem until you submitted your patch.
> 
> People don't read dmesg. Adding a "This firmware is unsupported"
> would have no effect.
> I experience same thing for the "bcm43xx-does-not-support-v3-issue".
> There is a clear error message saying what to do exactly. And _still_
> people mail me asking what this message means.

Sure, but naturally you don't hear from the presumably nonzero amount of
people who saw and understood the message.  Whereas if there was no
message at all, only disgusted and baffled people are possible.

> The use-or-die firmware is here:
> http://linuxwireless.org/en/users/Drivers/bcm43xx
> 
>>> Can I still get the firmware version from fwcutter if I don't have the
>>> original Windows binary the firmware came from?
>> AFAIK, fwcutter can only get the version from the foreign driver. It can be gotten from the dmesg 
>> output of your inlaws computer, or if you have the extracted firmware files here, you can bundle 
>> them up and email them to me privately.
> 
> People don't read dmesg.
> q.e.d. ;)

Actually, I can't read dmesg on my In-laws' box that has the card the
last few weeks: I read dmesg all the time if I suspect kernel-side
trouble.  It's pretty simple and cheap to do a printk and give someone
with problems the ability to dig themselves out of the trouble with a
clue and even a URL in this case.

If the driver is dependent on a particular version of an external file,
and you can read the version of that file at runtime, you really ought
to be issuing a diagnostic if the dependency is violated.

-Andy

  reply	other threads:[~2007-07-20 17:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-11 10:38 [PATCH 0/2] Small driver fixes andy
2007-06-11 10:38 ` [PATCH 1/2] zd1211rw-mac80211: return hardware specific tx rate code for rx status andy
2007-07-19 19:10   ` John W. Linville
2007-07-19 21:19     ` Ulrich Kunitz
2007-06-11 10:38 ` [PATCH 2/2] bcm43xx-mac80211: Fix reported rx frequency and channel andy
2007-06-11 11:26   ` Johannes Berg
2007-06-11 11:45     ` Johannes Berg
2007-07-19 19:10   ` John W. Linville
2007-07-19 19:39     ` Michael Buesch
2007-07-20  6:05       ` Andy Green
2007-07-20  7:37         ` Johannes Berg
2007-07-20 13:31           ` John W. Linville
2007-07-20 14:36         ` Larry Finger
2007-07-20 14:47           ` Andy Green
2007-07-20 16:58             ` Larry Finger
2007-07-20 17:36               ` Michael Buesch
2007-07-20 17:48                 ` Andy Green [this message]
2007-07-20 17:50                   ` Michael Buesch
2007-07-20 20:40               ` Johannes Berg

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=46A0F564.2090607@warmcat.com \
    --to=andy@warmcat.com \
    --cc=johannes@sipsolutions.net \
    --cc=larry.finger@lwfinger.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    /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).