1. 16 Apr, 2010 2 commits
  2. 15 Apr, 2010 10 commits
  3. 14 Apr, 2010 23 commits
    • Jesse Brandeburg's avatar
      ixgbe: fix bug with vlan strip in promsic mode · 5f6c0181
      Jesse Brandeburg authored
      The ixgbe driver was setting up 82598 hardware correctly, so that
      when promiscuous mode was enabled hardware stripping was turned
      off.  But on 82599 the logic to disable/enable hardware stripping
      is different, and the code was not updated correctly when the
      hardware vlan stripping was enabled as default.
      
      This change comprises the creation of two new helper functions
      and calling them from the right locations to disable and enable
      hardware stripping of vlan tags at appropriate times.
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f6c0181
    • Eric Dumazet's avatar
      drivers: net: use skb_headlen() · e743d313
      Eric Dumazet authored
      replaces (skb->len - skb->data_len) occurrences by skb_headlen(skb)
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e743d313
    • Xose Vazquez Perez's avatar
      wireless: rt2x00: rt2800usb: identify Sitecom devices · a5e944f1
      Xose Vazquez Perez authored
      A very useful information was provided by Sitecom R&D guys:
      
      Please find the information regarding our latest Ralink adapters below;
      
      WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
      WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
      WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
      WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
      WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
      WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
      WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
      WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
      WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
      WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070
      
      Note:
      PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--
      
      The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
      Signed-off-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a5e944f1
    • Christian Lamparter's avatar
      ar9170usb: add a couple more USB IDs · 94d0bbe8
      Christian Lamparter authored
      This patch adds the following 5 entries to the usbid device table:
      
       * Netgear WNA1000
       * Proxim ORiNOCO Dual Band 802.11n USB Adapter
       * 3Com Dual Band 802.11n USB Adapter
       * H3C Dual Band 802.11n USB Adapter
       * WNC Generic 11n USB dongle
      
      CC: <stable@kernel.org>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      94d0bbe8
    • Grazvydas Ignotas's avatar
      wl1251: don't require NVS data when EEPROM is used · afa5ec27
      Grazvydas Ignotas authored
      If EEPROM is used, NVS data is now loaded but ignored.
      Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: default avatarKalle Valo <kvalo@adurom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      afa5ec27
    • Ming Lei's avatar
      ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 usb device · f8e1d080
      Ming Lei authored
      This patch fixes two warnings below after unplugging ar9271 usb device:
      	-one is a kernel warning[1]
      	-another is a lockdep warning[2]
      
      The root reason is that __skb_queue_purge can't be executed in hardirq
      context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge),
      which frees skb with dev_kfree_skb_any which can be run in hardirq
      context safely, then prevent the lockdep warning and kernel warning after
      unplugging ar9271 usb device.
      
      [1] kernel warning
      [  602.894005] ------------[ cut here ]------------
      [  602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87()
      [  602.894005] Hardware name: 6475EK2
      [  602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath]
      [  602.894005] Pid: 2506, comm: ping Tainted: G        W  2.6.34-rc3-wl #20
      [  602.894005] Call Trace:
      [  602.894005]  <IRQ>  [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94
      [  602.894005]  [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16
      [  602.894005]  [<ffffffff813269c1>] skb_release_head_state+0x71/0x87
      [  602.894005]  [<ffffffff8132829a>] __kfree_skb+0x16/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc]
      [  602.894005]  [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc]
      [  602.894005]  [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc]
      [  602.894005]  [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  602.894005]  [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  602.894005]  [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  602.894005]  [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  602.894005]  [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df
      [  602.894005]  [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2
      [  602.894005]  [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  602.894005]  [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  602.894005]  [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  602.894005]  [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  602.894005]  [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  602.894005]  <EOI>  [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e
      [  602.894005]  [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e
      [  602.894005]  [<ffffffff811095fe>] __delete_object+0x5a/0xb1
      [  602.894005]  [<ffffffff81109814>] delete_object_full+0x25/0x31
      [  602.894005]  [<ffffffff813a60c0>] kmemleak_free+0x26/0x45
      [  602.894005]  [<ffffffff810ff517>] kfree+0xaa/0x149
      [  602.894005]  [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89
      [  602.894005]  [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff813285ce>] skb_release_data+0xc9/0xce
      [  602.894005]  [<ffffffff813282a2>] __kfree_skb+0x1e/0x81
      [  602.894005]  [<ffffffff813283b2>] kfree_skb+0x7e/0x86
      [  602.894005]  [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c
      [  602.894005]  [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709
      [  602.894005]  [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d
      [  602.894005]  [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf
      [  602.894005]  [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9
      [  602.894005]  [<ffffffff810e13b4>] ? might_fault+0x68/0xb8
      [  602.894005]  [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8
      [  602.894005]  [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31
      [  602.894005]  [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91
      [  602.894005]  [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63
      [  602.894005]  [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9
      [  602.894005]  [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9
      [  602.894005]  [<ffffffff810357fe>] ? need_resched+0x23/0x2d
      [  602.894005]  [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150
      [  602.894005]  [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  602.894005]  [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      [  602.894005] ---[ end trace 91ba2d8dc7826839 ]---
      
      [2] lockdep warning
      [  169.363215] ======================================================
      [  169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
      [  169.366334] 2.6.34-rc3-wl #20
      [  169.366872] ------------------------------------------------------
      [  169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      [  169.366872]  (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89
      [  169.366872]
      [  169.366872] and this task is already holding:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc]
      [  169.366872] which would create a new lock dependency:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..}
      [  169.366872]
      [  169.366872] but this new dependency connects a HARDIRQ-irq-safe lock:
      [  169.366872]  (&(&hif_dev->tx.tx_lock)->rlock){-.-...}
      [  169.366872] ... which became HARDIRQ-irq-safe at:
      [  169.366872]   [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73
      [  169.366872]   [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc]
      [  169.366872]   [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore]
      [  169.366872]   [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd]
      [  169.366872]   [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd]
      [  169.366872]   [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd]
      [  169.366872]   [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd]
      [  169.366872]   [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore]
      [  169.366872]   [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f
      [  169.366872]   [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2
      [  169.366872]   [<ffffffff8100c4fb>] handle_irq+0x88/0x91
      [  169.366872]   [<ffffffff8100baed>] do_IRQ+0x63/0xc9
      [  169.366872]   [<ffffffff813ba993>] ret_from_intr+0x0/0x16
      [  169.366872]   [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115
      [  169.366872]   [<ffffffff81008c4f>] cpu_idle+0x68/0xc4
      [  169.366872]   [<ffffffff813a41e0>] rest_init+0x104/0x10b
      [  169.366872]   [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc
      [  169.366872]   [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7
      [  169.366872]   [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107
      [  169.366872]
      [  169.366872] to a HARDIRQ-irq-unsafe lock:
      [  169.366872]  (clock-AF_INET){++.?..}
      [  169.366872] ... which became HARDIRQ-irq-unsafe at:
      [  169.366872] ...  [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b
      [  169.366872]   [<ffffffff8107866d>] lock_acquire+0xec/0x119
      [  169.366872]   [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a
      [  169.366872]   [<ffffffff8135cf14>] tcp_close+0x165/0x34d
      [  169.366872]   [<ffffffff8137aced>] inet_release+0x55/0x5c
      [  169.366872]   [<ffffffff81321350>] sock_release+0x1f/0x6e
      [  169.366872]   [<ffffffff813213c6>] sock_close+0x27/0x2b
      [  169.366872]   [<ffffffff8110dd45>] __fput+0x125/0x1ca
      [  169.366872]   [<ffffffff8110de04>] fput+0x1a/0x1c
      [  169.366872]   [<ffffffff8110adc9>] filp_close+0x68/0x72
      [  169.366872]   [<ffffffff8110ae80>] sys_close+0xad/0xe7
      [  169.366872]   [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b
      
      (Trimmed at the "other info that might help us debug this" line in
      the interest of brevity... -- JWL)
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Acked-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f8e1d080
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in reg out path · 0fa35a58
      Ming Lei authored
      In ath9k-htc register out path, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0fa35a58
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in reg in path · e6c6d33c
      Ming Lei authored
      In ath9k-htc register in path, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e6c6d33c
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in ath9k_hif_usb_alloc_rx_urbs · f28a7b30
      Ming Lei authored
      In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into
      usb hcd and usb hcd will do dma mapping and unmapping to the buffer
      pointed by skb->data, so we should pass a cache-line aligned address.
      
      This patch replace __dev_alloc_skb with alloc_skb to make skb->data
      pointed to a cacheline aligned address simply since ath9k-htc does not
      skb_push on the skb and pass it to mac80211, also use kfree_skb to free
      the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq
      context since skb->destructor is NULL always in the path).
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f28a7b30
    • Bruno Randolf's avatar
      ath5k: treat RXORN as non-fatal · 87d77c4e
      Bruno Randolf authored
      We get RXORN interrupts when all receive buffers are full. This is not
      necessarily a fatal situation. It can also happen when the bus is busy or the
      CPU is not fast enough to process all frames.
      
      Older chipsets apparently need a reset to come out of this situration, but on
      newer chips we can treat RXORN like RX, as going thru a full reset does more
      harm than good, there.
      
      The exact chip revisions which need a reset are unknown - this guess
      AR5K_SREV_AR5212 ("venice") is copied from the HAL.
      
      Inspired by openwrt 413-rxorn.patch:
      "treat rxorn like rx, reset after rxorn seems to do more harm than good"
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      87d77c4e
    • Bruno Randolf's avatar
      ath5k: Use high bitrates for ACK/CTS · 0edc9a67
      Bruno Randolf authored
      There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
      AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
      ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
      resulted in high bitrates, which i think is what we want anyways. Cleared the
      confusion and added some documentation.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0edc9a67
    • David S. Miller's avatar
      virtio_net: Fix mis-merge. · b4bf665c
      David S. Miller authored
      Pointed out by Stephen Rothwell.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4bf665c
    • David S. Miller's avatar
      Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · dad1e54b
      David S. Miller authored
      Conflicts:
      	drivers/net/pcmcia/smc91c92_cs.c
      	drivers/net/virtio_net.c
      dad1e54b
    • Michael S. Tsirkin's avatar
      tun: orphan an skb on tx · 0110d6f2
      Michael S. Tsirkin authored
      The following situation was observed in the field:
      tap1 sends packets, tap2 does not consume them, as a result
      tap1 can not be closed. This happens because
      tun/tap devices can hang on to skbs undefinitely.
      
      As noted by Herbert, possible solutions include a timeout followed by a
      copy/change of ownership of the skb, or always copying/changing
      ownership if we're going into a hostile device.
      
      This patch implements the second approach.
      
      Note: one issue still remaining is that since skbs
      keep reference to tun socket and tun socket has a
      reference to tun device, we won't flush backlog,
      instead simply waiting for all skbs to get transmitted.
      At least this is not user-triggerable, and
      this was not reported in practice, my assumption is
      other devices besides tap complete an skb
      within finite time after it has been queued.
      
      A possible solution for the second issue
      would not to have socket reference the device,
      instead, implement dev->destructor for tun, and
      wait for all skbs to complete there, but this
      needs some thought, probably too risky for 2.6.34.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarYan Vugenfirer <yvugenfi@redhat.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0110d6f2
    • Giuseppe CAVALLARO's avatar
    • Giuseppe CAVALLARO's avatar
      stmmac: fix vlan support setup · 8f617541
      Giuseppe CAVALLARO authored
      Moved STMMAC_VLAN_TAG_USED from stmmac.h to common.h header
      because it is used within the device and descriptor cores.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f617541
    • Giuseppe CAVALLARO's avatar
      stmmac: get the descriptor structure from platform · 3d90c508
      Giuseppe CAVALLARO authored
      Output for chip that uses the Enhanced descriptors:
      [snip]
      STMMAC driver:
      	platform registration... done!
      	DWMAC1000 - user ID: 0x10, Synopsys ID: 0x33
      	Enhanced descriptor structure
      	no valid MAC address;please, use ifconfig or nwhwconfig!
      	eth0 - (dev. name: stmmaceth - id: 0, IRQ #134
      	IO base addr: 0xfd110000)
      STMMAC MII Bus: probed
      [snip]
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d90c508
    • Giuseppe CAVALLARO's avatar
      stmmac: new descriptor field for the driver's platform · e326e850
      Giuseppe CAVALLARO authored
      The new enh_desc is used for selecting the enhanced descriptors
      structure. There are several scenarios; some chips (mac10/100
      or gmac) want to use the enhanced descriptors; others want the normal
      ones.
      For example, on ST platforms: MAC10/100 uses the normal desc structure
      and the GMAC uses the enhanced one.
      It can be useful to get this information from the platform.
      This could also be decided at run-time looking at the chip's ID number;
      but it could happen that chips with the same ID want to use different
      descriptor structure.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e326e850
    • Giuseppe CAVALLARO's avatar
      stmmac: fix Transmit FIFO flush operation · 688911c2
      Giuseppe CAVALLARO authored
      Fix the Transmit FIFO flush operation; it was
      disabled while reworking the descriptor structures.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      688911c2
    • Giuseppe CAVALLARO's avatar
      stmmac: rework normal and enhanced descriptors · 56b106ae
      Giuseppe CAVALLARO authored
      Currently the driver assumes that the mac10/100 can only use the
      normal descriptor structure and the gmac can only use the
      enhanced structures.
      This patch removes the descriptor's code from the dma files
      and adds two new files just for handling the normal and enhanced
      descriptors.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56b106ae
    • Giuseppe CAVALLARO's avatar
      stmmac: split core and dma for the mac10/100 · 3c32be63
      Giuseppe CAVALLARO authored
      The patch splits core and dma parts for the mac10/100 device.
      This was already done for the GMAC device.
      It should make more flexible the driver to support other chips.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c32be63
    • Christoph Hellwig's avatar
      vhost: fix sparse warnings · a8d3782f
      Christoph Hellwig authored
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      a8d3782f
    • Ayaz Abdulla's avatar
      forcedeth: fix tx limit2 flag check · 5c659322
      Ayaz Abdulla authored
      This is a fix for bug 572201 @ bugs.debian.org
      
      This patch fixes the TX_LIMIT feature flag. The previous logic check
      for TX_LIMIT2 also took into account a device that only had TX_LIMIT
      set.
      Reported-by: default avatarStephen Mulcahu <stephen.mulcahy@deri.org>
      Reported-by: default avatarBen Huchings <ben@decadent.org.uk>
      Signed-off-by: default avatarAyaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      
      
      5c659322
  4. 13 Apr, 2010 5 commits