Re: eeepc-laptop: bugreport

Re: eeepc-laptop: bugreport

[Corentin Chary]

> Corentin Chary writes:
>> On Sat, Nov 14, 2009 at 1:56 PM,  <andrej.gelenberg@udo.edu> wrote:
>>>
>>> Hi,
>>>
>>> please see my bugreport on http://bugzilla.kernel.org:
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14570
>>>
>>> I have posted a patch there too.
>>>
>>> Regards,
>>> Andrej Gelenberg
>>>
>>
>> Hi,
>> Did you test it on a newer 2.6.32-rc kernel ? The bug is still
>> reproductible ?
>> Thanks
>>
> Hi,
>
> i haven't tstes it on 32, but i tried to apply all patches for
> eeepc-laptop from 32 and next branches. As i can see, the pci-bus
> and pci-slot are still hardcoded and it will turn off my atl1c ethernet card
> and not my wlan-card.
>
> Hotplug in eeepc should not be where. Rfkill work fine
> without that and it make not much sense: after pci-rescan
> (echo 1 > /sys/bus/pci/rescan) is device there.
> In fakehotplug-driver is written, that there are no extra
> powersaving-benefit.
>
> Regard,
> Andrej Gelenberg
>

Hi,
We can't apply your patch as-is. But we need to fix that.

Matthew, you added hotplug in commit  5740294ca3a9b113fe146f2826effb69ca50008d,
it was needed for 701/900/901. Do you know if it's still needed for 1005ha ?

Thanks,

-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

Corentin Chary writes:

> Matthew, you added hotplug in commit  5740294ca3a9b113fe146f2826effb69ca50008d,
> it was needed for 701/900/901. Do you know if it's still needed for 1005ha ?

Is it not better to use rfkill-switch provided from wlan-driver when? At 
least Atheros drivers support rfkill propertly. You can make it LED for that 
eeepcs and set the default trigger to rfkill. I have tried to make it so, 
but on 1005ha it is a proper rfkill.

I have tried to make the devicesearch for hotplug propertly, but it cause
the system freeze. (http://bugzilla.kernel.org/show_bug.cgi?id=14570#c1)

Regards,
Andrej Gelenberg

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Alan Jenkins]

andrej.gelenberg@udo.edu wrote:
> Hi,
>
> Corentin Chary writes:
>
>> Matthew, you added hotplug in commit  
>> 5740294ca3a9b113fe146f2826effb69ca50008d,
>> it was needed for 701/900/901. Do you know if it's still needed for 
>> 1005ha ?
>
> Is it not better to use rfkill-switch provided from wlan-driver when? 
> At least Atheros drivers support rfkill propertly. You can make it LED 
> for that eeepcs and set the default trigger to rfkill. I have tried to 
> make it so, but on 1005ha it is a proper rfkill.
>
> I have tried to make the devicesearch for hotplug propertly, but it cause
> the system freeze. (http://bugzilla.kernel.org/show_bug.cgi?id=14570#c1)
>
> Regards,
> Andrej Gelenberg

That freeze shows eeepc_rfkill_set() calling eeepc_rfkill_hotplug().  
That's a bug which was introduced in 2.6.32-rc5 (I think), but it is 
definitely fixed in 2.6.32-rc7.  This freeze was happening on all systems.

So your modified device search _should_ work, on either 2.6.31 or 
2.6.32-rc7.  AFAICS the problem is making the same driver work on both 
1005ha and all the previous models.

Alan

Re: eeepc-laptop: bugreport

[Alan Jenkins]

andrej.gelenberg@udo.edu wrote:
> Hi,
>
> Corentin Chary writes:
>
>> Matthew, you added hotplug in commit  
>> 5740294ca3a9b113fe146f2826effb69ca50008d,
>> it was needed for 701/900/901. Do you know if it's still needed for 
>> 1005ha ?
>
> Is it not better to use rfkill-switch provided from wlan-driver when? 
> At least Atheros drivers support rfkill propertly. You can make it LED 
> for that eeepcs and set the default trigger to rfkill. I have tried to 
> make it so, but on 1005ha it is a proper rfkill.
>
> I have tried to make the devicesearch for hotplug propertly, but it cause
> the system freeze. (http://bugzilla.kernel.org/show_bug.cgi?id=14570#c1)

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).

Alan

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

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). 

> 
> Alan

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 10:39:22AM +0100, Corentin Chary wrote:

> Matthew, you added hotplug in commit  5740294ca3a9b113fe146f2826effb69ca50008d,
> it was needed for 701/900/901. Do you know if it's still needed for 1005ha ?

If people are poking about to force rescans of the PCI bus, it's still 
needed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Alan Jenkins]

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

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 12:53:11PM +0100, andrej.gelenberg@udo.edu wrote:

> Is it not better to use rfkill-switch provided from wlan-driver when? At  
> least Atheros drivers support rfkill propertly. You can make it LED for 
> that eeepcs and set the default trigger to rfkill. I have tried to make 
> it so, but on 1005ha it is a proper rfkill.

No. The platform is designed (for whatever reason) such that rfkill 
turns the device off and disassociates it from the PCI bus. Support for 
that is necessary.

> I have tried to make the devicesearch for hotplug propertly, but it cause
> the system freeze. (http://bugzilla.kernel.org/show_bug.cgi?id=14570#c1)

rt2860 is buggy.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Alan Jenkins]

Matthew Garrett wrote:
> On Sun, Nov 15, 2009 at 12:53:11PM +0100, andrej.gelenberg@udo.edu wrote:
>
>   
>> Is it not better to use rfkill-switch provided from wlan-driver when? At  
>> least Atheros drivers support rfkill propertly. You can make it LED for 
>> that eeepcs and set the default trigger to rfkill. I have tried to make 
>> it so, but on 1005ha it is a proper rfkill.
>>     
>
> No. The platform is designed (for whatever reason) such that rfkill 
> turns the device off and disassociates it from the PCI bus. Support for 
> that is necessary.
>
>   
>> I have tried to make the devicesearch for hotplug propertly, but it cause
>> the system freeze. (http://bugzilla.kernel.org/show_bug.cgi?id=14570#c1)
>>     
>
> rt2860 is buggy.
>   

More specifically, the eeepc-laptop workaround for rt2860 was buggy and 
broke all models with non-rt2860 wireless.

Regards
Alan

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 12:44:40PM +0000, Alan Jenkins wrote:

> Unfortunately, the BIOS doesn't tell us in advance which device it is  
> going to unplug.  Hence the hardcoded bus/slot.

Mm. Thinking about it, it does - it's sending a bus check notification, 
which means we're supposed to look at children of the device it 
notifies. Shouldn't be a difficult fix.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

Alan Jenkins writes:

> So your modified device search _should_ work, on either 2.6.31 or 
> 2.6.32-rc7.  AFAICS the problem is making the same driver work on both 
> 1005ha and all the previous models.

i can't load the eeepc-laptop in last git-revision of 2.6.32. insmod say:
"no such device". (vanila sources)

Regards,
Andrej

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Alan Jenkins]

Matthew Garrett wrote:
> On Sun, Nov 15, 2009 at 12:44:40PM +0000, Alan Jenkins wrote:
>
>   
>> Unfortunately, the BIOS doesn't tell us in advance which device it is  
>> going to unplug.  Hence the hardcoded bus/slot.
>>     
>
> Mm. Thinking about it, it does - it's sending a bus check notification, 
> which means we're supposed to look at children of the device it 
> notifies. Shouldn't be a difficult fix.
>   

We don't really look at the device though.  What we look at is the value 
of WLDG.

Stray notifications on either of the _other_ 2 pcie ports would then 
cause us to toggle them based on WLDG.

I see a _Lxx handler in my DSDT which looks like it notifies on _all_ 
the pcie ports.  So I think it's a bit tricky.

Alan

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 04:11:40PM +0000, Alan Jenkins wrote:

> We don't really look at the device though.  What we look at is the value  
> of WLDG.
>
> Stray notifications on either of the _other_ 2 pcie ports would then  
> cause us to toggle them based on WLDG.
>
> I see a _Lxx handler in my DSDT which looks like it notifies on _all_  
> the pcie ports.  So I think it's a bit tricky.

We could be smarter about that. WLDG is handy but not required - at the 
most basic level we could do a pci configuration space access and see if 
we get back 0xff or a value.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Alan Jenkins]

andrej.gelenberg@udo.edu wrote:
> Hi,
>
> Alan Jenkins writes:
>
>> We'd better fix that :).
>>
>> Any interesting errors in dmesg?
>>
>> What's the latest version that's worked for you in the past?
>
> i think, the problem is, that since 2.6.32-rc* acpi don't find
> ASUS010 (it is not in /sys/bus/acpi/devices).
> It is there on 2.6.31.
>
> Regards,
> Andrej

Well spotted!

Mind filing this in Bugzilla?  That helps both for the core ACPI 
developers, and for regression tracking.  It also gives a good place to 
attach large files like acpidump output and full dmesg logs.

Thanks
Alan

Re: eeepc-laptop: bugreport

[Corentin Chary]

On Sun, Nov 15, 2009 at 6:07 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> andrej.gelenberg@udo.edu wrote:
>>
>> Hi,
>>
>> Alan Jenkins writes:
>>
>>> We'd better fix that :).
>>>
>>> Any interesting errors in dmesg?
>>>
>>> What's the latest version that's worked for you in the past?
>>
>> i think, the problem is, that since 2.6.32-rc* acpi don't find
>> ASUS010 (it is not in /sys/bus/acpi/devices).
>> It is there on 2.6.31.
>>
>> Regards,
>> Andrej
>
> Well spotted!
>
> Mind filing this in Bugzilla?  That helps both for the core ACPI developers,
> and for regression tracking.  It also gives a good place to attach large
> files like acpidump output and full dmesg logs.
>
> Thanks
> Alan
>

Could you try to boot with acpi_osi="Linux" ?
This might be fixed by
http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488

-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeepc-laptop: bugreport

[andrej.gelenberg]

Hi,

Corentin Chary writes:

> Could you try to boot with acpi_osi="Linux" ?
> This might be fixed by
> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488

this patch solved the problem.

Regards,
Andrej

Re: eeepc-laptop: bugreport

[Alan Jenkins]

andrej.gelenberg@udo.edu wrote:
> Hi,
>
> Corentin Chary writes:
>
>> Could you try to boot with acpi_osi="Linux" ?
>> This might be fixed by
>> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488 
>>
>
> this patch solved the problem.
>
> Regards,
> Andrej

Ok.  Be aware that there may be more turmoil in future.  The preferred 
solution for linux ACPI is to do whatever the More Popular OS does.  See 
the recent rejection of a similar patch by thinkpad-acpi developers.

There may be a shiny new ACPI interface we need to write a driver for.  
Looking on the bright side, a new driver can easily use different pci 
hotplug code (or perhaps no hotplug code).

Regards
Alan

Re: eeepc-laptop: bugreport

[andrej.gelenberg]

Alan Jenkins writes:

> andrej.gelenberg@udo.edu wrote:
>> Hi,
>>
>> Corentin Chary writes:
>>
>>> Could you try to boot with acpi_osi="Linux" ?
>>> This might be fixed by
>>> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488 
>>>
>>
>> this patch solved the problem.
>>
>> Regards,
>> Andrej
> 
> Ok.  Be aware that there may be more turmoil in future.  The preferred 
> solution for linux ACPI is to do whatever the More Popular OS does.  See 
> the recent rejection of a similar patch by thinkpad-acpi developers.
> 
> There may be a shiny new ACPI interface we need to write a driver for.  
> Looking on the bright side, a new driver can easily use different pci 
> hotplug code (or perhaps no hotplug code).
> 
> Regards
> Alan

it has not solved the Problem, that my ethernet-device are unplugt on rfkill-off.
It solved only the problem with no founded ASUS010.

Regards,
Andrej

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 06:17:37PM +0100, Corentin Chary wrote:

> Could you try to boot with acpi_osi="Linux" ?
> This might be fixed by
> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488

Why would the behaviour differ between 2.6.31 and 2.6.32?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg]

Matthew Garrett writes:

> On Sun, Nov 15, 2009 at 06:17:37PM +0100, Corentin Chary wrote:
> 
>> Could you try to boot with acpi_osi="Linux" ?
>> This might be fixed by
>> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488
> 
> Why would the behaviour differ between 2.6.31 and 2.6.32?
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

There was a patch for ACPI with new OSI (for Windows Vista and 7).
EEE PC ACPI have no support for that, but linux (and older Windows).

Regards,
Andrej

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 07:11:25PM +0100, andrej.gelenberg@udo.edu wrote:

> There was a patch for ACPI with new OSI (for Windows Vista and 7).
> EEE PC ACPI have no support for that, but linux (and older Windows).

Or, rather, it assumes a different programming model for Windows 7. 
Interesting. Maybe it'll be less painful. Do we have ACPI dumps for the 
new firmware?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 04:14:58PM +0000, Matthew Garrett wrote:
> On Sun, Nov 15, 2009 at 04:11:40PM +0000, Alan Jenkins wrote:
> 
> > We don't really look at the device though.  What we look at is the value  
> > of WLDG.
> >
> > Stray notifications on either of the _other_ 2 pcie ports would then  
> > cause us to toggle them based on WLDG.
> >
> > I see a _Lxx handler in my DSDT which looks like it notifies on _all_  
> > the pcie ports.  So I think it's a bit tricky.
> 
> We could be smarter about that. WLDG is handy but not required - at the 
> most basic level we could do a pci configuration space access and see if 
> we get back 0xff or a value.

Though, thinking about it, you're right - we still need to know whether 
it was a wifi device so we know whether to update the rfkill status. Do 
Atheros devices still have their PCI class set to ethernet rather than 
wireless?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

Matthew Garrett writes:

> On Sun, Nov 15, 2009 at 04:14:58PM +0000, Matthew Garrett wrote:
>> On Sun, Nov 15, 2009 at 04:11:40PM +0000, Alan Jenkins wrote:
>> 
>> > We don't really look at the device though.  What we look at is the value  
>> > of WLDG.
>> >
>> > Stray notifications on either of the _other_ 2 pcie ports would then  
>> > cause us to toggle them based on WLDG.
>> >
>> > I see a _Lxx handler in my DSDT which looks like it notifies on _all_  
>> > the pcie ports.  So I think it's a bit tricky.
>> 
>> We could be smarter about that. WLDG is handy but not required - at the 
>> most basic level we could do a pci configuration space access and see if 
>> we get back 0xff or a value.
> 
> Though, thinking about it, you're right - we still need to know whether 
> it was a wifi device so we know whether to update the rfkill status. Do 
> Atheros devices still have their PCI class set to ethernet rather than 
> wireless?

cat /sys/bus/pci/devices/0000\:02\:00.0/class
0x028000

> 
> -- 
> Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 07:22:16PM +0100, andrej.gelenberg@udo.edu wrote:
> Matthew Garrett writes:
>> Though, thinking about it, you're right - we still need to know whether 
>> it was a wifi device so we know whether to update the rfkill status. Do 
>> Atheros devices still have their PCI class set to ethernet rather than  
>> wireless?
>
> cat /sys/bus/pci/devices/0000\:02\:00.0/class
> 0x028000

Unfortunately it's 0x020000 on some earlier Eees, so that's not going to 
work. I'd be almost inclined to just leave eeepc-laptop as is, and write 
a new driver for the systems with the new interface.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Corentin Chary]

On Sun, Nov 15, 2009 at 6:43 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> andrej.gelenberg@udo.edu wrote:
>>
>> Hi,
>>
>> Corentin Chary writes:
>>
>>> Could you try to boot with acpi_osi="Linux" ?
>>> This might be fixed by
>>>
>>> http://git.iksaif.net/?p=acpi4asus.git;a=commitdiff;h=a57818b9177b521d418e25bf549a609d0e79cd4a;hp=cbf69cbf597b31201038ecd7630c90183543c488
>>
>> this patch solved the problem.
>>
>> Regards,
>> Andrej
>
> Ok.  Be aware that there may be more turmoil in future.  The preferred
> solution for linux ACPI is to do whatever the More Popular OS does.  See the
> recent rejection of a similar patch by thinkpad-acpi developers.
>
> There may be a shiny new ACPI interface we need to write a driver for.
>  Looking on the bright side, a new driver can easily use different pci
> hotplug code (or perhaps no hotplug code).
>
> Regards
> Alan
>

There is new wmi interface, without any documentation of course.
Even Xandros had not been aware of that.
You can find a dsdt with that here :
http://dev.iksaif.net/attachments/download/83/eeepc_1000h_2204.dsl.gz
Search "ASUSWMI".


-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeepc-laptop: bugreport

[andrej.gelenberg]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hi,

Matthew Garrett writes:

> On Sun, Nov 15, 2009 at 07:11:25PM +0100, andrej.gelenberg@udo.edu wrote:
> 
>> There was a patch for ACPI with new OSI (for Windows Vista and 7).
>> EEE PC ACPI have no support for that, but linux (and older Windows).
> 
> Or, rather, it assumes a different programming model for Windows 7. 
> Interesting. Maybe it'll be less painful. Do we have ACPI dumps for the 
> new firmware?
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

here is dump from my 1005ha.

Regards,
Andrej

[-- Attachment #2: ACPI dump for 1005ha --]
[-- Type: application/octet-stream, Size: 26963 bytes --]

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Sun, Nov 15, 2009 at 07:31:55PM +0100, Corentin Chary wrote:

> There is new wmi interface, without any documentation of course.
> Even Xandros had not been aware of that.
> You can find a dsdt with that here :
> http://dev.iksaif.net/attachments/download/83/eeepc_1000h_2204.dsl.gz
> Search "ASUSWMI".

Looks easy enough to implement. From the hotkey perspective, it seems 
that you'll get a notification on the WMI device and get the event from 
the WMI event data. The rest of the programming model looks pretty 
similar to the old interface.

The slightly odd thing is that there's no bus check notifications sent 
for the 1005, so we should never be running the hotplug code to begin 
with at runtime - looks like the only case we'll cover is on suspend and 
resume. On the other hand, I've just realised that this is likely to go 
horribly wrong with the PCI runtime power management code. It may 
actually be possible to make the eee stuff generic after all, but that's 
going to take a small amount of work.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

Corentin Chary writes:

> Hi,
> We can't apply your patch as-is. But we need to fix that.
> 
> Matthew, you added hotplug in commit  5740294ca3a9b113fe146f2826effb69ca50008d,
> it was needed for 701/900/901. Do you know if it's still needed for 1005ha ?
> 
> Thanks,
> 
> -- 
> Corentin Chary
> http://xf.iksaif.net

how about to make hotplug optional?
http://bugzilla.kernel.org/show_bug.cgi?id=14570#c7

Regards,
Andrej


------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Corentin Chary]

On Sun, Nov 15, 2009 at 8:19 PM,  <andrej.gelenberg@udo.edu> wrote:
> Hi,
>
> Corentin Chary writes:
>
>> Hi,
>> We can't apply your patch as-is. But we need to fix that.
>>
>> Matthew, you added hotplug in commit
>>  5740294ca3a9b113fe146f2826effb69ca50008d,
>> it was needed for 701/900/901. Do you know if it's still needed for 1005ha
>> ?
>>
>> Thanks,
>>
>> --
>> Corentin Chary
>> http://xf.iksaif.net
>
> how about to make hotplug optional?
> http://bugzilla.kernel.org/show_bug.cgi?id=14570#c7
>
> Regards,
> Andrej
>
>

Hi,
Making hotplug optional won't fix the problem,
because this mean you need to ship a specific module for each Eeepc.

We need a more generic solution, and we need to implement a driver for
the new wmi interface.
I'll start to work on that as soon as I can get the hardware...
Thanks,


-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

i know, what it is not a proper solution, but it work
for me at the moment. Pleas tell me, if i can help.

I think it is better not to let switch the rfkill
on button in the driver itself.
It is more flexible when button send only event and
userspace-tool handle it. Userspace-tool  can
choose the right rfkill (or may be multiple rfkills)
(it can be runned, after wlan-driver was loaded).
As i can see, other platform-drivers provide
only rfkill device and do not bind it to
keys.

Regards,
Andrej

Corentin Chary writes:

> Hi,
> Making hotplug optional won't fix the problem,
> because this mean you need to ship a specific module for each Eeepc.
> 
> We need a more generic solution, and we need to implement a driver for
> the new wmi interface.
> I'll start to work on that as soon as I can get the hardware...
> Thanks,
> 
> 
> -- 
> Corentin Chary
> http://xf.iksaif.net

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Thu, Nov 26, 2009 at 05:45:25PM +0100, andrej.gelenberg@udo.edu wrote:

> I think it is better not to let switch the rfkill
> on button in the driver itself.

It doesn't. Disable rfkill-input if you don't want this behaviour.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,

how? It's not possible at the moment in eeepc-laptop.


Matthew Garrett writes:

> On Thu, Nov 26, 2009 at 05:45:25PM +0100, andrej.gelenberg-KJIyc1CJxjQ@public.gmane.org wrote:
> 
>> I think it is better not to let switch the rfkill
>> on button in the driver itself.
> 
> It doesn't. Disable rfkill-input if you don't want this behaviour.
> 
> -- 
> Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Alan Jenkins]

andrej.gelenberg@udo.edu wrote:
> Hi,
>
> how? It's not possible at the moment in eeepc-laptop.

CONFIG_RFKILL_INPUT=n. By default this is hidden; you have to enable 
CONFIG_EMBEDDED=y.

rfkill-input is alledgedly going to be removed soon, see 
Documentation/feature-removal-schedule.txt.

Re: eeepc-laptop: bugreport

[andrej.gelenberg]

Hi,

the problem is, when i press wlan-key, the hotplug-work is triggerd,
but you can not say, which device to unplug.

My idea is to separate the key-event and rfkill-handler.
So you can bind key to userspace-tool, which turn the
rfkill on and off.

Besides i think the hotplug-workaround ist not very
good solution. If rfkill don't work propper
on other models, then isn't it better to use
software-rfkill from wlan-driver?
(to use staging drivers isn't good,
and good drivers have it implemented)

The hotplug-workaround can be maded by
userspace too (fake hotplug driver).
The benifit is, you can say, which device
should i unplug (and not hope,
that it is on slot 0).

Regards,
Andrej

Alan Jenkins writes:

> andrej.gelenberg@udo.edu wrote:
>> Hi,
>>
>> how? It's not possible at the moment in eeepc-laptop.
> 
> CONFIG_RFKILL_INPUT=n. By default this is hidden; you have to enable 
> CONFIG_EMBEDDED=y.
> 
> rfkill-input is alledgedly going to be removed soon, see 
> Documentation/feature-removal-schedule.txt.

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Fri, Nov 27, 2009 at 12:21:19PM +0100, andrej.gelenberg@udo.edu wrote:
> Hi,
>
> how? It's not possible at the moment in eeepc-laptop.

It's an rfkill core thing, not eeepc-laptop.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Fri, Nov 27, 2009 at 01:27:37PM +0100, andrej.gelenberg@udo.edu wrote:
> Hi,
>
> the problem is, when i press wlan-key, the hotplug-work is triggerd,
> but you can not say, which device to unplug.

That's because the eee firmware gives us no control over which device is 
unplugged. I think you're missing the point of how the eee rfkill code 
works - we don't unplug any devices, the firmware does that. We then 
need to tell Linux that the PCI device has vanished in order to prevent 
drivers from attempting to use a piece of hardware that's no longer 
accessible.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Hi,


from Documentation/rfkill.txt:

  1. Introduction

  The rfkill subsystem provides a generic interface to disabling any radio
  transmitter in the system. When a transmitter is blocked, it shall not
  radiate any power.

  The subsystem also provides the ability to react on button presses and
  disable all transmitters of a certain type (or all). This is intended for
  situations where transmitters need to be turned off, for example on
  aircraft.

  The rfkill subsystem has a concept of "hard" and "soft" block, which
  differ little in their meaning (block == transmitters off) but rather in
  whether they can be changed or not:
   - hard block: read-only radio block that cannot be overriden by software
   - soft block: writable radio block (need not be readable) that is set by
                 the system software.

The eepc-latop-rfkill should be hard block. If the LED is not on,
my wlan-card won't transmit. The eeepc-laptop is only driver
which use hotplug-subsystem to hide the hardware.
It work only until next pci-rescan.
Firmware must not tell you, where the wlan-card is,
it should only provide hard-rfkill (on 1005ha it does).
Or the wlan-driver should provide proper rfkill
(at least soft block).
The hardcoded bus and slot it not proper solution.

For example in miniPCI-pinout pin 13 is "RF Silent input",
also the firmware shuld only set the pin.
http://www.interfacebus.com/MiniPCI_Pinout_124Pin.html

Matthew Garrett writes:

> That's because the eee firmware gives us no control over which device is 
> unplugged. I think you're missing the point of how the eee rfkill code 
> works - we don't unplug any devices, the firmware does that. We then 
> need to tell Linux that the PCI device has vanished in order to prevent 
> drivers from attempting to use a piece of hardware that's no longer 
> accessible.

eeepc firmware does not unplug device, it set only a rfkill-pin,
so the wlan-card know, that it should not transmit any more.

> 
> -- 
> Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org


Regards,
Andrej

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Corentin Chary]

On Fri, Nov 27, 2009 at 9:26 PM,  <andrej.gelenberg@udo.edu> wrote:
> Hi,
>
>
> from Documentation/rfkill.txt:
>
>  1. Introduction
>
>  The rfkill subsystem provides a generic interface to disabling any radio
>  transmitter in the system. When a transmitter is blocked, it shall not
>  radiate any power.
>
>  The subsystem also provides the ability to react on button presses and
>  disable all transmitters of a certain type (or all). This is intended for
>  situations where transmitters need to be turned off, for example on
>  aircraft.
>
>  The rfkill subsystem has a concept of "hard" and "soft" block, which
>  differ little in their meaning (block == transmitters off) but rather in
>  whether they can be changed or not:
>  - hard block: read-only radio block that cannot be overriden by software
>  - soft block: writable radio block (need not be readable) that is set by
>                the system software.
>
> The eepc-latop-rfkill should be hard block.

The block can be overriden by software (that's what we do), so it's a
soft block.

> If the LED is not on,
> my wlan-card won't transmit. The eeepc-laptop is only driver
> which use hotplug-subsystem to hide the hardware.
> It work only until next pci-rescan.
> Firmware must not tell you, where the wlan-card is,
> it should only provide hard-rfkill (on 1005ha it does).
> Or the wlan-driver should provide proper rfkill
> (at least soft block).
> The hardcoded bus and slot it not proper solution.
>
> For example in miniPCI-pinout pin 13 is "RF Silent input",
> also the firmware shuld only set the pin.
> http://www.interfacebus.com/MiniPCI_Pinout_124Pin.html
>
> Matthew Garrett writes:
>
>> That's because the eee firmware gives us no control over which device is
>> unplugged. I think you're missing the point of how the eee rfkill code works
>> - we don't unplug any devices, the firmware does that. We then need to tell
>> Linux that the PCI device has vanished in order to prevent drivers from
>> attempting to use a piece of hardware that's no longer accessible.
>
> eeepc firmware does not unplug device, it set only a rfkill-pin,
> so the wlan-card know, that it should not transmit any more.

Do you mean this is the case on all Eeepc or only on 1005h ?

Thanks;
-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eeepc-laptop: bugreport

[andrej.gelenberg-KJIyc1CJxjQ]

Corentin Chary writes:

>> eeepc firmware does not unplug device, it set only a rfkill-pin,
>> so the wlan-card know, that it should not transmit any more.
> 
> Do you mean this is the case on all Eeepc or only on 1005h ?

i don't know it exactly, i have only 1005ha.
But some other notebooks have it (thinkpads for example).

Regards,
Andrej

------------------------------------------------------------------------------
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

Re: eeepc-laptop: bugreport

[Matthew Garrett]

On Fri, Nov 27, 2009 at 09:26:23PM +0100, andrej.gelenberg@udo.edu wrote:

> The eepc-latop-rfkill should be hard block. If the LED is not on,
> my wlan-card won't transmit. The eeepc-laptop is only driver
> which use hotplug-subsystem to hide the hardware.

No. The *hardware* disables the PCI device, at which point all reads 
return errors and drivers fall over. The eeepc-laptop driver then hides 
the device because it's no longer there.

Now, it's entirely possible that this behaviour is no longer present on 
the 1005h. That's fine, and it necessitates changing the behaviour of 
the driver. But it's not a reason for removing the functionality 
entirely, because the 700s, 900s and earlier 1000 series *do* require 
that PCI hotplugging be peformed.

(Well. There's a separate situation where the PCI runtime power 
management code is going to interfere with the way eeepc-laptop does 
things, and this functionality is going to need to be added to the PCI 
core and removed from eeepc-laptop)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: eeepc-laptop: bugreport

[Corentin Chary]

On Fri, Nov 27, 2009 at 10:58 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, Nov 27, 2009 at 09:26:23PM +0100, andrej.gelenberg@udo.edu wrote:
>
>> The eepc-latop-rfkill should be hard block. If the LED is not on,
>> my wlan-card won't transmit. The eeepc-laptop is only driver
>> which use hotplug-subsystem to hide the hardware.
>
> No. The *hardware* disables the PCI device, at which point all reads
> return errors and drivers fall over. The eeepc-laptop driver then hides
> the device because it's no longer there.
>
> Now, it's entirely possible that this behaviour is no longer present on
> the 1005h. That's fine, and it necessitates changing the behaviour of
> the driver. But it's not a reason for removing the functionality
> entirely, because the 700s, 900s and earlier 1000 series *do* require
> that PCI hotplugging be peformed.
>
> (Well. There's a separate situation where the PCI runtime power
> management code is going to interfere with the way eeepc-laptop does
> things, and this functionality is going to need to be added to the PCI
> core and removed from eeepc-laptop)

Matthew, do you think that we could skip the hotplug code when all
rfkill notifier (_SB.PCI0.P0P[5,6,7]) fail to register ?

This should work at least for 1005ha.

-- 
Corentin Chary
http://xf.iksaif.net

Re: eeepc-laptop: bugreport

[Matthew Garrett]

That seems like a sane short-term fix, but we're going to have to rework 
this once the PCI tree gets merged. I'll try to sort that out.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[PATCH] eeepc-laptop: disable pci hotplug code when all notifiers fail to load

[Corentin Chary]

This is a short term workaround for Eeepc 1005HA.

refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570>

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
---
 drivers/platform/x86/eeepc-laptop.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
index 356ca11..45c3f52 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -177,6 +177,7 @@ struct eeepc_laptop {
 
 	struct hotplug_slot *hotplug_slot;
 	struct mutex hotplug_lock;
+	bool hotplug_enabled;
 
 	struct led_classdev tpd_led;
 	int tpd_led_wk;
@@ -642,6 +643,7 @@ static int eeepc_register_rfkill_notifier(struct eeepc_laptop *eeepc,
 						     eeepc);
 		if (ACPI_FAILURE(status))
 			pr_warning("Failed to register notify on %s\n", node);
+		eeepc->hotplug_enabled = true;
 	} else
 		return -ENODEV;
 
@@ -845,7 +847,17 @@ static int eeepc_rfkill_init(struct eeepc_laptop *eeepc)
 	if (result && result != -ENODEV)
 		goto exit;
 
-	result = eeepc_setup_pci_hotplug(eeepc);
+	/*
+	 * Register notifiers first, if they all fail, we won't enable
+	 * pci hotplug because it's probably not needed for this model
+	 * (eg: 1005HA)
+	 */
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
+	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
+
+	if (eeepc->hotplug_enabled)
+		result = eeepc_setup_pci_hotplug(eeepc);
 	/*
 	 * If we get -EBUSY then something else is handling the PCI hotplug -
 	 * don't fail in this case
@@ -853,9 +865,6 @@ static int eeepc_rfkill_init(struct eeepc_laptop *eeepc)
 	if (result == -EBUSY)
 		result = 0;
 
-	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
-	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
-	eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
 	/*
 	 * Refresh pci hotplug in case the rfkill state was changed during
 	 * setup.
-- 
1.6.5.4

Re: [PATCH] eeepc-laptop: disable pci hotplug code when all notifiers fail to load

[Corentin Chary]

Hi Len,
Please merge this patch too, I forgot so send it to you earlier.
Thanks,


On Sun, Dec 13, 2009 at 10:16 PM, Corentin Chary <corentincj@iksaif.net> wrote:
> This is a short term workaround for Eeepc 1005HA.
>
> refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570>
>
> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
> ---
>  drivers/platform/x86/eeepc-laptop.c |   17 +++++++++++++----
>  1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
> index 356ca11..45c3f52 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -177,6 +177,7 @@ struct eeepc_laptop {
>
>        struct hotplug_slot *hotplug_slot;
>        struct mutex hotplug_lock;
> +       bool hotplug_enabled;
>
>        struct led_classdev tpd_led;
>        int tpd_led_wk;
> @@ -642,6 +643,7 @@ static int eeepc_register_rfkill_notifier(struct eeepc_laptop *eeepc,
>                                                     eeepc);
>                if (ACPI_FAILURE(status))
>                        pr_warning("Failed to register notify on %s\n", node);
> +               eeepc->hotplug_enabled = true;
>        } else
>                return -ENODEV;
>
> @@ -845,7 +847,17 @@ static int eeepc_rfkill_init(struct eeepc_laptop *eeepc)
>        if (result && result != -ENODEV)
>                goto exit;
>
> -       result = eeepc_setup_pci_hotplug(eeepc);
> +       /*
> +        * Register notifiers first, if they all fail, we won't enable
> +        * pci hotplug because it's probably not needed for this model
> +        * (eg: 1005HA)
> +        */
> +       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
> +       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
> +       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
> +
> +       if (eeepc->hotplug_enabled)
> +               result = eeepc_setup_pci_hotplug(eeepc);
>        /*
>         * If we get -EBUSY then something else is handling the PCI hotplug -
>         * don't fail in this case
> @@ -853,9 +865,6 @@ static int eeepc_rfkill_init(struct eeepc_laptop *eeepc)
>        if (result == -EBUSY)
>                result = 0;
>
> -       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P5");
> -       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P6");
> -       eeepc_register_rfkill_notifier(eeepc, "\\_SB.PCI0.P0P7");
>        /*
>         * Refresh pci hotplug in case the rfkill state was changed during
>         * setup.
> --
> 1.6.5.4
>
>



-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html