netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: netdev@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>,
	Greg KH <greg@kroah.com>
Subject: Re: [RFC] sysfs + configfs on 802.11 wireless drivers
Date: Fri, 23 Jun 2006 07:50:47 -0400	[thread overview]
Message-ID: <1151063447.2473.6.camel@localhost.localdomain> (raw)
In-Reply-To: <43e72e890606220512h5197d473s5f7da9e734814005@mail.gmail.com>

On Thu, 2006-06-22 at 08:12 -0400, Luis R. Rodriguez wrote:
> (4) At resume() we could just have our driver read our sysfs
> attributes and try to set all of them back exactly how they were
> before but to reduce bloat on our drivers and since our state is
> already exported we could just have userspace do it for us so... we
> use netlink to communicate to userspace to go ahead and ask it to
> resume() us. Advantages of this would be userspace would always
> consistantly handle the assoc/desassoc and WPA in a consistent manner
> and as mentioned above, driver bloatness killing.

I think having the driver try to set all its state back is pretty much
useless in a large number of cases.  While definitely useful for some
cases, consider:

a) suspend, drive to work, resume
b) WPA-related stuff, which takes much more than simply setting SSID and
encryption key back on the card

Neither of these instances allows the driver to just stick its fingers
in its ears, hum loudly, and pretend nothing happened between suspend
and resume.  Essentially, drivers would be doing all this work for
unencrypted and WEP cases, and then only those cases where the machine
hasn't physically moved.

Our effort is probably better spent elsewhere, especially since many
popular userspace tools already handle resume for us just fine.  More
useful to have drivers just come back from resume in an initialized
state similar to system boot.

Dan



  parent reply	other threads:[~2006-06-23 11:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-22 12:12 [RFC] sysfs + configfs on 802.11 wireless drivers Luis R. Rodriguez
2006-06-22 16:44 ` Michael Wu
2006-06-22 20:41 ` Greg KH
2006-06-23 11:50 ` Dan Williams [this message]
2006-06-23 12:47   ` John W. Linville
2006-06-23 14:20     ` Luis R. Rodriguez
2006-06-23 14:37       ` Dan Williams
2006-06-23 11:52 ` Jiri Benc
2006-06-23 14:13   ` Luis R. Rodriguez
2006-06-23 15:12   ` 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=1151063447.2473.6.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=greg@kroah.com \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@gmail.com \
    --cc=netdev@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).