Re: atheros driver - desc

Re: atheros driver - desc

[Mateusz Berezecki]

On 09:46 Fri 05 Aug     , Bryan O'Sullivan wrote:
> On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:
> 
> How far from working is it?  I have a miniPCI Atheros card and would be
> interested in helping out with bringing the driver up, but it would be
> good to know what to expect first :-)
> 

HAL is completely reversed, and it appears to work quite good. I have
tested quite a lot using *cough* hardcoded solutions :-)


What the driver is missing is integration with ieee80211 API
from netdev tree, Wireless Extensions and I've recently added
empty ioctl function templates. Basically that's what is missing.
Nothing more, nothing less :-)

And regarding that ieee80211 API, I would be very excited if
anyone could explain the general overview of how new wireless
API works. I read the source but sometimes a quick answer from
experienced kernel coder would do more good. 


kind regards
Mateusz

Re: atheros driver - desc

[Jeff Garzik]

Mateusz Berezecki wrote:
> And regarding that ieee80211 API, I would be very excited if
> anyone could explain the general overview of how new wireless
> API works. I read the source but sometimes a quick answer from
> experienced kernel coder would do more good. 


There is no document describing the API AFAIK.

The best thing to do is read over the ipw2[12]00 drivers.

	Jeff

Re: atheros driver - desc

[Mateusz Berezecki]

On 8/5/05, Jeff Garzik <jgarzik@pobox.com> wrote:
 
> There is no document describing the API AFAIK.
> 
> The best thing to do is read over the ipw2[12]00 drivers.
> 
>         Jeff

Ok, thanks for pointing me there. 

best
Mateusz

atheros driver - desc

[Mateusz Berezecki]

Hi list members,

I just post the code for review for anyone interested.
I would be more than pleased to hear some feedback from you on the code.

Im sending a series of 8 patches splitted and diffed as in 
SubmittingPatches documentation.

The driver is not yet fully working because I didn't finish kernel 
integration yet. Almost all
driver I/O ops are reverse engineered independently of openbsd openhal 
which is missing just too much.


Ok, enough talking. Most of the atheros 5212 hal is now open :)

sending patches...

Mateusz

Re: atheros driver - desc

[Michael Renzmann]

Hi.

Mateusz Berezecki wrote:
> Im sending a series of 8 patches splitted and diffed as in
> SubmittingPatches documentation.

Patch 4/8 is missing here.

Bye, Mike
-- 
Use PGP/GPG!
My key: http://keys.indymedia.org/cgi-bin/lookup?op=get&search=62C29B94
Fingerprint: BC2E 79BF 0C8F 0282 864B 9CEC 8343 5169 62C2 9B94

Re: atheros driver - desc

[Bryan O'Sullivan]

On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:

> The driver is not yet fully working because I didn't finish kernel 
> integration yet.

How far from working is it?  I have a miniPCI Atheros card and would be
interested in helping out with bringing the driver up, but it would be
good to know what to expect first :-)

	<b

Re: atheros driver - desc

[Jeff Garzik]

Mateusz Berezecki wrote:
> Hi list members,
> 
> I just post the code for review for anyone interested.
> I would be more than pleased to hear some feedback from you on the code.
> 
> Im sending a series of 8 patches splitted and diffed as in 
> SubmittingPatches documentation.
> 
> The driver is not yet fully working because I didn't finish kernel 
> integration yet. Almost all
> driver I/O ops are reverse engineered independently of openbsd openhal 
> which is missing just too much.
> 
> 
> Ok, enough talking. Most of the atheros 5212 hal is now open :)
> 
> sending patches...

It's a good start.  When you get a basic working driver, I'll push it 
into ieee80211 branch, and further review and work can occur.

	Jeff

Re: atheros driver - desc

[Kalle Valo]

Mateusz Berezecki <mateuszb@gmail.com> writes:

> The driver is not yet fully working because I didn't finish kernel
> integration yet. Almost all
> driver I/O ops are reverse engineered independently of openbsd openhal
> which is missing just too much.
>
>
> Ok, enough talking. Most of the atheros 5212 hal is now open :)

This is great news. An open source Atheros driver which could be
included to Linux is really needed.

But how was the reverse engineering done? I noticed that forcedeth
driver was implemented using the clean room design[1] and Linux
Broadcom 4301 driver project[2] seems to be using the same method.

The reason I'm asking this is that I just wouldn't want see the same
happening this with this driver as happened during reverse engineering
of pwc Philips Webcam driver (some parts of the driver were removed
from kernel, but I believe the situation is now solved).

Actually, what are requirements to get a reverse engineered driver
included to Linux? Is clean room design an absolute must? It seems
that reverse engineering is needed if we want Linux support for most
of the WLAN cards on the market :(

[1] http://en.wikipedia.org/wiki/Clean_room_design
[2] http://linux-bcom4301.sourceforge.net/go/progress

-- 
Kalle Valo

Re: atheros driver - desc

[Jeff Garzik]

It is certainly preferred that someone write a document describing the
hardware, and then a totally separate team write the driver, based on
that document.

	Jeff

Re: atheros driver - desc

[Harald Welte]

[-- Attachment #1.1: Type: text/plain, Size: 2124 bytes --]

On Sat, Aug 06, 2005 at 04:53:08PM -0400, Jeff Garzik wrote:
> 
> It is certainly preferred that someone write a document describing the
> hardware, and then a totally separate team write the driver, based on
> that document.

No question to that.  However, I think it largely depends on _where_ the
actual re-engineering is done.

Here in Germany, the copyright law is  perfectly fine with reverse
engineering, as long as you don't actually decompile.  The intent of the
law is to prevent you from gaining access to the source code (which
isn't possible in heavily optimized compiled languages anyway).  There
is no problem with trying to learn how the program works and what it
actually does.

All over the EU, the EUCD states that you are explicitly allowed to do
_any_ kind of re-engineering for the purpose of compatibility /
interoperability (and you want to make that card interoperable with
the linux OS...)  All you need to do is to ask the copyright holder for
the required documentation. If they don't produce it within a given
timeframe (IIRC one month), then you can go and start re-engineering
without the approval of the copyright holders.

Also, lots of the low-level driver routines are not copyrightable works
anyway.  If you need to set up the registers of a device in a certain
sequence in order to get it work, then there is no other way of doing
so.  Therefore the corresponding source code is not the result of a
creative process of the author.

I don't want to turn this list into a list of legal discussion, but
since I'm heavily dealing with exactly those issues during my
gpl-violations.org efforts, I thought I share some of the facts.

So in general, at least if you're doing that kind of work within the EU,
I wouldn't be worried all that much.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors

Re: atheros driver - desc

[Kalle Valo]

Harald Welte <laforge@gnumonks.org> writes:

> I don't want to turn this list into a list of legal discussion, but
> since I'm heavily dealing with exactly those issues during my
> gpl-violations.org efforts, I thought I share some of the facts.

Thanks for your answer, it cleared up things. I also don't want to
discuss legal things here, we can discuss it more privately. But I'll
just ask one more question in public:

> So in general, at least if you're doing that kind of work within the EU,
> I wouldn't be worried all that much.

That's good news. But what about inclusion to the official Linux
kernel? Can a driver reverse-engineered in EU be included to the
kernel? (Big part of Linux is developed in US, I guess.)

-- 
Kalle Valo

Re: atheros driver - desc

[Harald Welte]

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

On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote:
> Harald Welte <laforge@gnumonks.org> writes:
> 
> > I don't want to turn this list into a list of legal discussion, but
> > since I'm heavily dealing with exactly those issues during my
> > gpl-violations.org efforts, I thought I share some of the facts.
> 
> Thanks for your answer, it cleared up things. I also don't want to
> discuss legal things here, we can discuss it more privately. But I'll
> just ask one more question in public:
> 
> > So in general, at least if you're doing that kind of work within the EU,
> > I wouldn't be worried all that much.
> 
> That's good news. But what about inclusion to the official Linux
> kernel? Can a driver reverse-engineered in EU be included to the
> kernel? (Big part of Linux is developed in US, I guess.)

I will consult my legal counsel about this.  My current naive position
on this is that only the actuall process of the re-engineering matters,
not the result.

I'll get back as soon as I have a reply from my legal counsel.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors

Re: atheros driver - desc

[Chris Wedgwood]

On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:

> I will consult my legal counsel about this.  My current naive
> position on this is that only the actuall process of the
> re-engineering matters, not the result.

Which countries is this advice valid for?  Does someone need to chase
this inside the US in parallel?

Re: atheros driver - desc

[Harald Welte]

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

On Fri, Aug 12, 2005 at 12:37:55AM -0700, Chris Wedgwood wrote:
> On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:
> 
> > I will consult my legal counsel about this.  My current naive
> > position on this is that only the actuall process of the
> > re-engineering matters, not the result.
> 
> Which countries is this advice valid for?  Does someone need to chase
> this inside the US in parallel?

I'll see whether I can get Eben Moglen to comment on that matter.

-- 
- Harald Welte <laforge@gnumonks.org>          	        http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors

Re: atheros driver - desc

[Mateusz Berezecki]

Kalle Valo <Kalle.Valo@iki.fi> wrote:
| 
| This is great news. An open source Atheros driver which could be
| included to Linux is really needed.
| 
| But how was the reverse engineering done? I noticed that forcedeth
| driver was implemented using the clean room design[1] and Linux
| Broadcom 4301 driver project[2] seems to be using the same method.

  Reverse engineering was done by dissassemblying binary HAL
  and in harder parts by running it in userspace(yes, that is possible)
  and analysing input and produced output. The crucial part was to
  discover the meaning of hidden part of the structure describing
  device state. Once this was done it will be a little if no problem to me
  to provide updates for this driver, unless the whole binary HAL
  changes dramatically. That's one of the reasons I do this work myself.
  
| 
| The reason I'm asking this is that I just wouldn't want see the same
| happening this with this driver as happened during reverse engineering
| of pwc Philips Webcam driver (some parts of the driver were removed
| from kernel, but I believe the situation is now solved).

  If get into trouble I write documentation :-) I promise.


| Actually, what are requirements to get a reverse engineered driver
| included to Linux? Is clean room design an absolute must? It seems
| that reverse engineering is needed if we want Linux support for most
| of the WLAN cards on the market :(
| 

   Sad but true. The problem is not at vendors' side though.
   Look at FCC regulations... :/


   kind regards
   Mateusz