Lines Matching full:we
12 * We fake being an ethernet device to simplify the support from user
19 * in what we get from the device). This is a known drawback and
23 * TX error handling is tricky; because we have to FIFO/queue the
24 * buffers for transmission (as the hardware likes it aggregated), we
26 * transmitted, we have long forgotten about it. So we just don't care
29 * Note that when the device is in idle mode with the basestation, we
31 * and possible user space interaction. Thus, we defer to a workqueue
32 * to do all that. By default, we only queue a single packet and drop
75 * station. We add 1sec for good measure. */
93 /* Make sure we wait until init is complete... */ in i2400m_open()
122 * When the device goes into basestation-idle mode, we need to tell it
125 * when it is ready to transmit the packet we have "queued". Still we
128 * On error, there is not much we can do. If the error was on TX, we
133 * (for example, the base station). In that case we get an -EILSEQ and
134 * we are just going to ignore that one. If the device is back to
158 /* If we have, somehow, lost the connection after this was in i2400m_wake_tx_work()
201 * Because we pretend to be an ethernet device, this packet comes with
218 * This is called by __i2400m_dev_stop and means we have to make sure
230 * here we release them if the packet was still pending. in i2400m_net_wake_stop()
251 * When the device is in basestation-idle mode, we need to wake it up
252 * and then TX. So we queue a work_struct for doing so.
254 * We need to get an extra ref for the skb (so it is not dropped), as
256 * at all). If more than one request comes or there are errors, we
274 /* We hold a ref count for i2400m and skb, so when in i2400m_net_wake_tx()
275 * stopping() the device, we need to cancel that work in i2400m_net_wake_tx()
289 /* Yes, this happens even if we stopped the in i2400m_net_wake_tx()
309 * We need to pull the ethernet header and add the hardware header,
340 * In case of error, we just drop it. Reasons:
342 * - we add a hw header to each skb, and if the network stack
343 * retries, we have no way to know if that skb has it or not.
347 * - there is not much else we can do
349 * If the device is idle, we need to wake it up; that is an operation
386 * We might want to kick the device in i2400m_tx_timeout()
388 * There is not much we can do though, as the device requires in i2400m_tx_timeout()
389 * that we send the data aggregated. By the time we receive in i2400m_tx_timeout()
429 * Note that due to firmware limitations, we don't have space to add
430 * an ethernet header, so we need to copy each packet. Firmware
433 * We just clone the skb and set it up so that it's skb->data pointer
437 * multi-payload message, we don't clone the SKB but just reuse it.
439 * This function is normally run from a thread context. However, we
442 * when sending/receiving a lot of data we seem to hit a softlock in
449 * FIXME: currently we don't do any efforts at distinguishing if what
450 * we got was an IPv4 or IPv6 header, to setup the protocol field
508 * This function is normally run from a thread context. However, we
511 * when sending/receiving a lot of data we seem to hit a softlock in