Re: [PATCH 4/5] Net: ath5k, license is GPLv2

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Johannes Berg]

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

On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:

> The files are available only under GPLv2 since now.

Since the BSD people are already getting upset about (for various
reasons among which seem to be a clear non-understanding) I'd suggest
changing it to:


+ * Parts of this file were originally licenced under the BSD licence:
+ *
>  * Permission to use, copy, modify, and distribute this software for any
>  * purpose with or without fee is hereby granted, provided that the above
>  * copyright notice and this permission notice appear in all copies.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
>  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * Further changes to this file since the moment this notice was extended
+ * are now distributed under the terms of the GPL version two as published
+ * by the Free Software Foundation <yaddaya>

johannes

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

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jiri Slaby]

On 8/29/07, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:
>
> > The files are available only under GPLv2 since now.
>
> Since the BSD people are already getting upset about (for various
> reasons among which seem to be a clear non-understanding) I'd suggest
> changing it to:

yes, please. Can somebody do it, I'm away from my box.

> + * Parts of this file were originally licenced under the BSD licence:
> + *
> >  * Permission to use, copy, modify, and distribute this software for any
> >  * purpose with or without fee is hereby granted, provided that the above
> >  * copyright notice and this permission notice appear in all copies.
> >  *
> >  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
> WARRANTIES
> >  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> >  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> >  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> >  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> >  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> >  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + *
> + * Further changes to this file since the moment this notice was extended
> + * are now distributed under the terms of the GPL version two as published
> + * by the Free Software Foundation <yaddaya>
>
> johannes
>

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Xavier Bestel]

On Wed, 2007-08-29 at 08:35 -0200, Jiri Slaby wrote:
> On 8/29/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:
> >
> > > The files are available only under GPLv2 since now.
> >
> > Since the BSD people are already getting upset about (for various
> > reasons among which seem to be a clear non-understanding) I'd suggest
> > changing it to:
> 
> yes, please. Can somebody do it, I'm away from my box.
> 
> > + * Parts of this file were originally licenced under the BSD licence:
> > + *
> > >  * Permission to use, copy, modify, and distribute this software for any
> > >  * purpose with or without fee is hereby granted, provided that the above
> > >  * copyright notice and this permission notice appear in all copies.
> > >  *
> > >  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
> > WARRANTIES
> > >  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > >  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > >  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > >  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > >  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > >  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + *
> > + * Further changes to this file since the moment this notice was extended
> > + * are now distributed under the terms of the GPL version two as published
> > + * by the Free Software Foundation <yaddaya>
> >
> > johannes

How about asking for changes to be dual-licenced too ?

	Xav

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Johannes Berg]

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

On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:

> How about asking for changes to be dual-licenced too ?

In theory, that could work, but in practice relying on functions that
the Linux kernel offers in GPLv2-only headers etc. will make the result
GPLv2 anyway, and disentangling it would be a nightmare.

johannes

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

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Valdis.Kletnieks]

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

On Tue, 28 Aug 2007 18:11:55 BST, Christoph Hellwig said:
> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> > ath5k, license is GPLv2
> > 
> > The files are available only under GPLv2 since now.
> 
> Is this really a good idea?  Most of the reverse-engineering was
> done by the OpenBSD folks, and it would certainly be helpful to
> work together with them on new hardware revisions, etc..

The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
to remove the BSD/other license.   Jiri can release *his* code as GPLv2
only, but I suspect the files as a whole really should be dual BSD/GPLv2,
due to the numerous other stakeholders in those files.

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

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jon Smirl]

On 8/29/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
> to remove the BSD/other license.   Jiri can release *his* code as GPLv2
> only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> due to the numerous other stakeholders in those files.

This mess has been occurring in the kernel for years. The DRM graphics
drivers are used in both BSD and Linux. It is quite easy to contribute
something to this code via LKML and think you are doing it under the
GPL. Doesn't a patch against the kernel have to be GPL? When these
patches get pulled back into BSD and distributed with it, did BSD get
infected with the GPL? AFAIK this has never been legally sorted out.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Alan Cox]

> > to remove the BSD/other license.   Jiri can release *his* code as GPLv2
> > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > due to the numerous other stakeholders in those files.
> 
> This mess has been occurring in the kernel for years. The DRM graphics
> drivers are used in both BSD and Linux. It is quite easy to contribute
> something to this code via LKML and think you are doing it under the
> GPL. Doesn't a patch against the kernel have to be GPL? When these
> patches get pulled back into BSD and distributed with it, did BSD get
> infected with the GPL? AFAIK this has never been legally sorted out.

I'm not aware anyone has felt it needed "sorting out". Its not exactly
complicated.

	BSD non advertising is compatible with GPL

The GPL says:
	"when you distribute the same sections as part of a whole which
	is a work based on the Program, the distribution of the whole
	must be on the terms of this License, "

The BSD license doesn't conflict with that

The GPL (and copyright law also say)

"If identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to ..."

All a bit irrelevant anyway as Ath5K code (not the .h file) say:

 * Alternatively, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") version 2 as published by the Free
 * Software Foundation.

So Jiri is choosing to distribute it under the GPL, and with his changes
GPL only.

So whats the problem ?

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jon Smirl]

On 8/29/07, Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> wrote:
> > > to remove the BSD/other license.   Jiri can release *his* code as GPLv2
> > > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > > due to the numerous other stakeholders in those files.
> >
> > This mess has been occurring in the kernel for years. The DRM graphics
> > drivers are used in both BSD and Linux. It is quite easy to contribute
> > something to this code via LKML and think you are doing it under the
> > GPL. Doesn't a patch against the kernel have to be GPL? When these
> > patches get pulled back into BSD and distributed with it, did BSD get
> > infected with the GPL? AFAIK this has never been legally sorted out.
>
> I'm not aware anyone has felt it needed "sorting out". Its not exactly
> complicated.
>
>         BSD non advertising is compatible with GPL
>
> The GPL says:
>         "when you distribute the same sections as part of a whole which
>         is a work based on the Program, the distribution of the whole
>         must be on the terms of this License, "
>
> The BSD license doesn't conflict with that
>
> The GPL (and copyright law also say)
>
> "If identifiable sections of that work are not derived from the Program,
> and can be reasonably considered independent and separate works in
> themselves, then this License, and its terms, do not apply to ..."
>
> All a bit irrelevant anyway as Ath5K code (not the .h file) say:
>
>  * Alternatively, this software may be distributed under the terms of the
>  * GNU General Public License ("GPL") version 2 as published by the Free
>  * Software Foundation.
>
> So Jiri is choosing to distribute it under the GPL, and with his changes
> GPL only.
>
> So whats the problem ?

BSD code can definitely be brought into a GPL project as you describe.
The problem is the other direction.

Aren't patches made against the kernel GPL'd if the author doesn't
explicitly grant them more liberal BSD license in addition?

The problem then comes in taking the patches that were only made
available against GPL code and reshipping them under the BSD license
without the author explicitly agreeing to this.

What if a patch spans both code that is pure GPL and code imported
from BSD, how do you license it?

-- 
Jon Smirl
jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Michael Buesch]

On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
> What if a patch spans both code that is pure GPL and code imported
> from BSD, how do you license it?

I think it's a valid assumption, if we say that the author
of the patch read the license header of a file and agreed with it.
So the patch is licensed to whatever the fileheader says. And if
there's none, it's licensed with the COPYING terms.
If a patch author likes some other license conditions, he must
explicitely add them with the patch to the file, saying that this
and that part have these and those conditions. Of course they must
be compatible with the original license.

-- 
Greetings Michael.

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On 29-08-2007 21:37, Michael Buesch wrote:
> On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
>> What if a patch spans both code that is pure GPL and code imported
>> from BSD, how do you license it?
> 
> I think it's a valid assumption, if we say that the author
> of the patch read the license header of a file and agreed with it.
> So the patch is licensed to whatever the fileheader says. And if
> there's none, it's licensed with the COPYING terms.
> If a patch author likes some other license conditions, he must
> explicitely add them with the patch to the file, saying that this
> and that part have these and those conditions. Of course they must
> be compatible with the original license.
> 

I didn't track this thread from the beginning, so maybe I repeat
somebody's ideas (probably like above), but IMHO: do we have to be
so selfish/pedantic? Can't we sometimes 'donate' a little bit to our
'older' bsd cousins or half-brothers? I think, it could be like this:

- if our changes are minor and authors of these changes don't mind
the file could stay BSD licensed only; plus we ask BSD to let it be
dual licensed (but no big hassle);

- otherwise, we should always distinctly mark all GPL parts.

Regards,
Jarek P.

PS: there is probably some mess with gmail addresses in this thread.

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On Thu, Aug 30, 2007 at 10:26:52AM +0200, Jarek Poplawski wrote:
...
> PS: there is probably some mess with gmail addresses in this thread.

...or maybe it's OK...  Sorry.

Jarek P.

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Alan Cox]

> Aren't patches made against the kernel GPL'd if the author doesn't
> explicitly grant them more liberal BSD license in addition?

That would be the normal assumption.

> The problem then comes in taking the patches that were only made
> available against GPL code and reshipping them under the BSD license
> without the author explicitly agreeing to this.
> 
> What if a patch spans both code that is pure GPL and code imported
> from BSD, how do you license it?

See the acpi codebase for a worked example.

Alan

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Jarek Poplawski]

On 30-08-2007 13:59, Johannes Berg wrote:
> On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote:
> 
>> How about asking for changes to be dual-licenced too ?
> 
> In theory, that could work, but in practice relying on functions that
> the Linux kernel offers in GPLv2-only headers etc. will make the result
> GPLv2 anyway, and disentangling it would be a nightmare.
> 

Why?

Very good point, but, in my opinion, it should be still resonable for
both sides: it simply means such changes are mostly unusable for the
other side, but nobody is going to waste time for marking all these
places, or care about suing if accidentally the changes, after some
adaptation, are usable for the other side. Unless you think or know
that "#include xyz" or "print_linux_way()" should add more than these
(maybe unusable) words or lines only?

Jarek P.

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[David Newall]

Is it actually necessary to change the license?  With the dual-license, 
you can keep a single code-base for both BSD and Linux platforms, which 
seems terribly important to me.  It'd be awful to lose that.  It would 
be a maintenance nightmare for BSD.  Is it even possible--in real life, 
I mean--to accept GPLed patches into a BSD project?  Nightmare, I tell you!

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Nick Kossifidis]

2007/8/28, Christoph Hellwig <hch@infradead.org>:
> On Tue, Aug 28, 2007 at 12:01:30PM -0400, Jiri Slaby wrote:
> > +config ATH5K_AR5210
> > +     bool "Support AR5210"
> > +     depends on ATH5K
> > +     default y
> > +
> > +config ATH5K_AR5211
> > +     bool "Support AR5211"
> > +     depends on ATH5K
> > +     default y
> > +
> > +config ATH5K_AR5212
> > +     bool "Support AR5212"
> > +     depends on ATH5K
> > +     default y
>
> Please don't add more default statements.
>
> Also this whole patch seems rather pointless.  It saves only
> very little and turns the driver into a complete ifdef maze.

It saves big chunks of code (not only initial register settings
arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this
is a very useful step, eg. check out descriptor processing / setup or
PHY functions (calibrate/channel set etc). For example AR5210 mac chip
only comes with RF5110 phy chip so we can get rid of RF5111/RF5112
code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112
code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110.
This thing also saves lots of checks during runtime (some of them
happen verry frequently, eg. durring descriptor processing). Also most
people will use 5212 code only, 5211 cards are on some old laptops and
5210, well i couldn't even find  a 5210 for actual testing :P

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Christoph Hellwig]

On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> It saves big chunks of code (not only initial register settings
> arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this
> is a very useful step, eg. check out descriptor processing / setup or
> PHY functions (calibrate/channel set etc). For example AR5210 mac chip
> only comes with RF5110 phy chip so we can get rid of RF5111/RF5112
> code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112
> code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110.
> This thing also saves lots of checks during runtime (some of them
> happen verry frequently, eg. durring descriptor processing). Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find  a 5210 for actual testing :P

If you're doing these checks in a hotpath something is badly wrong with
your architecture.

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[John W. Linville]

On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:

> > Also this whole patch seems rather pointless.  It saves only
> > very little and turns the driver into a complete ifdef maze.

> Also most
> people will use 5212 code only, 5211 cards are on some old laptops and
> 5210, well i couldn't even find  a 5210 for actual testing :P

FWIW, I'd bet dollars to donuts that distros will enable them all
together.

Is saving code space the only reason to turn these off?  How much
space do you save?

Is there some way you can isolate and/or limit the number of ifdef
blocks further?  If so, we might consider a version of this patch
that depends on EMBEDDED or somesuch...?

John
-- 
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Nick Kossifidis]

2007/8/30, John W. Linville <linville@tuxdriver.com>:
> On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> > 2007/8/28, Christoph Hellwig <hch@infradead.org>:
>
> > > Also this whole patch seems rather pointless.  It saves only
> > > very little and turns the driver into a complete ifdef maze.
>
> > Also most
> > people will use 5212 code only, 5211 cards are on some old laptops and
> > 5210, well i couldn't even find  a 5210 for actual testing :P
>
> FWIW, I'd bet dollars to donuts that distros will enable them all
> together.
>
> Is saving code space the only reason to turn these off?  How much
> space do you save?
>
> Is there some way you can isolate and/or limit the number of ifdef
> blocks further?  If so, we might consider a version of this patch
> that depends on EMBEDDED or somesuch...?
>
> John

O.K. as a first step i'll limit 5210 code only then, just an option
like "support older 5210 chipsets" which is going to be off by default
instead of 3 options. It's not just saving space, it's also saving
some runtime checks. It's not really a gain in performance though,
most checks are done during initialization and dfs setup, i just
thought it would be usefull to save as much cpu as possible.

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Nick Kossifidis]

2007/8/31, Nick Kossifidis <mickflemm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2007/8/30, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
> > On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> > > 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> >
> > > > Also this whole patch seems rather pointless.  It saves only
> > > > very little and turns the driver into a complete ifdef maze.
> >
> > > Also most
> > > people will use 5212 code only, 5211 cards are on some old laptops and
> > > 5210, well i couldn't even find  a 5210 for actual testing :P
> >
> > FWIW, I'd bet dollars to donuts that distros will enable them all
> > together.
> >
> > Is saving code space the only reason to turn these off?  How much
> > space do you save?
> >
> > Is there some way you can isolate and/or limit the number of ifdef
> > blocks further?  If so, we might consider a version of this patch
> > that depends on EMBEDDED or somesuch...?
> >
> > John
>
> O.K. as a first step i'll limit 5210 code only then, just an option
> like "support older 5210 chipsets" which is going to be off by default
> instead of 3 options. It's not just saving space, it's also saving
> some runtime checks. It's not really a gain in performance though,
> most checks are done during initialization and dfs setup, i just
> thought it would be usefull to save as much cpu as possible.
>

Well after some thought i removed them all, there is no real gain from
this in most cases (that ppl will use newer 5212 chips and
combatibles).



-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Dan Williams]

On Thu, 2007-08-30 at 08:36 -0400, John W. Linville wrote:
> On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> > 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> 
> > > Also this whole patch seems rather pointless.  It saves only
> > > very little and turns the driver into a complete ifdef maze.
> 
> > Also most
> > people will use 5212 code only, 5211 cards are on some old laptops and
> > 5210, well i couldn't even find  a 5210 for actual testing :P
> 
> FWIW, I'd bet dollars to donuts that distros will enable them all
> together.

I would certainly _hope_ that distros enable everything -that is in the
kernel- that they can get their hands on, otherwise when you stick a
card in, it doesn't just work.

Dan

> Is saving code space the only reason to turn these off?  How much
> space do you save?
> 
> Is there some way you can isolate and/or limit the number of ifdef
> blocks further?  If so, we might consider a version of this patch
> that depends on EMBEDDED or somesuch...?
> 
> John

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Jeff Garzik]

Dan Williams wrote:
> On Thu, 2007-08-30 at 08:36 -0400, John W. Linville wrote:
>> On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
>>> 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
>>>> Also this whole patch seems rather pointless.  It saves only
>>>> very little and turns the driver into a complete ifdef maze.
>>> Also most
>>> people will use 5212 code only, 5211 cards are on some old laptops and
>>> 5210, well i couldn't even find  a 5210 for actual testing :P
>> FWIW, I'd bet dollars to donuts that distros will enable them all
>> together.
> 
> I would certainly _hope_ that distros enable everything -that is in the
> kernel- that they can get their hands on, otherwise when you stick a
> card in, it doesn't just work.

Distros definitely -do not- do this.  Plenty of ancient ISA drivers are 
disabled at build time, for example, in many distros.

	Jeff

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Dan Williams]

On Fri, 2007-08-31 at 09:30 -0400, Jeff Garzik wrote:
> Dan Williams wrote:
> > On Thu, 2007-08-30 at 08:36 -0400, John W. Linville wrote:
> >> On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote:
> >>> 2007/8/28, Christoph Hellwig <hch@infradead.org>:
> >>>> Also this whole patch seems rather pointless.  It saves only
> >>>> very little and turns the driver into a complete ifdef maze.
> >>> Also most
> >>> people will use 5212 code only, 5211 cards are on some old laptops and
> >>> 5210, well i couldn't even find  a 5210 for actual testing :P
> >> FWIW, I'd bet dollars to donuts that distros will enable them all
> >> together.
> > 
> > I would certainly _hope_ that distros enable everything -that is in the
> > kernel- that they can get their hands on, otherwise when you stick a
> > card in, it doesn't just work.
> 
> Distros definitely -do not- do this.  Plenty of ancient ISA drivers are 
> disabled at build time, for example, in many distros.

Ok, so let me qualify to "within reason".  All 802.11-compliant wireless
cards would fall within the "within reason" IMHO, but, for example,
older non 802.11 wireless cards (early Aironet products for example)
probably don't.  ISA clearly does not for mainstream distros.

Dan

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Nick Kossifidis]

2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
> On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
> > -ath5k-objs           = ath5k_base.o ath5k_hw.o ath5k_regdom.o
> > +ath5k-objs           = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
> > +                       ath5k_hw_phy.o ath5k_hw_inivals.o
>
> And while I'm at nitpicking :)
>
> ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> most drivers and ath5k_hw_inivals.o mights aswell be something like
> ath5k_init.o
>

If you check out the code you'll see i'm using the same convention
inside them, ath5k_hw* files contain hw related functions
(ath5k_hw_<name>) while driver code has ath5k_<name>. Also ath5k_init
is misleading, file acually includes initial register settings for
various chips and the functions to apply them on hw, not the
initialization/attach/wakeup etc routines (that can be found  in
ath5k_hw.c), that's why it's inivals, i couldn't find a more
appropriate name.


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[John W. Linville]

On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote:
> 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:

> > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> > most drivers and ath5k_hw_inivals.o mights aswell be something like
> > ath5k_init.o

> If you check out the code you'll see i'm using the same convention
> inside them, ath5k_hw* files contain hw related functions
> (ath5k_hw_<name>) while driver code has ath5k_<name>. Also ath5k_init
> is misleading, file acually includes initial register settings for

I have to agree w/ Christoph -- the extra "_hw" in the names is just
a bit unwieldy.

John

P.S.  "ath5k_initvals.c" seems acceptable to me.
-- 
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Nick Kossifidis]

2007/8/30, John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
> On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote:
> > 2007/8/28, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>:
>
> > > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
> > > most drivers and ath5k_hw_inivals.o mights aswell be something like
> > > ath5k_init.o
>
> > If you check out the code you'll see i'm using the same convention
> > inside them, ath5k_hw* files contain hw related functions
> > (ath5k_hw_<name>) while driver code has ath5k_<name>. Also ath5k_init
> > is misleading, file acually includes initial register settings for
>
> I have to agree w/ Christoph -- the extra "_hw" in the names is just
> a bit unwieldy.
>
> John
>
> P.S.  "ath5k_initvals.c" seems acceptable to me.

ACK, i'll remove _hw ;-)

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: [PATCH 3/5] Net: ath5k, use int as retval

[John W. Linville]

On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote:
> ath5k, use int as retval
> 
> Convert some functions to return int and proper negative return value on
> error as we are used to.

Since I didn't apply 1/5, this one didn't apply either.  It seems
fine overall, so if you rediff I'll be happy to apply.

John
-- 
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org

Re: [PATCH 3/5] Net: ath5k, use int as retval

[Jiri Slaby]

John W. Linville napsal(a):
> On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote:
>> ath5k, use int as retval
>>
>> Convert some functions to return int and proper negative return value on
>> error as we are used to.
> 
> Since I didn't apply 1/5, this one didn't apply either.  It seems
> fine overall, so if you rediff I'll be happy to apply.

Ok, I'll do it, thanks,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz

Re: [PATCH 3/5] Net: ath5k, use int as retval

[Nick Kossifidis]

2007/9/1, Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> John W. Linville napsal(a):
> > On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote:
> >> ath5k, use int as retval
> >>
> >> Convert some functions to return int and proper negative return value on
> >> error as we are used to.
> >
> > Since I didn't apply 1/5, this one didn't apply either.  It seems
> > fine overall, so if you rediff I'll be happy to apply.
>
> Ok, I'll do it, thanks,

Can somebody commit my resent changes from madwifi-svn (cleanups,
kconfig, remove_hw_ from filenames etc) ? I don't have git repository
;-(


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick