summaryrefslogtreecommitdiffstats
path: root/drivers/net/wimax/i2400m/sdio.c
Commit message (Collapse)AuthorAgeFilesLines
* i2400m: remove SDIO device supportJohn W. Linville2012-07-111-602/+0
| | | | | | | | | | SDIO support in this driver was intended to support the iwmc3200 device. This hardware never became available to normal humans. Leaving this driver imposes unwelcome maintenance costs for no clear benefit. Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
* drivers/net: Add module.h to drivers who were implicitly using itPaul Gortmaker2011-10-311-0/+1
| | | | | | | | The device.h header was including module.h, making it present for most of these drivers. But we want to clean that up. Call out the include of module.h in the modular network drivers. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* i2400m: drop i2400m_schedule_work()Tejun Heo2010-12-121-1/+0
| | | | | | | | | | | | | | | | | | i2400m implements dynamic work allocation and queueing mechanism in i2400_schedule_work(); however, this is only used for reset and recovery which can be served equally well with preallocated per device works. Replace i2400m_schedule_work() with two work structs in struct i2400m. These works are explicitly canceled when the device is released making calls to flush_scheduled_work(), which is being deprecated, unnecessary. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: linux-wimax@intel.com Cc: netdev@vger.kernel.org
* wimax/i2400m: SDIO specific TX queue's minimum buffer room for new messagePrasanna S. Panchamukhi2010-05-111-0/+7
| | | | | | | | This patch specifies the TX queue's minimum buffer room required to accommodate one smallest SDIO payload. Please refer the documentation in the code. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
* include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* tree-wide: Assorted spelling fixesDaniel Mack2010-02-091-2/+2
| | | | | | | | | | | In particular, several occurances of funny versions of 'success', 'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address', 'beginning', 'desirable', 'separate' and 'necessary' are fixed. Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Joe Perches <joe@perches.com> Cc: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* wimax/i2400m: fix inverted value in i2400ms_bus_setup()Inaky Perez-Gonzalez2009-11-031-2/+2
| | | | | | | | Fix inverted setting of 'retries'; when we are in the probe() path, we should retry to enable the function only once; otherwise until it times out. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: fix SDIO debugfs dentry nameInaky Perez-Gonzalez2009-11-031-1/+1
| | | | | | | The SDIO specific debugfs dentry was being misnamed "i2400m-usb" instead of "i2400m-sdio". Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: don't retry SDIO enable in probe() pathsInaky Perez-Gonzalez2009-11-031-1/+12
| | | | | | | | | | | | | | The iwmc3200 has a quirk where retrying SDIO enable during the probe() path causes bad interactions with the TOP function controller that causes a reset storm. The workaround is simply not to retry an SDIO enable in said path (and still do in the reset / reinitialization paths). The driver does so by checking i2400ms->debugfs_dentry to see if it has been initialized; if not, it is in the probe() path. Document said fact in i2400ms->debugfs_entry. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: correctly identify all iwmc3200-based SKUsInaky Perez-Gonzalez2009-11-031-3/+13
| | | | | | | | | | Different paths of the i2400m SDIO driver need to take care of a few SKU-specific quirks. For the ones that are common to to all the iwmc3200 based devices, introduce i2400ms->iwmc3200 [set in i2400ms_probe()], so it doesn't have to check against the list of iwmc3200 SKU IDs on each quirk site. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: introduce i2400m_reset(), stopping TX and carrierInaky Perez-Gonzalez2009-11-031-8/+1
| | | | | | | | | | | | | | | | | | Currently the i2400m driver was resetting by just calling i2400m->bus_reset(). However, this was missing stopping the TX queue and downing the carrier. This was causing, for the corner case of the driver reseting a device that refuses to go out of idle mode, that a few packets would be queued and more than one reset would go through, making the recovery a wee bit messy. To avoid introducing the same cleanup in all the bus-specific driver, introduced a i2400m_reset() function that takes care of house cleaning and then calling the bus-level reset implementation. The bulk of the changes in all files are just to rename the call from i2400m->bus_reset() to i2400m_reset(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: SDIO: fix oops on reset when TXing on uninitialized dataInaky Perez-Gonzalez2009-10-191-34/+9
| | | | | | | | | | | | | | | | Currently the SDIO part of the TX resources were initialized/released with bus_dev_{start,stop}. The generic code's TX subsystem is destroyed afterwards, so there is a window from the bus-TX destruction to the generic-TX destruction where the generic-TX code might call into bus-TX to do transactions. The SDIO code cannot really cope with this (whereas in USB, how it is laid out, it correctly ignores it). In any case, it made no sense for the SDIO TX code to be in i2400m->bus_dev_start/stop(), so moved to i2400m->bus_setup/release(), which also takes care of the oops. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: do bootmode buffer management in i2400m_setup/release()Inaky Perez-Gonzalez2009-10-191-14/+0
| | | | | | | | | | | | | | | | After the introduction of i2400m->bus_setup/release, there is no more race condition where the bootmode buffers are needed before i2400m_setup() is called. Before, the SDIO driver would setup RX before calling i2400m_setup() and thus need those buffers; now RX setup is done in i2400m->bus_setup(), which is called by i2400m_setup(). Thus, all the bootmode buffer management can now be done completely inside i2400m_setup()/i2400m_release(), removing complexity from the bus-specific drivers. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: introduce i2400m->bus_setup/releaseInaky Perez-Gonzalez2009-10-191-36/+64
| | | | | | | | | | | | | | | | | | | The SDIO subdriver of the i2400m requires certain steps to be done before we do any acces to the device, even for doing firmware upload. This lead to a few ugly hacks, which basically involve doing those steps in probe() before calling i2400m_setup() and undoing them in disconnect() after claling i2400m_release(); but then, much of those steps have to be repeated when resetting the device, suspending, etc (in upcoming pre/post reset support). Thus, a new pair of optional, bus-specific calls i2400m->bus_{setup/release} are introduced. These are used to setup basic infrastructure needed to load firmware onto the device. This commit also updates the SDIO subdriver to use said calls. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/iwmc3200: add new sdio device ID to support iwmc3200 2.5GHz skuCindy H Kao2009-10-191-0/+2
| | | | | | | | | | Different sdio device IDs are designated to support different intel wimax silicon sku. The new macro SDIO_DEVICE_ID_IWMC3200_WIMAX_2G5(0x1407) is added to support iwmc3200 2.5GHz sku. The existing SDIO_DEVICE_ID_IWMC3200_WIMAX(0x1402) is for iwmc3200 general sku. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax: allow specifying debug levels as command line optionInaky Perez-Gonzalez2009-10-191-0/+10
| | | | | | | | | | | | | 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>
* wimax/i2400m: during probe, call sdio_disable at most onceInaky Perez-Gonzalez2009-10-191-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wimax/iwmc3200: don't disable the SDIO function if enable failsCindy H Kao2009-10-191-1/+0
| | | | | | | | | | | | | | 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>
* wimax/iwmc3200: overwrite SDIO IOR timeout value to avoid platform hangCindy H Kao2009-10-191-0/+8
| | | | | | | | | | | | | | | | 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>
* wimax/i2400m: Make boot retries a BUS-specific parameterDirk Brandewie2009-10-191-1/+1
| | | | | | | | | | | | | | | 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>
* wimax/i2400m: Ensure boot mode cmd and ack buffers are alloc'd before first ↵Dirk Brandewie2009-10-191-0/+14
| | | | | | | | | | | message 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>
* wimax/i2400m: Update comments to talk about SDIO reset and not USB.Dirk Brandewie2009-10-191-7/+6
| | | | | | | Fixing comments from original cut and paste error Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* net: Add DEVTYPE support for Ethernet based devicesMarcel Holtmann2009-09-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* imwc3200: move iwmc3200 SDIO ids to sdio_ids.hTomas Winkler2009-07-261-7/+5
| | | | | | | | 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>
* wimax/i2400m/sdio: Move all the RX code to a unified, IRQ based receive routineInaky Perez-Gonzalez2009-06-111-7/+11
| | | | | | | | | | | | | | | 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>
* wimax/i2400m/sdio: Add device specific poke table.Dirk Brandewie2009-06-111-0/+9
| | | | | | Add a poke table for the SDIO device (as it is different than USB). Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
* wimax/i2400m: Allow bus-specific driver to specify retry countInaky Perez-Gonzalez2009-06-111-0/+3
| | | | | | | | | | | | | | | 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>
* wimax/i2400m/sdio: Implement I2400M_RT_BUS reset typeDirk Brandewie2009-06-111-3/+17
| | | | | | | | | 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>
* wimax/i2400m: sdio: set the block size before enabling the functionInaky Perez-Gonzalez2009-05-281-9/+9
| | | | | | | | | From a fix by Cindy H Kao: Block size has to be set before sending IOE enable because the firmware reads the block size register before it reads IOE register. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: add the ability to fallback to other firmware files if the ↵Inaky Perez-Gonzalez2009-03-021-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default is not there 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: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax: replace uses of __constant_{endian}Harvey Harrison2009-02-011-8/+8
| | | | | | | | Base versions handle constant folding now. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i2400m/SDIO: probe/disconnect, dev init/shutdown and reset backendsInaky Perez-Gonzalez2009-01-071-0/+511
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> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud