Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
directory name to mount debugfs filesystem for ftrace according to
./Documentation/tracers/ftrace.txt file.

And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
existed in kernel source like ftrace, DRM, Wireless, Documentation,
Network[sky2]files to mount debugfs filesystem.

debugfs means debug filesystem for debugging easy to use by greg kroah
hartman. "/sys/kernel/debug/" name is suitable as directory name
of debugfs filesystem.
- debugfs related reference: http://lwn.net/Articles/334546/

Fix inconsistency of directory name to mount debugfs filesystem.

* From Steven Rostedt
  - find_debugfs() and tracing_files() in this patch.
Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com>
Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
Reviewed-by  : James Smart <james.smart@emulex.com>
CC: Jiri Kosina <trivial@kernel.org>
CC: David Airlie <airlied@linux.ie>
CC: Peter Osterlund <petero2@telia.com>
CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
CC: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This change moves the table of "pokes" performed on the device at boot
time to the bus specific portion of the driver.

Different models of the i2400m device supported by this driver require
different poke tables, thus having a single table that works for all
is impossible. For that, the table is moved to the bus-specific
driver, who can decide which table to use based on the specifics of
the device and point the generic driver to it.
Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>

The code that sets up the i2400m (firmware load and general driver
setup after it) includes a couple of retry loops.

The SDIO device sometimes can get in more complicated corners than the
USB one (due to its interaction with other SDIO functions), that
require trying a few more times.

To solve that, without having a failing USB device taking longer to be
considered dead, allow the retry counts to be specified by the
bus-specific driver, which the general driver takes as a parameter.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The i2400m driver waits for the device to report being ready for
entering power save before asking it to do so. This module parameter
allows control of said operation; if disabled, the driver won't ask
the device to enter power save mode.

This is useful in setups where power saving is not so important or
when the overhead imposed by network reentry after power save is not
acceptable; by combining this with parameter 'idle_mode_disabled', the
driver will always maintain both the connection and the device in
active state.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

The WiMAX i2400m driver needs to generate a fake source MAC address to
fake an ethernet header (for destination, the card's MAC is
used). This is the source of the packet, which is the basestation it
came from. The basestation's mac address is not usable for this, as it
uses its own namespace and it is not always available.

Currently the fake source MAC address was being set to all zeros,
which was causing trouble with bridging.

Use random_ether_addr() to generate a proper one that creates no
trouble.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>

Allow the device to give the driver RX data with reorder information.

When that is done, the device will indicate the driver if a packet has
to be held in a (sorted) queue. It will also tell the driver when held
packets have to be released to the OS.

This is done to improve the WiMAX-protocol level retransmission
support when missing frames are detected.

The code docs provide details about the implementation.

In general, this just hooks into the RX path in rx.c; if a packet with
the reorder bit in the RX header is detected, the reorder information
in the header is extracted and one of the four main reorder operations
are executed. In one case (queue) no packet will be delivered to the
networking stack, just queued, whereas in the others (reset, update_ws
and queue_update_ws), queued packet might be delivered depending on
the window start for the specific queue.

The modifications to files other than rx.c are:

- control.c: during device initialization, enable reordering support
  if the rx_reorder_disabled module parameter is not enabled

- driver.c: expose a rx_reorder_disable module parameter and call
  i2400m_rx_setup/release() to initialize/shutdown RX reorder
  support.

- i2400m.h: introduce members in 'struct i2400m' needed for
  implementing reorder support.

- linux/i2400m.h: introduce TLVs, commands and constant definitions
  related to RX reorder

Last but not least, the rx reorder code includes an small circular log
where the last N reorder operations are recorded to be displayed in
case of inconsistency. Otherwise diagnosing issues would be almost
impossible.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Newer i2400m firmwares (>= v1.4) extend the data RX protocol so that
each packet has a 16 byte header. This header is mainly used to
implement host reordeing (which is addressed in later commits).

However, this header also allows us to overwrite it (once data has
been extracted) with an Ethernet header and deliver to the networking
stack without having to reallocate the skb (as it happened in fw <=
v1.3) to make room for it.

- control.c: indicate the device [dev_initialize()] that the driver
  wants to use the extended data RX protocol. Also involves adding the
  definition of the needed data types in include/linux/wimax/i2400m.h.

- rx.c: handle the new payload type for the extended RX data
  protocol. Prepares the skb for delivery to
  netdev.c:i2400m_net_erx().

- netdev.c: Introduce i2400m_net_erx() that adds the fake ethernet
  address to a prepared skb and delivers it to the networking
  stack.

- cleanup: in most instances in rx.c, the variable 'single' was
  renamed to 'single_last' for it better conveys its meaning.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For power saving reasons, WiMAX links can be put in idle mode while
connected after a certain time of the link not being used for tx or
rx. In this mode, the device pages the base-station regularly and when
data is ready to be transmitted, the link is revived.

This patch allows the user to control the time the device has to be
idle before it decides to go to idle mode from a sysfs
interace.

It also updates the initialization code to acknowledge the module
variable 'idle_mode_disabled' when the firmware is a newer version
(upcoming 1.4 vs 2.6.29's v1.3).

The method for setting the idle mode timeout in the older firmwares is
much more limited and can be only done at initialization time. Thus,
the sysfs file will return -ENOSYS on older ones.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Upcoming modifications will need to test for the running firmware
version before activating a feature or not. This is helpful to
implement backward compatibility with older firmware versions.

Modify i2400m_firmware_check() to encode in i2400m->fw_version the
major and minor version numbers of the firmware interface.

As well, move the call to be done as the very first operation once we
have communication with the device during probe() [in
__i2400m_dev_start()]. This is needed so any operation that is
executed afterwards can determine which fw version it is talking to.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In order to support backwards compatibility with older firmwares when
a driver is updated by a new kernel release, the i2400m bus drivers
can declare a list of firmware files they can work with (in general
these will be each a different version). The firmware loader will try
them in sequence until one loads.

Thus, if a user doesn't have the latest and greatest firmware that a
newly installed kernel would require, the driver would fall back to
the firmware from a previous release.

To support this, the i2400m->bus_fw_name is changed to be a NULL
terminated array firmware file names (and renamed to bus_fw_names) and
we add a new entry (i2400m->fw_name) that points to the name of the
firmware being currently used. All code that needs to print the
firmware file name uses i2400m->fw_name instead of the old
i2400m->bus_fw_name.

The code in i2400m_dev_bootstrap() that loads the firmware is changed
with an iterator over the firmware file name list that tries to load
each form user space, using the first one that succeeds in
request_firmware() (and thus stopping the iteration).

The USB and SDIO bus drivers are updated to take advantage of this and
reflect which firmwares they support.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a one liner change to have the driver use by default the v1.4
of the i2400m firmware instead of v1.3. The v1.4 version of the
firmware has been submitted to David Woodhouse for inclusion in the
linux-firmware tree and it is already available at
http://linuxwimax.org/Download.

The reason for this change is that the 1.3 release of the user space
software and firmware has a few issues that will make it difficult to
use with currently deployed commercial networks such as Xohm and
Clearwire.

As well, the new 1.4 release of the user space software (which matches
the 1.4 firmware) has intermitent issues with the 1.3 firmware.

The 1.4 release in http://linuxwimax.org/Download has been widely
deployed and tested with the codebase in 2.6.29-rc, the 1.4 firmware
and the 1.4 user space components.

We understand it is quite late in the rc process for such a change,
but would like to ask for the change to be taken into consideration.

Alternatively, a user could always force feed a 1.4 firmware into a
driver that doesn't have this modification by:

$ cd /lib/firmware
$ mv i2400m-fw-usb-1.3.sbcf i2400m-fw-usb-1.3.real.sbcf
$ ln -sf i2400m-fw-usb-1.4.sbc i2400m-fw-usb-1.3.sbcf
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Base versions handle constant folding now.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Acked-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The wimax/i2400m.h defines the structures and constants for the
host-device protocols:

 - boot / firmware upload protocol

 - general data transport protocol

 - control protocol

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

drivers/net/wimax/i2400m.h 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.

debug-levels.h adds the core driver's debug settings.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>