[Debian-eeepc-devel] [RFC] wireless.sh: remove special treatment for Atheros

[Alan Jenkins]

On 8/13/09, Damyan Ivanov <dmn at debian.org> wrote:
> -=| Alan Jenkins, Wed, Aug 12, 2009 at 09:53:01PM +0100 |=-
>> Ok, I tested the patch.  It does work with 2.6.26 + madwifi +
>> pciehp_force=1 (whew).  Also 2.6.31-rc, both with and without pciehp.
>
> I aassume you mean the patch to eeepc-acpi-scripts.

Yes.

> Can you also try the stock unstable kernel (2.6.30)? That would be
> appreciated by unstable users.

Sure, better safe than sorry.  I've tested that now and it works fine,

> The current code in the init script says:
>     # Load pciehp if required.
>     # There are three recognised cases:
>     # - kernel 2.6.26 & older: two parameters required
>     # - kernel 2.6.27 & .28  : one of those parameters has been removed
>     # - kernel 2.6.29 & newer: hotplugging is handled in eeepc-laptop
>
> This means pciehp_force=1 is used on anything prior to 2.6.29 (plus
> pciehp_slot_with_bus=1 with 2.6.26 and older).
>
> Does this sound right for madwifi (.26) and ath5k (.27+)?

madwifi vs. ath5k souldn't matter, just the hotplug code.  But yes,
that looks fine.

I don't know about pciehp_slot_with_bus.  But it's true that
eeepc-laptop gained hotplug support in 2.6.29.

>
> On related note, I see the eeepc-acpi-scripts patch removed
> workarounds that are not necessary and only add noise. The real fix
> for the ath5k problems is in eeepc-laptop, right? What is the status
> of your patch to that? Also, until the patch reaches Debian, is there
> other workaround we may want to implement in eeepc-acpi-scripts?
>

The eeepc-laptop hotplug was the important fix.  It's present in
mainline 2.6.29.  (I can only take credit for testing it; it wasn't my
patch).

Yeah, I don't know what the "workarounds" in wireless.sh were actually
for.  I'd chalk it down to cargo-cult programming ;-p.  I don't have
any new workarounds to suggest.

As far as I can tell, simply loading pciehp with pciehp_force=1 (as
the eeepc init script does) is a completely useable workaround for
older kernels.  (Modulo a few seconds delay on boot / suspend /
resume.  Modulo the bug I mentioned, when the user toggles the
wireless multiple times in quick succession).

If there's anything else you would like to know, feel free to ask.
Alan