This also adds a longer delay for waiting for the microcode
to initialize itself. It seems that the current timeout is sufficient
on all available devices, but there's no real reason why we shouldn't
wait for up to one second. Slow embedded devices might exist.
Your decision, but I very much
On Thursday 24 January 2008 10:13:01 Johannes Berg wrote:
This also adds a longer delay for waiting for the microcode
to initialize itself. It seems that the current timeout is sufficient
on all available devices, but there's no real reason why we shouldn't
wait for up to one second.
Hi,
The following series of patches is intended to fix the suspend/resume deadlock
occuring as a result of unregistering device objects, locked by the PM core,
during suspend/resume cycles by the b43 driver.
In short, the b43 driver is modified to avoid unregistering device objects
during
From: Rafael J. Wysocki [EMAIL PROTECTED]
Move the declaration of device_pm_schedule_removal() to device.h
and make it exported, as it will be used directly by some drivers
for unregistering device objects during suspend/resume cycles in a
safe way.
Signed-off-by: Rafael J. Wysocki [EMAIL
From: Rafael J. Wysocki [EMAIL PROTECTED]
Modify the b43 driver to avoid deadlocking suspend and resume,
which happens as a result of attempting to unregister device objects
locked by the PM core during suspend/resume cycles. Also, make it
use a suspend-safe method of unregistering device object
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a Hardware Random Number Generator
device object in a safe way during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/char/hw_random/core.c
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a led classdev object in a safe way
during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/leds/led-class.c | 13 +
include/linux/leds.h | 10 +-
2 files
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make it possible to unregister a misc device object in a safe way
during a suspend/resume cycle.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/char/misc.c| 13 +
include/linux/miscdevice.h | 10 +-
2
On Friday 25 January 2008 08:47:46 Pavel Machek wrote:
On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Modify the b43 driver to avoid deadlocking suspend and resume,
which happens as a result of attempting to unregister device objects
This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.
Signed-off-by: Michael Buesch
This patch makes suspend/resume work with the b43 driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume. With an all-zero MAC the device
firmware is not able to ACK any received packets anymore.
Fix this by moving the initializion
We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).
This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.
It is
On Friday, 25 of January 2008, Michael Buesch wrote:
On Friday 25 January 2008 08:47:46 Pavel Machek wrote:
On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Modify the b43 driver to avoid deadlocking suspend and resume,
which happens as
This fixes four resource leakages.
In any error path we must deallocate the DMA frame slots we
previously allocated by request_slot().
This is done by storing the ring pointers before doing any ring
allocation and restoring the old pointers in case of an error.
This patch by Michael Buesch has
This patch makes suspend/resume work with the b43legacy driver.
We must not overwrite the MAC addresses in the init function, as this
would also overwrite the MAC on resume. With an all-zero MAC the device
firmware is not able to ACK any received packets anymore.
Fix this by moving the
Fix the crash reported below, which seems to happen on bcm4306 rev. 2 devices
only while using PIO:
Oops: [#1] PREEMPT
Modules linked in: b43(F) rfkill(F) led_class(F) input_polldev(F) arc4
b43legacy mac80211 cfg80211 i915 drm snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device ohci1394
We must drop any packets we are not able to encrypt.
We must not send them unencrypted or with an all-zero-key (which
basically is the same as unencrypted, from a security point of view).
This might only trigger shortly after resume before mac80211 reassociated
and reconfigured the keys.
It is
17 matches
Mail list logo
