ath5k/madwifi status on samsung q1

[Loïc Minier]

        Hi

On Wed, Oct 22, 2008, Amit Kucheria wrote:
> So the issue here is that -mobile team is upset that a newer ath5k
> cannot be shipped in the default kernel.

 Hmm no, we want working wifi; we don't want ath5k in particular.  Newer
 ath5k if it fixes wifi (which I'm told it does) is fine, but madwifi
 has been working reliably for us too, and we would have been happy with
 madwifi as well.

 bug #284354 is about the two drivers being loaded at the same time
 which is completely wrong on its own.

>                                          As the above bug points out,
> the AR2424 chip in the samsung is showing the following
> characteristics:
> - works with madwifi [only wep works since the wpasupplicant module
> for madwifi was removed?]

 No, WPA works fine.  I have WPA TKIP at home, when I boot today's daily
 mobile image it uses madwifi and connects to my wifi just fine.  When I
 suspend/resume, I end up with both ath5k and madwifi half loaded and
 wifi doesn't work anymore.

 I understand that even if the madwifi backend of wpasupplicant was
 removed, another backend works with madwifi modules.

> - does not work with in-kernel ath5k

 Correct.

> - works with ath5k from linux-backports-modules (LBM) [full
> functionality including WPA]

 (NB: didn't try this out, but this was confirmed by various people.)

> Contention point ---> Mobile team would like ath5k from LBM to be
> integrated into our kernel.

 Not really; I've been recommending consistently to blacklist ath5k on
 our PCI id.  Until recently, I didn't see any other hardware working
 with ath5k with the same PCI id, but this comment suggest that there
 is some EeePC hardware with the same PCI id and working wifi with
 ath5k:
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/284354/comments/4

> Why updating in-kernel ath5k is not so easy?
> ------------------------------------------------------
> 2. And the above diff doesn't even compile with our kernel. Because it
> needs updated headers like include/linux/mac80211.h

 Ok; so not an option; thanks for looking into it.

> Solution for -mobile
> -----------------------
> 1. Install LBM by default
>     - risk of regression if kernel-team adds something else to LBM
> 2. Blacklist ath5k in the -mobile image
>     - madwifi will work with WEP
>     - mobile images will break for eee pc users

 This issue is not specific to mobile images/flavours; it affects all
 flavours.

> Any other possibilities that I might have missed?

 1. One option I've recommended in the past is changing PCI ids; sadly:
     * it's very late in the cycle; only one kernel upload remains
       between RC and final (AIUI)
     * we have contradictory reports with the same PCI ids that only
       madwifi works (mobile team, Q1U), or that ath5k works (EeePC
       comment above); these reports DO NOT mention the actual wifi
       setup, and I've seen no report that madwifi is not working for
       these EeePC users
     * we don't have test hardware or testers to ensure testing in time
       before release; we'd need to identify people and have testing be
       done on time to ensure we don't regress wifi support further with
       any change in PCI ids

 2. Shipping multiple versions of ath5k/mac80211 or of madwifi
     * while technically feasible, would eat large amount of time
     * would make maintenance of linux or lrm harder
     * basically same issues with testing and timing as 1.


 So, you've looked into updating ath5k before release, that's not
 possible, I propose the following best effort measures:
 - kernel team continues looking into fixing ath5k in linux for Q1U /
   WPA as a SRU
 - we document the issue in the release notes, with known workarounds
   (either blacklisting madwifi or ath5k, or installing lbm's ath5k)
 - we provide linux-backports-modules as an installable .deb on the
   images, at least the mobile images, as to allow the release notes to
   give an easy networkless recipe to get wifi working (sudo gdebi
   /path/to/lbm.deb); this last idea is one by Oliver, thanks!


 I also highly recommend that the kernel team looks at preventing
 multiple drivers for the same PCI id to be selected.  Having ath5k and
 madwifi claim the same PCI ids and racing to get loaded, or having both
 of them loaded is completely broken and needs to be blocked ASAP.

   Cheers,
-- 
Loïc Minier