1. 05 9月, 2008 15 次提交
  2. 24 8月, 2008 6 次提交
    • L
      mv643xx_eth: bump version to 1.3 · c4560318
      Lennert Buytenhek 提交于
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      c4560318
    • L
      mv643xx_eth: enforce multiple-of-8-bytes receive buffer size restriction · abe78717
      Lennert Buytenhek 提交于
      The mv643xx_eth hardware ignores the lower three bits of the buffer
      size field in receive descriptors, causing the reception of full-sized
      packets to fail at some MTUs.  Fix this by rounding the size of
      allocated receive buffers up to a multiple of eight bytes.
      
      While we are at it, add a bit of extra space to each receive buffer so
      that we can handle multiple vlan tags on ingress.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      abe78717
    • L
      mv643xx_eth: fix NULL pointer dereference in rxq_process() · 9e1f3772
      Lennert Buytenhek 提交于
      When we are low on memory, the assumption that every descriptor in the
      receive ring will have an skbuff associated with it does not hold.
      
      rxq_process() was assuming that if the receive descriptor it is working
      on is not owned by the hardware, it can safely be processed and handed
      to the networking stack.  But a descriptor in the receive ring not being
      owned by the hardware can also happen when we are low on memory and did
      not manage to refill the receive ring fully.
      
      This patch changes rxq_process()'s bailout condition from "the first
      receive descriptor to be processed is owned by the hardware" to "the
      first receive descriptor to be processed is owned by the hardware OR
      the number of valid receive descriptors in the ring is zero".
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      9e1f3772
    • L
      mv643xx_eth: fix inconsistent lock semantics · 8e0b1bf6
      Lennert Buytenhek 提交于
      Nicolas Pitre noted that mv643xx_eth_poll was incorrectly using
      non-IRQ-safe locks while checking whether to wake up the netdevice's
      transmit queue.  Convert the locking to *_irq() variants, since we
      are running from softirq context where interrupts are enabled.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      8e0b1bf6
    • L
      mv643xx_eth: fix double add_timer() on the receive oom timer · 92c70f27
      Lennert Buytenhek 提交于
      Commit 12e4ab79 ("mv643xx_eth: be
      more agressive about RX refill") changed the condition for the receive
      out-of-memory timer to be scheduled from "the receive ring is empty"
      to "the receive ring is not full".
      
      This can lead to a situation where the receive out-of-memory timer is
      pending because a previous rxq_refill() didn't manage to refill the
      receive ring entirely as a result of being out of memory, and
      rxq_refill() is then called again as a side effect of a packet receive
      interrupt, and that rxq_refill() call then again does not succeed to
      refill the entire receive ring with fresh empty skbuffs because we are
      still out of memory, and then tries to call add_timer() on the already
      scheduled out-of-memory timer.
      
      This patch fixes this issue by changing the add_timer() call in
      rxq_refill() to a mod_timer() call.  If the OOM timer was not already
      scheduled, this will behave as before, whereas if it was already
      scheduled, this patch will push back its firing time a bit, which is
      safe because we've (unsuccessfully) attempted to refill the receive
      ring just before we do this.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      92c70f27
    • L
      mv643xx_eth: fix NAPI 'rotting packet' issue · 819ddcaf
      Lennert Buytenhek 提交于
      When a receive interrupt occurs, mv643xx_eth would first process the
      receive descriptors and then ACK the receive interrupt, instead of the
      other way round.
      
      This would leave a small race window between processing the last
      receive descriptor and clearing the receive interrupt status in which
      a new packet could come in, which would then 'rot' in the receive
      ring until the next receive interrupt would come in.
      
      Fix this by ACKing (clearing) the receive interrupt condition before
      processing the receive descriptors.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      819ddcaf
  3. 24 7月, 2008 12 次提交
    • L
      mv643xx_eth: bump version to 1.2 · ac0a2d0c
      Lennert Buytenhek 提交于
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      ac0a2d0c
    • L
      mv643xx_eth: enable hardware TX checksumming with vlan tags · e32b6617
      Lennert Buytenhek 提交于
      Although mv643xx_eth has no hardware support for inserting a vlan
      tag by twiddling some bits in the TX descriptor, it does support
      hardware TX checksumming on packets where the IP header starts {a
      limited set of values other than 14} bytes into the packet.
      
      This patch sets mv643xx_eth's ->vlan_features to NETIF_F_SG |
      NETIF_F_IP_CSUM, which prevents the stack from checksumming vlan'ed
      packets in software, and if vlan tags are present on a transmitted
      packet, notifies the hardware of this fact by toggling the right
      bits in the TX descriptor.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      e32b6617
    • L
      mv643xx_eth: print message on link status change · 2f7eb47a
      Lennert Buytenhek 提交于
      When there is a link status change (link or phy status interrupt),
      print a message notifying the user of the new link status.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      2f7eb47a
    • L
      mv643xx_eth: use auto phy polling for configuring (R)(G)MII interface · 81600eea
      Lennert Buytenhek 提交于
      The mv643xx_eth hardware has a provision for polling the PHY's
      MII management registers to obtain the (R)(G)MII interface speed
      (10/100/1000) and duplex (half/full) and pause (off/symmetric)
      settings to use to talk to the PHY.
      
      The driver currently does not make use of this feature.  Instead,
      whenever there is a link status change event, it reads the current
      link parameters from the PHY, and programs those parameters into
      the mv643xx_eth MAC by hand.
      
      This patch switches the mv643xx_eth driver to letting the MAC
      auto-determine the (R)(G)MII link parameters by PHY polling, if there
      is a PHY present.  For PHYless ports (when e.g. the (R)(G)MII
      interface is connected to a hardware switch), we keep hardcoding the
      MII interface parameters.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      81600eea
    • L
      mv643xx_eth: print driver version on init · 7dde154d
      Lennert Buytenhek 提交于
      Print the mv643xx_eth driver version on init to help debugging.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      7dde154d
    • L
      mv643xx_eth: use symbolic MII register addresses and values · 7f106c1d
      Lennert Buytenhek 提交于
      Instead of hardcoding MII register addresses and values, use the
      symbolic constants defined in linux/mii.h.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      7f106c1d
    • L
      mv643xx_eth: use longer DMA bursts · cd4ccf76
      Lennert Buytenhek 提交于
      The mv643xx_eth driver is limiting DMA bursts to 32 bytes, while
      using the largest burst size (128 bytes) gives a couple percentage
      points performance improvement in throughput tests, and the docs
      say that the 128 byte default should not need to be changed, so
      use 128 byte bursts instead.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      cd4ccf76
    • L
      mv643xx_eth: also check TX_IN_PROGRESS when disabling transmit path · ae9ae064
      Lennert Buytenhek 提交于
      The recommended sequence for waiting for the transmit path to clear
      after disabling all of the transmit queues is to wait for the
      TX_FIFO_EMPTY bit in the Port Status register to become set as well
      as the TX_IN_PROGRESS bit to clear.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      ae9ae064
    • L
      mv643xx_eth: don't fiddle with maximum receive packet size setting · 65193a91
      Lennert Buytenhek 提交于
      The maximum receive packet size field in the Port Serial Control
      register controls at what size received packets are flagged
      overlength in the receive descriptor, but it doesn't prevent
      overlength packets from being DMAd to memory and signaled to the
      host like other received packets.
      
      mv643xx_eth does not support receiving jumbo frames in 10/100 mode,
      but setting the packet threshold to larger than 1522 bytes in 10/100
      mode won't cause breakage by itself.
      
      If we really want to enforce maximum packet size on the receiving
      end instead of on the sending end where it should be done, we can
      always just add a length check to the software receive handler
      instead of relying on the hardware to do the comparison for us.
      
      What's more, changing the maximum packet size field requires
      temporarily disabling the RX/TX paths.  So once the link comes
      up in 10/100 Mb/s mode or 1000 Mb/s mode, we'd have to disable it
      again just to set the right maximum packet size field (1522 in
      10/100 Mb/s mode or 9700 in 1000 Mb/s mode), just so that we can
      offload one comparison operation to hardware that we might as well
      do in software, assuming that we'd want to do it at all.
      
      Contrary to what the documentation suggests, there is no harm in
      just setting a 9700 byte maximum packet size in 10/100 mode, so use
      the maximum maximum packet size for all modes.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      65193a91
    • L
      mv643xx_eth: fix transmit-reclaim-in-napi-poll · 4dfc1c87
      Lennert Buytenhek 提交于
      The mv643xx_eth driver allows doing transmit reclaim from within the
      napi poll routine, but after doing reclaim, it would forget to check
      the free transmit descriptor count and wake up the transmit queue if
      the reclaim caused enough descriptors for a new packet to become
      available.  This would cause the netdev watchdog to occasionally kick
      in during certain workloads with combined receive and transmit traffic.
      
      Fix this by adding a wakeup check identical to the one in the
      interrupt handler to the napi poll routine.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      4dfc1c87
    • L
      mv643xx_eth: prevent breakage when link goes down during transmit · 6b368f68
      Lennert Buytenhek 提交于
      When the ethernet link goes down while mv643xx_eth is transmitting
      data, transmit DMA can stop before all queued transmit descriptors
      have been processed.  But even the descriptors that _have_ been
      processed might not be properly marked as done before the transmit
      DMA unit shuts down.
      
      Then when the link comes up again, the hardware transmit pointer
      might have advanced while not all previous packet descriptors have
      been marked as transmitted, causing software transmit reclaim to
      hang waiting for the hardware to finish transmitting a descriptor
      that it has already skipped.
      
      This patch forcibly reclaims all packets on the transmit ring on a
      link down interrupt, and then resyncs the hardware transmit pointer to
      what the software's idea of the first free descriptor is.  Also, we
      need to prevent re-waking the transmit queue if we get a 'transmit
      done' interrupt at the same time as a 'link down' interrupt, which
      this patch does as well.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      6b368f68
    • L
      mv643xx_eth: fix TX hang erratum workaround · 8fa89bf5
      Lennert Buytenhek 提交于
      The previously merged TX hang erratum workaround ("mv643xx_eth:
      work around TX hang hardware issue") assumes that TX_END interrupts
      are delivered simultaneously with or after their corresponding TX
      interrupts, but this is not always true in practise.
      
      In particular, it appears that TX_END interrupts are issued as soon
      as descriptor fetch returns an invalid descriptor, which may happen
      before earlier descriptors have been fully transmitted and written
      back to memory as being done.
      
      This hardware behavior can lead to a situation where the current
      driver code mistakenly assumes that the MAC has given up transmitting
      before noticing the packets that it is in fact still currently working
      on, causing the driver to re-kick the transmit queue, which will only
      cause the MAC to re-fetch the invalid head descriptor, and generate
      another TX_END interrupt, et cetera, until the packets in the pipe
      finally finish transmitting and have their descriptors written back
      to memory, which will then finally break the loop.
      
      Fix this by having the erratum workaround not check the 'number of
      unfinished descriptor', but instead, to compare the software's idea
      of what the head descriptor pointer should be to the hardware's head
      descriptor pointer (which is updated on the same conditions as the
      TX_END interupt is generated on, i.e. possibly before all previous
      descriptors have been transmitted and written back).
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      8fa89bf5
  4. 23 7月, 2008 1 次提交
    • L
      mv643xx_eth: fix NETPOLL build · f2ca60f2
      Lennert Buytenhek 提交于
      Joseph Fannin <jfannin@gmail.com> and Takashi Iwai <tiwai@suse.de>
      noticed that commit 073a345c
      ("mv643xx_eth: clarify irq masking and unmasking") broke the
      mv643xx_eth build when NETPOLL is enabled, due to it not renaming
      one instance of INT_CAUSE_EXT in mv643xx_eth_netpoll().  This patch
      takes care of that instance as well.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Cc: Dale Farnsworth <dale@farnsworth.org>
      Cc: Joseph Fannin <jfannin@gmail.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f2ca60f2
  5. 12 6月, 2008 6 次提交