Re: [PATCH] Add vt6656 driver to drivers/staging.

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Xose Vazquez Perez]

Dan Williams wrote:

> The only fixes that drivers are getting in staging now are netdev_ops,
> whitespace cleanups, and trivial fixes.  Nobody is actually rewriting
> the Ralink or Via staging drivers to use mac80211, which is what's
> needed for them to be merged.  Given that they are going nowhere, are

Only rtl8187se and wlan-ng don't have a mac80211 port.

mac80211 drivers:

agnx		-> http://git.sipsolutions.net/agnx.git
at76_usb	-> replacement already in kernel.org code at drivers/net/wireless/at76c50x-usb.[ch]
otus		-> replacement already in kernel.org code at drivers/net/wireless/ar9170/
rt2860		-> rt2800pci.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
rt2870		-> rt2800usb.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
rt3070		-> rt2800usb.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
rtl8187se	-> ???
stlc45xx	-> replacement already in kernel.org code at drivers/net/wireless/p54/p54spi*
winbond		-> http://code.google.com/p/winbondport/
wlan-ng		-> ftp://ftp.linux-wlan.org/pub/linux-wlan-ng/FAQ ???



I hope rt2800pci/usb to be included *ASAP*, because rt2800usb supports
more than 1oo USB devices and rt2800pci is included in a lot of
laptops(ask Torvalds [1] [2])

[1] http://marc.info/?l=linux-netdev&m=121799144422863&w=2
[2] http://marc.info/?l=linux-kernel&m=123187052023831&w=2



regards,
-- 
Polycommander, Erkowit, Urquiola, Andros Patria, Cason, Aegean Sea, Prestige, ...

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Wed, Apr 15, 2009 at 09:16:49PM +0200, Xose Vazquez Perez wrote:
> Dan Williams wrote:
> 
> > The only fixes that drivers are getting in staging now are netdev_ops,
> > whitespace cleanups, and trivial fixes.  Nobody is actually rewriting
> > the Ralink or Via staging drivers to use mac80211, which is what's
> > needed for them to be merged.  Given that they are going nowhere, are
> 
> Only rtl8187se and wlan-ng don't have a mac80211 port.
> 
> mac80211 drivers:
> 
> agnx		-> http://git.sipsolutions.net/agnx.git
> at76_usb	-> replacement already in kernel.org code at drivers/net/wireless/at76c50x-usb.[ch]
> otus		-> replacement already in kernel.org code at drivers/net/wireless/ar9170/
> rt2860		-> rt2800pci.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
> rt2870		-> rt2800usb.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
> rt3070		-> rt2800usb.[ch] http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git
> rtl8187se	-> ???
> stlc45xx	-> replacement already in kernel.org code at drivers/net/wireless/p54/p54spi*
> winbond		-> http://code.google.com/p/winbondport/
> wlan-ng		-> ftp://ftp.linux-wlan.org/pub/linux-wlan-ng/FAQ ???

Thanks for the summary.

Note, whenever a "real" wireless driver goes into the tree that
obsoletes any of the staging drivers, please let me know and I'll
instantly remove it.

Right now the otus code is staying because the ar9170 developers want it
to.

But what about at76_usb?  stlc45xx?  Do they now have workable drivers
to replace them in the tree today?  If so, _please_ let me know.


As for the other drivers, here's what I know:
	rtl8187se - a varient of rtl818x, someone just needs to do the
	work to add the proper parts to the existing driver.  I tried,
	and it wasn't obvious how to do this :(
	wlan-ng - this is being cleaned up by community members for
	eventual inclusion in the main tree.  It only supports a single
	type of USB device.
	winbond - community members are cleaning it up as well.

> I hope rt2800pci/usb to be included *ASAP*, because rt2800usb supports
> more than 1oo USB devices and rt2800pci is included in a lot of
> laptops(ask Torvalds [1] [2])
> 
> [1] http://marc.info/?l=linux-netdev&m=121799144422863&w=2
> [2] http://marc.info/?l=linux-kernel&m=123187052023831&w=2

That would be great to have in, what's keeping it from happening?

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Kalle Valo]

Greg KH <greg@kroah.com> writes:

> Note, whenever a "real" wireless driver goes into the tree that
> obsoletes any of the staging drivers, please let me know and I'll
> instantly remove it.
>
> Right now the otus code is staying because the ar9170 developers want it
> to.
>
> But what about at76_usb?  stlc45xx?  Do they now have workable drivers
> to replace them in the tree today?  If so, _please_ let me know.

I have received a report that at76_usb has worked better than
at76c50x-usb. Also p54spi implementation is quite new and not that much
tested.

If it's ok for you, I would like to have both at76_usb and stlc45xx in
the staging area for some time still. I will let you know when they can
be removed.

-- 
Kalle Valo

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Max Filippov]

> I have received a report that at76_usb has worked better than
> at76c50x-usb. Also p54spi implementation is quite new and not that much
> tested.
>
> If it's ok for you, I would like to have both at76_usb and stlc45xx in
> the staging area for some time still. I will let you know when they can
> be removed.
>
> --
> Kalle Valo

Kalle, what is the primary location for stlc45xx sources then? I see
that version in staging is pretty old.
-- 
Max

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Kalle Valo]

Max Filippov <jcmvbkbc@gmail.com> writes:

>> I have received a report that at76_usb has worked better than
>> at76c50x-usb. Also p54spi implementation is quite new and not that much
>> tested.
>>
>> If it's ok for you, I would like to have both at76_usb and stlc45xx in
>> the staging area for some time still. I will let you know when they can
>> be removed.
>
> Kalle, what is the primary location for stlc45xx sources then?

I have been thinking about using staging the primary location. What do
you think?

> I see that version in staging is pretty old.

Yeah, I have been planning to patch bomb Greg at some point with all the
patches from the stlc45xx git tree. It's just that n800 support is
currently broken in 2.6.30-rc1 from linux-omap tree :(

-- 
Kalle Valo

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Max Filippov]

>> Kalle, what is the primary location for stlc45xx sources then?
>
> I have been thinking about using staging the primary location. What do
> you think?

Partly agree: drivers/staging is better than gitorious and there are
more potential testers than at stlc45xx-devel@garage.maemo.org.
But I don't realize what is the purpose to have two drivers for one
hw? p54spi IMHO only lacks firmware restart feature now. And most of
the p54 code is used collectively by the pci, usb and spi, so it is
probably more tested than stlc45xx.

-- 
Max

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Kalle Valo]

Max Filippov <jcmvbkbc@gmail.com> writes:

>>> Kalle, what is the primary location for stlc45xx sources then?
>>
>> I have been thinking about using staging the primary location. What do
>> you think?
>
> Partly agree: drivers/staging is better than gitorious and there are
> more potential testers than at stlc45xx-devel@garage.maemo.org.

Good.

> But I don't realize what is the purpose to have two drivers for one
> hw? p54spi IMHO only lacks firmware restart feature now. And most of
> the p54 code is used collectively by the pci, usb and spi, so it is
> probably more tested than stlc45xx.

p54spi is definitely the future. Christian and you have done great work
to get p54spi working N800/N810.

-- 
Kalle Valo

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Ivo van Doorn]

Hi,

> > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb supports
> > more than 1oo USB devices and rt2800pci is included in a lot of
> > laptops(ask Torvalds [1] [2])
> > 
> > [1] http://marc.info/?l=linux-netdev&m=121799144422863&w=2
> > [2] http://marc.info/?l=linux-kernel&m=123187052023831&w=2
> 
> That would be great to have in, what's keeping it from happening?

In short: A stable workable driver.

The rt2800usb driver is pretty far (at least on my testsetup), but
still has problems with transmitting frames immediately after
association.

As for rt2800pci that card still refuses to anything. The MCU registers
simply refuses the initialize, the TX and RX refuse to do anything.

I have some help from Ralink on this, as well as some patches from
others which have been merged. But I lack the time to really dive
into these issues. I don't get much further then a guick glance every
few days.

Ivo

Re: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Sat, Apr 18, 2009 at 11:18:56PM +0200, Ivo van Doorn wrote:
> Hi,
> 
> > > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb supports
> > > more than 1oo USB devices and rt2800pci is included in a lot of
> > > laptops(ask Torvalds [1] [2])
> > > 
> > > [1] http://marc.info/?l=linux-netdev&m=121799144422863&w=2
> > > [2] http://marc.info/?l=linux-kernel&m=123187052023831&w=2
> > 
> > That would be great to have in, what's keeping it from happening?
> 
> In short: A stable workable driver.
> 
> The rt2800usb driver is pretty far (at least on my testsetup), but
> still has problems with transmitting frames immediately after
> association.

I read this as "it works, but some frames are lost immediately after
association" -- is that right?  FWIW, this sounds good enough to me
to get it into the mainline kernel.  _Please_ submit the rt2800usb
driver for wireless-testing/linux-next ASAP!

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

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Ivo Van Doorn]

On Mon, Apr 20, 2009 at 3:59 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Sat, Apr 18, 2009 at 11:18:56PM +0200, Ivo van Doorn wrote:
>> Hi,
>>
>> > > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb su=
pports
>> > > more than 1oo USB devices and rt2800pci is included in a lot of
>> > > laptops(ask Torvalds [1] [2])
>> > >
>> > > [1] http://marc.info/?l=3Dlinux-netdev&m=3D121799144422863&w=3D2
>> > > [2] http://marc.info/?l=3Dlinux-kernel&m=3D123187052023831&w=3D2
>> >
>> > That would be great to have in, what's keeping it from happening?
>>
>> In short: A stable workable driver.
>>
>> The rt2800usb driver is pretty far (at least on my testsetup), but
>> still has problems with transmitting frames immediately after
>> association.
>
> I read this as "it works, but some frames are lost immediately after
> association" -- is that right?

It is not "Some frames" it is "All frames" you can't get a DHCP lease,
or use a static IP and try to do anything.

Also 11n APs are not detected at all, which for a 11n client sounds
very problematic.

> FWIW, this sounds good enough to me
> to get it into the mainline kernel. =A0_Please_ submit the rt2800usb
> driver for wireless-testing/linux-next ASAP!

If the above 2 problems aren't critical for merge, then I'll send the
patches as soon as possible.

Ivo
--
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: [PATCH] Add vt6656 driver to drivers/staging.

[Ivo Van Doorn]

On Tue, Apr 21, 2009 at 12:30 PM, Ivo Van Doorn <ivdoorn@gmail.com> wro=
te:
> On Mon, Apr 20, 2009 at 3:59 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> On Sat, Apr 18, 2009 at 11:18:56PM +0200, Ivo van Doorn wrote:
>>> Hi,
>>>
>>> > > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb s=
upports
>>> > > more than 1oo USB devices and rt2800pci is included in a lot of
>>> > > laptops(ask Torvalds [1] [2])
>>> > >
>>> > > [1] http://marc.info/?l=3Dlinux-netdev&m=3D121799144422863&w=3D=
2
>>> > > [2] http://marc.info/?l=3Dlinux-kernel&m=3D123187052023831&w=3D=
2
>>> >
>>> > That would be great to have in, what's keeping it from happening?
>>>
>>> In short: A stable workable driver.
>>>
>>> The rt2800usb driver is pretty far (at least on my testsetup), but
>>> still has problems with transmitting frames immediately after
>>> association.
>>
>> I read this as "it works, but some frames are lost immediately after
>> association" -- is that right?
>
> It is not "Some frames" it is "All frames" you can't get a DHCP lease=
,
> or use a static IP and try to do anything.

To clarify a bit, this behavior summarizes the first minute after assoc=
iation,
after that all frames queued in the past minute are bursted out in a si=
ngle shot
and normal traffic is possible again.

> Also 11n APs are not detected at all, which for a 11n client sounds
> very problematic.
>
>> FWIW, this sounds good enough to me
>> to get it into the mainline kernel. =A0_Please_ submit the rt2800usb
>> driver for wireless-testing/linux-next ASAP!
>
> If the above 2 problems aren't critical for merge, then I'll send the
> patches as soon as possible.

Ivo
--
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: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Tue, Apr 21, 2009 at 12:30:16PM +0200, Ivo Van Doorn wrote:
> On Mon, Apr 20, 2009 at 3:59 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Sat, Apr 18, 2009 at 11:18:56PM +0200, Ivo van Doorn wrote:
> >> Hi,
> >>
> >> > > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb =
supports
> >> > > more than 1oo USB devices and rt2800pci is included in a lot o=
f
> >> > > laptops(ask Torvalds [1] [2])
> >> > >
> >> > > [1] http://marc.info/?l=3Dlinux-netdev&m=3D121799144422863&w=3D=
2
> >> > > [2] http://marc.info/?l=3Dlinux-kernel&m=3D123187052023831&w=3D=
2
> >> >
> >> > That would be great to have in, what's keeping it from happening=
?
> >>
> >> In short: A stable workable driver.
> >>
> >> The rt2800usb driver is pretty far (at least on my testsetup), but
> >> still has problems with transmitting frames immediately after
> >> association.
> >
> > I read this as "it works, but some frames are lost immediately afte=
r
> > association" -- is that right?
>=20
> It is not "Some frames" it is "All frames" you can't get a DHCP lease=
,
> or use a static IP and try to do anything.

Is this permanent?  Or does it start working at some point?

> Also 11n APs are not detected at all, which for a 11n client sounds
> very problematic.

If 11g works then I think that is good enough to merge.

> > FWIW, this sounds good enough to me
> > to get it into the mainline kernel. =A0_Please_ submit the rt2800us=
b
> > driver for wireless-testing/linux-next ASAP!
>=20
> If the above 2 problems aren't critical for merge, then I'll send the
> patches as soon as possible.

If there is no traffic at all then I guess it can still wait -- ping
seems like a reasonable requirement.  But 11n is not a requirement
for merge.

John
--=20
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
--
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: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Tue, Apr 21, 2009 at 02:42:46PM +0200, Ivo Van Doorn wrote:
> On Tue, Apr 21, 2009 at 12:30 PM, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
> > On Mon, Apr 20, 2009 at 3:59 PM, John W. Linville
> > <linville@tuxdriver.com> wrote:
> >> On Sat, Apr 18, 2009 at 11:18:56PM +0200, Ivo van Doorn wrote:
> >>> Hi,
> >>>
> >>> > > I hope rt2800pci/usb to be included *ASAP*, because rt2800usb supports
> >>> > > more than 1oo USB devices and rt2800pci is included in a lot of
> >>> > > laptops(ask Torvalds [1] [2])
> >>> > >
> >>> > > [1] http://marc.info/?l=linux-netdev&m=121799144422863&w=2
> >>> > > [2] http://marc.info/?l=linux-kernel&m=123187052023831&w=2
> >>> >
> >>> > That would be great to have in, what's keeping it from happening?
> >>>
> >>> In short: A stable workable driver.
> >>>
> >>> The rt2800usb driver is pretty far (at least on my testsetup), but
> >>> still has problems with transmitting frames immediately after
> >>> association.
> >>
> >> I read this as "it works, but some frames are lost immediately after
> >> association" -- is that right?
> >
> > It is not "Some frames" it is "All frames" you can't get a DHCP lease,
> > or use a static IP and try to do anything.
> 
> To clarify a bit, this behavior summarizes the first minute after association,
> after that all frames queued in the past minute are bursted out in a single shot
> and normal traffic is possible again.

Ah, well in that case I'd say let's get it into at least wireless-testing.

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

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Olivier Blin]

Forest Bond <forest@alittletooquiet.net> writes:

> Hi Olivier,
>
> On Mon, Jun 08, 2009 at 07:08:14PM +0200, Olivier Blin wrote:
>> By the way, are you sure about the hook below about wpactl.c in commit
>> 8f2c32b86b3ac16ba4c93bf0c2b766089644d9d1 ?
>> 
>> If I do the same in vt6656, it is freezing the kernel, or causing random
>> crashes. Removing the netdev priv assignation makes the driver ok.
>> I don't think the wpa priv was really useful, but I fail to see where it
>> was used, and why it caused the hang.
>> 
>> Don't you have the same issue with vt6655?
>
> I'm embarrassed to say that I haven't actually tested this change on real
> hardware yet.  I've been trying to make changes that do not introduce any
> difference in functionality, but that fix the compile errors resulting from
> changing kernel APIs.
>
> Let me restate that I'm not really a kernel hacker, so much of my work is
> best-effort material.  TBH, I don't really understand the wpadev stuff, so it's
> not clear to me why wpadev->priv can be removed.  If you have insight here that
> I lack, I'd love to hear it.

Well, same here. My only insight is that I have tested the code on
vt6656 hardware, and that duplicating the device in netdev_priv of
wpadev makes the driver crash the system randomly.

> I should be able to get some real hardware to test on sometime this week.
>
>> BTW, I have some patches to send for vt6656, what is the proper place to
>> submit them since vt6656 is not in staging for now?
>
> I have a similar set of patches for vt6656 mostly prepared that I was going to
> submit to Greg.  Hopefully I can do that soon.  I suspect your patches are
> roughly the same; if they look anything like the vt6655 patches, they probably
> are.

My first patches are the same, and I ended up reusing your tree.
But I have a few more cleanups.

-- 
Olivier Blin (blino) - Mandriva

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

Hi Olivier,

On Mon, Jun 08, 2009 at 07:08:14PM +0200, Olivier Blin wrote:
> By the way, are you sure about the hook below about wpactl.c in commit
> 8f2c32b86b3ac16ba4c93bf0c2b766089644d9d1 ?
> 
> If I do the same in vt6656, it is freezing the kernel, or causing random
> crashes. Removing the netdev priv assignation makes the driver ok.
> I don't think the wpa priv was really useful, but I fail to see where it
> was used, and why it caused the hang.
> 
> Don't you have the same issue with vt6655?

I'm embarrassed to say that I haven't actually tested this change on real
hardware yet.  I've been trying to make changes that do not introduce any
difference in functionality, but that fix the compile errors resulting from
changing kernel APIs.

Let me restate that I'm not really a kernel hacker, so much of my work is
best-effort material.  TBH, I don't really understand the wpadev stuff, so it's
not clear to me why wpadev->priv can be removed.  If you have insight here that
I lack, I'd love to hear it.

I should be able to get some real hardware to test on sometime this week.

> BTW, I have some patches to send for vt6656, what is the proper place to
> submit them since vt6656 is not in staging for now?

I have a similar set of patches for vt6656 mostly prepared that I was going to
submit to Greg.  Hopefully I can do that soon.  I suspect your patches are
roughly the same; if they look anything like the vt6655 patches, they probably
are.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Olivier Blin]

Forest Bond <forest@alittletooquiet.net> writes:

> Hi,
>
> On Mon, Jun 01, 2009 at 06:35:35PM +0200, Gábor Stefanik wrote:
>> On Tue, Apr 14, 2009 at 12:52 PM, Forest Bond
>> <forest@alittletooquiet.net> wrote:
>> > This patch adds the vt6656 driver to drivers/staging.  This code was literally
>> > copied from the upstream source archive, available here:
>> >
>> >  http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
>> >
>> > Copyright: VIA Networking Technologies, Inc.
>> > License: GPL
>> > Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
>> >         Yiching Chen
>> > Signed-off-by: Forest Bond <forest@alittletooquiet.net>
>> >
>> > Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
>> > Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig
>> 
>> Did this patch (along with the vt6655 one) somehow get lost? I can't
>> see it in drivers/staging.
>
> vt6655 is in drivers/staging on linux-next, although I have three more patches
> that I'll be sending to Greg sometime tonight.  He has been applying them for
> me.
>
> vt6656 is currently delayed a bit.  I may be able to get a start on that
> tonight, as well, but there is likelihood of further delay.

By the way, are you sure about the hook below about wpactl.c in commit
8f2c32b86b3ac16ba4c93bf0c2b766089644d9d1 ?

If I do the same in vt6656, it is freezing the kernel, or causing random
crashes. Removing the netdev priv assignation makes the driver ok.
I don't think the wpa priv was really useful, but I fail to see where it
was used, and why it caused the hang.

Don't you have the same issue with vt6655?

BTW, I have some patches to send for vt6656, what is the proper place to
submit them since vt6656 is not in staging for now?

diff --git a/drivers/staging/vt6655/wpactl.c b/drivers/staging/vt6655/wpactl.c
index ee7109d..cc4f0ad 100644 (file)
--- a/drivers/staging/vt6655/wpactl.c
+++ b/drivers/staging/vt6655/wpactl.c
@@ -112,14 +112,17 @@ static void wpadev_setup(struct net_device *dev)
 
 static int wpa_init_wpadev(PSDevice pDevice)
 {
+    PSDevice wpadev_priv;
        struct net_device *dev = pDevice->dev;
          int ret=0;
 
-       pDevice->wpadev = alloc_netdev(0, "vntwpa", wpadev_setup);
+       pDevice->wpadev = alloc_netdev(sizeof(PSDevice), "vntwpa", wpadev_setup);
        if (pDevice->wpadev == NULL)
                return -ENOMEM;
 
-       pDevice->wpadev->priv = pDevice;
+    wpadev_priv = netdev_priv(pDevice->wpadev);
+    *wpadev_priv = *pDevice;
+
        memcpy(pDevice->wpadev->dev_addr, dev->dev_addr, U_ETHER_ADDR_LEN);
          pDevice->wpadev->base_addr = dev->base_addr;
        pDevice->wpadev->irq = dev->irq;

-- 
Olivier Blin (blino) - Mandriva

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Hi,

On Mon, Jun 01, 2009 at 06:35:35PM +0200, Gábor Stefanik wrote:
> On Tue, Apr 14, 2009 at 12:52 PM, Forest Bond
> <forest@alittletooquiet.net> wrote:
> > This patch adds the vt6656 driver to drivers/staging.  This code was literally
> > copied from the upstream source archive, available here:
> >
> >  http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
> >
> > Copyright: VIA Networking Technologies, Inc.
> > License: GPL
> > Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
> >         Yiching Chen
> > Signed-off-by: Forest Bond <forest@alittletooquiet.net>
> >
> > Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
> > Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig
> 
> Did this patch (along with the vt6655 one) somehow get lost? I can't
> see it in drivers/staging.

vt6655 is in drivers/staging on linux-next, although I have three more patches
that I'll be sending to Greg sometime tonight.  He has been applying them for
me.

vt6656 is currently delayed a bit.  I may be able to get a start on that
tonight, as well, but there is likelihood of further delay.

Hope this is helpful.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Gábor Stefanik]

On Tue, Apr 14, 2009 at 12:52 PM, Forest Bond
<forest@alittletooquiet.net> wrote:
> This patch adds the vt6656 driver to drivers/staging.  This code was literally
> copied from the upstream source archive, available here:
>
>  http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
>
> Copyright: VIA Networking Technologies, Inc.
> License: GPL
> Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
>         Yiching Chen
> Signed-off-by: Forest Bond <forest@alittletooquiet.net>
>
> Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
> Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig
>
> Thanks,
> Forest
> --
> Forest Bond
> http://www.alittletooquiet.net
> http://www.pytagsfs.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJ5GrQRO4fQQdv5AwRAjRIAKDb73oGJyViwov/yvUomOTKCeQC7wCeJ1Tr
> Sq8Nqu8rIJI/wL7AlIyyRv0=
> =cloX
> -----END PGP SIGNATURE-----
>
>

Did this patch (along with the vt6655 one) somehow get lost? I can't
see it in drivers/staging.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Fri, Apr 24, 2009 at 08:08:30PM -0400, Forest Bond wrote:
> Hi,
> 
> On Fri, Apr 24, 2009 at 03:58:20PM -0700, Greg KH wrote:
> > On Fri, Apr 24, 2009 at 07:03:29AM -0400, Forest Bond wrote:
> > > Hi Greg,
> > > 
> > > On Sun, Apr 19, 2009 at 03:32:18PM -0700, Greg KH wrote:
> > > > On Sun, Apr 19, 2009 at 04:01:46PM -0400, Forest Bond wrote:
> > > > > On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> > > > > > Forest Bond wrote:
> > > > > > > 
> > > > > > > However, I did have a question:
> > > > > > > 
> > > > > > > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > > > > > > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > > > > > > appropriate for them to be named "vt6655" and "vt6656"?
> > > > > > 
> > > > > > Of course Greg has the final say, but I vote to keep the directories with the
> > > > > > vt6656 name and change the name of the driver, which is defined in  the line
> > > > > > #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.
> > > > > 
> > > > > This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
> > > > > you'd prefer I didn't do this.
> > > > 
> > > > No objection from me.
> > > 
> > > The following git repository has a vt6655 branch and a vt6656 branch:
> > > 
> > >   http://www.alittletooquiet.net/media/code/vt665x.git
> > > 
> > > The vt6655 branch contains pretty much all of the work I'll likely be able to do
> > > for that driver.  The vt6656 branch needs more work.  I've not gone farther than
> > > build-testing either, at this point.
> > > 
> > > As I've mentioned before, some of this kind of work is really a bit outside my
> > > usual domain, so if you do look at it, I'd appreciate feedback.
> > > 
> > > Feel free to make requests.
> > 
> > Could you send it out as patches so it's easier to review?
> 
> Yes, I would've preferred that but the first patch is >1MB, so I figured it
> might be more useful to point you to a git repository, rather than send out a
> compressed patch.  I can send it out uncompressed if you prefer, or I can just
> send all but the first patch (which only copies files from the upstream archive,
> anyway).

Well, I'll need all of them, including the first patch, if I'm going to
ever apply them to the tree, so I don't mind :)

Everyone else might not care, so you can just send that one to me...

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

Hi,

On Fri, Apr 24, 2009 at 03:58:20PM -0700, Greg KH wrote:
> On Fri, Apr 24, 2009 at 07:03:29AM -0400, Forest Bond wrote:
> > Hi Greg,
> > 
> > On Sun, Apr 19, 2009 at 03:32:18PM -0700, Greg KH wrote:
> > > On Sun, Apr 19, 2009 at 04:01:46PM -0400, Forest Bond wrote:
> > > > On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> > > > > Forest Bond wrote:
> > > > > > 
> > > > > > However, I did have a question:
> > > > > > 
> > > > > > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > > > > > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > > > > > appropriate for them to be named "vt6655" and "vt6656"?
> > > > > 
> > > > > Of course Greg has the final say, but I vote to keep the directories with the
> > > > > vt6656 name and change the name of the driver, which is defined in  the line
> > > > > #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.
> > > > 
> > > > This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
> > > > you'd prefer I didn't do this.
> > > 
> > > No objection from me.
> > 
> > The following git repository has a vt6655 branch and a vt6656 branch:
> > 
> >   http://www.alittletooquiet.net/media/code/vt665x.git
> > 
> > The vt6655 branch contains pretty much all of the work I'll likely be able to do
> > for that driver.  The vt6656 branch needs more work.  I've not gone farther than
> > build-testing either, at this point.
> > 
> > As I've mentioned before, some of this kind of work is really a bit outside my
> > usual domain, so if you do look at it, I'd appreciate feedback.
> > 
> > Feel free to make requests.
> 
> Could you send it out as patches so it's easier to review?

Yes, I would've preferred that but the first patch is >1MB, so I figured it
might be more useful to point you to a git repository, rather than send out a
compressed patch.  I can send it out uncompressed if you prefer, or I can just
send all but the first patch (which only copies files from the upstream archive,
anyway).

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Fri, Apr 24, 2009 at 07:03:29AM -0400, Forest Bond wrote:
> Hi Greg,
> 
> On Sun, Apr 19, 2009 at 03:32:18PM -0700, Greg KH wrote:
> > On Sun, Apr 19, 2009 at 04:01:46PM -0400, Forest Bond wrote:
> > > On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> > > > Forest Bond wrote:
> > > > > 
> > > > > However, I did have a question:
> > > > > 
> > > > > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > > > > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > > > > appropriate for them to be named "vt6655" and "vt6656"?
> > > > 
> > > > Of course Greg has the final say, but I vote to keep the directories with the
> > > > vt6656 name and change the name of the driver, which is defined in  the line
> > > > #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.
> > > 
> > > This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
> > > you'd prefer I didn't do this.
> > 
> > No objection from me.
> 
> The following git repository has a vt6655 branch and a vt6656 branch:
> 
>   http://www.alittletooquiet.net/media/code/vt665x.git
> 
> The vt6655 branch contains pretty much all of the work I'll likely be able to do
> for that driver.  The vt6656 branch needs more work.  I've not gone farther than
> build-testing either, at this point.
> 
> As I've mentioned before, some of this kind of work is really a bit outside my
> usual domain, so if you do look at it, I'd appreciate feedback.
> 
> Feel free to make requests.

Could you send it out as patches so it's easier to review?

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]

Hi,

On Fri, Apr 24, 2009 at 09:44:06AM -0500, Larry Finger wrote:
> Forest Bond wrote:
> > 
> > The following git repository has a vt6655 branch and a vt6656 branch:
> > 
> >   http://www.alittletooquiet.net/media/code/vt665x.git
> > 
> > The vt6655 branch contains pretty much all of the work I'll likely be able to do
> > for that driver.  The vt6656 branch needs more work.  I've not gone farther than
> > build-testing either, at this point.
> 
> It would be a little easier for looking at the code if both vt6655 and vt6656
> directories were in the same branch of the git repo, but it's not a big deal.
> 
> > As I've mentioned before, some of this kind of work is really a bit outside my
> > usual domain, so if you do look at it, I'd appreciate feedback.
> 
> There are a number of warnings when compiling the vt6655 driver on x86_64
> architecture that arise from pointers having 64 bits while integers have 32
> bits. I think the warnings will not cause any problems.

I'll have a closer look at the warnings.

> There is, however, one error, namely:
> 
>   CC [M]  drivers/staging/vt6655/device_main.o
> drivers/staging/vt6655/device_main.c:347: error: initializer element is not constant
> drivers/staging/vt6655/device_main.c:347: error: (near initialization for
> ‘device_id_table[0].driver_data’)

Hm, didn't see this on my system.  Not sure why.  Thanks for the patch.

> Driver vt6656 also does not build, but that does not seem to be 64-bit related.
> If it builds on your system, let me know and I'll send you the error messages.

No, I haven't gotten that in a good state yet.

> I didn't look that thoroughly at the code, but I did notice one thing. The
> constructions like "#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)" are in the
> code so that it can build on a number of different kernels. Once it is in
> staging, it only has to build on the current kernel and you can trim out those
> conditionals.

Right, my intention was to look at those once the major build issues were sorted
out.

Were you able to look over my changes for net device private data accesses in
the vt6655 driver?  That is what I'm most concerned about.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Larry Finger]

=46orest Bond wrote:
>=20
> The following git repository has a vt6655 branch and a vt6656 branch:
>=20
>   http://www.alittletooquiet.net/media/code/vt665x.git
>=20
> The vt6655 branch contains pretty much all of the work I'll likely be=
 able to do
> for that driver.  The vt6656 branch needs more work.  I've not gone f=
arther than
> build-testing either, at this point.

It would be a little easier for looking at the code if both vt6655 and =
vt6656
directories were in the same branch of the git repo, but it's not a big=
 deal.

> As I've mentioned before, some of this kind of work is really a bit o=
utside my
> usual domain, so if you do look at it, I'd appreciate feedback.

There are a number of warnings when compiling the vt6655 driver on x86_=
64
architecture that arise from pointers having 64 bits while integers hav=
e 32
bits. I think the warnings will not cause any problems. There is, howev=
er, one
error, namely:

  CC [M]  drivers/staging/vt6655/device_main.o
drivers/staging/vt6655/device_main.c:347: error: initializer element is=
 not constant
drivers/staging/vt6655/device_main.c:347: error: (near initialization f=
or
=E2=80=98device_id_table[0].driver_data=E2=80=99)

The following patch fixes the compilation by removing the integer cast =
on
chip_info_table:

Index: vt665x/drivers/staging/vt6655/device_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- vt665x.orig/drivers/staging/vt6655/device_main.c
+++ vt665x/drivers/staging/vt6655/device_main.c
@@ -344,7 +344,7 @@ static CHIP_INFO chip_info_table[]=3D {
 };

 static struct pci_device_id device_id_table[] __devinitdata =3D {
-{ 0x1106, 0x3253, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (int)&chip_info_table[=
0]},
+{ 0x1106, 0x3253, PCI_ANY_ID, PCI_ANY_ID, 0, 0, &chip_info_table[0]},
 { 0, }
 };
 #endif

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

Driver vt6656 also does not build, but that does not seem to be 64-bit =
related.
If it builds on your system, let me know and I'll send you the error me=
ssages.

I didn't look that thoroughly at the code, but I did notice one thing. =
The
constructions like "#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)" ar=
e in the
code so that it can build on a number of different kernels. Once it is =
in
staging, it only has to build on the current kernel and you can trim ou=
t those
conditionals.

Larry
--
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: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

Hi Greg,

On Sun, Apr 19, 2009 at 03:32:18PM -0700, Greg KH wrote:
> On Sun, Apr 19, 2009 at 04:01:46PM -0400, Forest Bond wrote:
> > On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> > > Forest Bond wrote:
> > > > 
> > > > However, I did have a question:
> > > > 
> > > > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > > > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > > > appropriate for them to be named "vt6655" and "vt6656"?
> > > 
> > > Of course Greg has the final say, but I vote to keep the directories with the
> > > vt6656 name and change the name of the driver, which is defined in  the line
> > > #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.
> > 
> > This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
> > you'd prefer I didn't do this.
> 
> No objection from me.

The following git repository has a vt6655 branch and a vt6656 branch:

  http://www.alittletooquiet.net/media/code/vt665x.git

The vt6655 branch contains pretty much all of the work I'll likely be able to do
for that driver.  The vt6656 branch needs more work.  I've not gone farther than
build-testing either, at this point.

As I've mentioned before, some of this kind of work is really a bit outside my
usual domain, so if you do look at it, I'd appreciate feedback.

Feel free to make requests.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Sun, Apr 19, 2009 at 04:01:46PM -0400, Forest Bond wrote:
> Hi Larry,
> 
> On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> > Forest Bond wrote:
> > > 
> > > However, I did have a question:
> > > 
> > > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > > appropriate for them to be named "vt6655" and "vt6656"?
> > 
> > Of course Greg has the final say, but I vote to keep the directories with the
> > vt6656 name and change the name of the driver, which is defined in  the line
> > #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.
> 
> This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
> you'd prefer I didn't do this.

No objection from me.

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hi Larry,

On Sun, Apr 19, 2009 at 02:52:57PM -0500, Larry Finger wrote:
> Forest Bond wrote:
> > 
> > However, I did have a question:
> > 
> > The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> > Should the directories be named "viawget" and "vntwusb," respectively, or is it
> > appropriate for them to be named "vt6655" and "vt6656"?
> 
> Of course Greg has the final say, but I vote to keep the directories with the
> vt6656 name and change the name of the driver, which is defined in  the line
> #define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.

This makes sense to me.  I'll proceed this way for now.  Greg, let me know if
you'd prefer I didn't do this.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Larry Finger]

Forest Bond wrote:
> 
> However, I did have a question:
> 
> The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
> Should the directories be named "viawget" and "vntwusb," respectively, or is it
> appropriate for them to be named "vt6655" and "vt6656"?

Of course Greg has the final say, but I vote to keep the directories with the
vt6656 name and change the name of the driver, which is defined in  the line
#define DEVICE_NAME "vntwusb" in file include/device_cfg.h in the vendor driver.

Larry

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Hi,

On Tue, Apr 14, 2009 at 09:51:16PM -0400, Forest Bond wrote:
> I need to get you some new patches, anyway, as the upstream sources depend on
> header files that I failed to provide as they sit in a separate includes
> directory.  I'll get this sent as soon as time permits (probably today or
> tomorrow).

I have some new patches almost ready, including Kconfig files and Makefiles.  I
am in the process of resolving a few build failures.

However, I did have a question:

The vt6655 driver builds viawget.ko, and the vt6656 driver builds vntwusb.ko.
Should the directories be named "viawget" and "vntwusb," respectively, or is it
appropriate for them to be named "vt6655" and "vt6656"?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Wed, Apr 15, 2009 at 11:43:33AM -0400, Dan Williams wrote:
> On Tue, 2009-04-14 at 18:10 -0700, Greg KH wrote:
> > On Tue, Apr 14, 2009 at 10:19:06AM -0400, Forest Bond wrote:
> > > Hi,
> > > 
> > > On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> > > > On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > > > > Hi Marcel,
> > > > > 
> > > > > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > > > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > > > > kernel. Now the staging crap is doing exactly the same.
> > 
> > Yes we are.  But we are doing it correctly :)
> > 
> > Turns out that people actually want to use their hardware, and no one
> > else was working on merging these drivers, so that is what staging is
> > for.
> 
> If nobody else was working on merging them, then adding them to staging
> isn't magically going to make people step up and rewrite the drivers
> into a state where they *can* actually be merged.
> 
> The solution isn't to drag crap drivers that have no hope of getting
> merged without a major rewrite into the kernel, the solution is to get
> manufacturers to write drivers that don't suck.  And staging doesn't
> help that at all; it doesn't encourage manufacturers to stop pushing out
> crap.
> 
> The only fixes that drivers are getting in staging now are netdev_ops,
> whitespace cleanups, and trivial fixes.  Nobody is actually rewriting
> the Ralink or Via staging drivers to use mac80211, which is what's
> needed for them to be merged.  Given that they are going nowhere, are
> you going to drop them after 6 months of no substantial contributions
> that advance their mergability?  Or are they going to sit around in
> staging forever, sapping away focus and resources that could be better
> spent moving wireless forward instead of fixing up a dead-end?

I've been pointing people at the community-based ralink drivers, that is
why there is only minor cleanups for those drivers.  That is what the
linux-wireless developers wanted me to do, so to claim that people are
not cleaning them up is totally unfair.

> (yes, some wireless drivers in staging are getting attention, but they
> are 95% NOT vendor drivers; they are community-originated drivers like
> at76_usb or stlc45xx that were written to use mac80211 in the first
> place)

I had patches that added mac80211 to one driver in staging that a
wireless developer asked me to revert.  So it is happening.

Again, it seems that if there is a community driver, people will help
out with it and let the staging one lie for a while, until it gets
dropped.  Which is what I was told the wireless developers _wanted_ to
have happen.  So don't complain if exactly what you all wanted to happen
is now happening...

As for the via driver, if there is no community driver, and people can
find the hardware, let's see what happens.

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Dan Williams]

On Tue, 2009-04-14 at 18:10 -0700, Greg KH wrote:
> On Tue, Apr 14, 2009 at 10:19:06AM -0400, Forest Bond wrote:
> > Hi,
> > 
> > On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> > > On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > > > Hi Marcel,
> > > > 
> > > > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > > > kernel. Now the staging crap is doing exactly the same.
> 
> Yes we are.  But we are doing it correctly :)
> 
> Turns out that people actually want to use their hardware, and no one
> else was working on merging these drivers, so that is what staging is
> for.

If nobody else was working on merging them, then adding them to staging
isn't magically going to make people step up and rewrite the drivers
into a state where they *can* actually be merged.

The solution isn't to drag crap drivers that have no hope of getting
merged without a major rewrite into the kernel, the solution is to get
manufacturers to write drivers that don't suck.  And staging doesn't
help that at all; it doesn't encourage manufacturers to stop pushing out
crap.

The only fixes that drivers are getting in staging now are netdev_ops,
whitespace cleanups, and trivial fixes.  Nobody is actually rewriting
the Ralink or Via staging drivers to use mac80211, which is what's
needed for them to be merged.  Given that they are going nowhere, are
you going to drop them after 6 months of no substantial contributions
that advance their mergability?  Or are they going to sit around in
staging forever, sapping away focus and resources that could be better
spent moving wireless forward instead of fixing up a dead-end?

(yes, some wireless drivers in staging are getting attention, but they
are 95% NOT vendor drivers; they are community-originated drivers like
at76_usb or stlc45xx that were written to use mac80211 in the first
place)

Dan

> > Well, gosh, I understand the criticism here and if I were a kernel developer I
> > imagine my perspective would be much the same.  But I can't help but feel that
> > there's some amount of hypocrisy when we hammer on a manufacturer to properly
> > license their driver and then let it drop dead when they do.
> 
> I agree.
> 
> > I understand that the problem would be solved if they manufacturers would
> > suddenly "get it," but the scale of social problem preventing that is likely too
> > large to change anytime soon.
> 
> Agreed.
> 
> > If kernel developers are too busy to support the hardware, why do the
> > manufacturers take so much criticism for releasing binary-only drivers or badly
> > licensed drivers, or for neglecting to release technical specifications?  If
> > what I'm sensing is correct and there's no practical likelihood of these devices
> > getting in-kernel support even with those issues resolved, the criticism almost
> > seems unjustified.
> > 
> > I appreciate what the kernel developers do, of course, and my intention is not
> > to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
> > for its approach to the Linux community shows some good will, it seems like we
> > ought to be able to turn that into something productive.  If we can't, what have
> > we been complaining about?
> > 
> > My apologies if I'm way off on this.  I haven't been around all that long so it
> > is certainly possible.
> 
> You aren't way off at all.
> 
> Thanks for the patches, I'll get to them in a few days when my "real
> job" calms down a bit.  They're now in my queue, and will not get lost.
> 
> thanks,
> 
> greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Tue, Apr 14, 2009 at 10:19:06AM -0400, Forest Bond wrote:
> On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:

> > None of the above is meant to disagree about the staging crap.
> > Having that stuff around is at best an optimistic attempt to help a
> > few stray users... :-)
> 
> Well, gosh, I understand the criticism here and if I were a kernel developer I
> imagine my perspective would be much the same.  But I can't help but feel that
> there's some amount of hypocrisy when we hammer on a manufacturer to properly
> license their driver and then let it drop dead when they do.

Proper licensing is a prerequisite, not the final objective.

> I understand that the problem would be solved if they manufacturers would
> suddenly "get it," but the scale of social problem preventing that is likely too
> large to change anytime soon.
> 
> If kernel developers are too busy to support the hardware, why do the
> manufacturers take so much criticism for releasing binary-only drivers or badly
> licensed drivers, or for neglecting to release technical specifications?  If
> what I'm sensing is correct and there's no practical likelihood of these devices
> getting in-kernel support even with those issues resolved, the criticism almost
> seems unjustified.

Swimming with the red fishes..."next to no support" may be infinitely
greater than "no support", but it still is only a first step.
It amounts to throwing something over the wall and walking away.

Most kernel developers have neither financial nor personal interest
in supporting hardware they don't have in their possession.  Some may
still lack both of those for random hardware in their collection.
A vendor choosing to take a minimal step towards the community does
not obligate us to take great leaps in their direction, especially
not at our own expense of time or money.

> I appreciate what the kernel developers do, of course, and my intention is not
> to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
> for its approach to the Linux community shows some good will, it seems like we
> ought to be able to turn that into something productive.  If we can't, what have
> we been complaining about?

I would love to see this hardware properly supported in the kernel.
I sincerely hope someone finds the time to do something positive
with it.  But as it stands neither I nor any of the other known
wireless developers have infinite time to support a driver for hardware
that none of us has -- especially not simply out of the goodness of
our hearts.  I'm sorry, but that is just the way it is.
 
> My apologies if I'm way off on this.  I haven't been around all that long so it
> is certainly possible.

Greg has provided drivers/staging as a compromise.  I'm sorry if some
of the comments seem too harsh, but I think there is room for both
positive and negative opinions about drivers/staging.  If anything,
I'm a bit neutral about it -- I think it helps some users but is
probably a net demotivator for development of proper drivers.

Hth...

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

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2836 bytes --]

Hi,

On Tue, Apr 14, 2009 at 06:10:20PM -0700, Greg KH wrote:
> On Tue, Apr 14, 2009 at 10:19:06AM -0400, Forest Bond wrote:
> > Hi,
> > 
> > On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> > > On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > > > Hi Marcel,
> > > > 
> > > > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > > > kernel. Now the staging crap is doing exactly the same.
> 
> Yes we are.  But we are doing it correctly :)
> 
> Turns out that people actually want to use their hardware, and no one
> else was working on merging these drivers, so that is what staging is
> for.
> 
> > Well, gosh, I understand the criticism here and if I were a kernel developer I
> > imagine my perspective would be much the same.  But I can't help but feel that
> > there's some amount of hypocrisy when we hammer on a manufacturer to properly
> > license their driver and then let it drop dead when they do.
> 
> I agree.
> 
> > I understand that the problem would be solved if they manufacturers would
> > suddenly "get it," but the scale of social problem preventing that is likely too
> > large to change anytime soon.
> 
> Agreed.
> 
> > If kernel developers are too busy to support the hardware, why do the
> > manufacturers take so much criticism for releasing binary-only drivers or badly
> > licensed drivers, or for neglecting to release technical specifications?  If
> > what I'm sensing is correct and there's no practical likelihood of these devices
> > getting in-kernel support even with those issues resolved, the criticism almost
> > seems unjustified.
> > 
> > I appreciate what the kernel developers do, of course, and my intention is not
> > to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
> > for its approach to the Linux community shows some good will, it seems like we
> > ought to be able to turn that into something productive.  If we can't, what have
> > we been complaining about?
> > 
> > My apologies if I'm way off on this.  I haven't been around all that long so it
> > is certainly possible.
> 
> You aren't way off at all.
> 
> Thanks for the patches, I'll get to them in a few days when my "real
> job" calms down a bit.  They're now in my queue, and will not get lost.

Thanks, Greg.  Your reputation is well-deserved, to say the least.

I need to get you some new patches, anyway, as the upstream sources depend on
header files that I failed to provide as they sit in a separate includes
directory.  I'll get this sent as soon as time permits (probably today or
tomorrow).

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Tue, Apr 14, 2009 at 10:19:06AM -0400, Forest Bond wrote:
> Hi,
> 
> On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> > On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > > Hi Marcel,
> > > 
> > > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > > kernel. Now the staging crap is doing exactly the same.

Yes we are.  But we are doing it correctly :)

Turns out that people actually want to use their hardware, and no one
else was working on merging these drivers, so that is what staging is
for.

> Well, gosh, I understand the criticism here and if I were a kernel developer I
> imagine my perspective would be much the same.  But I can't help but feel that
> there's some amount of hypocrisy when we hammer on a manufacturer to properly
> license their driver and then let it drop dead when they do.

I agree.

> I understand that the problem would be solved if they manufacturers would
> suddenly "get it," but the scale of social problem preventing that is likely too
> large to change anytime soon.

Agreed.

> If kernel developers are too busy to support the hardware, why do the
> manufacturers take so much criticism for releasing binary-only drivers or badly
> licensed drivers, or for neglecting to release technical specifications?  If
> what I'm sensing is correct and there's no practical likelihood of these devices
> getting in-kernel support even with those issues resolved, the criticism almost
> seems unjustified.
> 
> I appreciate what the kernel developers do, of course, and my intention is not
> to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
> for its approach to the Linux community shows some good will, it seems like we
> ought to be able to turn that into something productive.  If we can't, what have
> we been complaining about?
> 
> My apologies if I'm way off on this.  I haven't been around all that long so it
> is certainly possible.

You aren't way off at all.

Thanks for the patches, I'll get to them in a few days when my "real
job" calms down a bit.  They're now in my queue, and will not get lost.

thanks,

greg k-h

Re: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Tue, Apr 14, 2009 at 07:17:24PM +0530, Sujith wrote:
> John W. Linville wrote:
> > John
> > -- 
> > John W. Linville		Someday the world will need a hero, and you
> > linville@tuxdriver.com			might be all we have.  Be ready.
> > --
> 
> I knew it.
> My mom always told me I was special.

Of course you are special...just like everybody else!! :-)

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

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

Hi,

[My mail server appears to be having issues.  I apologize if anyone receives
more than one copy of this message.]

On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > Hi Marcel,
> > 
> > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > kernel. Now the staging crap is doing exactly the same.
> > 
> > :)
> > 
> > Actually, last I counted it was already 7 or 8 stacks in staging _only_.
> > This (and the other patch) will add two more. Not to mention that of
> > course we already have something like two and a half stacks in the
> > kernel tree (mac80211, in hostapd, and libipw [former ieee80211]).
> 
> FWIW I had started trying to consolidate some code between those three.
> I stalled-out a bit and got distracted with the rndis_wlan cfg80211
> bits, but I hope to get back to it.  Of course, hostap seems mighty
> complex internally -- it might just have to lay there.  And libipw
> and mac80211 target different types of designs, but I hope they can
> eventually share some infrastructure in lib80211.
> 
> None of the above is meant to disagree about the staging crap.
> Having that stuff around is at best an optimistic attempt to help a
> few stray users... :-)

Well, gosh, I understand the criticism here and if I were a kernel developer I
imagine my perspective would be much the same.  But I can't help but feel that
there's some amount of hypocrisy when we hammer on a manufacturer to properly
license their driver and then let it drop dead when they do.

I understand that the problem would be solved if they manufacturers would
suddenly "get it," but the scale of social problem preventing that is likely too
large to change anytime soon.

If kernel developers are too busy to support the hardware, why do the
manufacturers take so much criticism for releasing binary-only drivers or badly
licensed drivers, or for neglecting to release technical specifications?  If
what I'm sensing is correct and there's no practical likelihood of these devices
getting in-kernel support even with those issues resolved, the criticism almost
seems unjustified.

I appreciate what the kernel developers do, of course, and my intention is not
to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
for its approach to the Linux community shows some good will, it seems like we
ought to be able to turn that into something productive.  If we can't, what have
we been complaining about?

My apologies if I'm way off on this.  I haven't been around all that long so it
is certainly possible.

Respectfully,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

Hi,

On Tue, Apr 14, 2009 at 09:02:48AM -0400, John W. Linville wrote:
> On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> > Hi Marcel,
> > 
> > > just to document the irony here. Two or three years ago at OLS, Kyle and
> > > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > > kernel. Now the staging crap is doing exactly the same.
> > 
> > :)
> > 
> > Actually, last I counted it was already 7 or 8 stacks in staging _only_.
> > This (and the other patch) will add two more. Not to mention that of
> > course we already have something like two and a half stacks in the
> > kernel tree (mac80211, in hostapd, and libipw [former ieee80211]).
> 
> FWIW I had started trying to consolidate some code between those three.
> I stalled-out a bit and got distracted with the rndis_wlan cfg80211
> bits, but I hope to get back to it.  Of course, hostap seems mighty
> complex internally -- it might just have to lay there.  And libipw
> and mac80211 target different types of designs, but I hope they can
> eventually share some infrastructure in lib80211.
> 
> None of the above is meant to disagree about the staging crap.
> Having that stuff around is at best an optimistic attempt to help a
> few stray users... :-)

Well, gosh, I understand the criticism here and if I were a kernel developer I
imagine my perspective would be much the same.  But I can't help but feel that
there's some amount of hypocrisy when we hammer on a manufacturer to properly
license their driver and then let it drop dead when they do.

I understand that the problem would be solved if they manufacturers would
suddenly "get it," but the scale of social problem preventing that is likely too
large to change anytime soon.

If kernel developers are too busy to support the hardware, why do the
manufacturers take so much criticism for releasing binary-only drivers or badly
licensed drivers, or for neglecting to release technical specifications?  If
what I'm sensing is correct and there's no practical likelihood of these devices
getting in-kernel support even with those issues resolved, the criticism almost
seems unjustified.

I appreciate what the kernel developers do, of course, and my intention is not
to ruffle feathers.  But when a manufacturer that has taken a lot of criticism
for its approach to the Linux community shows some good will, it seems like we
ought to be able to turn that into something productive.  If we can't, what have
we been complaining about?

My apologies if I'm way off on this.  I haven't been around all that long so it
is certainly possible.

Respectfully,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[John W. Linville]

On Tue, Apr 14, 2009 at 02:43:54PM +0200, Johannes Berg wrote:
> Hi Marcel,
> 
> > just to document the irony here. Two or three years ago at OLS, Kyle and
> > Greg were making fun of Ubuntu merging its 5th wireless stack into their
> > kernel. Now the staging crap is doing exactly the same.
> 
> :)
> 
> Actually, last I counted it was already 7 or 8 stacks in staging _only_.
> This (and the other patch) will add two more. Not to mention that of
> course we already have something like two and a half stacks in the
> kernel tree (mac80211, in hostapd, and libipw [former ieee80211]).

FWIW I had started trying to consolidate some code between those three.
I stalled-out a bit and got distracted with the rndis_wlan cfg80211
bits, but I hope to get back to it.  Of course, hostap seems mighty
complex internally -- it might just have to lay there.  And libipw
and mac80211 target different types of designs, but I hope they can
eventually share some infrastructure in lib80211.

None of the above is meant to disagree about the staging crap.
Having that stuff around is at best an optimistic attempt to help a
few stray users... :-)

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

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

Hi Marcel,

> just to document the irony here. Two or three years ago at OLS, Kyle and
> Greg were making fun of Ubuntu merging its 5th wireless stack into their
> kernel. Now the staging crap is doing exactly the same.

:)

Actually, last I counted it was already 7 or 8 stacks in staging _only_.
This (and the other patch) will add two more. Not to mention that of
course we already have something like two and a half stacks in the
kernel tree (mac80211, in hostapd, and libipw [former ieee80211]).

> At some point I like to see some proper future development/cleanup
> planning for drivers in the staging area. Dumping stuff in there doesn't
> help at all and personally I don't see anybody cleaning up this mess.

Which is why, for all wireless "drivers" but agnx and stlc45xx in
staging I have requested that the linux-wireless list not be copied on
any of the "patches" for those drivers. All of these other drivers are,
in my opinion, entirely pointless and need to be rewritten from scratch
using the current infrastructure. No amount of cleanup will help --
there is a _fundamental_ design difference. Compare ar9170 (rewritten)
with otus (vendor) for an example.

Mind you, there don't seem to be many developers capable of doing that,
and therefore all these drivers will never "make it". All wireless
patches in staging, that haven't been proposed by people very familiar
with the wireless code, have so far been in the "brain-dead cleanup"
category.

> Do we have an option to taint the kernel when a staging driver is used.
> Similar to what we do with binary drivers or ndiswrapper?

It's already doing that. FWIW, I trust many of those staging drivers a
lot _less_ than, for instance, Broadcom's binary-only wl.ko driver.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Marcel Holtmann]

Hi Johannes,

> > > Can we also please add files here saying to not bother the
> > > linux-wireless list about this crap?
> > 
> > I would assume this is somewhat implied for any code in drivers/staging.  Is
> > that not the case?
> 
> It seems to be on a per case basis -- and there's one driver at least
> (agnx) that we actually do care about because it is there only because
> it's incomplete not because the code is in some way problematic (like
> using its own 802.11 stack)

just to document the irony here. Two or three years ago at OLS, Kyle and
Greg were making fun of Ubuntu merging its 5th wireless stack into their
kernel. Now the staging crap is doing exactly the same.

Not to mention the regulatory database I found in this specific driver.

At some point I like to see some proper future development/cleanup
planning for drivers in the staging area. Dumping stuff in there doesn't
help at all and personally I don't see anybody cleaning up this mess.

Do we have an option to taint the kernel when a staging driver is used.
Similar to what we do with binary drivers or ndiswrapper?

Regards

Marcel

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Tue, 2009-04-14 at 07:39 -0400, Forest Bond wrote:

> > Can we also please add files here saying to not bother the
> > linux-wireless list about this crap?
> 
> I would assume this is somewhat implied for any code in drivers/staging.  Is
> that not the case?

It seems to be on a per case basis -- and there's one driver at least
(agnx) that we actually do care about because it is there only because
it's incomplete not because the code is in some way problematic (like
using its own 802.11 stack)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Hi,

On Tue, Apr 14, 2009 at 01:07:38PM +0200, Johannes Berg wrote:
> On Tue, 2009-04-14 at 06:52 -0400, Forest Bond wrote:
> > This patch adds the vt6656 driver to drivers/staging.  This code was literally
> > copied from the upstream source archive, available here:
> > 
> >   http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
> > 
> > Copyright: VIA Networking Technologies, Inc.
> > License: GPL
> > Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
> >          Yiching Chen
> > Signed-off-by: Forest Bond <forest@alittletooquiet.net>
> > 
> > Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
> > Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig
> 
> Can we also please add files here saying to not bother the
> linux-wireless list about this crap?

I would assume this is somewhat implied for any code in drivers/staging.  Is
that not the case?

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Tue, 2009-04-14 at 06:52 -0400, Forest Bond wrote:
> This patch adds the vt6656 driver to drivers/staging.  This code was literally
> copied from the upstream source archive, available here:
> 
>   http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
> 
> Copyright: VIA Networking Technologies, Inc.
> License: GPL
> Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
>          Yiching Chen
> Signed-off-by: Forest Bond <forest@alittletooquiet.net>
> 
> Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
> Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig

Can we also please add files here saying to not bother the
linux-wireless list about this crap?

Thanks,
Johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] Add vt6656 driver to drivers/staging.

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

This patch adds the vt6656 driver to drivers/staging.  This code was literally
copied from the upstream source archive, available here:

  http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip

Copyright: VIA Networking Technologies, Inc.
License: GPL
Authors: Jerry Chen, Kyle Hsu, Lucas Lin, Lyndon Chen, Tevin Chen, Warren Hsu,
         Yiching Chen
Signed-off-by: Forest Bond <forest@alittletooquiet.net>

Patch: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz
Signature: http://www.alittletooquiet.net/media/code/0002-Add-vt6656-driver-to-drivers-staging.patch.gz.sig

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Add vt6656 driver to drivers/staging.

[Greg KH]

On Mon, Apr 13, 2009 at 10:46:10PM -0400, Forest Bond wrote:
> This patch adds the vt6656 driver to drivers/staging.  This code was literally
> copied from the upstream source archive, available here:
> 
>   http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip

Same signed-off-by and author info request here as well please...

thanks,

greg k-h