Re: h5400_wifi - proposal for the driver

Hi,

On Thu, May 8, 2008 at 10:13 AM, Milan Plzik <milan.plzik_at_gmail.com> wrote:
>
> On Št, 2008-05-08 at 00:53 +0200, Michal Panczyk wrote:
>> Hello (full working) list :)
>
> Hello:)
>
>> I would like to propose the first step of getting a nice wifi driver
>> for h5000 devices. I tried to get some help on that on kernel-discuss
>> but due to current situation of the kernel development it failed.
>>
>> My work was mostly concentrated on h5400_wifi.c - mostly stripping the
>> old version to the very necessary minimum. All the work was inspired
>> by Milan Plizk - chats on irc, post at angstrom-devel and or bugzilla.
>> In current form driver works. The procedure is simple (but needs to be
>> simplified !). The driver sets two bits to enable the wifi device -
>> for details see [1].
>> To get the wifi working the ohci_hcd need to be loaded before the
>> h5400_wifi. I think this is the first thing that needs to be changed -
>> make the h5400_wifi depend on the ohci module.
>
> This sounds viable -- you could use request_module to do that, and
> combined with proper Kconfig dependency on OHCI_HCD, it should work as
> desired (if h5400_wifi is compiled and loaded, we are sure we also have
> ohci_hcd in memory).

Ok - it seems this is the thing I was missing all the time - I will
give it a try - maybe tonight:)
On the other hand - how should it be handled after merging to h5400.c
? I would not like to add dependency for ohci to h5400.c ...

>> The next thing the module does is activates the led. In current form
>> it is the left red one blinking, showing that the module is loaded. It
>> does not show "connected" state, or rx/tx activity (as in wince -
>> AFAIR).
>
> LEDs should be fully controlled by at76_usb in ideal case (newer
> at76_usb is even capable of triggering LEDs). There should be somewhere
> also patched version of older at76_usb, which "blinks" (or at least some
> patch) :)

Do you know how to do that ?
It means no led control in h5400_wifi.c and no h5400_wifi in leds
description in h5400.c....

>> Another problem with the driver, or more precisely with the kernel is
>> that the GPIOs are not reseted after reboot - once the module is
>> loaded, bits are set, and the machine is reseted, the bits stay set
>> on. This results in uncontrolled wifi activation after loading
>> ohci_hcd module, with no h5400_wifi module.
>
> If you are speaking about "hardware reset", I think disabling wifi in
> h5400.c would suffice. But this is more an ugly hack than good solution.
> Maybe if would be worth the effort if h5400_wifi exported some sysfs
> files, which could be used for manipulation with wifi state; maybe even
> separate for radio and for wifi chip itself.

I was thinking of setting the proper bits at machine initzation... I
guess it should be done and at the current state is missing in the
kernel. Could somebody more experienced (a hh.org and kernel-discuss
veteran :) ) confirm that ?
>>
>> The future of the driver is:
>> -merging it to h5400.c
>
> Yes, this is neccessity.
>
>> -figure out a nice way to control activation if the wifi device
>> instead of loading/unloading module
>
> See two paragraphs above :)
>
>> -making it powersave in sleepmode
>> -more control of leds (rx, tx activity signaling)
>
> I think this should be handled by the at76_usb driver itself.
>
>> -investigating the driver crashes
>
> ... and this as well, plus samcop's DMA and OHCI :)

I have never seen any _pure_ driver crashes. I had some problems with
turning on the wifi - I guess it was something with irq - I don't
remember right now.... It has been a while since I played with it.
>>
>> Please keep in mind that this is just a proposal - I worked on that
>> and tested the driver in a bit older kernel version - one from
>> angstrom-devel, where bt and bl were not yet merged in the h5400.c. I
>> can supply a test image after some progress is made.
>>
>> I attach a patch against cvs.
>>
>> I would be more than happy to answer all questions concerning this
>> proposal. I would really like to see it working with no "ugly hacks",
>> so all the help is appreciated.
>
> The sysfs-way might be good enough for now. I also have the original
> idea in my head, where wifi could be enabled using ifconfig wlan0 up,
> but I'm not sure whether it can be hacked easily enough.

I remember your idea - making at76_usb create a fake interface and
activate it after ifconfig wlan up - right ?

> Milan
>

Erik :
I have tested the driver against "current" cvs - current means a month
old (ago). But since hardly anything has changed I guess it can be
called tested. Wifi works like charm. The only problem is with
initzation - is sometimes goes smoothly, sometimes not that smoothly.
At the current state please don't commit it - yet... At least not
before I add pulling the ohci and some testing, by me and a volunteer
(anyone willing to test it ? )

Thanks guys for reply. It gives some motivation for future work - lack
of response is really demotivating.

-- 
Michal Panczyk