Re: eeepc-laptop: bugreport

[Alan Jenkins <alan-jenkins-cCz0Lq7MMjm9FHfhHBbuYA@public.gmane.org>]

andrej.gelenberg-KJIyc1CJxjQ@public.gmane.org wrote:
> Alan Jenkins writes:
>
>> At least on the original systems, the eeepc-laptop driver has no way 
>> to control the wireless LED directly.  The wireless LED is set by the 
>> WLDS acpi method (when the wireless is enabled/disabled).
>>
>> The pci hotplug in the eeepc-laptop driver doesn't actually save any 
>> power.  The WLDS acpi method is what actually "unplugs" the PCI 
>> slot.  What eeepc-laptop does is notify the kernel after the fact, so 
>> that the wireless driver doesn't try to talk to hardware that isn't 
>> there.  Without this notification, the wireless driver isn't able to 
>> recover when the wireless is toggled off and back on again.
>>
>> Unfortunately, the BIOS doesn't tell us in advance which device it is 
>> going to unplug.  Hence the hardcoded bus/slot.
>>
>> We may be able to filter the notifications.  The _ADR field on the 
>> P0P* devices tells us which PCI bridge device it corresponds to.  So 
>> we can hopefully avoid toggling the wrong device and disabling the 
>> LAN on 1005ha.
>>
>> But I don't know how to find the _right_ device in a generic way (or 
>> detect that hotplug is not needed and so we should not toggle any 
>> device).
>
> search for wlan on pci-bus? (you can easy walk over all net-devices,
> and then wich have parent-device on pci-subsystem).

Ow.

That won't work if we load before the wireless driver :-(.






------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july