1. 18 4月, 2013 13 次提交
  2. 17 4月, 2013 16 次提交
  3. 16 4月, 2013 11 次提交
    • O
      can: sja1000: use common prefix for all sja1000 defines · 06e1d1d7
      Oliver Hartkopp 提交于
      This is a follow up patch to:
      
          f901b6bc can: sja1000: fix define conflict on SH
      
      That patch fixed a define conflict between the SH architecture and the sja1000
      driver, by addind a prefix to one macro only. This patch consistently renames
      the prefix of the SJA1000 controller registers from "REG_" to "SJA1000_".
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      06e1d1d7
    • P
      openvswitch: Use generic struct pcpu_tstats. · e0f0ecf3
      Pravin B Shelar 提交于
      Rather than defining ovs specific stats struct (vport_percpu_stats),
      we can use existing pcpu_tstats to achieve exactly same functionality.
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      e0f0ecf3
    • P
      openvswitch: Simplify datapath locking. · 8e4e1713
      Pravin B Shelar 提交于
      Currently OVS uses combination of genl and rtnl lock to protect
      datapath state.  This was done due to networking stack locking.
      But this has complicated locking and there are few lock ordering
      issues with new tunneling protocols.
      Following patch simplifies locking by introducing new ovs mutex
      and now this lock is used to protect entire ovs state.
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      8e4e1713
    • D
      Merge branch 'sync_multiple' · 61f47132
      David S. Miller 提交于
      Vlad Yasevich says:
      
      ====================
      Current dev_[uc|mc]_addr_sync() API currently correctly syncs the
      addresses to the first device.  Any subsequent calls to sync will
      not do anything since the synched variable will be set.  This
      variable is used as an optimization to skip over addresses that have
      been synched.
      
      There are some devices (ex: team) that attempt to do the above.  There
      is other work in progress that needs to above to work corretly.
      
      The short series introduces dev_[uc|mc]_addr_synch_multiple() that
      allows multiple calls to sync to multiple different devices.  Original
      API is left alone and still has the limitation.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61f47132
    • V
      team: Use new sync_multiple api to sync devices adressess. · 72b27032
      Vlad Yasevich 提交于
      Team drivers attempts to sync addresses to each of the port
      devices; however, the current api doesn't really perform the sync
      for any device after the first one.  Switch to using the new api
      that will actually sync the addresses to all ports.
      
      CC: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72b27032
    • V
      net: add dev_uc_sync_multiple() and dev_mc_sync_multiple() api · 4cd729b0
      Vlad Yasevich 提交于
      The current implementation of dev_uc_sync/unsync() assumes that there is
      a strict 1-to-1 relationship between the source and destination of the sync.
      In other words, once an address has been synced to a destination device, it
      will not be synced to any other device through the sync API.
      However, there are some virtual devices that aggreate a number of lower
      devices and need to sync addresses to all of them.  The current
      API falls short there.
      
      This patch introduces a new dev_uc_sync_multiple() api that can be called
      in the above circumstances and allows sync to work for every invocation.
      
      CC: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cd729b0
    • D
      net: sctp: minor: make sctp_ep_common's member 'dead' a bool · 0022d2dd
      Daniel Borkmann 提交于
      Since dead only holds two states (0,1), make it a bool instead
      of a 'char', which is more appropriate for its purpose.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0022d2dd
    • D
      net: sctp: remove sctp_ep_common struct member 'malloced' · ff2266cd
      Daniel Borkmann 提交于
      There is actually no need to keep this member in the structure, because
      after init it's always 1 anyway, thus always kfree called. This seems to
      be an ancient leftover from the very initial implementation from 2.5
      times. Only in case the initialization of an association fails, we leave
      base.malloced as 0, but we nevertheless kfree it in the error path in
      sctp_association_new().
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff2266cd
    • D
      sis900: check for DMA map errors · 1e8edc2a
      Denis Kirjanov 提交于
      The first backtrace appears on tx path with DMA mapping operations debug
      enabled.
      
      [  345.637919] ------------[ cut here ]------------
      [  345.637971] WARNING: at lib/dma-debug.c:937 check_unmap+0x4df/0x910()
      [  345.637977] Hardware name: System Name
      [  345.637987] sis900 0000:00:01.1: DMA-API: device driver failed to check map error[device address=0x000000000d4aed02] [si
      ze=60 bytes] [mapped as single]
      [  345.637993] Modules linked in: bridge stp llc dmfe sundance 3c59x sis900
      [  345.638022] Pid: 0, comm: swapper Not tainted 3.9.0-rc6+ #4
      [  345.638028] Call Trace:
      [  345.638042]  [<c122097f>] ? check_unmap+0x4df/0x910
      [  345.638059]  [<c102b19c>] warn_slowpath_common+0x7c/0xa0
      [  345.638070]  [<c122097f>] ? check_unmap+0x4df/0x910
      [  345.638081]  [<c102b23e>] warn_slowpath_fmt+0x2e/0x30
      [  345.638092]  [<c122097f>] check_unmap+0x4df/0x910
      [  345.638107]  [<c100bfeb>] ? save_stack_trace+0x2b/0x50
      [  345.638120]  [<c107238e>] ? mark_lock+0x31e/0x5d0
      [  345.638132]  [<c1072b2c>] ? __lock_acquire+0x4ec/0x7d0
      [  345.638143]  [<c1220f6d>] debug_dma_unmap_page+0x6d/0x80
      [  345.638166]  [<cf834dec>] sis900_interrupt+0x49c/0x860 [sis900]
      [  345.638195]  [<c1094b73>] handle_irq_event_percpu+0x43/0x1c0
      [  345.638206]  [<c1094d1e>] ? handle_irq_event+0x2e/0x60
      [  345.638217]  [<c1094d27>] handle_irq_event+0x37/0x60
      [  345.638235]  [<c10973f0>] ? irq_set_chip_data+0x40/0x40
      [  345.638246]  [<c1097442>] handle_level_irq+0x52/0xa0
      [  345.638251]  <IRQ>  [<c1003629>] ? do_IRQ+0x39/0xa0
      [  345.638293]  [<c1484631>] ? common_interrupt+0x31/0x36
      [  345.638347]  [<d08c2c52>] ? br_flood_forward+0x12/0x20 [bridge]
      [  345.638364]  [<d08c2d40>] ? br_dev_queue_push_xmit+0x60/0x60 [bridge]
      [  345.638381]  [<d08c3b2b>] ? br_handle_frame_finish+0x25b/0x280 [bridge]
      [  345.638399]  [<d08c3ce3>] ? br_handle_frame+0x193/0x290 [bridge]
      [  345.638416]  [<d08c3b50>] ? br_handle_frame_finish+0x280/0x280 [bridge]
      [  345.638431]  [<c13b3c87>] ? __netif_receive_skb_core+0x1d7/0x710
      [  345.638442]  [<c13b3b19>] ? __netif_receive_skb_core+0x69/0x710
      [  345.638454]  [<c13b41e1>] ? __netif_receive_skb+0x21/0x70
      [  345.638464]  [<c13b42b5>] ? process_backlog+0x85/0x130
      [  345.638476]  [<c13b4bbb>] ? net_rx_action+0xfb/0x1d0
      [  345.638497]  [<c1032768>] ? __do_softirq+0xa8/0x1f0
      [  345.638527]  [<c147daad>] ? _raw_spin_unlock+0x1d/0x20
      [  345.638538]  [<c10038c0>] ? handle_irq+0x20/0xd0
      [  345.638550]  [<c1032f27>] ? irq_exit+0x97/0xa0
      [  345.638560]  [<c1003632>] ? do_IRQ+0x42/0xa0
      [  345.638580]  [<c104d003>] ? hrtimer_start+0x23/0x30
      [  345.638580]  [<c1484631>] ? common_interrupt+0x31/0x36
      [  345.638580]  [<c1008703>] ? default_idle+0x33/0xc0
      [  345.638580]  [<c10086ac>] ? cpu_idle+0x4c/0x70
      [  345.638580]  [<c14787e0>] ? rest_init+0xa0/0xb0
      [  345.638580]  [<c1478740>] ? reciprocal_value+0x50/0x50
      [  345.638580]  [<c16b5bcf>] ? start_kernel+0x28f/0x320
      [  345.638580]  [<c16b54e0>] ? repair_env_string+0x60/0x60
      [  345.638580]  [<c16b5269>] ? i386_start_kernel+0x39/0xa0
      [  345.638580] ---[ end trace a244264b69b8a7ae ]---
      [  345.638580] Mapped at:
      [  345.638580]  [<c1221c65>] debug_dma_map_page+0x65/0x110
      [  345.638580]  [<cf8355a9>] sis900_start_xmit+0x129/0x210 [sis900]
      [  345.638580]  [<c13b2527>] dev_hard_start_xmit+0x1b7/0x530
      [  345.638580]  [<c13cc32e>] sch_direct_xmit+0x8e/0x280
      [  345.638580]  [<c13b4e39>] dev_queue_xmit+0x1a9/0x5b0
      Signed-off-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e8edc2a
    • N
      net/macb: fix error return code in macb_probe() · 72ca820b
      Nicolas Ferre 提交于
      Fix to return a negative error code from the error handling
      case instead of 0, as returned elsewhere in this function.
      
      Original-idea-by: <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72ca820b
    • M
      vxlan: don't bypass encapsulation for multi- and broadcasts · ab09a6d0
      Mike Rapoport 提交于
      The multicast and broadcast packets may have RTCF_LOCAL set in rt_flags
      and therefore will be sent out bypassing encapsulation. This breaks
      delivery of packets sent to the vxlan multicast group.
      Disabling encapsulation bypass for multicasts and broadcasts fixes the
      issue.
      Signed-off-by: NMike Rapoport <mike.rapoport@ravellosystems.com>
      Tested-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NSridhar Samudrala <sri@us.ibm.com>
      Tested-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab09a6d0