summaryrefslogtreecommitdiffstats
path: root/drivers/net
Commit message (Collapse)AuthorAgeFilesLines
* 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/i2400m: on firmware upload, select BCF header that matches device's ↵Inaky Perez-Gonzalez2009-10-191-19/+92
| | | | | | | | | | | | | | | | | | | | | | | request Devices based on the i2400m emit a "barker" (32 bit unsigned) when they boot. This barker is used to select, in the firmware file image, which header should be used to process the rest of the file. This commit implements said support, completing the series started by previous commits. We modify the i2400m_fw_dnload() firmware loading path by adding a call to i2400m_bcf_hdr_find() [new function], in which the right BCF header [as listed in i2400m->fw_hdrs by i2400m_fw_check()] is located. Then this header is fed to i2400m_dnload_init() and i2400m_dnload_finalize(). The changes to i2400m_dnload_finalize() are smaller than they look; they add the bcf_hdr argument and use that instead of bcf. Likewise in i2400m_dnload_init(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: support extended firmware formatInaky Perez-Gonzalez2009-10-192-59/+134
| | | | | | | | | | | | | | | | | | | | | | 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>
* wimax/i2400m: verify firmware format version is knownInaky Perez-Gonzalez2009-10-191-1/+7
| | | | | | | | 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>
* wimax/i2400m: fix reboot echo/ack barker deadlockInaky Perez-Gonzalez2009-10-191-12/+51
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* wimax/i2400m: retry loading firmware files in sequenceInaky Perez-Gonzalez2009-10-191-18/+17
| | | | | | | | | | | | | | | | | 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>
* wimax/i2400m: rework bootrom initialization to be more flexibleInaky Perez-Gonzalez2009-10-196-85/+355
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wimax/i2400m: decide properly if using signed vs non-signed firmware loadingInaky Perez-Gonzalez2009-10-191-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wimax/i2400m: workaround not-so-working %zd printf formatInaky Perez-Gonzalez2009-10-191-2/+2
| | | | | | | The kernel's %zd modifier does not really work. Use %ld (has to cast ssize_t to long). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax: allow specifying debug levels as command line optionInaky Perez-Gonzalez2009-10-193-0/+29
| | | | | | | | | | | | | 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: add missing debug submodule definitionInaky Perez-Gonzalez2009-10-191-0/+1
| | | | | | | 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>
* 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/i2400m: don't write to memory allocated by request_firmware()Cindy H Kao2009-10-191-0/+4
| | | | | | | | | | | 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>
* wimax/i2400m: be smarter about copying command buffer to bm_cmd_bufInaky Perez-Gonzalez2009-10-193-3/+4
| | | | | | | | | | | | | | | | | | 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>
* wimax/i2400m/sdio: clear the INTR status bit after reading sizeCindy H Kao2009-10-191-1/+5
| | | | | | | | 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>
* wimax/i2400m: USB driver uses a configurable endpoint mapDirk Brandewie2009-10-196-17/+29
| | | | | | | | | 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>
* wimax/iwmc3200: increase wait time before enable retryCindy H Kao2009-10-191-1/+1
| | | | | | | | | | | | | | 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>
* 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-192-0/+10
| | | | | | | | | | | | | | | | 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-196-6/+5
| | | | | | | | | | | | | | | 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-194-14/+64
| | | | | | | | | | | 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>
* i2400m: minimal ethtool supportDan Williams2009-10-191-0/+18
| | | | | | | 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>
* wimax: misplaced parenthesisRoel Kluin2009-10-191-1/+1
| | | | | | | Fix misplaced parenthesis Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* i2400m: keep index within ms_to_errno[]Roel Kluin2009-10-191-1/+1
| | | | | | | 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>
* wimax/i2400m: fix the bootmode RX deadlock in SDIO driverCindy H Kao2009-10-192-4/+11
| | | | | | | | | | | | | | | | | 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>
* wimax/i2400m/usb: remove unnecessary power management primitive in i2400mOliver Neukum2009-10-191-1/+0
| | | | | | | | 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>
* cosa: Kill off the use of the old ioctl pathAlan Cox2009-10-181-7/+13
| | | | | Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* inet: rename some inet_sock fieldsEric Dumazet2009-10-181-9/+13
| | | | | | | | | | | | | | | | In order to have better cache layouts of struct sock (separate zones for rx/tx paths), we need this preliminary patch. Goal is to transfert fields used at lookup time in the first read-mostly cache line (inside struct sock_common) and move sk_refcnt to a separate cache line (only written by rx path) This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr, sport and id fields. This allows a future patch to define these fields as macros, like sk_refcnt, without name clashes. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* cxgb3: No need to wake queue in xmit handlerKrishna Kumar2009-10-171-1/+1
| | | | | | | | | | | The xmit handler doesn't need to wake the queue after stopping it temporarily (some other drivers are doing the same). Patch on net-next-2.6, multiple netperf sessions tested. Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Acked-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen; update version to 4.0.62Dhananjay Phadke2009-10-171-2/+2
| | | | | Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: sysfs control for auto firmware recoveryNarender Kumar2009-10-172-1/+52
| | | | | | | | | | | | | Firmware hang detection and recovery (reset) need to be disabled for diagnostic tools, which can run some disruptive tests. This adds a driver level control to turn off this feature by diag tools. Signed-off-by: Narender Kumar <narender.kumar@qlogic.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: fix error codes in for tools accessDhananjay Phadke2009-10-172-24/+31
| | | | | | | | Use -EIO or -EINVAL as error codes, these can get passed up to applications (tools). Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: onchip memory access changeAmit Kumar Salecha2009-10-173-9/+17
| | | | | | | | | | Add support for different windowing scheme for on chip memory in future chip revisions. This is required by diagnostic tools. Signed-off-by: Amit Kumar Salecha <amit@netxen.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: reset sequence changesAmit Kumar Salecha2009-10-173-29/+16
| | | | | | | | | | | Future revisions need different chip reset sequence and firmware initialization. Also clean up some never used debug code. Signed-off-by: Amit Kumar Salecha <amit@netxen.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: 128 memory controller supportAmit Kumar Salecha2009-10-172-10/+53
| | | | | | | | | | | Future revisions of the chip have 128 bit memory transactions. Require drivers to implement rmw in case of sub-128 bit accesses by driver. This is mostly used by diagnostic tools. Signed-off-by: Amit Kumar Salecha <amit@netxen.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* netxen: defines for next revisionAmit Kumar Salecha2009-10-171-0/+2
| | | | | | Signed-off-by: Amit Kumar Salecha <amit@netxen.com> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* be2net: Add support for next generation of BladeEngine device.Ajit Khaparde2009-10-161-2/+13
| | | | | | | Add new PCI ids to support next generation of BladeEngine device. Signed-off-by: Ajit Khaparde <ajitk@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Update to version 1.52.1-1Eilon Greenstein2009-10-151-2/+2
| | | | | Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Report the maximal available BW as link speedEilon Greenstein2009-10-151-1/+13
| | | | | | | | The device is limited to the maximal BW allocation, so it should be displayed as the link speed to notify the user. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Do not call load/unload functionality from DCCEilon Greenstein2009-10-151-14/+5
| | | | | | | | | There is really no need to clear the MAC or the FW filtering rules - it was added for completion, but caused race conditions with load/unload. Removing this redundant code Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Adding FW mailbox mutexEilon Greenstein2009-10-152-2/+8
| | | | | | | DCC commands are not protected with the RTNL lock, so a mutex should be added Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Changing the Disabled state to a flagEilon Greenstein2009-10-152-16/+20
| | | | | | | | | | When working with DCC, a function can be disabled or enabled (virtual link down or up). Using the function state introduced some race conditions with the load/unload flow. Using a separate flag to indicate that the function is disabled. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bnx2x: Allowing 0 as initial fairness valueEilon Greenstein2009-10-152-30/+30
| | | | | | | | | | | | | Value of zero was used to disable the fairness mechanism. Though the code (driver and FW) allowed changing the value at run time, it did not allow to do that if the mechanism was disabled to begin with. Fixed the FW to allow turning on and off the mechanism at run time. Fixed the code to read the value from the chip at the right sequence. Without this fix, if the initial value was set to zero, traffic could not run on the interface. Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* hamradio: Fix bit test correctly.Thomas Sailer2009-10-141-4/+3
| | | | | Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Remove BKL from tunThomas Gleixner2009-10-141-4/+1
| | | | | | | | | | | | | The lock_kernel/unlock_kernel() in cycle_kernel_lock() which is called in tun_chr_open() is not serializing against anything and safe to remove. tun_chr_fasync() is serialized by get/put_tun() and fasync_helper() has no dependency on BKL. The modification of tun->flags is racy with and without the BKL so removing it does not make it worse. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2009-10-1324-103/+5209
|\ | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
| * TI DaVinci EMAC: Clear statistics register properly.Sriram2009-10-131-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mechanism to clear the statistics register is dependent on the status of GMIIEN bit in MAC control register. If the GMIIEN bit is set, the stats registers are write to decrement. If the GMIIEN bit is cleared, the stats registers are plain read/write registers. The stats register clearing operation must take into account the current state of GMIIEN as it can be cleared when the interface is brought down. With existing implementation logic, querying for interface stats when the interface is down, can corrupt the statistics counters. This patch examines the GMIIEN bit status in MAC_CONTROL register before choosing an appropriate mask for clearing stats registers. Signed-off-by: Sriramakrishnan <srk@ti.com> Acked-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * r8169: partial support and phy init for the 8168dfrançois romieu2009-10-131-55/+932
| | | | | | | | | | | | | | | | | | Extracted from Realtek's 8.012.00 r8168 driver. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Simon Farnsworth <simon.farnsworth@onelan.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'master' of ↵David S. Miller2009-10-133-2/+5
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
OpenPOWER on IntegriCloud