The SBCF firmware format has been extended to support extra headers
after the main payload. These extra headers are used to sign the
firmware code with more than one certificate. This eases up
distributing single code images that work in more than one SKU of the
device.
The changes to support this feature will be spread in a series of
commits. This one just adds the support to parse the extra headers and
store them in i2400m->fw_hdrs. Coming changes to the loader code will
use that to determine which header to upload to the device.
The i2400m_fw_check() function now iterates over all the headers and
for each, calls i2400m_fw_hdr_check(), which does some basic checks on
each header. It then stores the headers for the bootloader code to use.
The i2400m_dev_bootstrap() function has been modified to cleanup
i2400m->fw_hdrs when done.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Make sure the bootloading code checks that the format of the file is
understood (major version match). This also fixes a dumb typo in
extracting the major version field.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The i2400m based devices can get in a sort of a deadlock some times;
when they boot, they send a reboot "barker" (a magic number) and then
the driver has to echo that same barker to ack reception
(echo/ack). Then the device does a final ack by sending an ACK barker.
The first time this happens, we don't know ahead of time with barker
the device is going to send, as different device models and SKUs will
send different barker depending on the EEPROM programming.
If the device has sent the barker before the driver has been able to
read it, the driver looses, as it doesn't know which barker it has to
echo/ack back. With older devices, we tried a couple of combinations
and that always worked; but now, with adding support for more, in
which we have an unlimited number of new barkers, that is not an
option.
So we rework said case so that when the device gets stuck, we just
cycle through all the known types until one forces the device to send
an ack. Otherwise, the driver gives up and aborts.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The i2400m firmware loader is given a list of firmware files to try to
load by the probe() function (which can be different based on the
device's model / generation).
Current code didn't attempt to load, check and try to boot with each
file, but just to try to load if off disk. This is limiting in some
cases, where we might want to try to load a firmware and if it fails
to load onto the device, just fall back to another one.
This changes the behaviour so all files are tried for being loaded
from disk, checked and uploaded to the device until one suceeds in
bringing the device up.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This modifies the bootrom initialization code of the i2400m driver so
it can more easily support upcoming hardware.
Currently, the code detects two types of barkers (magic numbers) sent
by the device to indicate the types of firmware it would take (signed
vs non-signed).
This schema is extended so that multiple reboot barkers are
recognized; upcoming hw will expose more types barkers which will have
to match a header in the firmware image before we can load it.
For that, a barker database is introduced; the first time the device
sends a barker, it is matched in the database. That gives the driver
the information needed to decide how to upload the firmware and which
types of firmware to use. The database can be populated from module
parameters.
The execution flow is not altered; a new function
(i2400m_is_boot_barker) is introduced to determine in the RX path if
the device has sent a boot barker. This function is becoming heavier,
so it is put away from the hot reception path [this is why there is
some reorganization in sdio-rx.c:i2400ms_rx and
usb-notifc.c:i2400mu_notification_grok()].
The documentation on the process has also been updated.
All these modifications are heavily based on previous work by Dirk
Brandewie <dirk.brandewie@intel.com>.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The i2400m based devices can boot two main types of firmware images:
signed and non-signed. Signed images have signature data included that
must match that of a certificate stored in the device.
Currently the code is making the decission on what type of firmware
load (signed vs non-signed) is going to be loaded based on a hardcoded
decission in __i2400m_ack_verify(), based on the barker the device
sent upon boot.
This is not flexible enough as future hardware will emit more barkers;
thus the bit has to be set in a place where there is better knowledge
of what is going on. This will be done in follow-up commits -- however
this patch paves the way for it.
So the querying of the mode is packed into i2400m_boot_is_signed();
the main changes are just using i2400m_boot_is_signed() to determine
the method to follow and setting i2400m->sboot in
i2400m_is_boot_barker(). The modifications in i2400m_dnload_init() and
i2400m_dnload_finalize() are just reorganizing the order of the if
blocks and thus look larger than they really are.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Add "debug" module options to all the wimax modules (including
drivers) so that the debug levels can be set upon kernel boot or
module load time.
This is needed as currently there was a limitation where the debug
levels could only be set when a device was succesfully
enumerated. This made it difficult to debug issues that made a device
not probe properly.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The i2400m driver was missing the definition for the sysfs debug
level, which is declared in debug-levels.h.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In the Intel Wireless Multicomm 3200, the initialization is
orchestrated by a component called Top. This component also monitors
how many times a function is reset (via sdio_disable) to detect
possible issues and will reset the whole multifunction device if any
function triggers a maximum reset level.
During WiMAX's probe, the driver needs to wait for Top to come up
before it can enable the WiMAX function. If it cannot, it will return
-ENODEV and the Top driver will rescan the SDIO bus once done
loading.
Currently, the WiMAX SDIO probe routine was trying a few times before
returning -ENODEV, and this was triggering Top's too-many-resets
detector. This is, in any case, unnecessary because the Top driver will
force the bus rescan when the functions can be probed successfully.
Added then a maxtries argument to i2400ms_enable_func() and set it to
1 when calling from probe. We want to reuse this function instead of
flat calling out sdio_enable_func() to take advantage of hardware
quirk workarounds.
Reported-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In kernel 2.6.31, the firmware requested to ram could be marked
with read only attribute, and we can't write any thing directly
to the memory when setting up the last JUMP brh cmd.
Changed so that the scratch buffer is used.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Because some underlying bus APIs (like USB) don't like data buffers in
the stack or vmalloced areas, the i2400m driver provides a scratch
buffer (i2400m->bm_cmd_buf) for said low-level drivers to copy command
data to before passing it to said API. This is only used during boot
mode.
However, at some the code was copying the buffer even when the command
was already specified in said buffer. This is ok, but it needs to be
more careful. As thus, change so that:
(a) the copy happens only if command buffer is not the scratch buffer
(b) use memmove() in case there is overlapping
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In order to avoid issues during high-load traffic, the interrupt
status register has to be cleared ONLY after the RX size is read.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Newer generations of the i2400m USB WiMAX device use a different
endpoint map; in order to make it easy to support it, we make the
endpoint-to-function mapeable instead of static.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When trying to enable the iwmc3200 WiMAX SDIO function, we loop
waiting for the top controller to be up and running (at which point we
can succesfully enable the function). Between each try we wait for
I2400MS_INIT_SLEEP_INTERVAL ms.
Integration tests have found the current value of 10ms to be too
short; it was upped to 100ms to give more time to the top controller
to be ready.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In the iwmc3200, disabling the WiMAX SDIO function when enable fails
would possibly result in a device reset triggered by the iwmc3200's
top controller since it monitors the bus reset activities from each
SDIO function. In any case, the disable makes no sense; if the enable
fails, it should not be disabled.
Thus we remove the unecessary sdio_disable_func() in
i2400ms_enable_function().
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The default SDIO IOE wait timeout returned from iwmc3200-wimax's CCCR
is not efficient. This inefficiency will actually cause problems on
Moorestown platforms (system hang).
This is a sillicon bug that requires a software patch to by
overwritting func->enable_timeout. The new value I2400MS_IOR_TIMEOUT
is recommended and verified from the system integration results.
Future sillicon releases will have this default value corrected in the
future.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In i2400m-based devices, the driver's bootloader will retry to load
the firmware when things go wrong. The driver currently has a constant
(I2400M_BOOT_RETRIES) which governs the max number of tries.
However, different SKUs of the same hardware may admit or require
different numbers of retries due to it's particulars, so it is made a
BUS specific parameter and different values are assigned for 5x50
devices versus the 3200 ones.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The change to the SDIO boot mode RX chain could try to use the cmd and
ack buffers befor they were allocated. USB does not have the problem
but both were changed for consistency's sake.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Add minimal ethtool support for carrier detection.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Ensure that index `status' remains within ms_to_errno[]
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400ms_bus_bm_wait_for_ack() causes a race condition. It happens
because this function clears i2400ms->bm_ack_size before waiting for
an interrupt, which is set by the interrupt service routine i2400ms_rx()
to indicate reception and size of received data; thus, if the interrupt
came right before the clearing/waiting, it is lost.
The fix is clear the bm_ack_size to -EINPROGRESS before we are enabling
the RX interrupt configuration in i2400ms_rx_setup(). Then everytime
when the interrupt service routine i2400ms_rx() is invoked during bootmode,
bm_ack_size is updated with the actual rx_size and it is cleared to
-EINPROGRESS again after the RX data is handled.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This patch removes an unneeded power management primitive.
Power management is automatically enabled as probe ends.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The Ethernet framing is used for a lot of devices these days. Most
prominent are WiFi and WiMAX based devices. However for userspace
application it is important to classify these devices correctly and
not only see them as Ethernet devices. The daemons like HAL, DeviceKit
or even NetworkManager with udev support tries to do the classification
in userspace with a lot trickery and extra system calls. This is not
good and actually reaches its limitations. Especially since the kernel
does know the type of the Ethernet device it is pretty stupid.
To solve this problem the underlying device type needs to be set and
then the value will be exported as DEVTYPE via uevents and available
within udev.
# cat /sys/class/net/wlan0/uevent
DEVTYPE=wlan
INTERFACE=wlan0
IFINDEX=5
This is similar to subsystems like USB and SCSI that distinguish
between hosts, devices, disks, partitions etc.
The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
device type. All device types are free form, but for convenience the
same strings as used with RFKILL are choosen.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mostly just simple conversions:
* ray_cs had bogus return of NET_TX_LOCKED but driver
was not using NETIF_F_LLTX
* hostap and ipw2x00 had some code that returned value
from a called function that also had to change to return netdev_tx_t
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1. add intel's sdio vendor id to sdio_ids.h
2. move iwmc3200 sdio devices' ids to sdio_ids.h
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: GeunSik 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: Greg Kroah-Hartman <gregkh@suse.de>
SH4's BUG() seems to confuse the compiler as it is considered to
return; thus, some functions would trigger usage of uninitialized
variables or non-void functions returning void.
Work around by initializing/returning.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When the i2400m device resets, the driver code will force some
functions to return a -ERESTARTSYS error code, which can is used by
the caller to determine which recovery actions to take.
However, in certain situations the only thing that can be done is to
bubble up said error code to user space, for handling.
However, -ERESTARSYS was a poor choice, as it is supposed to be used
by the kernel only.
As such, replace -ERESTARTSYS with -EL3RST; as well, in
i2400m_msg_to_dev(), when the device is in boot mode (following a
recent reset), return -EL3RST instead of -ENODEV (meaning the device
is in bootrom mode after a reset, not that the device was
disconnected, and thus, normal commands cannot be executed).
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
When a device reset happens during firmware load [in
i2400m_dev_bootstrap()], __i2400m_dev_start() will retry a number of
times. However, for those retries to be able to accomplish anything,
the device's bootrom has to be reinitialized.
Thus, on the retry path, pass the I2400M_MAC_REINIT to the firmware
load code.
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
The current SDIO code was working in polling mode for boot-mode
(firmware load) mode. This was causing issues on some hardware.
Moved all the RX code to use a unified IRQ handler that based on the
type of data the device is sending can discriminate and decide which
is the right destination.
As well, all the reads from the device are made to be at least the
block size (256); the driver will ignore the rest when not needed.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When i2400m_bootrom_init() fails to put the device into a state of
being ready to accept firmware, the driver was currently trying to
reset it if it failed to do so. This is not too useful; as part of
trying to put the device in the right state a few resets have already
been tried.
At this point, things are probably fried out and an extra reset might
do more harm than good (for example causing reseting of other
functions in the same composite device).
So it is left up to the callers to determine the error path to take
(at the end this is always i2400m_setup(), who depending on how many
retries are left, might give up on the device).
From a fix by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
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: Dirk 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: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When a device reboot happens when we are under probe, with init_mutex
taken, make sure we can recover. Have dev_reset_handle set boot mode
and i2400m_msg_to_dev() will see it and fail gracefully instead of
timing out.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When the TX FIFO filled up and i2400m_tx_new() failed to allocate a
new TX message header, a missing check for said condition was causing a
kernel oops when trying to dereference a NULL i2400m->tx_msg pointer.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_dev_shutdown() tried to reset the device to put it in a known
state before shutting down.
But that turned out to be pointless. We reach this case in two paths:
1 - when the device resets, to clean up state
2 - when the driver is unloaded, for the same
however, in both cases it is pointless; in (1) the device is already
reset, why do it again? in (2) we can't -- the USB stack, for example,
doesn't allow communicating with the device when the driver is being
unbound and if the device is disconnected, the device is gone already.
So just remove it. Leave the function as a placeholder for future
cleanups that will be done from data allocated by the driver during
device operation.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
i2400m_tx_skip_tail() needs to handle the special case of being called
when the tail room that is left over in the FIFO is zero.
This happens when a TX message header was opened at the very end of
the FIFO (without payloads). The i2400m_tx_close() code already marked
said TX message (header) to be skipped and this function should be
doing nothing.
It is called anyway because it is part of a common "corner case" path
handling which takes care of more cases than only this one.
The tail room computation was also improved to take care of the case
when tx_in is at the end of the buffer boundary; tail_room has to be
modded (%) to the buffer size. To do that in a single well-documented
place, __i2400m_tx_tail_room() is introduced and used.
Treat i2400m->tx_in == 0 as a corner case and handle it accordingly.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
In some situations, when a new TX message header is started, there
might be no space for data payloads. In this case the message is left
with zero payloads and the i2400m_tx_close() function has just to mark
it as "to skip". If it tries to go ahead it will overwrite things
because there is no space to add padding as defined by the
bus-specific layer. This can cause buffer overruns and in some stress
cases, panics.
Found and diagnosed by Cindy H. Kao.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
The constant is being use as an alignment factor, not as a padding
factor; made reading/reviewing the code quite confusing.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
This reset type causes the WiMAX function to be disabled and
re-enabled, which will force the WiMAX device to reset and enter boot
mode.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
By mistake, the BUG_ON() check was left in there and it will fail when
called if i2400m->work_queue is still not setup.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
RX support is the only user of the work-queue, to process
reports/notifications from the device. Thus, it needs the work queue
to be initialized first.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reported and fixed by Cindy H Kao.
When the device is stopped __i2400m_dev_stop() stops the network
queue.
However, when this is done in the middle of heavy network operation,
when the bus-specific subdriver is still wrapping up and it reports a
sent TX transaction with _tx_msg_sent() right after the device was
stopped, the queue was being started again, which was causing a stream
of oopsen and finally a panic.
In any case, said call has no place there. It's a left over from an
early implementation that was discarded later on.
Signed-off-by: Inaky 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: Inaky Perez-Gonzalez <inaky@linux.intel.com>
When the i2400m is connected to a network, the host interface (USB)
cannot be suspended. For that to happen, the device has to have
negotiated with the basestation to put the link on IDLE state.
If the host tries to put the device in standby while it is connected
but not idle, the device resets, as the driver should not do that.
To avoid triggering that, when the USB susbsytem requires the driver
to autosuspend the device, the driver checks if the device is not yet
idle. If it is not, the request is requested (will be retried again
later on after the autosuspend timeout). At some point the device will
enter idle and the request will succeed (unless of course, there is
network traffic, but at that point, there is no idle neither in the
link or the host interface).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
