linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Ketrenos <jketreno@linux.intel.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: network manager vs. missing firmware
Date: Tue, 13 Feb 2007 16:36:20 -0800	[thread overview]
Message-ID: <45D25984.7080808@linux.intel.com> (raw)
In-Reply-To: <1171394598.5329.31.camel@localhost.localdomain>

Dan Williams wrote:

> The simpler, the better I think; but it's complicated.  A sample of
> current drivers and when they call request_firmware() from a 2.6.19
> kernel:
> 
> on dev->open: atmel, prism54, bcm43xx (softmac)
> on dev->init: ipw2100, ipw2200

request_firmware is also used during mode changes (ie, BSS to IBSS to 
MONITOR)

Perhaps solving the larger problem of "the driver knows something is 
horribly wrong, but has no way to tell the user" would be good. 
Firmware not being there is bad.  There are also periodic failures or 
usage conditions that keep things from working.  Right now we might have 
failures due to:

	FIRMWARE missing
	RF KILL active

but maybe tomorrow we would have:

	Conflict with other active wifi device / coexistence

or any number of solution specific error codes that the vendor / driver 
writer would be able to articulate in a text string how to resolve.

Perhaps a simple cfg80211 interface for querying the interface status 
and and associated text string (if in an error condition).  Missing 
firmware or RF kill could have standard numbers and the text string 
could be standardized to return just the name of the firmware file expected.

Even if it didn't get standardized across all devices, NM or other 
utilities could provide a standard place for the user to look at the 
error and then google on it.  Right now, things break and the user can't 
figure out why without looking at the kernel log (which many users don't 
even know exist).

James

  parent reply	other threads:[~2007-02-14  1:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-13 18:41 network manager vs. missing firmware Johannes Berg
2007-02-13 19:23 ` Dan Williams
2007-02-13 19:37   ` Johannes Berg
2007-02-13 19:43     ` Michael Wu
2007-02-13 20:13       ` Luis R. Rodriguez
2007-02-13 20:58         ` Dan Williams
2007-02-14  0:36   ` James Ketrenos [this message]
2007-02-14  2:47     ` Luis R. Rodriguez
2007-02-15 18:53       ` James Ketrenos
2007-02-14 19:24     ` 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=45D25984.7080808@linux.intel.com \
    --to=jketreno@linux.intel.com \
    --cc=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /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).