1. 09 Jul, 2014 34 commits
  2. 08 Jul, 2014 6 commits
    • David S. Miller's avatar
      Merge branch 'bridge_batmanadv_exports' · 9274f9f8
      David S. Miller authored
      Linus Lüssing says:
      
      ====================
      bridge: multicast snooping exports #2
      
      Some people pointed out to me that it might be helpful to add stubs for
      the newly added multicast exports. That way e.g. batman-adv should continue
      to be compile and useable without having to have a kernel compiled
      with bridge code in the future. This is what the first patch is supposed
      to do.
      
      The second patch adds a third multicast export for the bridge which
      e.g. batman-adv is supposed to use, too, soon: Just like the bridge
      disables its multicast snooping activities if no querier is present,
      batman-adv needs to do the same if bridges are involved.
      
      These three exports should be the final ones needed to marry the bridge
      multicast snooping with the batman-adv multicast optimizations recently
      added for the 3.15 kernel, allowing to use these optimzations in common
      setups having a bridge on top of e.g. bat0, too. So far these bridged
      setups would fall back to simple flooding through the batman-adv mesh
      network for any multicast packet entering bat0.
      
      More information about the batman-adv multicast optimizations currently
      implemented can be found here:
      
      http://www.open-mesh.org/projects/batman-adv/wiki/Basic-multicast-optimizations
      
      The integration on the batman-adv side could afterwards look like this,
      for instance (now including the third export):
      
      http://git.open-mesh.org/batman-adv.git/commitdiff/61e4f6af4b7a21ed4040f2e711d50c778e5b6d93?hp=6ae4281474675fbca5bedcf768972a32db586eb6
      ====================
      9274f9f8
    • Linus Lüssing's avatar
      bridge: export knowledge about the presence of IGMP/MLD queriers · c34963e2
      Linus Lüssing authored
      With this patch other modules are able to ask the bridge whether an
      IGMP or MLD querier exists on the according, bridged link layer.
      
      Multicast snooping can only be performed if a valid, selected querier
      exists on a link.
      
      Just like the bridge only enables its multicast snooping if a querier
      exists, e.g. batman-adv too can only activate its multicast
      snooping in bridged scenarios if a querier is present.
      
      For instance this export avoids having to reimplement IGMP/MLD
      querier message snooping and parsing in e.g. batman-adv, when
      multicast optimizations for bridged scenarios are added in the
      future.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c34963e2
    • Linus Lüssing's avatar
      bridge: adding stubs for multicast exports · f941a6d9
      Linus Lüssing authored
      To make users (e.g. batman-adv soon) load- and runnable even if the
      bridge was compiled without snooping capabilities - or even if the
      kernel was compiled without any bridge code at all.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f941a6d9
    • Erik Hugne's avatar
      tipc: fix a memleak when sending data · 70452dcb
      Erik Hugne authored
      This fixes a regression bug caused by:
      067608e9 ("tipc: introduce direct
      iovec to buffer chain fragmentation function")
      
      If data is sent on a nonblocking socket and the destination link
      is congested, the buffer chain is leaked. We fix this by freeing
      the chain in this case.
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70452dcb
    • Maciej W. Rozycki's avatar
      defxx: Fix issues with debug printk calls · 51ba0ed1
      Maciej W. Rozycki authored
      This fixes issues with debug printk calls across the driver, normally
      disabled; first compilation errors:
      
      drivers/net/fddi/defxx.c:676:1: error: pasting "(" and ""In dfx_bus_init...\n"" does not give a valid preprocessing token
      drivers/net/fddi/defxx.c:820:1: error: pasting "(" and ""In dfx_bus_uninit...\n"" does not give a valid preprocessing token
      
      and so on, and then warnings:
      
      drivers/net/fddi/defxx.c: In function 'dfx_driver_init':
      drivers/net/fddi/defxx.c:1132: warning: format '%0X' expects type 'unsigned int', but argument 4 has type 'dma_addr_t'
      drivers/net/fddi/defxx.c:1132: warning: format '%0X' expects type 'unsigned int', but argument 4 has type 'dma_addr_t'
      
      etc.  Additionally casts are removed from virtual addresses and %p used.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51ba0ed1
    • David S. Miller's avatar
      Merge branch 'defxx-next' · 284a83a0
      David S. Miller authored
      Maciej W. Rozycki says:
      
      ====================
      defxx: Fixes for 64-bit host support
      
       This mini patch series addresses issues with 64-bit host support for FDDI
      interface boards supported by the defxx driver where DMA mapping
      synchronisation is required on swiotlb systems.  While PDQ, the DMA engine
      chip used with these boards, supports 48-bit addressing that would
      normally suffice for typical 64-bit systems in existence, the host bus
      interface chips used by individual implementations have their limitations
      as follows:
      
      * DEFTA or DEC FDDIcontroller/TURBOchannel -- there's no host bus
        interface chip, the PDQ connects to TURBOchannel directly; TURBOchannel
        supports DMA addressing of up to 16GB (34-bit addressing), however no
        TURBOchannel system has ever been made that supports more than 1GB of
        RAM, so in reality no remapping is ever required,
      
      * DEFEA or DEC FDDIcontroller/EISA -- the ESIC EISA interface chip only
        supports 32-bit addressing, all accesses beyond 4GB have to be remapped,
      
      * DEFPA or DEC FDDIcontroller/PCI -- the PFI PCI interface chip rev. 1 & 2
        only support 32-bit addressing, they have 32 AD lines only both on the
        PDQ and the PCI side, and consequently no Dual Address Cycle support, so
        all accesses beyond 4GB have to be remapped; the range of addressing
        supported by PFI rev. 3 is currently not certain, however the chip is
        backwards compatible with earlier revisions and will work with code that
        supports them.
      
      Some other issues discovered in the course of correcting 64-bit support
      have been fixed as well.  Each of the patches is functionally
      self-contained and can be applied independentely, although there may be
      mechanical dependencies making it necessary to apply patches in order.
      
       The driver suffers from non-standard formatting and while I did my best
      with these bug fixes to follow our coding style, I found some pieces
      hopeless, checkpatch.pl will complain.  I plan to reformat the whole
      driver, that will inevitably require factoring out some pieces into
      separate functions, but that's going to be a major effort and therefore I
      want to do this separately, with no functional changes made at the same
      time.  If anyone has specific suggestions as to how to reformat any of the
      pieces submitted here for a better layout, then I'll be happy to take them
      into account.
      
       And last but not least many thanks to Robert Coerver, who was the most
      recent person to report this problem with the driver and was kind enough
      to patiently try a few revisions of the driver update on his system as I
      was finding and addressing issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      284a83a0