Hi All

This patchset (or the linux-wimax GIT tree at git.kernel.org) merges
the WiMAX subsystem and driver for the Intel 2400m Wireless WiMAX
connection to the tree. We'd like to get it in for the 2.6.29 merge
window. 

[read on for changelog since previous submit]

[Note linux-wimax will have netdev as upstream, but there is a
 dependency for patches in gregkh's patches tree that forbid
 submitting against netdev for now -- so the base for this is said
 tree as of 11/19. See *2]

WiMAX is a new wireless boadband technology that differs significantly
from WiFi. It is also called 4G and resembles more the model of
cellular phones, where you sign up for service with a provider.

Your WiMAX card connects to a basestation, which is operated by a
certain Network Access Provider (NAP). The NAP leases (or might be the
same) connectivity to a Network Service Provider (NSP), which is your
ISP.

When you move around, your connectivity will be handed over from
basestation to basestation in a seamless way. As in cellphones, there
is the roaming case, where you could be are connecting to your service
plan through other provider.

WiMAX's main components have been standarized (some parts still in the
process) as in a set of 802.16 standards. The WiMAX Forum's members
drive the development of WiMAX features that end up in 802.16.

This code is broken up in a WiMAX subsystem and a driver for the Intel
2400m Wireless WiMAX Link. To be able to fully utilize WiMAX services,
you need extra pieces of device-specific user space software; for now,
there is a C level API (the Common API) to use/control it, but a high
level API over DBUS that should work for any device is in the
works. See details further below.

Support for other vendor's hardware would require a driver registering
with the WiMAX stack and a user space component implementing the high
level API.

Changes since v1:

 - (Stephen Hemminger) don't use bitfields in struct wimax_dev 

 - (Stephen Hemminger) don't use the ...
[ message continues ]

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 Documentation/wimax/README.wimax |   86 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 86 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/wimax/README.wimax

diff --git a/Documentation/wimax/README.wimax b/Documentation/wimax/README.wimax
new file mode 100644
index 0000000..5f6a0a1
--- /dev/null
+++ b/Documentation/wimax/README.wimax
@@ -0,0 +1,86 @@
+   Linux kernel WiMAX stack
+
+   (C) 2008 Intel Corporation < linux-wimax@intel.com >
+
+   This provides a basic Linux kernel WiMAX stack to provide a common
+   control API for WiMAX devices, usable from kernel and user space.
+
+Design
+
+   The WiMAX stack is designed to provide for common WiMAX control
+   services to current and future WiMAX devices from any vendor.
+
+   Because currently there is only one and we don't know what would be the
+   common services, the APIs it currently provides are very minimal.
+   However, it is done in such a way that it is easily extensible to
+   accommodate future requirements.
+
+   The stack works by embedding a struct wimax_dev in your device's
+   control structures. This provides a set of callbacks that the WiMAX
+   stack will call in order to implement control operations requested by
+   the user. As well, the stack provides API functions that the driver
+   calls to notify about changes of state in the device.
+
+   The stack exports the API calls needed to control the device to user
+   space using generic netlink as a marshalling mechanism. You can access
+   them using your own code or use the wrappers provided for your
+   convenience in libwimax (in the wimax-tools package).
+
+   For detailed information on the stack, please see
+   include/net/wimax.h.
+
+Usage
+
+   For usage in a driver (registration, API, etc) please refer to the
+   instructions in the header file include/net/wimax.h.
+
+   When a device is registered with the WiMAX stack, a set of control
+   ...
[ message continues ]

Why add files that are deprecated from the start?

johannes
[ message continues ]

Old documentation--removed

Thanks,

-- 
Inaky

--

[ message continues ]

This file defines the user/kernel API protocol through generic
netlink.

User space can copy it verbatim and use it.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 include/linux/wimax.h |  235 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 235 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/wimax.h

diff --git a/include/linux/wimax.h b/include/linux/wimax.h
new file mode 100644
index 0000000..f9d6a17
--- /dev/null
+++ b/include/linux/wimax.h
@@ -0,0 +1,235 @@
+/*
+ * Linux WiMax
+ * API for user space
+ *
+ *
+ * Copyright (C) 2007 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This file declares the user/kernel protocol that is spoken over
+ * Generic Netlink, as well as any type declaration that is to be used
+ * by kernel and user space.
+ *
+ * It is intended for user space to clone it verbatim to use it as a
+ * primary reference for definitions.
+ *
+ * Stuff intended for kernel usage as well as full protocol and stack
+ * documentation is rooted in include/net/wimax.h.
+ */
+
+#ifndef __LINUX__WIMAX_H__
+#define __LINUX__WIMAX_H__
+
+#include <linux/types.h>
+
+enum {
+	/**
+	 * Version of the interface (unsigned decimal, MMm, max 25.5)
+	 * M - Major: change if ...
[ message continues ]

Explicitly licensing a header file that's used for userspace tools under
GPL2 might seem to indicate that the tool must be GPL2'ed as well, this
seems unintended. To be on the safe side, it seems that a lot of people
would prefer this to be under something as simple as the ISC license
just so that you can simply copy the file if necessary.

I know this hasn't been done traditionally, but in wireless a lot of
people are complaining and I know of one case where a complete header

This is another side effect of your decision of declaring attributes for
each command. If you didn't, you could simply do

enum wimax_attr {
	__WIMAX_GNL_ATTR_INVALID,
	WIMAX_GNL_ATTR_RFKILL_STATE,
	WIMAX_GNL_ATTR_...

	__WIMAX_GNL_ATTR_AFTER_LAST,
	WIMAX_GNL_ATTR_MAX =3D __WIMAX_GNL_ATTR_AFTER_LAST - 1
};

and have everything fall into place naturally.

Having just a single policy for all top-level attributes is a lot easier



So this is iwpriv? Why bother with an enum if you're not doing

What's wrong with making that 2, and using a single enum for all the

again, not MAX, also what do you need MC_GROUP stuff for? genl mc groups

This is a bit strange, what operations cannot just use the regular genl

That's not really available to userspace, is it? I mean, at that point
wimax-genl will just not work?

johannes
[ message continues ]

I've consolidated replies to some items in this email, instead of the
other ones, as some were repeated. These are mainly:

- using one policy per command

- licensing of the linux/wimax* headers

- the message channel

- the RP_RESULT to transfer results back to user space instead of


I could argue it is a side effect of netlink's implementation :)

The whole idea behind using a policy per command/signal is very simple
(and I realize now, very undocumented):

I want the attribute validator to do the validation job for me.a

Each command/signal have a list of arguments, each with a type, they
take. There is a policy for each that containst exactly that
list. When I get it from the user, I just need to validate it and if
there is something in there that should not, then that's an error.

So change the concept of "attribute maps to type" to "attribute type X
as an argument to command/signal Y".

However, if I had a single policy for *all* commands/signals, after
running the validator I'd have to check "does this attribute belong in
here"? for each one. I can do that manually (not) or I can have an
already working and proven piece of code do it for me. Makes it
easier. 

As well, it makes it easier to later expand each command/signal
signature without affecting others and keeping the namespace more or

Yes, that's what's they are, because there is still no known good
interface for the basic primitives (scan, connect, disconnect). That
will have to evolve or it might stay like that if there is no way to
find a common ground for those basic primitives [for others reading

This is used for something different. User space can use this to quick
check if this is a good message or not. It is actually redundant the

Consistency with the rest of the stuff and that I try to avoid cpp


Couldn't get it to work -- in a prev message you mentioned to look
into the example done at the iw tarball. Will check and kill all this

After going over other of your comments, I just ...
[ message continues ]

Add an EXPORT_SYMBOL() to genl_unregister_mc_group(), to allow
unregistering groups on the run. EXPORT_SYMBOL_GPL() is not used as
the rest of the functions exported by this module (eg:
genl_register_mc_group) are also not _GPL().

Cleanup is currently done when unregistering a family, but there is
no way to unregister a single multicast group due to that function not
being exported. Seems to be a mistake as it is documented as for
external consumption.

This is needed by the WiMAX stack to be able to cleanup unused mc
groups.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Thomas Graf <tgraf@suug.ch>
---
 net/netlink/genetlink.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 3e1191c..1d3dd30 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -225,6 +225,7 @@ void genl_unregister_mc_group(struct genl_family *family,
 	__genl_unregister_mc_group(family, grp);
 	genl_unlock();
 }
+EXPORT_SYMBOL(genl_unregister_mc_group);
 
 static void genl_unregister_mc_groups(struct genl_family *family)
 {
-- 
1.5.6.5

--

[ message continues ]

Haven't looked at the users, but you definitely need that as soon as you
need to unregister a group on the fly, so obviously

[ message continues ]

Declares the main data types and calls for the drivers to integrate
into the WiMAX stack. Provides usage documentation.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 include/net/wimax.h |  568 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 568 insertions(+), 0 deletions(-)
 create mode 100644 include/net/wimax.h

diff --git a/include/net/wimax.h b/include/net/wimax.h
new file mode 100644
index 0000000..1e8bbf8
--- /dev/null
+++ b/include/net/wimax.h
@@ -0,0 +1,568 @@
+/*
+ * Linux WiMAX
+ * Kernel space API for accessing WiMAX devices
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * The WiMAX stack provides an API for controlling and managing the
+ * system's WiMAX devices. This API affects the control plane; the
+ * data plane is accessed via the network stack (netdev).
+ *
+ * Parts of the WiMAX stack API and notifications are exported to
+ * user space via Generic Netlink. In user space, libwimax (part of
+ * the wimax-tools package) provides a shim layer for accessing those
+ * calls.
+ *
+ * The API is standarized for all WiMAX devices and different drivers
+ * implement the backend support for it. However, device-specific
+ * messaging pipes are provided ...
[ message continues ]

Why bother versioning the API? Since this is generic netlink, and things
are looked up by the family name, a completely new version would just
use a new family name and be done with it, old userspace won't even
_find_ that new "version" of the API. The "minor version" seems also
useless, either you can do the change in a backward compatible way or
you cannot and need to provide compat code.

I'd just remove this.

johannes
[ message continues ]

That'd be a way to do majors -- hadn't thought about it.

But then, it forces a way to create "a way to grok versions" in the
family name, which is moving the problem from one place to the other.

Because parsing in the family means having to set a protocol and
parsing ASCII, I'd say it's easier to use the family's version field,

No it is not -- you are missing the case of adding an API
call/signal. Addition doesn't break backwards compatibility, yet a
user that requires the addition has to double check it is
available.

-- 
Inaky

--

[ message continues ]

I wasn't actually advocating parsing the family name, but thinking that
if you were to actually do a major revision then you'd be rewriting all
the userland code anyway and could just hardcode a new family name

No! API additions can always be discovered through the genl controller,
it supports listing which operations are available. Check out the genl
command from iproute2.

johannes

--

[ message continues ]

Well, if the change were *that* big, then yes, that makes full sense. 

Oh, then this can be used too -- I mean, one does not preclude the other.

-- 
Inaky
--

[ message continues ]

This file contains a simple debug framework that is used in the stack;
it allows the debug level to be controlled at compile-time (so the
debug code is optimized out) and at run-time (for what wasn't compiled
out).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 include/linux/wimax/debug.h |  495 +++++++++++++++++++++++++++++++++++++++++++
 net/wimax/debug-levels.h    |   42 ++++
 2 files changed, 537 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/wimax/debug.h
 create mode 100644 net/wimax/debug-levels.h

diff --git a/include/linux/wimax/debug.h b/include/linux/wimax/debug.h
new file mode 100644
index 0000000..2987c7d
--- /dev/null
+++ b/include/linux/wimax/debug.h
@@ -0,0 +1,495 @@
+/*
+ * Linux WiMAX
+ * Collection of tools to manage debug operations.
+ *
+ *
+ * Copyright (C) 2005-2007 Intel Corporation
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Don't #include this file directly, read on!
+ *
+ *
+ * EXECUTING DEBUGGING ACTIONS OR NOT
+ *
+ * The main thing this framework provides is decission power to take a
+ * debug action (like printing a message) if the current debug level
+ * allows it.
+ *
+ * The decission power is at two levels: at compile-time (what does
+ * not make it is compiled out) and at run-time. The run-time
+ * ...
[ message continues ]

Recently we got new stuff for dynamic printk
(include/linux/dynamic_printk.h) and pr_debug with a start format
(include/linux/kernel.h, pr_fmt); can you use any of that to make this
smaller? If not, I think you ought to argue why not, and possibly
improve the generic facility.

Personally, I'm tired of seeing every Intel driver come with a new huge

That && dev is wrong.

johannes
[ message continues ]

Yep, it was just too recent. I hadn't noticed it and I was told about
it a week ago. I just need to map it. It's on my plan to change it,

me too -- I am glad there is finally a common facility in the kernel

Another remnant from a previous implementation -- killed, thanks

-- 
Inaky

--

[ message continues ]

This file contains declarations and definitions used by the different
submodules of the stack.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/wimax-internal.h |   92 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/wimax-internal.h

diff --git a/net/wimax/wimax-internal.h b/net/wimax/wimax-internal.h
new file mode 100644
index 0000000..712890b
--- /dev/null
+++ b/net/wimax/wimax-internal.h
@@ -0,0 +1,92 @@
+/*
+ * Linux WiMAX
+ * Internal API for kernel space WiMAX stack
+ *
+ *
+ * Copyright (C) 2007 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This header file is for declarations and definitions internal to
+ * the WiMAX stack. For public APIs and documentation, see
+ * include/net/wimax.h and include/linux/wimax.h.
+ */
+
+#ifndef __WIMAX_INTERNAL_H__
+#define __WIMAX_INTERNAL_H__
+#ifdef __KERNEL__
+
+#include <linux/device.h>
+#include <net/wimax.h>
+
+
+/*
+ * Decide if a (locked) device is ready for use
+ *
+ * Before using the device structure, it must be locked
+ * (wimax_dev->mutex). As well, most operations need to call this
+ * function to check if the state is the right one.
+ *
+ * An error value will be ...
[ message continues ]

Might help to explain just what the concept is :)

johannes
[ message continues ]

Well, this means there is no medium on which to try to establish a
link. It doesn't really matter.


Yes, that required some documentation fixes; added, thanks.


-- 
Inaky

--

[ message continues ]

Yes, I think so.

johannes

--

[ message continues ]

Ack, I'll switch it to -ENOLINK.

Thanks,

-- 
Inaky
--

[ message continues ]

Low overhead method to map generic netlink family IDs to the WiMAX
device attached to them that optimizes for the case where most systems
have a single WiMAX device, or at most, a very low number of WiMAX
adaptors.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/id-table.c |  141 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 141 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/id-table.c

diff --git a/net/wimax/id-table.c b/net/wimax/id-table.c
new file mode 100644
index 0000000..b6b060e
--- /dev/null
+++ b/net/wimax/id-table.c
@@ -0,0 +1,141 @@
+/*
+ * Linux WiMAX
+ * Mappping of generic netlink family IDs to net devices
+ *
+ *
+ * Copyright (C) 2005-2006 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * We assign a single generic netlink family ID to each device (to
+ * simplify lookup).
+ *
+ * We need a way to map family ID to a wimax_dev pointer.
+ *
+ * The idea is to use a very simple lookup. Using a netlink attribute
+ * with (for example) the interface name implies a heavier search over
+ * all the network devices; seemed kind of a waste given that we know
+ * we are looking for a WiMAX device and that most systems will have
+ * just a single WiMAX adapter.
+ *
+ * We ...
[ message continues ]

No need for gotos any more :)

johannes
[ message continues ]

Duh ... sometimes the autopilot is not a good thing.

Fixed, thanks

-- 
Inaky

--

[ message continues ]

When user space wants to open a handle to a WiMAX device, it needs
information that is provided as a response to an "open" generic
netlink message.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/op-open.c |  157 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 157 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/op-open.c

diff --git a/net/wimax/op-open.c b/net/wimax/op-open.c
new file mode 100644
index 0000000..06c9cce
--- /dev/null
+++ b/net/wimax/op-open.c
@@ -0,0 +1,157 @@
+/*
+ * Linux WiMAX
+ * Netlink layer, open operation
+ *
+ *
+ * Copyright (C) 2005-2006 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Parse the open-handle command from user space.
+ *
+ * Accepts an "open" request from user space through generic netlink
+ * and replies to it with the information about internals that user
+ * space will need.
+ *
+ * This will only work if the device is in a state ready to accept
+ * user space intervention.
+ */
+#include <net/genetlink.h>
+#include <linux/wimax.h>
+#include <linux/security.h>
+#include "wimax-internal.h"
+
+#define D_SUBMODULE op_open
+#include "debug-levels.h"
+
+
+/*
+ * Authoritative source for the IFINFO attribute policy
+ *
+ * These ...
[ message continues ]

Why is this called "open" when it's not actually any opening that would

All this is discoverable via the genl controller and a pipe naming


GENL_ADMIN_PERM and remove the checks above?

[ message continues ]

In fact, it's entirely trivial since you use a genl family for each
interface, thus you just have to ask the genl controller for the groups
associated with that family. If you need sample code, check out iw.

johannes
[ message continues ]

The naming is a remnant from when I didn't really understand genl
and there was actually a close; then it got reused to do the discovery
part, but now I am going to kill all that using the iw code you pointed 

This was another consequence (as mentioned somewhere else) of me
not knowning how to use libnl properly; with that fixed, this is not
needed now and it is done with GENL_ADMIN_PERM in the policy flags.

Thanks,

-- 
Inaky

--

[ message continues ]

The nla_put results must be checked unless there's a guarantee that

This seems a bit excessive considering that its very unlikely
--

[ message continues ]

This patch provides Makefile and KConfig for the WiMAX stack,
integrating them into the networking stack's Makefile, Kconfig and
doc-book templates.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 Documentation/DocBook/networking.tmpl |    8 +++++++
 net/Kconfig                           |    2 +
 net/Makefile                          |    1 +
 net/wimax/Kconfig                     |   36 +++++++++++++++++++++++++++++++++
 net/wimax/Makefile                    |   12 +++++++++++
 5 files changed, 59 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/Kconfig
 create mode 100644 net/wimax/Makefile

diff --git a/Documentation/DocBook/networking.tmpl b/Documentation/DocBook/networking.tmpl
index f24f9e8..7053c1c 100644
--- a/Documentation/DocBook/networking.tmpl
+++ b/Documentation/DocBook/networking.tmpl
@@ -101,6 +101,14 @@ X!Enet/core/wireless.c
      <sect1><title>Synchronous PPP</title>
 !Edrivers/net/wan/syncppp.c
      </sect1>
+     <sect1><title>WiMAX</title>
+!Enet/wimax/op-msg.c
+!Enet/wimax/op-reset.c
+!Enet/wimax/op-rfkill.c
+!Enet/wimax/stack.c
+!Iinclude/net/wimax.h
+!Iinclude/linux/wimax.h
+     </sect1>
   </chapter>
 
 </book>
diff --git a/net/Kconfig b/net/Kconfig
index d789d79..3bff221 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -251,6 +251,8 @@ source "net/ieee80211/Kconfig"
 
 endif # WIRELESS
 
+source "net/wimax/Kconfig"
+
 source "net/rfkill/Kconfig"
 source "net/9p/Kconfig"
 
diff --git a/net/Makefile b/net/Makefile
index 27d1f10..620a505 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_NET_9P)		+= 9p/
 ifeq ($(CONFIG_NET),y)
 obj-$(CONFIG_SYSCTL)		+= sysctl_net.o
 endif
+obj-$(CONFIG_WIMAX)		+= wimax/
diff --git a/net/wimax/Kconfig b/net/wimax/Kconfig
new file mode 100644
index 0000000..67d5f4d
--- /dev/null
+++ b/net/wimax/Kconfig
@@ -0,0 +1,36 @@
+#
+# WiMAX LAN device configuration
+#
+
+menuconfig WIMAX
+       tristate "WiMAX Wireless Broadband support"
+      ...
[ message continues ]

Provides wimax_reset() for the kernel to reset a wimax device as
needed.

Exports wimax_reset() over generic netlink to user space.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/op-reset.c |  134 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 134 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/op-reset.c

diff --git a/net/wimax/op-reset.c b/net/wimax/op-reset.c
new file mode 100644
index 0000000..5ec64f6
--- /dev/null
+++ b/net/wimax/op-reset.c
@@ -0,0 +1,134 @@
+/*
+ * Linux WiMAX
+ * Implement and export a method for resetting a WiMAX device
+ *
+ *
+ * Copyright (C) 2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This implements a simple synchronous call to reset a WiMAX device.
+ *
+ * Resets aim at being warm, keeping the device handles active;
+ * however, when that fails, it falls back to a cold reset (that will
+ * disconnect and reconnect the device).
+ */
+
+#include <net/wimax.h>
+#include <net/genetlink.h>
+#include <linux/wimax.h>
+#include <linux/security.h>
+#include "wimax-internal.h"
+
+#define D_SUBMODULE op_reset
+#include "debug-levels.h"
+
+
+/**
+ * wimax_reset - Reset a WiMAX device
+ *
+ * @wimax_dev: WiMAX device descriptor
+ *
+ * ...
[ message continues ]

This is strange. Can you show your corresponding userspace code? It
shouldn't be necessary with generic netlink to explicitly send the
result, if you just return the result from wimax_reset() it'll be part
of the ACK message and thus already be relayed to userspace. I think
you're not using genl correctly here.

johannes
[ message continues ]

Fixed

FYI, the user space code is in 
kernel.org/pub/scm/linux/kernel/inaky/wimax-tools.git. However, that's the 
old one that doesn't contain all the fixes I've done with your feedback. 
Still haven't been able to push that one (been a little bit overwhelmed with 
other stuff).

I should be able to push all the changes tomorrow after I finish looking at 
the controller thing.

Thanks,


-- 
Inaky

--

[ message continues ]

Implements the basic life cycles of a 'struct wimax_dev', some common
generic netlink functionality for marshalling calls to user space,
and the device state machine.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/stack.c |  739 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 739 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/stack.c

diff --git a/net/wimax/stack.c b/net/wimax/stack.c
new file mode 100644
index 0000000..a674060
--- /dev/null
+++ b/net/wimax/stack.c
@@ -0,0 +1,739 @@
+/*
+ * Linux WiMAX
+ * Initialization, addition and removal of wimax devices
+ *
+ *
+ * Copyright (C) 2005-2006 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This implements:
+ *
+ *   - basic life cycle of 'struct wimax_dev' [wimax_dev_*()]; on
+ *     addition/registration initialize all subfields and allocate
+ *     generic netlink resources for user space communication. On
+ *     removal/unregistration, undo all that.
+ *
+ *   - helpers to send an operation result value back to user space
+ *     [wimax_gnl_send_rp_result()] over generic netlink.
+ *
+ *   - device state machine [wimax_state_change()] and support to send
+ *     reports to user space when the state changes
+ *     ...
[ message continues ]

This is not how netlink protocols should treat errors.
--

[ message continues ]

Other than the fact that this function is gone after Johannes comments
(so for everywhere else), wouldn't returning the -EMSGSIZE nla_put_*() 
returns enough?

I changed all of them to be something like:

result = nla_put*();
if (result < 0)
	goto error path /* release skb/msg, return result */

Thanks,

-- 
Inaky

--

[ message continues ]

That looks fine.
--

[ message continues ]

Provide most of the RF-Kill integration for WiMAX drivers so that all
device drivers have to do is after wimax_dev_add() is call
wimax_report_rfkill_{hw,sw}() to update initial state and then every
time it changes.

Provides wimax_rfkill() for the kernel to call to set software RF-Kill
status and/or query current hardware and software switch status.

Exports wimax_rfkill() over generic netlink to user space.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/op-rfkill.c |  546 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 546 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/op-rfkill.c

diff --git a/net/wimax/op-rfkill.c b/net/wimax/op-rfkill.c
new file mode 100644
index 0000000..1b7167f
--- /dev/null
+++ b/net/wimax/op-rfkill.c
@@ -0,0 +1,546 @@
+/*
+ * Linux WiMAX
+ * RF-kill framework integration
+ *
+ *
+ * Copyright (C) 2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This integrates into the Linux Kernel rfkill susbystem so that the
+ * drivers just have to do the bare minimal work, which is providing a
+ * method to set the software RF-Kill switch and to report changes in
+ * the software and hardware switch status.
+ *
+ * A non-polled generic rfkill device is embedded ...
[ message continues ]

permissions thing again

Also, doesn't rfkill already have a userspace interface in sysfs? Why
add another one?

johannes
[ message continues ]

Need it to query also the hardware rfkill state, which wasn't available
on rfkill's interface. This uses almost the same mechanism, in any case.

-- 
Inaky

--

[ message continues ]

The driver for the i2400m is a stacked driver. There is a core driver,
the bus-generic driver that has no knowledge or dependencies on how
the device is connected to the system; it only knows how to speak the
device protocol. Then there are the bus-specific drivers (for USB and
SDIO) that provide backends for the generic driver to communicate with
the device.

The bus generic driver connects to the network and WiMAX stacks on the
top side, and on the bottom to the bus-specific drivers.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 Documentation/wimax/README.i2400m |  236 +++++++++++++++++++++++++++++++++++++
 1 files changed, 236 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/wimax/README.i2400m

diff --git a/Documentation/wimax/README.i2400m b/Documentation/wimax/README.i2400m
new file mode 100644
index 0000000..b6ba951
--- /dev/null
+++ b/Documentation/wimax/README.i2400m
@@ -0,0 +1,236 @@
+   Driver for the Intel Wireless Wimax Connection 2400m
+
+   (C) 2008 Intel Corporation < linux-wimax@intel.com >
+
+   This provides a driver for the Intel Wireless WiMAX Connection 2400m
+   and a basic Linux kernel WiMAX stack.
+
+Requirements
+
+     * Linux installation with Linux kernel 2.6.22 or newer (if building
+       from a separate tree)
+     * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel
+       Wireless WiMAX/WiFi Link 5x50 series. 
+     * build tools:
+          + Linux kernel development package for the target kernel; to
+            build against your currently running kernel, you need to have
+            the kernel development package corresponding to the running
+            image installed (usually if your kernel is named
+            linux-VERSION, the development package is called
+            linux-dev-VERSION or linux-headers-VERSION).
+          + GNU C Compiler, make
+
+Compilation and installation
+
+Compilation of the drivers included in the kernel
+
+   Configure the kernel; to enable ...
[ message continues ]

Are any of those actually needed for normal operation, and cannot be in

Couldn't statistics be in some more generic wimax file rather than per
driver?

johannes
[ message continues ]

Yes, it will. There is a linux-firmware-wimax tree I'll ask David to pull

Actually some of them could. I'll see to put them.

The reset ones I want to keep in there, as for support they come in 

Very driver specific. These statistics refer to the way the device sends
and receives stuff, which is coalesced (so one of this packets doesn't map
to an IP packet).

This one belongs to debugfs.


-- 
Inaky

--

[ message continues ]

This defines the structures and constants for the host-device
protocols:

 - boot / firmware upload protocol

 - general data transport protocol

 - control protocol

This header file is done in such a way that can also be used verbatim
by user space.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 include/linux/wimax/i2400m.h |  512 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 512 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/wimax/i2400m.h

diff --git a/include/linux/wimax/i2400m.h b/include/linux/wimax/i2400m.h
new file mode 100644
index 0000000..74198f5
--- /dev/null
+++ b/include/linux/wimax/i2400m.h
@@ -0,0 +1,512 @@
+/*
+ * Intel Wireless WiMax Connection 2400m
+ * Host-Device protocol interface definitions
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR ...
[ message continues ]

Since this is all device-specific, this is like implementing all of
802.11 management with iwpriv. Do you really want that? Why wouldn't
most of these commands port over to other hardware?

johannes
[ message continues ]

No it is not -- management is done at the device level; disconnect WiFi, 

As explained on the first message, vendors might choose to break the
hw interface at a different level. We won't force vendors to use the
same interface as the Intel device does or make the same design 
decisions we made.

-- 
Inaky

--

[ message continues ]

This header file defines all the APIs used by the core, bus-generic
driver (i2400m) and the bus specific drivers (i2400m-BUSNAME). It also
gives a roadmap to the driver implementation.

Also add the core driver's debug settings.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/debug-levels.h |   45 ++
 drivers/net/wimax/i2400m/i2400m.h       |  745 +++++++++++++++++++++++++++++++
 2 files changed, 790 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/debug-levels.h
 create mode 100644 drivers/net/wimax/i2400m/i2400m.h

diff --git a/drivers/net/wimax/i2400m/debug-levels.h b/drivers/net/wimax/i2400m/debug-levels.h
new file mode 100644
index 0000000..dd45938
--- /dev/null
+++ b/drivers/net/wimax/i2400m/debug-levels.h
@@ -0,0 +1,45 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Debug levels control file for the i2400m module
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+#ifndef __debug_levels__h__
+#define __debug_levels__h__
+
+/* Maximum compile and run time debug level for all submodules */
+#define D_MODULENAME i2400m
+#define D_MASTER CONFIG_WIMAX_I2400M_DEBUG_LEVEL
+
+#include <linux/wimax/debug.h>
+
+/* List of all the enabled ...
[ message continues ]

This implements a direct communication channel between user space and
the driver/device, by which free form messages can be sent back and
forth.

This is intended for device-specific features, vendor quirks, etc.

Currently is the only communication mechanism used because there is no
standard kernel API defined for WiMAX operation. Not enough devices
are in the market to decide what is a good user-kernel API/abstraction
layer.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 net/wimax/op-msg.c |  495 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 495 insertions(+), 0 deletions(-)
 create mode 100644 net/wimax/op-msg.c

diff --git a/net/wimax/op-msg.c b/net/wimax/op-msg.c
new file mode 100644
index 0000000..cfa7929
--- /dev/null
+++ b/net/wimax/op-msg.c
@@ -0,0 +1,495 @@
+/*
+ * Linux WiMAX
+ * Generic messaging interface between userspace and driver/device
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * This implements a direct communication channel between user space and
+ * the driver/device, by which free form messages can be sent back and
+ * forth.
+ *
+ * This is intended for device-specific features, vendor quirks, etc.
+ *
+ * By default, all devices ...
[ message continues ]

Obviously I don't like this, reminds me too much of iwpriv. What kind of
messages are you passing now? What would be wrong with defining those
things you need now as actual commands, and then later
extending/modifying the command set when new hardware shows up?

That's what we're doing in cfg80211, simply adding commands as we go
along and not everybody has to support all commands, ultimately. You can

same thing with permissions here

johannes
[ message continues ]

I think this is fundamentally wrong by design. There should be one
WiMAX genetlink family with a set of commands taking the interface
index as attribute. The number of genetlink families is critical

Not sure what you mean by that, the attribute policies are not shared
between kernel and userspace. The attribute policy defines the semantics


This dosen't look right, genlmsg_new() expects the size of the


You shouldn't access the netlink header via skb->head or skb->data as it
is done in numerous places. The genetlink layer passes a struct
genl_info to the doit() callback which conains a pointer to the netlink

So users have to call both wimax_msg_data() and wimax_msg_len() which
both walk through all attributes to find the attribute in question.
You could simply return the nlattr and rely on users to call nla_data()


It's not wrong to parse the attributes yourself but it's a lot easier to
define them as one sequence and have the genetlink layer parse and
validate them for you. Simply assign the highest attribute number and
policy to the family and they will be made available in the info
structure.
--

[ message continues ]

The number should not be a problem; the strange case is going to be the 
system that has more than one WiMAX interface.

So if the general case is going to be 1 interface, instead of making one
lookup for the family name and then another lookup for the attribute 

the libnls I've seen don't define type NLA_BINARY -- I don't really know 
how they map onto each other, but using NLA_UNSPEC on both sides (kernel


So I am going to create a message, with no family specific payload
but just an attribute with a buffer sized 'size'. What should
I pass to it so it preallocates correctly? 



This is mostly used before sending a message to user space, so genl_info 
doesn't apply. By default all notifications from the device are sent over
generic netlink to user space.

But some times we need to consume that information inside the kernel, so
instead of creating two separate formats, we just use the same. So we need
to extract, from an SKB that is packaged to be sent as generic netlink, 
the header. And at his point there is no genl_info :(

I've missed a couple that can get it from genl_info (in rfkill and msg), plus 
reset doesn't really needed. Updated them; the rest are contained in 

Good point; actually in most cases it either needs the pointer data

Why? Should I just use NLA_BINARY then? What do I use in user space to compose
it if libnl still doesn't know about NLA_BINARY?


So the policy is already set up like that, it has a pointer to the policy.
Are you saying it should be possible for me to just access genl_info->attrs[]?
[I didn't know that existed, just found out after your comment made me look
at it].

/me tries...

sweet, it works -- well, this cuts more code out, thanks.

-- 
Inaky

--

[ message continues ]

Implements the generic probe and disconnect functions, plus WiMAX
stack backends for device reset and message passing.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/driver.c |  729 +++++++++++++++++++++++++++++++++++++
 1 files changed, 729 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/driver.c

diff --git a/drivers/net/wimax/i2400m/driver.c b/drivers/net/wimax/i2400m/driver.c
new file mode 100644
index 0000000..f7b960e
--- /dev/null
+++ b/drivers/net/wimax/i2400m/driver.c
@@ -0,0 +1,729 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Generic probe/disconnect, reset and message passing
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * See i2400m.h for driver documentation. This contains helpers for
+ * the driver model glue [_setup()/_release()], handling device resets
+ * [_dev_reset_handle()], and the backends for the WiMAX stack ops
+ * reset [_op_reset()] and message from user [_op_msg_from_user()].
+ *
+ * ROADMAP:
+ *
+ * i2400m_op_msg_from_user()
+ *   i2400m_msg_to_dev()
+ *   wimax_msg_to_user_send()
+ *
+ * i2400m_op_reset()
+ *   i240m->bus_reset()
+ *
+ * i2400m_dev_reset_handle()
+ *   ...
[ message continues ]

Expose knobs to control the device (induce reset, power saving,
querying tx or rx stats, internal debug information and debug level
manipulation).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/sysfs.c |  458 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 458 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/sysfs.c

diff --git a/drivers/net/wimax/i2400m/sysfs.c b/drivers/net/wimax/i2400m/sysfs.c
new file mode 100644
index 0000000..3640719
--- /dev/null
+++ b/drivers/net/wimax/i2400m/sysfs.c
@@ -0,0 +1,458 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Sysfs interfaces to show driver and device information
+ *
+ *
+ * Copyright (C) 2007 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/spinlock.h>
+#include <linux/device.h>
+#include "i2400m.h"
+
+
+#define D_SUBMODULE sysfs
+#include "debug-levels.h"
+
+/*
+ * Cold reset the device (deferred work routine)
+ *
+ * Need to use a workstruct because when done from sysfs, the device
+ * lock is taken, so after a reset, the new device "instance" is
+ * connected before we have a chance to disconnect the current
+ * instance. This ...
[ message continues ]

Seems all of that would be better in debugfs rather than making it part
of some userspace ABI? Do you actually use this in programs (rather than
manually, test tools don't count) in userspace?

johannes
[ message continues ]

Provides a backend function pointer to the WiMAX stack to manipulate
the rfkill state when requested by the kernel or user space (either
directly through the rfkill subsystem or through the WiMAX control
interface).

As well, it reports back any changes in the RF-Kill switches state to
the stack.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/op-rfkill.c |  207 ++++++++++++++++++++++++++++++++++
 1 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/op-rfkill.c

diff --git a/drivers/net/wimax/i2400m/op-rfkill.c b/drivers/net/wimax/i2400m/op-rfkill.c
new file mode 100644
index 0000000..487ec58
--- /dev/null
+++ b/drivers/net/wimax/i2400m/op-rfkill.c
@@ -0,0 +1,207 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Implement backend for the WiMAX stack rfkill support
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * The WiMAX kernel stack integrates into RF-Kill and keeps the
+ * switches's status. We just need to:
+ *
+ * - report changes in the HW RF Kill switch [with
+ *   wimax_rfkill_{sw,hw}_report(), which happens when we detect those
+ *   indications coming through hardware reports]. We also do it on
+ *   ...
[ message continues ]

Implementation of the glue to the network stack so the WiMAX device
shows up as an Ethernet device.

Initially we shot for implementing a Pure IP device -- however, the
world seems to turn around Ethernet devices. Main issues were with the
ISC DHCP client and servers (as they don't understand types other than
Ethernet and Token Ring).

We proceeded to register with IANA the PureIP hw type, so that DHCP
requests could declare such. We also created patches to the main ISC
DHCP versions to support it. However, until all that permeates into
deployments, there is going to be a long time.

So we moved back to wrap Ethernet frames around the PureIP device. At
the time being this has overhead; we need to reallocate with space for
an Ethernet header. The reason is the device-to-host protocol
coalesces many network packets into a single message, so we can't
introduce Ethernet headers without overwriting valid data from other
packets.

Follow up versions of the firmware have this issue solved.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/netdev.c |  524 +++++++++++++++++++++++++++++++++++++
 1 files changed, 524 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/netdev.c

diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
new file mode 100644
index 0000000..63fe708
--- /dev/null
+++ b/drivers/net/wimax/i2400m/netdev.c
@@ -0,0 +1,524 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Glue with the networking stack
+ *
+ *
+ * Copyright (C) 2007 Intel Corporation <linux-wimax@intel.com>
+ * Yanir Lubetkin <yanirx.lubetkin@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY ...
[ message continues ]

Handling of data coming from the i2400m device (IP packets, control
and diagnostics). This parses the received read transaction from the
device, breaks it in chunks and passes it to the corresponding
subsystems (network and control).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/rx.c |  536 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 536 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/rx.c

diff --git a/drivers/net/wimax/i2400m/rx.c b/drivers/net/wimax/i2400m/rx.c
new file mode 100644
index 0000000..dbe9e5e
--- /dev/null
+++ b/drivers/net/wimax/i2400m/rx.c
@@ -0,0 +1,536 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Handle incoming traffic and deliver it to the control or data planes
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, ...
[ message continues ]

Implements the firmware loader (using the bus-specific driver's
backends for the actual upload). The most critical thing in here is
the piece that puts the device in boot-mode from any other
(undetermined) state, otherwise, it is just pushing the bytes from the
firmware file to the device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/fw.c | 1095 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 1095 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/fw.c

diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
new file mode 100644
index 0000000..1d8271f
--- /dev/null
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -0,0 +1,1095 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Firmware uploader
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, ...
[ message continues ]

Implements data transmission to the device; this is done through a
software FIFO, as data/control frames can be coalesced (while the
device is reading the previous tx transaction, others accumulate).

A FIFO is used because at the end it is resource-cheaper that trying
to implement scatter/gather over USB. As well, most traffic is going
to be download (vs upload).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/tx.c |  817 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 817 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/tx.c

diff --git a/drivers/net/wimax/i2400m/tx.c b/drivers/net/wimax/i2400m/tx.c
new file mode 100644
index 0000000..613a88f
--- /dev/null
+++ b/drivers/net/wimax/i2400m/tx.c
@@ -0,0 +1,817 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Generic (non-bus specific) TX handling
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ...
[ message continues ]

When the device has anything for the host (namely when there is data
ready to be read or when it resets), it sends a notification to the
host; this is the code that receives and deals with them, passing
reads to i2400m_rx() or handling resets with
i2400m_dev_reset_handle().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/usb-notif.c |  263 ++++++++++++++++++++++++++++++++++
 1 files changed, 263 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/usb-notif.c

diff --git a/drivers/net/wimax/i2400m/usb-notif.c b/drivers/net/wimax/i2400m/usb-notif.c
new file mode 100644
index 0000000..2715d58
--- /dev/null
+++ b/drivers/net/wimax/i2400m/usb-notif.c
@@ -0,0 +1,263 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m over USB
+ * Notification handling
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, ...
[ message continues ]

This is a collection of functions used to control the device (plus a
few helpers).

There are utilities for handling TLV buffers, hooks on the device's
reports to act on device changes of state [i2400m_report_hook()], on
acks to commands [i2400m_msg_ack_hook()], a helper for sending
commands to the device and blocking until a reply arrives
[i2400m_msg_to_dev()], a few high level commands for manipulating the
device state, powersving mode and configuration plus the routines to
setup the device once communication is established with it
[i2400m_dev_initialize()].

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/control.c | 1295 ++++++++++++++++++++++++++++++++++++
 1 files changed, 1295 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/control.c

diff --git a/drivers/net/wimax/i2400m/control.c b/drivers/net/wimax/i2400m/control.c
new file mode 100644
index 0000000..d4bcf3c
--- /dev/null
+++ b/drivers/net/wimax/i2400m/control.c
@@ -0,0 +1,1295 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Miscellaneous control functions for managing the device
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE ...
[ message continues ]

These two files are what user space can use to establish communication
with the WiMAX kernel API and to speak the Intel 2400m Wireless WiMAX
connection's control protocol.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
 include/linux/Kbuild       |    2 ++
 include/linux/wimax/Kbuild |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/wimax/Kbuild

diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index e531783..89079ff 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -375,3 +375,5 @@ unifdef-y += xattr.h
 unifdef-y += xfrm.h
 
 objhdr-y += version.h
+header-y += wimax.h
+header-y += wimax/
diff --git a/include/linux/wimax/Kbuild b/include/linux/wimax/Kbuild
new file mode 100644
index 0000000..3cb4f26
--- /dev/null
+++ b/include/linux/wimax/Kbuild
@@ -0,0 +1 @@
+header-y += i2400m.h
-- 
1.5.6.5

--

[ message continues ]

Implements the backend so that the generic driver can send data to the
USB device. Implemented with a kthread sitting in a never-ending loop
that when kicked by the generic driver will pull data from the TX FIFO
and send it to the device until it drains it. Then it goes back sleep,
waiting for another kick.

This is a thread for similar reasons as the case of USB reading. We
need to be able to use the USB autopm management functions, which are
blocking. As well, it is dedicated to a single task, so it has less
overhead than a workqueue.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/usb-tx.c |  229 +++++++++++++++++++++++++++++++++++++
 1 files changed, 229 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/usb-tx.c

diff --git a/drivers/net/wimax/i2400m/usb-tx.c b/drivers/net/wimax/i2400m/usb-tx.c
new file mode 100644
index 0000000..dfd8933
--- /dev/null
+++ b/drivers/net/wimax/i2400m/usb-tx.c
@@ -0,0 +1,229 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * USB specific TX handling
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR ...
[ message continues ]

This patch adds entries for the original developers of the i2400m
drivers and up-to-date maintainer entries.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 CREDITS     |   17 +++++++++++++++++
 MAINTAINERS |   16 ++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/CREDITS b/CREDITS
index b50db17..ae5b804 100644
--- a/CREDITS
+++ b/CREDITS
@@ -464,6 +464,11 @@ S: 1200 Goldenrod Dr.
 S: Nampa, Idaho 83686
 S: USA
 
+N: Dirk J. Brandewie
+E: dirk.j.brandewie@intel.com
+E: linux-wimax@intel.com
+D: Intel Wireless WiMAX Connection 2400 SDIO driver
+
 N: Derrick J. Brashear
 E: shadow@dementia.org
 W: http://www.dementia.org/~shadow
@@ -2119,6 +2124,11 @@ N: H.J. Lu
 E: hjl@gnu.ai.mit.edu
 D: GCC + libraries hacker
 
+N: Yanir Lubetkin
+E: yanirx.lubatkin@intel.com
+E: linux-wimax@intel.com
+D: Intel Wireless WiMAX Connection 2400 driver
+
 N: Michal Ludvig
 E: michal@logix.cz
 E: michal.ludvig@asterisk.co.nz
@@ -2693,6 +2703,13 @@ S: RR #5, 497 Pole Line Road
 S: Thunder Bay, Ontario
 S: CANADA P7C 5M9
 
+N: Inaky Perez-Gonzalez
+E: inaky.perez-gonzalez@intel.com
+E: linux-wimax@intel.com
+E: inakypg@yahoo.com
+D: WiMAX stack
+D: Intel Wireless WiMAX Connection 2400 driver
+
 N: Yuri Per
 E: yuri@pts.mipt.ru
 D: Some smbfs fixes
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e0777f..7950b97 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2299,6 +2299,14 @@ W:	http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
 W:	http://ipw2200.sourceforge.net
 S:	Supported
 
+INTEL WIRELESS WIMAX CONNECTION 2400
+P:	Inaky Perez-Gonzalez
+M:	inaky.perez-gonzalez@intel.com
+M:	linux-wimax@intel.com
+L:	wimax@linuxwimax.org
+S:	Supported
+W:	http://linuxwimax.org
+
 INTEL WIRELESS WIFI LINK (iwlwifi)
 P:	Zhu Yi
 M:	yi.zhu@intel.com
@@ -4704,6 +4712,14 @@ M:	zaga@fly.cc.fer.hr
 L:	linux-scsi@vger.kernel.org
 S:	Maintained
 
+WIMAX STACK
+P:	Inaky ...
[ message continues ]

This contains the common function declaration and constants for the
SDIO driver for the 2400m Wireless WiMAX Connection and the debug
level settings for the SDIO driver.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/i2400m-sdio.h       |  130 ++++++++++++++++++++++++++
 drivers/net/wimax/i2400m/sdio-debug-levels.h |   22 +++++
 2 files changed, 152 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/i2400m-sdio.h
 create mode 100644 drivers/net/wimax/i2400m/sdio-debug-levels.h

diff --git a/drivers/net/wimax/i2400m/i2400m-sdio.h b/drivers/net/wimax/i2400m/i2400m-sdio.h
new file mode 100644
index 0000000..1c9cd54
--- /dev/null
+++ b/drivers/net/wimax/i2400m/i2400m-sdio.h
@@ -0,0 +1,130 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * SDIO-specific i2400m driver definitions
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE ...
[ message continues ]

This implements the backends for the generic driver (i2400m) to be
able to load firmware to the SDIO device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/sdio-fw.c |  224 ++++++++++++++++++++++++++++++++++++
 1 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/sdio-fw.c

diff --git a/drivers/net/wimax/i2400m/sdio-fw.c b/drivers/net/wimax/i2400m/sdio-fw.c
new file mode 100644
index 0000000..8e3a286
--- /dev/null
+++ b/drivers/net/wimax/i2400m/sdio-fw.c
@@ -0,0 +1,224 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Firmware uploader's SDIO specifics
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR ...
[ message continues ]

Implements probe/disconnect for the USB device, as well as main
backends for the generic driver to control the USB device
(bus_dev_start(), bus_dev_stop() and bus_reset()).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/usb.c |  622 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 622 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/usb.c

diff --git a/drivers/net/wimax/i2400m/usb.c b/drivers/net/wimax/i2400m/usb.c
new file mode 100644
index 0000000..60092ef
--- /dev/null
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -0,0 +1,622 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Linux driver model glue for USB device, reset & fw upload
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ * Yanir Lubetkin <yanirx.lubetkin@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * See i2400m-usb.h for a general description of this driver.
+ *
+ * This file implements driver model glue, and hook ups for the
+ * generic driver to implement the bus-specific functions (device
+ * communication setup/tear down, firmware upload and resetting).
+ *
+ * ROADMAP
+ *
+ * i2400mu_probe()
+ *   alloc_netdev()...
+ *     i2400mu_netdev_setup()
+ *       i2400mu_init()
+ *       ...
[ message continues ]

This is a simple framework for tracking the amount of soft-errors in
time, so that if they go over a certain threshold they can be
considered hard errors and recovery started (instead of just
retrying).

We use this in the USB driver -- some of the USB errors are considered
soft and retried.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/edc.h |   90 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 90 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/edc.h

diff --git a/drivers/net/wimax/i2400m/edc.h b/drivers/net/wimax/i2400m/edc.h
new file mode 100644
index 0000000..714540f
--- /dev/null
+++ b/drivers/net/wimax/i2400m/edc.h
@@ -0,0 +1,90 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Error Density Count: cheapo error density (over time) counter
+ *
+ *
+ * Copyright (C) 2005-2007 Intel Corporation <linux-wimax@intel.com>
+ * Reinette Chatre <reinette.chatre@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Embed an 'struct edc' somewhere. Each time there is a soft or
+ * retryable error, call edc_inc() and check if the error top
+ * watermark has been reached.
+ */
+
+#ifndef __EDC_H__
+#define __EDC_H__
+
+enum {
+	EDC_MAX_ERRORS = 10,
+	EDC_ERROR_TIMEFRAME = HZ,
+};
+
+/* error density counter */
+struct edc {
+	unsigned long ...
[ message continues ]

This contains the common function declaration and constants for the
USB driver for the 2400m Wireless WiMAX Connection, as well as the
debug level settings for the USB driver.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/i2400m-usb.h       |  190 +++++++++++++++++++++++++++
 drivers/net/wimax/i2400m/usb-debug-levels.h |   42 ++++++
 2 files changed, 232 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/i2400m-usb.h
 create mode 100644 drivers/net/wimax/i2400m/usb-debug-levels.h

diff --git a/drivers/net/wimax/i2400m/i2400m-usb.h b/drivers/net/wimax/i2400m/i2400m-usb.h
new file mode 100644
index 0000000..e22cde4
--- /dev/null
+++ b/drivers/net/wimax/i2400m/i2400m-usb.h
@@ -0,0 +1,190 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * USB-specific i2400m driver definitions
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE ...
[ message continues ]

This code implements reading from the USB device; it uses a simple
adaptive algorithm so it doesn't preallocate huge buffers that then
are underused. When a transaction is read, it is passed to the generic
driver for processing and delivery.

All is done in a kthread sitting on a loop. We need a thread context
to run USB autopm functions and to process the received data (can get
to be heavy in processing time). It is dedicated to a single task, so
it has less overhead than a workqueue.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/usb-rx.c |  417 +++++++++++++++++++++++++++++++++++++
 1 files changed, 417 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/usb-rx.c

diff --git a/drivers/net/wimax/i2400m/usb-rx.c b/drivers/net/wimax/i2400m/usb-rx.c
new file mode 100644
index 0000000..074cc1f
--- /dev/null
+++ b/drivers/net/wimax/i2400m/usb-rx.c
@@ -0,0 +1,417 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * USB RX handling
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE ...
[ message continues ]

Implements probe/disconnect for the SDIO device, as well as main
backends for the generic driver to control the SDIO device
(bus_dev_start(), bus_dev_stop() and bus_reset()).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/sdio.c |  491 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 491 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/sdio.c

diff --git a/drivers/net/wimax/i2400m/sdio.c b/drivers/net/wimax/i2400m/sdio.c
new file mode 100644
index 0000000..b70ffd7
--- /dev/null
+++ b/drivers/net/wimax/i2400m/sdio.c
@@ -0,0 +1,491 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Linux driver model glue for the SDIO device, reset & fw upload
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation <linux-wimax@intel.com>
+ * Dirk Brandewie <dirk.j.brandewie@intel.com>
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
+ * Yanir Lubetkin <yanirx.lubetkin@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * See i2400m-sdio.h for a general description of this driver.
+ *
+ * This file implements driver model glue, and hook ups for the
+ * generic driver to implement the bus-specific functions (device
+ * communication setup/tear down, firmware upload and resetting).
+ *
+ * ROADMAP
+ *
+ * i2400m_probe()
+ *   alloc_netdev()
+ *     ...
[ message continues ]

This code implements reading from the SDIO device; when data is ready
the SDIO IRQ is fired and that will allocate an skb, put all the data
there and then pass it to the generic driver for processing and delivery.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/sdio-rx.c |  255 ++++++++++++++++++++++++++++++++++++
 1 files changed, 255 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/sdio-rx.c

diff --git a/drivers/net/wimax/i2400m/sdio-rx.c b/drivers/net/wimax/i2400m/sdio-rx.c
new file mode 100644
index 0000000..237279d
--- /dev/null
+++ b/drivers/net/wimax/i2400m/sdio-rx.c
@@ -0,0 +1,255 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * SDIO RX handling
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * ...
[ message continues ]

Implements the backend so that the generic driver can send data to the
SDIO device. When kicked by the generic driver, this will schedule
work on a driver-specific workqueue that pulls data from the TX FIFO
and sends it to the device until it drains it.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/sdio-tx.c |  153 ++++++++++++++++++++++++++++++++++++
 1 files changed, 153 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/sdio-tx.c

diff --git a/drivers/net/wimax/i2400m/sdio-tx.c b/drivers/net/wimax/i2400m/sdio-tx.c
new file mode 100644
index 0000000..8f29a3b
--- /dev/null
+++ b/drivers/net/wimax/i2400m/sdio-tx.c
@@ -0,0 +1,153 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * SDIO TX transaction backends
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, ...
[ message continues ]

This patch provides the Makefile and KConfig for the i2400m driver,
integrating them into the WiMAX stack's Makefile and Kconfig.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/Kconfig               |    2 +
 drivers/net/Makefile              |    1 +
 drivers/net/wimax/Kconfig         |   17 +++++++++++++
 drivers/net/wimax/Makefile        |    2 +
 drivers/net/wimax/i2400m/Kconfig  |   49 +++++++++++++++++++++++++++++++++++++
 drivers/net/wimax/i2400m/Makefile |   28 +++++++++++++++++++++
 6 files changed, 99 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/Kconfig
 create mode 100644 drivers/net/wimax/Makefile
 create mode 100644 drivers/net/wimax/i2400m/Kconfig
 create mode 100644 drivers/net/wimax/i2400m/Makefile

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 11f143f..f413d58 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2584,6 +2584,8 @@ source "drivers/net/tokenring/Kconfig"
 
 source "drivers/net/wireless/Kconfig"
 
+source "drivers/net/wimax/Kconfig"
+
 source "drivers/net/usb/Kconfig"
 
 source "drivers/net/pcmcia/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index f19acf8..3ac378f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -262,3 +262,4 @@ obj-$(CONFIG_NIU) += niu.o
 obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
 obj-$(CONFIG_SFC) += sfc/
 
+obj-y += wimax/
diff --git a/drivers/net/wimax/Kconfig b/drivers/net/wimax/Kconfig
new file mode 100644
index 0000000..30347e4
--- /dev/null
+++ b/drivers/net/wimax/Kconfig
@@ -0,0 +1,17 @@
+#
+# WiMAX LAN device drivers configuration
+#
+
+
+comment "Enable WiMAX (Networking options) to see the WiMAX drivers"
+        depends on WIMAX = n
+
+if WIMAX
+
+menu "WiMAX Wireless Broadband devices"
+
+source "drivers/net/wimax/i2400m/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/net/wimax/Makefile b/drivers/net/wimax/Makefile
new file mode 100644
index 0000000..bda9430
--- ...
[ message continues ]

This implements the backends for the generic driver (i2400m) to be
able to load firmware to the USB device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
 drivers/net/wimax/i2400m/usb-fw.c |  340 +++++++++++++++++++++++++++++++++++++
 1 files changed, 340 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wimax/i2400m/usb-fw.c

diff --git a/drivers/net/wimax/i2400m/usb-fw.c b/drivers/net/wimax/i2400m/usb-fw.c
new file mode 100644
index 0000000..5ad287c
--- /dev/null
+++ b/drivers/net/wimax/i2400m/usb-fw.c
@@ -0,0 +1,340 @@
+/*
+ * Intel Wireless WiMAX Connection 2400m
+ * Firmware uploader's USB specifics
+ *
+ *
+ * Copyright (C) 2007-2008 Intel Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR ...
[ message continues ]

From: Inaky Perez-Gonzalez <inaky@linux.intel.com>

I'm fine with this, so feel free to merge this stuff in via
the USB stack (due to the dependencies there).

Thanks!
--

[ message continues ]

Thanks David -- I'll wait for some feedback some guys told me they were
going to send and submit (latest on Monday) the patchset to Greg KH.

-- 
Inaky
--

[ message continues ]

On Wednesday 26 of November 2008, Inaky Perez-Gonzalez wrote:


Is 802.11b/g also supported by this driver (or other existing linux driver) ?

AFAIK these intel cards do support 802.11b/g, too.

(I asked this before but vger bounced my email, so resending)
-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
--

[ message continues ]

some of them are multi-function devices and Linux binds drivers on a  
per function (or in the USB term, interface). So in case of multi- 
radio cards you need separate drivers for each function. The 2400m  
driver is only responsible for the WiMAX function.

Regards

Marcel

--

[ message continues ]

Hi,

Thanks for this work. I don't personally have much of an interest in
wimax, so I don't really care what you do, so take things I have said
and will say with a grain of salt. It's not my intention to say "you've
done it all wrong", but more to offer observations on how these things
were done in wifi and how it went all wrong there, requiring a complete
rewrite recently.

Conceptually, I think wimax is now at a point where wifi was many years
ago with the first wireless drivers: everything was full-mac, wext
ioctls were written to go directly to the driver. Then ipw2x00 came
along, more functionality was moved to the host (yes, you say this won't
happen with wimax, but I think it will, eventually, if wimax gets to be
popular enough. never say never), and wext got more messy. Wext even was
defining actual operations, as undefined as they often were, you're not

I don't think you can say it's like cfg80211, cfg80211 in fact does a
lot more than the wimax "stack", it can validate parameters for example,
and provides actual operations (key operations, peer operations,
scanning [soon], ...) rather than just a transport to the driver. As
I've said on the relevant patch, I'd love to see the wimax stack take

I don't see that as much of a problem. Many of the commands you have
defined for the i2400m driver are very generic, for example:
 * I2400M_MT_GET_SCAN_RESULT
 * I2400M_MT_SET_SCAN_PARAM (why are those not part of the SCAN command btw=
?)
 * I2400M_MT_CMD_SCAN
 * I2400M_MT_CMD_CONNECT
 * I2400M_MT_CMD_DISCONNECT
 * I2400M_MT_GET_LINK_STATUS
 * I2400M_MT_GET_STATISTICS
 * I2400M_MT_GET_STATE
 * I2400M_MT_SET_INIT_CONFIG
 * I2400M_MT_CMD_INIT
 * I2400M_MT_CMD_ENTER_POWERSAVE
 * all the *EAP* seem applicable to devices that don't offload all of
   that to the host, and those devices that do will just need new, more
   lower level, primitives, compare for example the wext WPA stuff which
   handles both the PS3 wifi that does this in the "hardware" and normal
   wireless ...
[ message continues ]

some parts of the WiMAX specification are still undergoing re-writes  
and we really don't know for sure what is coming. We just have to  

The idea is to make the WiMAX subsystem more generic and create  
something similar to what we have with mac80211/cfg80211 and also  
inside Bluetooth. This is the common starting point and next step is  
to move functionality that has been identified as generic and common  
from the driver into the subsystem.

I prefer if we do this development inside the kernel tree instead of  
externally. One big thing we should have learned from mac80211 is that  
developing a full stack outside the kernel source tree is not really  
working out. We should apply the same model as we did for ext4 or what  

It has been open source since quite some time now at linuxwimax.org  

Either we do Ethernet framing or a pure IP device. I am for the pure  
IP device with a separate ARP header (which we managed to get  
allocated). Wrapping everything into Ethernet only because dhclient is  
broken is not an answer. An alternate option would be a point-to-point  
device like the HSO driver or PPP is using. However then the usage of  
DHCP becomes a lot more trickier. Don't ask me why WiMAX decided to go  
for DHCP and not did the IP stuff in-band.

Regards

Marcel

--

[ message continues ]

The problem is with the current stack design this isn't really possible,
since the stack only provides like three real commands:
 * talk to driver
 * reset device

The problem with that is that the stack is setting APIs in stone that
are, if you ask me, suboptimal. Once we add those, I don't see how we
can migrate away from a "command handled by driver" model towards a
"command handled by stack and appropriate driver callback called" model,

Ok, sorry, I thought there was a bunch of binary code still.

johannes
[ message continues ]

The 802.1x supplicant still is.

Dan


--

[ message continues ]

It's not only dhclient, but also lots of other raw packet users like

I personally think user convenience is more important at least short term.
It's also not that the pseudo header is that much overhead.

-Andi
-- 
ak@linux.intel.com
--

[ message continues ]

tcpdump works fine on almost anything you throw at it, I have a hard
time believing it wouldn't be able to decompose rawip easily.

johannes
[ message continues ]

Hi There


Thanks, I really appreciate the level of review (from you, Patrik and Thomas).

Many of the comments you guys have are solved by documenting why things were
done, others require work, others are remnants that I missed to clean up. 

It's Thanksgiving weekend here in the US, so I most probably will wait for
Monday to address all your guys concerns -- just sending this so you don't
think I don't care :) I do.

-- 
Inaky
--

[ message continues ]

Agree, never say never; but these are the reasons why I highly doubt
it'll ever happen:

 - WiMAX spectrum is heavily regulated

 - Operators won't allow it. They want tightly safe, certified and
   tested firmwares/devices that adhere to the standard so they can
   make sure devices don't mess up a single hertz as that means lost
   money, especially with a radio that can beam over miles.

 - Certification (required) of stacks make it almost

Why would I define them when I don't even know how they are going to
look like? It is not as simple as it looks.

The basics that aren't covered in current's kernel API are scan,
connect, disconnect. Disconnect is simple, but scan & connect? very
much impossible to tell what common ground is going to be until more
devices show up.

For scanning, some devices require to be told exactly where to scan in
(as in which combination of band, fft width and coloring of the
band). Some others don't. Then of course, the scan results might be
operators? Network Service Providers? Network Access Providers?  base
station IDs? how do you stitch'em together? You need information to
map from one to the other, and that is device specific depending on at
which level they work. How to stich that information together depends
on the network too (OMA-DM and provisining information help to compose
this). If it is done at the device/firmware level or at the host level
is device specific.

Connect has exactly the same levels of issues as scan: what do I
connect to? A base station? a NAP or an NSP?

So back to the original question: I have no information to define such

If it has to happen, it will happen eventually. If it is a stack or
not as of now and just a simple control interface, not that I really

As I said above, it is not so simple. They are not as generic as they

I agree -- and that's the whole reason why the "stack" is
there--because even if it doesn't look so hard, it's just a
pain. 

This way someone comes in with a need for a driver ...
[ message continues ]

Well, to be fair 3.5GHz is "lightly regulated" here in the US, you just
have to register your base station with the FCC and as long as nobody
else has done so in your area, you win.  The Intel parts don't support
3.5 GHz, but I'm sure somebody elses parts will in the future.

TowerStream has already deployed 3.5GHz fixed WiMAX gear here in Boston,
though they are doing fixed access/T1-replacement for businesses, not a
large consumer-focused mobile wimax network like XOHM/Clear.


--

[ message continues ]

But things like these are fairly easy to cover, just allow netlink
attributes to specify where to scan, and allow drivers to disregard
them, no harm caused. Maybe include a capability bit, like I'm adding to
nl80211 in my scanning patch (not included yet) that includes a

I have no idea about these things, obviously. But what's wrong with just
defining the scan operation with netlink attributes as you need them now
(say the scan returns NSPs) and then later when somebody needs to return
NAPs add a new attribute? Userspace will easily be able to figure out

Here's where I disagree, obviously, I think you should at least define a
subset of the imaginable interface, which is, in my opinion, _much_
better than defining no interface at all and hoping for the next guy to
figure it out, which is unlikely to happen when you haven't started with


Ok, thanks for the explanation.

johannes

--

[ message continues ]

The implementation details are not the problem, there I totally agree
with you. The problem is how to establish the cutline. What you are saying
is exactly how I envision it to happen and the direction I'd like it to
take, but I just don't want to do it until at least we have two vendors


No wait, I don't want guy #2 to define it--I want to work together to define
it, to make sure it works for him and for me without having to throw to



-- 
Inaky
--

[ message continues ]

But, but, you have to throw away all your 'behind-the-private-call'
things anyway, at that point.

I think my point here really is that you're defining an API that's
intentionally private because you don't want to define a public one even
though that should be extensible enough. And then we get to the stuck
with the private API because all the userland uses it, and the next guy
will invariably implement it that way too, simply because you did and it
works that way and is much easier than getting it right (he'll just say
that because his is somewhat similar to yours he wants to wait for the
third implementation... ;) )

johannes
[ message continues ]

That was a lot of feedback, thanks guys.

I think I covered most of your concerns, please let me know. I still have
left to work on:

- replacing the ifinfo stuff with looking at the controller

- moving some of the sysfs files to debugfs

- moving to use dynamic_printk()

First two ones I plan to tackle ASAP. The dynamic_printk() stuff might take
longer and I was wondering if you would be ok with changing that post-29 in
case I were about to miss the merge window (got a few very busy weeks
ahead of me).

Once I am done tackling those two ones I'll update the trees in kernel.org
and repost a new set of patches.

Thanks,

-- 
Inaky
--

[ message continues ]

Fine with me, I guess, I don't even know if the dynprintk is applicable
(though I'd rather see you make it work if it isn't than add yet another
huge debug macro file :) )

johannes

--

[ message continues ]

I switched over the Bluetooth stack to use dynamic_printk(). It is as
easy as just using pr_debug() or dev_dbg(). The rest already works
perfectly fine.

However it is either full debug or nothing. Not a fine grained stuff we
have in the iwlwifi drivers. However not sure if that is actually
needed. It confuses me more and having to unload the driver and reload
it makes me not using it a lot. The dynamic_printk() is really nice
since you can turn it on and off. And since it is on a per module basis
it was enough for Bluetooth. Not sure if that is applicable to
everything, but then it could be extended with debug levels, I guess.

Regards

Marcel


--

[ message continues ]