1. 02 3月, 2009 1 次提交
    • I
      wimax/i2400m: support extended data RX protocol (no need to reallocate skbs) · fd5c565c
      Inaky Perez-Gonzalez 提交于
      Newer i2400m firmwares (>= v1.4) extend the data RX protocol so that
      each packet has a 16 byte header. This header is mainly used to
      implement host reordeing (which is addressed in later commits).
      
      However, this header also allows us to overwrite it (once data has
      been extracted) with an Ethernet header and deliver to the networking
      stack without having to reallocate the skb (as it happened in fw <=
      v1.3) to make room for it.
      
      - control.c: indicate the device [dev_initialize()] that the driver
        wants to use the extended data RX protocol. Also involves adding the
        definition of the needed data types in include/linux/wimax/i2400m.h.
      
      - rx.c: handle the new payload type for the extended RX data
        protocol. Prepares the skb for delivery to
        netdev.c:i2400m_net_erx().
      
      - netdev.c: Introduce i2400m_net_erx() that adds the fake ethernet
        address to a prepared skb and delivers it to the networking
        stack.
      
      - cleanup: in most instances in rx.c, the variable 'single' was
        renamed to 'single_last' for it better conveys its meaning.
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd5c565c
  2. 01 2月, 2009 1 次提交
  3. 22 1月, 2009 1 次提交
  4. 08 1月, 2009 1 次提交
    • I
      i2400m: linkage to the networking stack · ce6cde92
      Inaky Perez-Gonzalez 提交于
      Implementation of the glue to the network stack so the WiMAX device
      shows up as an Ethernet device.
      
      Initially we shot for implementing a Pure IP device -- however, the
      world seems to turn around Ethernet devices. Main issues were with the
      ISC DHCP client and servers (as they don't understand types other than
      Ethernet and Token Ring).
      
      We proceeded to register with IANA the PureIP hw type, so that DHCP
      requests could declare such. We also created patches to the main ISC
      DHCP versions to support it. However, until all that permeates into
      deployments, there is going to be a long time.
      
      So we moved back to wrap Ethernet frames around the PureIP device. At
      the time being this has overhead; we need to reallocate with space for
      an Ethernet header. The reason is the device-to-host protocol
      coalesces many network packets into a single message, so we can't
      introduce Ethernet headers without overwriting valid data from other
      packets.
      
      Coming-soon versions of the firmware have this issue solved.
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ce6cde92