Hi,
In my quest to suck drivers into drivers/staging/ I noticed that the
at76_usb driver is being shipped by both Fedora and Ubuntu in their
kernels.
So I was wondering what the status of this driver is, and if I
could/should add it to drivers/staging/? If it's about to go into
2.6.28 then I'll hold off, but it would be nice to know what the status
is.
Also, it looks like it is being developed in a git tree, where is that
tree?
And, did you merge the USB DFU code into the driver itself? Having that
kind of functionality in the USB core is fine with me if you want me to
add that portion there, no reason it needs to be burried in individual
drivers.
thanks,
greg k-h
On Mon, Oct 06, 2008 at 11:23:13AM -0400, Dan Williams wrote:
> On Sat, 2008-10-04 at 23:16 -0700, Greg KH wrote:
> > On Sun, Oct 05, 2008 at 08:56:20AM +0300, Kalle Valo wrote:
> > > Greg KH <[email protected]> writes:
> > > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > > kernels.
> > >
> > > Yes, that's the original at76_usb driver which has it's own 802.11
> > > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > > feedback in linux-wireless I then started porting the driver to use
> > > mac80211.
> > >
> > > (Maybe I should have renamed the port to something else than at76_usb
> > > because having two different drivers with the same name creates
> > > confusion.)
> > >
> > > > So I was wondering what the status of this driver is, and if I
> > > > could/should add it to drivers/staging/?
> > >
> > > The original at76_usb is working quite well, but it's unacceptable for
> > > the mainline because we cannot have two 802.11 stacks in kernel.
> >
> > I understand this, but for the issue of the drivers/staging/ tree, it's
> > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > there :)
>
> Well, you have to ask yourself then, what's the point of putting that
> driver with it's own 802.11 stack into staging when it's never going to
> go into the mainline kernel until it uses mac80211?
Because at least 2 distros currently ship their kernels with it (Fedora
and Ubuntu), and people have that hardware today and want to use it with
Linux.
> Doesn't that direct effort away from porting the driver to mac80211,
> giving legitimacy to code that will never, ever get upstream until
> it's substantially rewritten anyway? Ideally we put Kalle's 802.11
> port in staging and then people can actually move things forward.
>
> Same thing for linux-wlan-ng really; if people just keep fixing bugs and
> keep improving p80211 without porting it to the standard kernel wireless
> bits, what's the point of having it in staging?
Users using their hardware with Linux today.
I'll gladly drop it from drivers/staging when the "real" version hits
mainline, until then, it should stay in staging, as that is the whole
point of it.
thanks,
greg k-h
On Sun, Oct 05, 2008 at 09:29:14AM +0300, Kalle Valo wrote:
> Greg KH <[email protected]> writes:
>
> >> > So I was wondering what the status of this driver is, and if I
> >> > could/should add it to drivers/staging/?
> >>
> >> The original at76_usb is working quite well, but it's unacceptable for
> >> the mainline because we cannot have two 802.11 stacks in kernel.
> >
> > I understand this, but for the issue of the drivers/staging/ tree, it's
> > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > there :)
>
> That's good.
>
> > See my previous posts on lkml for details on the staging tree if you
> > have questions about it.
> >
> > So for now, if no one really screams, I'll put Pavel's driver into the
> > drivers/staging/ tree so that users can use their devices. When your
> > driver is merged, we can merely delete this driver instead.
> >
> > Sound good?
>
> That sounds very good. User's benefit from this and that's what
> counts.
>
> BTW, Pavel doesn't have time for at76 anymore. So if you have any
> problems with Pavel's driver in the stating tree, I can help you.
Thanks for the offer, hopefully I'll not have to take you up on it.
greg k-h
On Sun, Oct 05, 2008 at 06:17:06PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> > > > > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > > > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > > > > kernels.
> > > > >
> > > > > Yes, that's the original at76_usb driver which has it's own 802.11
> > > > > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > > > > feedback in linux-wireless I then started porting the driver to use
> > > > > mac80211.
> > > > >
> > > > > (Maybe I should have renamed the port to something else than at76_usb
> > > > > because having two different drivers with the same name creates
> > > > > confusion.)
> > > > >
> > > > > > So I was wondering what the status of this driver is, and if I
> > > > > > could/should add it to drivers/staging/?
> > > > >
> > > > > The original at76_usb is working quite well, but it's unacceptable for
> > > > > the mainline because we cannot have two 802.11 stacks in kernel.
> > > >
> > > > I understand this, but for the issue of the drivers/staging/ tree, it's
> > > > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > > > there :)
> > >
> > > did you start working for Ubuntu now ;)
> >
> > Heh, no, I'm just, to quote Linux, now the "Maintainer of Crap". See
> > the lwn.net summary of the kernel summit for details :)
>
> I was mainly referring to Kyle from OLS a year ago ;)
Doh, I forgot about that joke!
sorry, was slow this morning...
greg k-h
On Thu, Oct 02, 2008 at 02:07:42PM -0700, Greg KH wrote:
> Hi,
>
> In my quest to suck drivers into drivers/staging/ I noticed that the
> at76_usb driver is being shipped by both Fedora and Ubuntu in their
> kernels.
>
> So I was wondering what the status of this driver is, and if I
> could/should add it to drivers/staging/? If it's about to go into
> 2.6.28 then I'll hold off, but it would be nice to know what the status
> is.
>
> Also, it looks like it is being developed in a git tree, where is that
> tree?
>
> And, did you merge the USB DFU code into the driver itself? Having that
> kind of functionality in the USB core is fine with me if you want me to
> add that portion there, no reason it needs to be burried in individual
> drivers.
Also, it may help to keep this status here, once we find out what it is:
http://wireless.kernel.org/en/users/Drivers/at76_usb
Luis
Hi Luis,
> > Well, you have to ask yourself then, what's the point of putting that
> > driver with it's own 802.11 stack into staging when it's never going to
> > go into the mainline kernel until it uses mac80211?
>
> And provided that there is an alternative driver that uses mac80211. Die
> out of tree drivers, die.
I can only second that. If it is a SoftMAC and not using mac80211 then
it is not even worth it. We want the mac80211 ported driver to go
upstream. Everything else is just waste of time.
Regards
Marcel
Pavel Roskin <[email protected]> writes:
>> I agree, it's very confusing. I'll change the name of the mac80211
>> port to something else, most probably to at76c50x-usb. Any comments?
>> Anyone?
>
> I'd rather avoid the old driver completely. But if we want to resurrect
> it, its name was "at76c503a".
The atmel driver says it supports that also that chipset:
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
Hence I would like to have the usb suffix in the name, just to avoid
the confusion.
--
Kalle Valo
Hi Greg,
> > > > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > > > kernels.
> > > >
> > > > Yes, that's the original at76_usb driver which has it's own 802.11
> > > > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > > > feedback in linux-wireless I then started porting the driver to use
> > > > mac80211.
> > > >
> > > > (Maybe I should have renamed the port to something else than at76_usb
> > > > because having two different drivers with the same name creates
> > > > confusion.)
> > > >
> > > > > So I was wondering what the status of this driver is, and if I
> > > > > could/should add it to drivers/staging/?
> > > >
> > > > The original at76_usb is working quite well, but it's unacceptable for
> > > > the mainline because we cannot have two 802.11 stacks in kernel.
> > >
> > > I understand this, but for the issue of the drivers/staging/ tree, it's
> > > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > > there :)
> >
> > did you start working for Ubuntu now ;)
>
> Heh, no, I'm just, to quote Linux, now the "Maintainer of Crap". See
> the lwn.net summary of the kernel summit for details :)
I was mainly referring to Kyle from OLS a year ago ;)
Regards
Marcel
Pavel Roskin <[email protected]> writes:
> I'm not going to scream, and I'm not sure my opinion really matters, but
> I don't think it's a good idea to have two different drivers under the
> same name in different kernel trees.
>
> My preference is that we give a better exposure to the mac80211 based
> driver, so that potential contributors don't spend time on dead end
> code.
I agree, it's very confusing. I'll change the name of the mac80211
port to something else, most probably to at76c50x-usb. Any comments?
Anyone?
> Finally, I would prefer that my name is not used with either driver.
> The original driver was written by other people. I just cleaned it up
> and fixed some bugs.
Ok. After I rename the mac80211 port we don't have to use names of
persons anymore.
--
Kalle Valo
Kalle Valo <[email protected]> writes:
> The current mac80211 port is in linux-wireless (in one patch)
Sorry, I meant wireless-testing.
--
Kalle Valo
On Mon, Oct 06, 2008 at 08:23:13AM -0700, Dan Williams wrote:
> Well, you have to ask yourself then, what's the point of putting that
> driver with it's own 802.11 stack into staging when it's never going to
> go into the mainline kernel until it uses mac80211?
And provided that there is an alternative driver that uses mac80211. Die
out of tree drivers, die.
Luis
On Mon, 2008-10-06 at 08:39 +0300, Kalle Valo wrote:
> Pavel Roskin <[email protected]> writes:
>
> > I'm not going to scream, and I'm not sure my opinion really matters, but
> > I don't think it's a good idea to have two different drivers under the
> > same name in different kernel trees.
> >
> > My preference is that we give a better exposure to the mac80211 based
> > driver, so that potential contributors don't spend time on dead end
> > code.
>
> I agree, it's very confusing. I'll change the name of the mac80211
> port to something else, most probably to at76c50x-usb. Any comments?
> Anyone?
I'd rather avoid the old driver completely. But if we want to resurrect
it, its name was "at76c503a".
--
Regards,
Pavel Roskin
On Mon, 2008-10-06 at 09:10 +0300, Kalle Valo wrote:
> Pavel Roskin <[email protected]> writes:
>
> >> I agree, it's very confusing. I'll change the name of the mac80211
> >> port to something else, most probably to at76c50x-usb. Any comments?
> >> Anyone?
> >
> > I'd rather avoid the old driver completely. But if we want to resurrect
> > it, its name was "at76c503a".
>
> The atmel driver says it supports that also that chipset:
>
> config ATMEL
> tristate "Atmel at76c50x chipset 802.11b support"
>
> Hence I would like to have the usb suffix in the name, just to avoid
> the confusion.
We'll get confusion either way, especially if we recover the old driver.
I see almost no interest to the driver after drivers for modern hardware
(like Broadcom, Intel, Ralink) became functional. The only activity I'm
aware of is in the Red Hat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=438606
I'm afraid the existing userbase just cannot support two different
drivers. There are not enough users to test them, report bugs and avoid
being confused by our actions.
--
Regards,
Pavel Roskin
On Mon, Oct 06, 2008 at 05:39:09PM -0400, John W. Linville wrote:
> On Mon, Oct 06, 2008 at 10:42:28PM +0200, Johannes Berg wrote:
> > On Mon, 2008-10-06 at 16:31 -0400, John W. Linville wrote:
> > > On Mon, Oct 06, 2008 at 04:12:20PM -0400, Dan Williams wrote:
> > > > On Mon, 2008-10-06 at 11:35 -0700, Greg KH wrote:
> > >
> > > > > I'll gladly drop it from drivers/staging when the "real" version hits
> > > > > mainline, until then, it should stay in staging, as that is the whole
> > > > > point of it.
> > > >
> > > > It does nobody any good if (a) the drivers are _never_ going to go
> > > > upstream, and (b) if the drivers aren't going to get any attention in
> > > > their current form because of (a).
> > > >
> > > > I don't care if the driver allows peoples hardware to work; I want a
> > > > driver that makes peoples hardware work _well_. Out of tree drivers
> > > > that are never going upstream will not work well.
> > >
> > > I think/thought the main point of -staging was to give drivers
> > > visibility in hopes of people working to fix them.
> >
> > Shouldn't then the mac80211-based at76_usb be in -staging instead? That
> > one might not work completely, but at least it's fixable without a
> > rewrite.
>
> Yes, probably so. That is what I had planned to send to Greg, but I
> was thinking that the version currently in wireless-testing probably
> won't compile against -staging (which is based on 2.6.27).
No, sorry, I've moved my -staging tree into my "main" kernel development
tree which is based on 2.6.27-rc8 right now.
So if you have a version that you would rather see instead of the "old"
one in drivers/staging/ please feel free to send it to me.
thanks,
greg k-h
Luis R. Rodriguez <[email protected]> writes:
> Also, it may help to keep this status here, once we find out what it is:
>
> http://wireless.kernel.org/en/users/Drivers/at76_usb
I added a small status section to the wiki.
--
Kalle Valo
Hi Kalle,
> > In my quest to suck drivers into drivers/staging/ I noticed that the
> > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > kernels.
>
> Yes, that's the original at76_usb driver which has it's own 802.11
> stack. Pavel Rosking was the maintainer of that driver. Based on the
> feedback in linux-wireless I then started porting the driver to use
> mac80211.
>
> (Maybe I should have renamed the port to something else than at76_usb
> because having two different drivers with the same name creates
> confusion.)
>
> > So I was wondering what the status of this driver is, and if I
> > could/should add it to drivers/staging/?
>
> The original at76_usb is working quite well, but it's unacceptable for
> the mainline because we cannot have two 802.11 stacks in kernel.
>
> I'm working to get the mac80211 port to mainline. But the port is
> still unstable, biggest problem being that firmware seems to crash
> when I associate to the same AP twice. I'm sure this is a bug in the
> port, I just haven't found it yet.
>
> > If it's about to go into 2.6.28 then I'll hold off, but it would be
> > nice to know what the status is.
>
> The mac80211 port is not ready for mainline yet, my aim is to get it
> ready during this year.
>
> > Also, it looks like it is being developed in a git tree, where is that
> > tree?
>
> The originial at76_usb git tree was here:
>
> http://git.80211libre.org/at76_usb.git/
>
> But it seems to be gone now. The current mac80211 port is in
> linux-wireless (in one patch) and the original history is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-legacy.git at76
>
> > And, did you merge the USB DFU code into the driver itself?
>
> Yes, someone implemented it in driver.
>
> > Having that kind of functionality in the USB core is fine with me if
> > you want me to add that portion there, no reason it needs to be
> > burried in individual drivers.
>
> USB DFU is a standard? So it seems:
>
> http://wiki.openmoko.org/wiki/USB_DFU
>
> Heh, I didn't know this. I though it was some Atmel proprietary
> interface :)
>
> I might be interested in getting DFU into USB core, because I would
> like to learn more about USB. But first I need to get at76_usb stable.
please be careful with this. I have seen so many broken or vendor
enhanced DFU stuff that it might be not a good idea to put it into the
USB core since it would be full of quirks.
I do have my own dfutool used for firmware flashing and the OpenMoko
project got their own dfu-util. Both in userspace.
Regards
Marcel
On Mon, 2008-10-06 at 16:31 -0400, John W. Linville wrote:
> On Mon, Oct 06, 2008 at 04:12:20PM -0400, Dan Williams wrote:
> > On Mon, 2008-10-06 at 11:35 -0700, Greg KH wrote:
>
> > > I'll gladly drop it from drivers/staging when the "real" version hits
> > > mainline, until then, it should stay in staging, as that is the whole
> > > point of it.
> >
> > It does nobody any good if (a) the drivers are _never_ going to go
> > upstream, and (b) if the drivers aren't going to get any attention in
> > their current form because of (a).
> >
> > I don't care if the driver allows peoples hardware to work; I want a
> > driver that makes peoples hardware work _well_. Out of tree drivers
> > that are never going upstream will not work well.
>
> I think/thought the main point of -staging was to give drivers
> visibility in hopes of people working to fix them.
Shouldn't then the mac80211-based at76_usb be in -staging instead? That
one might not work completely, but at least it's fixable without a
rewrite.
johannes
On Sun, Oct 05, 2008 at 08:41:12AM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> > > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > > kernels.
> > >
> > > Yes, that's the original at76_usb driver which has it's own 802.11
> > > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > > feedback in linux-wireless I then started porting the driver to use
> > > mac80211.
> > >
> > > (Maybe I should have renamed the port to something else than at76_usb
> > > because having two different drivers with the same name creates
> > > confusion.)
> > >
> > > > So I was wondering what the status of this driver is, and if I
> > > > could/should add it to drivers/staging/?
> > >
> > > The original at76_usb is working quite well, but it's unacceptable for
> > > the mainline because we cannot have two 802.11 stacks in kernel.
> >
> > I understand this, but for the issue of the drivers/staging/ tree, it's
> > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > there :)
>
> did you start working for Ubuntu now ;)
Heh, no, I'm just, to quote Linux, now the "Maintainer of Crap". See
the lwn.net summary of the kernel summit for details :)
thanks,
greg k-h
On Mon, Oct 06, 2008 at 04:12:20PM -0400, Dan Williams wrote:
> On Mon, 2008-10-06 at 11:35 -0700, Greg KH wrote:
> > I'll gladly drop it from drivers/staging when the "real" version hits
> > mainline, until then, it should stay in staging, as that is the whole
> > point of it.
>
> It does nobody any good if (a) the drivers are _never_ going to go
> upstream, and (b) if the drivers aren't going to get any attention in
> their current form because of (a).
>
> I don't care if the driver allows peoples hardware to work; I want a
> driver that makes peoples hardware work _well_. Out of tree drivers
> that are never going upstream will not work well.
I think/thought the main point of -staging was to give drivers
visibility in hopes of people working to fix them.
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Mon, Oct 06, 2008 at 10:42:28PM +0200, Johannes Berg wrote:
> On Mon, 2008-10-06 at 16:31 -0400, John W. Linville wrote:
> > On Mon, Oct 06, 2008 at 04:12:20PM -0400, Dan Williams wrote:
> > > On Mon, 2008-10-06 at 11:35 -0700, Greg KH wrote:
> >
> > > > I'll gladly drop it from drivers/staging when the "real" version hits
> > > > mainline, until then, it should stay in staging, as that is the whole
> > > > point of it.
> > >
> > > It does nobody any good if (a) the drivers are _never_ going to go
> > > upstream, and (b) if the drivers aren't going to get any attention in
> > > their current form because of (a).
> > >
> > > I don't care if the driver allows peoples hardware to work; I want a
> > > driver that makes peoples hardware work _well_. Out of tree drivers
> > > that are never going upstream will not work well.
> >
> > I think/thought the main point of -staging was to give drivers
> > visibility in hopes of people working to fix them.
>
> Shouldn't then the mac80211-based at76_usb be in -staging instead? That
> one might not work completely, but at least it's fixable without a
> rewrite.
Yes, probably so. That is what I had planned to send to Greg, but I
was thinking that the version currently in wireless-testing probably
won't compile against -staging (which is based on 2.6.27).
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Sun, 2008-10-05 at 09:29 +0300, Kalle Valo wrote:
> > So for now, if no one really screams, I'll put Pavel's driver into the
> > drivers/staging/ tree so that users can use their devices. When your
> > driver is merged, we can merely delete this driver instead.
> >
> > Sound good?
>
> That sounds very good. User's benefit from this and that's what
> counts.
>
> BTW, Pavel doesn't have time for at76 anymore. So if you have any
> problems with Pavel's driver in the stating tree, I can help you.
I'm not going to scream, and I'm not sure my opinion really matters, but
I don't think it's a good idea to have two different drivers under the
same name in different kernel trees.
My preference is that we give a better exposure to the mac80211 based
driver, so that potential contributors don't spend time on dead end
code.
Finally, I would prefer that my name is not used with either driver.
The original driver was written by other people. I just cleaned it up
and fixed some bugs.
--
Regards,
Pavel Roskin
On Sat, 2008-10-04 at 23:16 -0700, Greg KH wrote:
> On Sun, Oct 05, 2008 at 08:56:20AM +0300, Kalle Valo wrote:
> > Greg KH <[email protected]> writes:
> > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > kernels.
> >
> > Yes, that's the original at76_usb driver which has it's own 802.11
> > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > feedback in linux-wireless I then started porting the driver to use
> > mac80211.
> >
> > (Maybe I should have renamed the port to something else than at76_usb
> > because having two different drivers with the same name creates
> > confusion.)
> >
> > > So I was wondering what the status of this driver is, and if I
> > > could/should add it to drivers/staging/?
> >
> > The original at76_usb is working quite well, but it's unacceptable for
> > the mainline because we cannot have two 802.11 stacks in kernel.
>
> I understand this, but for the issue of the drivers/staging/ tree, it's
> ok for us to have as many 802.11 stacks in the kernel as we can cram in
> there :)
Well, you have to ask yourself then, what's the point of putting that
driver with it's own 802.11 stack into staging when it's never going to
go into the mainline kernel until it uses mac80211? Doesn't that direct
effort away from porting the driver to mac80211, giving legitimacy to
code that will never, ever get upstream until it's substantially
rewritten anyway? Ideally we put Kalle's 802.11 port in staging and
then people can actually move things forward.
Same thing for linux-wlan-ng really; if people just keep fixing bugs and
keep improving p80211 without porting it to the standard kernel wireless
bits, what's the point of having it in staging?
Dan
> See my previous posts on lkml for details on the staging tree if you
> have questions about it.
>
> So for now, if no one really screams, I'll put Pavel's driver into the
> drivers/staging/ tree so that users can use their devices. When your
> driver is merged, we can merely delete this driver instead.
>
> Sound good?
>
> > > And, did you merge the USB DFU code into the driver itself?
> >
> > Yes, someone implemented it in driver.
> >
> > > Having that kind of functionality in the USB core is fine with me if
> > > you want me to add that portion there, no reason it needs to be
> > > burried in individual drivers.
> >
> > USB DFU is a standard? So it seems:
> >
> > http://wiki.openmoko.org/wiki/USB_DFU
> >
> > Heh, I didn't know this. I though it was some Atmel proprietary
> > interface :)
>
> Oh yeah, I wrote portions of that spec, oh so long ago :)
>
> > I might be interested in getting DFU into USB core, because I would
> > like to learn more about USB. But first I need to get at76_usb stable.
>
> Fair enough, patches are always welcome.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Greg,
> > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > kernels.
> >
> > Yes, that's the original at76_usb driver which has it's own 802.11
> > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > feedback in linux-wireless I then started porting the driver to use
> > mac80211.
> >
> > (Maybe I should have renamed the port to something else than at76_usb
> > because having two different drivers with the same name creates
> > confusion.)
> >
> > > So I was wondering what the status of this driver is, and if I
> > > could/should add it to drivers/staging/?
> >
> > The original at76_usb is working quite well, but it's unacceptable for
> > the mainline because we cannot have two 802.11 stacks in kernel.
>
> I understand this, but for the issue of the drivers/staging/ tree, it's
> ok for us to have as many 802.11 stacks in the kernel as we can cram in
> there :)
did you start working for Ubuntu now ;)
Regards
Marcel
On Sun, Oct 05, 2008 at 08:56:20AM +0300, Kalle Valo wrote:
> Greg KH <[email protected]> writes:
> > In my quest to suck drivers into drivers/staging/ I noticed that the
> > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > kernels.
>
> Yes, that's the original at76_usb driver which has it's own 802.11
> stack. Pavel Rosking was the maintainer of that driver. Based on the
> feedback in linux-wireless I then started porting the driver to use
> mac80211.
>
> (Maybe I should have renamed the port to something else than at76_usb
> because having two different drivers with the same name creates
> confusion.)
>
> > So I was wondering what the status of this driver is, and if I
> > could/should add it to drivers/staging/?
>
> The original at76_usb is working quite well, but it's unacceptable for
> the mainline because we cannot have two 802.11 stacks in kernel.
I understand this, but for the issue of the drivers/staging/ tree, it's
ok for us to have as many 802.11 stacks in the kernel as we can cram in
there :)
See my previous posts on lkml for details on the staging tree if you
have questions about it.
So for now, if no one really screams, I'll put Pavel's driver into the
drivers/staging/ tree so that users can use their devices. When your
driver is merged, we can merely delete this driver instead.
Sound good?
> > And, did you merge the USB DFU code into the driver itself?
>
> Yes, someone implemented it in driver.
>
> > Having that kind of functionality in the USB core is fine with me if
> > you want me to add that portion there, no reason it needs to be
> > burried in individual drivers.
>
> USB DFU is a standard? So it seems:
>
> http://wiki.openmoko.org/wiki/USB_DFU
>
> Heh, I didn't know this. I though it was some Atmel proprietary
> interface :)
Oh yeah, I wrote portions of that spec, oh so long ago :)
> I might be interested in getting DFU into USB core, because I would
> like to learn more about USB. But first I need to get at76_usb stable.
Fair enough, patches are always welcome.
thanks,
greg k-h
Greg KH <[email protected]> writes:
> Hi,
Hello,
> In my quest to suck drivers into drivers/staging/ I noticed that the
> at76_usb driver is being shipped by both Fedora and Ubuntu in their
> kernels.
Yes, that's the original at76_usb driver which has it's own 802.11
stack. Pavel Rosking was the maintainer of that driver. Based on the
feedback in linux-wireless I then started porting the driver to use
mac80211.
(Maybe I should have renamed the port to something else than at76_usb
because having two different drivers with the same name creates
confusion.)
> So I was wondering what the status of this driver is, and if I
> could/should add it to drivers/staging/?
The original at76_usb is working quite well, but it's unacceptable for
the mainline because we cannot have two 802.11 stacks in kernel.
I'm working to get the mac80211 port to mainline. But the port is
still unstable, biggest problem being that firmware seems to crash
when I associate to the same AP twice. I'm sure this is a bug in the
port, I just haven't found it yet.
> If it's about to go into 2.6.28 then I'll hold off, but it would be
> nice to know what the status is.
The mac80211 port is not ready for mainline yet, my aim is to get it
ready during this year.
> Also, it looks like it is being developed in a git tree, where is that
> tree?
The originial at76_usb git tree was here:
http://git.80211libre.org/at76_usb.git/
But it seems to be gone now. The current mac80211 port is in
linux-wireless (in one patch) and the original history is here:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-legacy.git at76
> And, did you merge the USB DFU code into the driver itself?
Yes, someone implemented it in driver.
> Having that kind of functionality in the USB core is fine with me if
> you want me to add that portion there, no reason it needs to be
> burried in individual drivers.
USB DFU is a standard? So it seems:
http://wiki.openmoko.org/wiki/USB_DFU
Heh, I didn't know this. I though it was some Atmel proprietary
interface :)
I might be interested in getting DFU into USB core, because I would
like to learn more about USB. But first I need to get at76_usb stable.
--
Kalle Valo
Greg KH <[email protected]> writes:
>> > So I was wondering what the status of this driver is, and if I
>> > could/should add it to drivers/staging/?
>>
>> The original at76_usb is working quite well, but it's unacceptable for
>> the mainline because we cannot have two 802.11 stacks in kernel.
>
> I understand this, but for the issue of the drivers/staging/ tree, it's
> ok for us to have as many 802.11 stacks in the kernel as we can cram in
> there :)
That's good.
> See my previous posts on lkml for details on the staging tree if you
> have questions about it.
>
> So for now, if no one really screams, I'll put Pavel's driver into the
> drivers/staging/ tree so that users can use their devices. When your
> driver is merged, we can merely delete this driver instead.
>
> Sound good?
That sounds very good. User's benefit from this and that's what
counts.
BTW, Pavel doesn't have time for at76 anymore. So if you have any
problems with Pavel's driver in the stating tree, I can help you.
--
Kalle Valo
Marcel Holtmann <[email protected]> writes:
> Hi Kalle,
Hello Marcel,
>> I might be interested in getting DFU into USB core, because I would
>> like to learn more about USB. But first I need to get at76_usb stable.
>
> please be careful with this. I have seen so many broken or vendor
> enhanced DFU stuff that it might be not a good idea to put it into the
> USB core since it would be full of quirks.
Heh, I should have guessed this. Thanks for the heads up.
> I do have my own dfutool used for firmware flashing and the OpenMoko
> project got their own dfu-util. Both in userspace.
Thanks, I'll take a look at them.
--
Kalle Valo
On Mon, 2008-10-06 at 11:35 -0700, Greg KH wrote:
> On Mon, Oct 06, 2008 at 11:23:13AM -0400, Dan Williams wrote:
> > On Sat, 2008-10-04 at 23:16 -0700, Greg KH wrote:
> > > On Sun, Oct 05, 2008 at 08:56:20AM +0300, Kalle Valo wrote:
> > > > Greg KH <[email protected]> writes:
> > > > > In my quest to suck drivers into drivers/staging/ I noticed that the
> > > > > at76_usb driver is being shipped by both Fedora and Ubuntu in their
> > > > > kernels.
> > > >
> > > > Yes, that's the original at76_usb driver which has it's own 802.11
> > > > stack. Pavel Rosking was the maintainer of that driver. Based on the
> > > > feedback in linux-wireless I then started porting the driver to use
> > > > mac80211.
> > > >
> > > > (Maybe I should have renamed the port to something else than at76_usb
> > > > because having two different drivers with the same name creates
> > > > confusion.)
> > > >
> > > > > So I was wondering what the status of this driver is, and if I
> > > > > could/should add it to drivers/staging/?
> > > >
> > > > The original at76_usb is working quite well, but it's unacceptable for
> > > > the mainline because we cannot have two 802.11 stacks in kernel.
> > >
> > > I understand this, but for the issue of the drivers/staging/ tree, it's
> > > ok for us to have as many 802.11 stacks in the kernel as we can cram in
> > > there :)
> >
> > Well, you have to ask yourself then, what's the point of putting that
> > driver with it's own 802.11 stack into staging when it's never going to
> > go into the mainline kernel until it uses mac80211?
>
> Because at least 2 distros currently ship their kernels with it (Fedora
> and Ubuntu), and people have that hardware today and want to use it with
> Linux.
>
> > Doesn't that direct effort away from porting the driver to mac80211,
> > giving legitimacy to code that will never, ever get upstream until
> > it's substantially rewritten anyway? Ideally we put Kalle's 802.11
> > port in staging and then people can actually move things forward.
> >
> > Same thing for linux-wlan-ng really; if people just keep fixing bugs and
> > keep improving p80211 without porting it to the standard kernel wireless
> > bits, what's the point of having it in staging?
>
> Users using their hardware with Linux today.
>
> I'll gladly drop it from drivers/staging when the "real" version hits
> mainline, until then, it should stay in staging, as that is the whole
> point of it.
It does nobody any good if (a) the drivers are _never_ going to go
upstream, and (b) if the drivers aren't going to get any attention in
their current form because of (a).
I don't care if the driver allows peoples hardware to work; I want a
driver that makes peoples hardware work _well_. Out of tree drivers
that are never going upstream will not work well.
Dan