aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'master' of ↵David S. Miller2010-05-17
|\ | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: include/linux/if_link.h
| * rtnetlink: make SR-IOV VF interface symmetricChris Wright2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now we have a set of nested attributes: IFLA_VFINFO_LIST (NESTED) IFLA_VF_INFO (NESTED) IFLA_VF_MAC IFLA_VF_VLAN IFLA_VF_TX_RATE This allows a single set to operate on multiple attributes if desired. Among other things, it means a dump can be replayed to set state. The current interface has yet to be released, so this seems like something to consider for 2.6.34. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * sctp: delete active ICMP proto unreachable timer when free transportWei Yongjun2010-05-16
| | | | | | | | | | | | | | | | | | | | transport may be free before ICMP proto unreachable timer expire, so we should delete active ICMP proto unreachable timer when transport is going away. Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * tcp: fix MD5 (RFC2385) supportEric Dumazet2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TCP MD5 support uses percpu data for temporary storage. It currently disables preemption so that same storage cannot be reclaimed by another thread on same cpu. We also have to make sure a softirq handler wont try to use also same context. Various bug reports demonstrated corruptions. Fix is to disable preemption and BH. Reported-by: Bhaskar Dutta <bhaskie@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'net-2.6' of ↵David S. Miller2010-05-14
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
| | * vhost: fix barrier pairingMichael S. Tsirkin2010-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to memory-barriers.txt, an smp memory barrier in guest should always be paired with an smp memory barrier in host, and I quote "a lack of appropriate pairing is almost certainly an error". In case of vhost, failure to flush out used index update before looking at the interrupt disable flag could result in missed interrupts, resulting in networking hang under stress. This might happen when flags read bypasses used index write. So we see interrupts disabled and do not interrupt, at the same time guest writes flags value to enable interrupt, reads an old used index value, thinks that used ring is empty and waits for interrupt. Note: the barrier we pair with here is in drivers/virtio/virtio_ring.c, function vring_enable_cb. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Juan Quintela <quintela@redhat.com>
* | | qeth: synchronize configuration interfaceFrank Blaschka2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | Synchronize access to the drivers configuration interface. Also do not allow configuration changes during online/offline transition. Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | qeth: new message if OLM limit is reachedUrsula Braun2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | z/OS may activate Optimized Latency Mode (OLM) for a connection through an OSA Express3 adapter, which reduces the number of allowed concurrent connections, if adapter is used in shared mode. Create a meaningful message, if activation of an OSA-connection fails due to an active OLM-connection on the shared OSA-adapter. Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | qeth: exploit HW TX checksummingFrank Blaschka2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OSA supports HW TX checksumming in layer 3 mode. Enable this feature and remove software fallback used for TSO. Cleanup checksum bits to indicate OSA can do checksumming only for IPv4 TCP and UDP. Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: congestion notifications are not dropped packetsEric Dumazet2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vlan/macvlan start_xmit() can inform caller of congestion with NET_XMIT_CN return value. This doesnt mean packet was dropped. Increment normal stat counters instead of tx_dropped. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: Introduce sk_route_nocapsEric Dumazet2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TCP-MD5 sessions have intermittent failures, when route cache is invalidated. ip_queue_xmit() has to find a new route, calls sk_setup_caps(sk, &rt->u.dst), destroying the sk->sk_route_caps &= ~NETIF_F_GSO_MASK that MD5 desperately try to make all over its way (from tcp_transmit_skb() for example) So we send few bad packets, and everything is fine when tcp_transmit_skb() is called again for this socket. Since ip_queue_xmit() is at a lower level than TCP-MD5, I chose to use a socket field, sk_route_nocaps, containing bits to mask on sk_route_caps. Reported-by: Bhaskar Dutta <bhaskie@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: Consistent skb timestampingEric Dumazet2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With RPS inclusion, skb timestamping is not consistent in RX path. If netif_receive_skb() is used, its deferred after RPS dispatch. If netif_rx() is used, its done before RPS dispatch. This can give strange tcpdump timestamps results. I think timestamping should be done as soon as possible in the receive path, to get meaningful values (ie timestamps taken at the time packet was delivered by NIC driver to our stack), even if NAPI already can defer timestamping a bit (RPS can help to reduce the gap) Tom Herbert prefer to sample timestamps after RPS dispatch. In case sampling is expensive (HPET/acpi_pm on x86), this makes sense. Let admins switch from one mode to another, using a new sysctl, /proc/sys/net/core/netdev_tstamp_prequeue Its default value (1), means timestamps are taken as soon as possible, before backlog queueing, giving accurate timestamps. Setting a 0 value permits to sample timestamps when processing backlog, after RPS dispatch, to lower the load of the pre-RPS cpu. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | xfrm: fix policy unreferencing on larval dropTimo Teras2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I mistakenly had the error path to use num_pols to decide how many policies we need to drop (cruft from earlier patch set version which did not handle socket policies right). This is wrong since normally we do not keep explicit references (instead we hold reference to the cache entry which holds references to policies). drop_pols is set to num_pols if we are holding the references, so use that. Otherwise we eventually BUG_ON inside xfrm_policy_destroy due to premature policy deletion. Signed-off-by: Timo Teras <timo.teras@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: adjust handle_macvlan to pass port struct to hookJiri Pirko2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now there's null check here and also again in the hook. Looking at bridge bits which are simmilar, port structure is rcu_dereferenced right away in handle_bridge and passed to hook. Looks nicer. Signed-off-by: Jiri Pirko <jpirko@redhat.com> Acked-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | skge: use the DMA state API instead of the pci equivalentsFUJITA Tomonori2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This replace the PCI DMA state API (include/linux/pci-dma.h) with the DMA equivalents since the PCI DMA state API will be obsolete. No functional change. For further information about the background: http://marc.info/?l=linux-netdev&m=127037540020276&w=2 Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | net: reserve ports for applications using fixed port numbersAmerigo Wang2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Dropped the infiniband part, because Tetsuo modified the related code, I will send a separate patch for it once this is accepted.) This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports which allows users to reserve ports for third-party applications. The reserved ports will not be used by automatic port assignments (e.g. when calling connect() or bind() with port number 0). Explicit port allocation behavior is unchanged. Signed-off-by: Octavian Purdila <opurdila@ixiacom.com> Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | sysctl: add proc_do_large_bitmapOctavian Purdila2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new function can be used to read/write large bitmaps via /proc. A comma separated range format is used for compact output and input (e.g. 1,3-4,10-10). Writing into the file will first reset the bitmap then update it based on the given input. Signed-off-by: Octavian Purdila <opurdila@ixiacom.com> Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | sysctl: refactor integer handling proc codeAmerigo Wang2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Based on Octavian's work, and I modified a lot.) As we are about to add another integer handling proc function a little bit of cleanup is in order: add a few helper functions to improve code readability and decrease code duplication. In the process a bug is also fixed: if the user specifies a number with more then 20 digits it will be interpreted as two integers (e.g. 10000...13 will be interpreted as 100.... and 13). Behavior for EFAULT handling was changed as well. Previous to this patch, when an EFAULT error occurred in the middle of a write operation, although some of the elements were set, that was not acknowledged to the user (by shorting the write and returning the number of bytes accepted). EFAULT is now treated just like any other errors by acknowledging the amount of bytes accepted. Signed-off-by: Octavian Purdila <opurdila@ixiacom.com> Signed-off-by: WANG Cong <amwang@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | Merge branch 'master' of ↵David S. Miller2010-05-16
|\ \ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
| * | | wimax/i2400m: driver defaults to firmware v1.5 for i6x60 devicesInaky Perez-Gonzalez2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | Firmware is available in the linux-firmware package. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
| * | | wimax/i2400m: driver defaults to firmware v1.5 for i5x50 devicesInaky Perez-Gonzalez2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates the i2400m driver to default to firmware versions v1.5 for the Intel Wireless WiMAX Connection 5150 and 5350 devices. Firmware available in linux-firmware. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
| * | | wimax/i2400m: Move module params to other file so they can be staticPrasanna S Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch moves the module parameters to the file where they can be avoided to be global and allow them to be static. The module param : idle_mode_disabled and power_save_disabled are moved from driver.c to control.c. Also these module parameters are declared to be static as they are not required to be global anymore. The module param : rx_reorder_disabled is moved from driver.c file to rx.c file. Also this parameter is declated as static as it is not required to be global anymore. Signed-off-by: Prasanna S Panchamukhi<prasannax.s.panchamukhi@intel.com>
| * | | wimax: wimax_msg_alloc() returns ERR_PTR not nullDan Carpenter2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wimax_msg_alloc() returns an ERR_PTR and not null. I changed it to test for ERR_PTR instead of null. I also added a check in front of the kfree() because kfree() can handle null but not ERR_PTR. Signed-off-by: Dan Carpenter <error27@gmail.com>
| * | | wimax: checking ERR_PTR vs nullDan Carpenter2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | stch_skb is allocated with wimax_gnl_re_state_change_alloc(). That function returns ERR_PTRs on failure and doesn't return NULL. Signed-off-by: Dan Carpenter <error27@gmail.com>
| * | | wimax/i2400m: USB specific TX queue's minimum buffer room required for new ↵Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | message This patch specifies the TX queue's buffer room required by the USB bus driver while allocating header space for a new message. Please refer the documentation in the code. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: SDIO specific TX queue's minimum buffer room for new messagePrasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | wimax/i2400m: reserve additional space in the TX queue's buffer while ↵Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocating space for a new message header Increase the possibilities of including at least one payload by reserving some additional space in the TX queue while allocating TX queue's space for new message header. Please refer the documentation in the code for details. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: fix incorrect handling of type 2 and 3 RX messagesPrasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Intel Wimax i3200, i5x50 and i6x60 device specification documents, the host driver must not reset the device if the normalized sequence numbers are greater than 1023 for type 2 and type 3 RX messages. This patch removes the code that incorrectly used to reset the device. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax i2400m: fix race condition while accessing rx_roq by using kref countPrasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the race condition when one thread tries to destroy the memory allocated for rx_roq, while another thread still happen to access rx_roq. Such a race condition occurs when i2400m-sdio kernel module gets unloaded, destroying the memory allocated for rx_roq while rx_roq is accessed by i2400m_rx_edata(), as explained below: $thread1 $thread2 $ void i2400m_rx_edata() $ $Access rx_roq[] $ $roq = &i2400m->rx_roq[ro_cin] $ $ i2400m_roq_[reset/queue/update_ws] $ $ $ void i2400m_rx_release(); $ $kfree(rx->roq); $ $rx->roq = NULL; $Oops! rx_roq is NULL This patch fixes the race condition using refcount approach. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: increase tx queue length from 5 to 20 [v1]Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch increases the tx_queue_len to 20 so as to minimize the jitter in the throughput. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: fix system freeze caused by an infinite loop [v1]Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an infinite loop caused by i2400m_tx_fifo_push() due to a corner case where there is no tail space in the TX FIFO. Please refer the documentation in the code for details. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: modify i2400m_tx_fifo_push() to check for head room space in ↵Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the TX FIFO [v1] This fixes i2400m_tx_fifo_push(); the check for having enough space in the TX FIFO's tail was obscure and broken in certain corner cases. The new check works in all cases and is way clearer. Please refer the documentation in the code for details. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: fix BUILD_BUG_ON() to use the maximum message size constant [v1]Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The older method of computing the maximum PDU size relied on a method that doesn't work when we prop the maximum number of payloads up to the physical limit, and thus we kill the whole computation and just verify that the constants are congruent. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: limit the message size upto 16KiB [v1]Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Intel Wimax i3200, i5x50 and i6x50 specification documents, the maximum size of each TX message can be upto 16KiB. This patch modifies the i2400m_tx() routine to check that the message size does not exceed the 16KiB limit. Please refer the documentation in the code for details. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: increase the maximum number of payloads per message to 60 [v1]Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Intel Wimax i3200, i5x50 and i6x50 device specification documents, the maximum number of payloads per message can be up to 60. Increasing the number of payloads to 60 per message helps to accommodate smaller payloads in a single transaction. This patch increases the maximum number of payloads from 12 to 60 per message. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
| * | | wimax/i2400m: Reset the TX FIFO indices when allocating the TX FIFO in ↵Cindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tx_setup() This patch makes sure whenever tx_setup() is invoked during driver initialization or device reset where TX FIFO is released and re-allocated, the indices tx_in, tx_out, tx_msg_size, tx_sequence, tx_msg are properly initialized. When a device reset happens and the TX FIFO is released/re-allocated, a new block of memory may be allocated for the TX FIFO, therefore tx_msg should be cleared so that no any TX threads (tx_worker, tx) would access to the out-of-date addresses. Also, the TX threads use tx_in and tx_out to decide where to put the new host-to-device messages and from where to copy them to the device HW FIFO, these indices have to be cleared so after the TX FIFO is re-allocated during the reset, the indices both refer to the head of the FIFO, ie. a new start. The same rational applies to tx_msg_size and tx_sequence. To protect the indices from being accessed by multiple threads simultaneously, the lock tx_lock has to be obtained before the initializations and released afterwards. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: Correct the error path handlers order in i2400m_post_reset()Cindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When bus_setup fails in i2400m_post_reset(), it falls to the error path handler "error_bus_setup:" which includes unlock the mutext. However, we didn't ever try to the obtain the lock when running bus_setup. The patch is to fix the misplaced error path handler "error_bus_setup:". Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: add the error recovery mechanism on TX pathCindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds an error recovery mechanism on TX path. The intention is to bring back the device to some known state whenever TX sees -110 (-ETIMEOUT) on copying the data to the HW FIFO. The TX failure could mean a device bus stuck or function stuck, so the current error recovery implementation is to trigger a bus reset and expect this can bring back the device. Since the TX work is done in a thread context, there may be a queue of TX works already that all hit the -ETIMEOUT error condition because the device has somewhat stuck already. We don't want any consecutive bus resets simply because multiple TX works in the queue all hit the same device erratum, the flag "error_recovery" is introduced to denote if we are ready for taking any error recovery. See @error_recovery doc in i2400m.h. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: fix for missed reset events if triggered by dev_reset_handle()Cindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is only seen on SDIO interface since on USB, a bus reset would really re-probe the driver, but on SDIO interface, a bus reset will not re-enumerate the SDIO bus, so no driver re-probe is happening. Therefore, on SDIO interface, the reset event should be still detected and handled by dev_reset_handle(). Problem description: Whenever a reboot barker is received during operational mode (i2400m->boot_mode == 0), dev_reset_handle() is invoked to handle that function reset event. dev_reset_handle() then sets the flag i2400m->boot_mode to 1 indicating the device is back to bootmode before proceeding to dev_stop() and dev_start(). If dev_start() returns failure, a bus reset is triggered by dev_reset_handle(). The flag i2400m->boot_mode then remains 1 when the second reboot barker arrives. However the interrupt service routine i2400ms_rx() instead of invoking dev_reset_handle() to handle that reset event, it filters out that boot event to bootmode because it sees the flag i2400m->boot_mode equal to 1. The fix: Maintain the flag i2400m->boot_mode within dev_reset_handle() and set the flag i2400m->boot_mode to 1 when entering dev_reset_handle(). It remains 1 until the dev_reset_handle() issues a bus reset. ie: the bus reset is taking place just like it happens for the first time during operational mode. To denote the actual device state and the state we expect, a flag i2400m->alive is introduced in addition to the existing flag i2400m->updown. It's maintained with the same way for i2400m->updown but instead of reflecting the actual state like i2400m->updown does, i2400m->alive maintains the state we expect. i2400m->alive is set 1 just like whenever i2400m->updown is set 1. Yet i2400m->alive remains 1 since we expect the device to be up all the time until the driver is removed. See the doc for @alive in i2400m.h. An enumeration I2400M_BUS_RESET_RETRIES is added to define the maximum number of bus resets that a device reboot can retry. A counter i2400m->bus_reset_retries is added to track how many bus resets have been retried in one device reboot. If I2400M_BUS_RESET_RETRIES bus resets were retried in this boot, we give up any further retrying so the device would enter low power state. The counter i2400m->bus_reset_retries is incremented whenever dev_reset_handle() is issuing a bus reset and is cleared to 0 when dev_start() is successfully done, ie: a successful reboot. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: correct the error path handlers in dev_start()Cindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fix is to correct order of the handlers in the error path of dev_start(). When i2400m_firmware_check fails, all the works done before it should be released or cleared. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: fix the race condition for accessing TX queueCindy H Kao2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The race condition happens when the TX queue is accessed by the TX work while the same TX queue is being destroyed because a bus reset is triggered either by debugfs entry or simply by failing waking up the device from WiMAX IDLE mode. This fix is to prevent the TX queue from being accessed by multiple threads Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
| * | | wimax/i2400m: fix insufficient size of Tx buffer for 12 payload of 1400 MTU.Prasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch increases the Tx buffer size so as to accommodate 12 payloads of 1408 (1400 MTU 16 bytes aligned). Currently Tx buffer is 32 KiB which is insufficient to accommodate 12 payloads of 1408 size. This patch - increases I2400M_TX_BUF_SIZE from 32KiB to 64KiB - Adds a BUILD_BUG_ON if the calculated buffer size based on the given MTU exceeds the I2400M_TX_BUF_SIZE. Below is how we calculate the size of the Tx buffer. Payload + 4 bytes prefix for each payload (1400 MTU 16 bytes boundary aligned) = (1408 + sizeof(struct i2400m_pl_data_hdr)) * I2400M_TX_PLD_MAX Adding 16 byte message header = + sizeof(struct i2400m_msg_hdr) Aligning to 256 byte boundary Total Tx buffer = (((((1408 + sizeof(struct i2400m_pl_data_hdr)) * I2400M_TX_PLD_MAX )+ sizeof(struct i2400m_msg_hdr)) / 256) + 1) * 256 * 2 Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
| * | | wimax/i2400m: move I2400M_MAX_MTU enum from netdev.c to i2400m.hPrasanna S. Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch moves I2400M_MAX_MTU enum defined in netdev.c to i2400m.h. Follow up changes will make use of this value in other location, thus requiring it to be moved to a global header file i2400m.h. Signed-off-by: Prasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
| * | | wimax/i2400m: fix incorrect return -ESHUTDOWN when there is no Tx buffer ↵Prasanna S.Panchamukhi2010-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | available i2400m_tx() routine was returning -ESHUTDOWN even when there was no Tx buffer available. This patch fixes the i2400m_tx() to return -ESHUTDOWN only when the device is down(i2400m->tx_buf is NULL) and also to return -ENOSPC when there is no Tx buffer. Error seen in the kernel log. kernel: i2400m_sdio mmc0:0001:1: can't send message 0x5606: -108 kernel: i2400m_sdio mmc0:0001:1: Failed to issue 'Enter power save'command: -108 Signed-off-by: Prasanna S.Panchamukhi <prasannax.s.panchamukhi@intel.com>
* | | | bridge: update sysfs link names if port device names have changedSimon Arlott2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Links for each port are created in sysfs using the device name, but this could be changed after being added to the bridge. As well as being unable to remove interfaces after this occurs (because userspace tools don't recognise the new name, and the kernel won't recognise the old name), adding another interface with the old name to the bridge will cause an error trying to create the sysfs link. This fixes the problem by listening for NETDEV_CHANGENAME notifications and renaming the link. https://bugzilla.kernel.org/show_bug.cgi?id=12743 Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Acked-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | bridge: change console message interfacestephen hemminger2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use one set of macro's for all bridge messages. Note: can't use netdev_XXX macro's because bridge is purely virtual and has no device parent. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | bridge: netpoll cleanupstephen hemminger2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move code around so that the ifdef for NETPOLL_CONTROLLER don't have to show up in main code path. The control functions should be in helpers that are only compiled if needed. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | rndis_host: Poll status channel before control channelBen Hutchings2010-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some RNDIS devices don't respond on the control channel until polled on the status channel. In particular, this was reported to be the case for the 2Wire HomePortal 1000SW. This is roughly based on a patch by John Carr <john.carr@unrouted.co.uk> which is reported to be needed for use with some Windows Mobile devices and which is currently applied by Mandriva. Reported-by: Mark Glassberg <vzeeaxwl@myfairpoint.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Tested-by: Mark Glassberg <vzeeaxwl@myfairpoint.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | netfilter: xt_TEE depends on NF_CONNTRACKRandy Dunlap2010-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix xt_TEE build for the case of NF_CONNTRACK=m and NETFILTER_XT_TARGET_TEE=y: xt_TEE.c:(.text+0x6df5c): undefined reference to `nf_conntrack_untracked' 4x Built with all 4 m/y combinations. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | qlcnic: add idc debug registersSucheta Chakraborty2010-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ever driver changes the device state, it should write pci-func number and timestamp in debug registers. Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>