at76_usb development

at76_usb development

[Jason Andryuk]

Where should development on at76_usb take place?
staging-at76_usb-mention-mac80211-port-in-todo-file.patch mentions
John Linville's wireless-legacy tree with
revert-staging-at76_usb-update-drivers-staging-at76_usb-w-mac80211-port.patch
reverting mac80211.  wireless-legacy has not been updated since
2.6.27-rc4, but a quick comparison showed that it was more or less
equivalent to what is in wireless-testing/drivers/staging/at76_usb.

I have more or less tracked down an Oops on disconnect with the
wireless-testing version.  Hopefully the time spent has been
worthwhile.

Let me know,

Jason

Re: at76_usb development

[Oliver Neukum]

Am Wednesday 04 February 2009 05:05:04 schrieb Jason Andryuk:
> Where should development on at76_usb take place?
[..]
> I have more or less tracked down an Oops on disconnect with the
> wireless-testing version.  Hopefully the time spent has been
> worthwhile.
> 
> Let me know,

This is an important question. We cannot develop against widely
diverging versions. If the driver is changed a lot, development must happen
against the kernel version or it should be removed from the kernel.

	Regards
		Oliver
 

Re: at76_usb development

[John W. Linville]

On Wed, Feb 04, 2009 at 09:17:12AM +0100, Oliver Neukum wrote:
> Am Wednesday 04 February 2009 05:05:04 schrieb Jason Andryuk:
> > Where should development on at76_usb take place?
> [..]
> > I have more or less tracked down an Oops on disconnect with the
> > wireless-testing version.  Hopefully the time spent has been
> > worthwhile.
> > 
> > Let me know,
> 
> This is an important question. We cannot develop against widely
> diverging versions. If the driver is changed a lot, development must happen
> against the kernel version or it should be removed from the kernel.

AFAIK you should be sending patches to Greg against the version in
drivers/staging.  Kalle may want to be copied.

FWIW, I haven't seen the revised driver that Kalle is developing.
Hopefully we will see that before too long.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: at76_usb development

[Kalle Valo]

On Wed, Feb 4, 2009 at 4:43 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Wed, Feb 04, 2009 at 09:17:12AM +0100, Oliver Neukum wrote:
>> Am Wednesday 04 February 2009 05:05:04 schrieb Jason Andryuk:
>> > Where should development on at76_usb take place?
>> [..]
>> > I have more or less tracked down an Oops on disconnect with the
>> > wireless-testing version.  Hopefully the time spent has been
>> > worthwhile.
>> >
>> > Let me know,
>>
>> This is an important question. We cannot develop against widely
>> diverging versions. If the driver is changed a lot, development must happen
>> against the kernel version or it should be removed from the kernel.

My plan is that at76_usb is not going to get that much changes. I have
created a new driver at76c50x-usb which is basically at76_usb plus my
mac80211 port. That way users still have a working driver until
mac80211 port has stabilised.

> AFAIK you should be sending patches to Greg against the version in
> drivers/staging.  Kalle may want to be copied.

Yes, please cc also me. I try to keep up-to-date what's happening with
at76-usb so that the same fixes will be fixed in at76c50x-usb as well.

> FWIW, I haven't seen the revised driver that Kalle is developing.
> Hopefully we will see that before too long.

Hopefully I'll send a first version of at76c50-usb soon. Sorry for
taking it so long.

It's nice to see interest for at76_usb, though. I was sure that nobody
uses it anymore.

Kalle

Re: at76_usb development

[Oliver Neukum]

Am Wednesday 04 February 2009 16:48:11 schrieb Kalle Valo:
> > FWIW, I haven't seen the revised driver that Kalle is developing.
> > Hopefully we will see that before too long.
> 
> Hopefully I'll send a first version of at76c50-usb soon. Sorry for
> taking it so long.
> 
> It's nice to see interest for at76_usb, though. I was sure that nobody
> uses it anymore.

I am not using it. I was trying to get it into an acceptable shape from
a USB viewpoint.

	Regards
		Oliver

Re: at76_usb development

[Greg KH]

On Tue, Feb 03, 2009 at 11:05:04PM -0500, Jason Andryuk wrote:
> Where should development on at76_usb take place?

Kalle has a version that is being worked on.  I would suggest that being
the one.

thanks,

greg k-h

Re: at76_usb development

[Jason Andryuk]

On Wed, Feb 4, 2009 at 10:48 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> Hopefully I'll send a first version of at76c50-usb soon. Sorry for
> taking it so long.
>
> It's nice to see interest for at76_usb, though. I was sure that nobody
> uses it anymore.

Ok, the future is at76c50x-usb.  Kalle, I'd like to see the driver as
soon as possible since working on the staging version seems rather
pointless.

I did track down an oops related to workqueues on at76_usb + mac80211.
 I can send that out, but it isn't relevant to the old at76_usb in
staging.

I'd like to help so that my at76c503-i3861 adapter just works if I
need it in the future.

Jason

Re: at76_usb development

[Oliver Neukum]

Am Wednesday 04 February 2009 16:48:11 schrieb Kalle Valo:
> > AFAIK you should be sending patches to Greg against the version in
> > drivers/staging. =A0Kalle may want to be copied.
>=20
> Yes, please cc also me. I try to keep up-to-date what's happening wit=
h
> at76-usb so that the same fixes will be fixed in at76c50x-usb as well=
=2E

Here is what I found with at76-usb as it is in the current kernel:

 static int at76_wait_completion(struct at76_priv *priv, int cmd)
 {
        int status =3D 0;

        unsigned long timeout =3D jiffies + CMD_COMPLETION_TIMEOUT;

        do {

This can go wrong in a preemptible kernel. You have no guarantee the fu=
ll
timeout is granted.

@@ -1631,7 +1633,7 @@ static void at76_rx_tasklet(unsigned long param)
        buf =3D (struct at76_rx_buffer *)priv->rx_skb->data;

        if (urb->status !=3D 0) {
-               if (urb->status !=3D -ENOENT && urb->status !=3D -ECONN=
RESET)
+               if (urb->status !=3D -ENOENT && urb->status !=3D -ECONN=
RESET && urb->status !=3D -ESHUTDOWN)

Should also check for ESHUTDOWN, also in at76_mac80211_tx_callback()

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: at76_usb development

[Kalle Valo]

Oliver Neukum <oliver@neukum.org> writes:

> Am Wednesday 04 February 2009 16:48:11 schrieb Kalle Valo:
>> Yes, please cc also me. I try to keep up-to-date what's happening with
>> at76-usb so that the same fixes will be fixed in at76c50x-usb as well.
>
> Here is what I found with at76-usb as it is in the current kernel:
>
>  static int at76_wait_completion(struct at76_priv *priv, int cmd)
>  {
>         int status = 0;
>
>         unsigned long timeout = jiffies + CMD_COMPLETION_TIMEOUT;
>
>         do {
>
> This can go wrong in a preemptible kernel. You have no guarantee the full
> timeout is granted.
>
> @@ -1631,7 +1633,7 @@ static void at76_rx_tasklet(unsigned long param)
>         buf = (struct at76_rx_buffer *)priv->rx_skb->data;
>
>         if (urb->status != 0) {
> -               if (urb->status != -ENOENT && urb->status != -ECONNRESET)
> +               if (urb->status != -ENOENT && urb->status != -ECONNRESET && urb->status != -ESHUTDOWN)
>
> Should also check for ESHUTDOWN, also in at76_mac80211_tx_callback()

Thanks. I added these comments to my todo list, and will fix them
later.
 
-- 
Kalle Valo