1. 30 Jun, 2015 3 commits
  2. 29 Jun, 2015 17 commits
    • Nik Nyby's avatar
      net: icplus: fix typo in constant name · 1625fecf
      Nik Nyby authored
      This fixes a typo in the IPG_FRAMETOOLONGERRORS constant.
      Signed-off-by: default avatarNik Nyby <nikolas@gnu.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1625fecf
    • Nik Nyby's avatar
      sis900: Trivial: Fix typos in enums · 47af6b0c
      Nik Nyby authored
      "reigster" -> "register"
      Signed-off-by: default avatarNik Nyby <nikolas@gnu.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47af6b0c
    • Nik Nyby's avatar
      stmmac: Trivial: fix typo in constant name · 55d91614
      Nik Nyby authored
      This fixes a typo in the MMC_RX_CRC_ERROR constant.
      Signed-off-by: default avatarNik Nyby <nikolas@gnu.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55d91614
    • Alexander Sverdlin's avatar
      sctp: Fix race between OOTB responce and route removal · 29c4afc4
      Alexander Sverdlin authored
      There is NULL pointer dereference possible during statistics update if the route
      used for OOTB responce is removed at unfortunate time. If the route exists when
      we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
      ABORT, but in the meantime route is removed under our feet, we take "no_route"
      path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).
      
      But sctp_ootb_pkt_new() used to prepare responce packet doesn't call
      sctp_transport_set_owner() and therefore there is no asoc associated with this
      packet. Probably temporary asoc just for OOTB responces is overkill, so just
      introduce a check like in all other places in sctp_packet_transmit(), where
      "asoc" is dereferenced.
      
      To reproduce this, one needs to
      0. ensure that sctp module is loaded (otherwise ABORT is not generated)
      1. remove default route on the machine
      2. while true; do
           ip route del [interface-specific route]
           ip route add [interface-specific route]
         done
      3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT
         responce
      
      On x86_64 the crash looks like this:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
      IP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
      PGD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: ...
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.0.5-1-ARCH #1
      Hardware name: ...
      task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000
      RIP: 0010:[<ffffffffa05ec9ac>]  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
      RSP: 0018:ffff880127c037b8  EFLAGS: 00010296
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480
      RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700
      RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af
      R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28
      R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0
      FS:  0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0
      Stack:
       ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400
       ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520
       0000000000000000 0000000000000001 0000000000000000 0000000000000000
      Call Trace:
       <IRQ>
       [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]
       [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]
       [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]
       [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210
       [<ffffffff810e0329>] ? update_process_times+0x59/0x60
       [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0
       [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0
       [<ffffffff8101f599>] ? read_tsc+0x9/0x10
       [<ffffffff8116d4b5>] ? put_page+0x55/0x60
       [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100
       [<ffffffff81462b68>] ? skb_free_head+0x58/0x80
       [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]
       [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0
       [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]
       [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]
       [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]
       [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]
       [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]
       [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30
       [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150
       [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210
       [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90
       [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370
       [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0
       [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50
       [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60
       [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0
       [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120
       [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]
       [<ffffffff8147896a>] net_rx_action+0x21a/0x360
       [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0
       [<ffffffff8107912d>] irq_exit+0xad/0xb0
       [<ffffffff8157d158>] do_IRQ+0x58/0xf0
       [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d
       <EOI>
       [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20
       [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]
       [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0
       [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20
       [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480
       [<ffffffff8156b365>] rest_init+0x85/0x90
       [<ffffffff818eb035>] start_kernel+0x48b/0x4ac
       [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120
       [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c
       [<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184
      Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9
      RIP  [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
       RSP <ffff880127c037b8>
      CR2: 0000000000000020
      ---[ end trace 5aec7fd2dc983574 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
      drm_kms_helper: panic occurred, switching back to text console
      ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29c4afc4
    • Markus Elfring's avatar
      net-Liquidio: Delete unnecessary checks before the function call "vfree" · 9686f310
      Markus Elfring authored
      The vfree() function performs also input parameter validation.
      Thus the test around the call is not needed.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9686f310
    • Shreyas Bhatewara's avatar
      vmxnet3: Bump up driver version number · a6947174
      Shreyas Bhatewara authored
      Bump up the driver version number to reflect the changes done to
      work with vmxnet3 adapter version 2
      Signed-off-by: default avatarShreyas N Bhatewara <sbhatewara@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6947174
    • Tom Lendacky's avatar
      amd-xgbe: Add the __GFP_NOWARN flag to Rx buffer allocation · 472cfe71
      Tom Lendacky authored
      When allocating Rx related buffers, alloc_pages is called using an order
      number that is decreased until successful. A system under stress can
      experience failures during this allocation process resulting in a warning
      being issued. This message can be of concern to end users even though the
      failure is not fatal. Since the failure is not fatal and can occur
      multiple times, the driver should include the __GFP_NOWARN flag to
      suppress the warning message from being issued.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      472cfe71
    • David S. Miller's avatar
      Merge branch 'bcm7xxx_workaround' · 7c80c3af
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: phy: bcm7xxx initial read/write workaround
      
      This patch series fixes occasional BCM7xxx PHY driver binding failure due
      to a harware bug where the first read or write does not come out of the PHY
      MDIO management controller.
      
      Since we have two different MDIO controllers using this PHY, a similar
      need to be replicated in GENET and UniMAC MDIO.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c80c3af
    • Florian Fainelli's avatar
      net: phy: mdio-bcm-unimac: workaround initial read failures for integrated PHYs · d8e704e4
      Florian Fainelli authored
      All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
      management controller which will make the initial read or write to them
      to fail and return 0xffff. This is a real issue as the typical first
      thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
      to register a driver for these PHYs.
      
      Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
      workaround for the MDIO bus controller consists in scanning the list of
      PHYs to do this initial read workaround for as part of the MDIO bus
      reset routine which is invoked prior to mdiobus_scan().
      
      Once we have a proper PHY driver/device registered, all workarounds are
      located there (e.g: power management suspend/resume calls).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8e704e4
    • Florian Fainelli's avatar
      net: bcmgenet: workaround initial read failures for integrated PHYs · 7b635da8
      Florian Fainelli authored
      All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
      management controller which will make the initial read or write to them
      to fail and return 0xffff. This is a real issue as the typical first
      thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
      to register a driver for these PHYs.
      
      Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
      workaround for the MDIO bus controller consists in scanning the list of
      PHYs to do this initial read workaround for as part of the MDIO bus
      reset routine which is invoked prior to mdiobus_scan().
      
      Once we have a proper PHY driver/device registered, all workarounds are
      located there (e.g: power management suspend/resume calls).
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b635da8
    • Florian Fainelli's avatar
      net: phy: bcm7xxx: workaround MDIO management controller initial read · 8e346e15
      Florian Fainelli authored
      The initial MDIO read or write towards the BCM7xxx integrated PHY may
      fail, workaround this by inserting a dummy MII_BMSR read to force the
      MDIO management controller to see at least one valid transaction and get
      out of stuck state out of reset.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e346e15
    • Michal Schmidt's avatar
      bnx2x: fix DMA API usage · 8031612d
      Michal Schmidt authored
      With CONFIG_DMA_API_DEBUG=y bnx2x triggers the error "DMA-API: device
      driver frees DMA memory with wrong function".
      On archs where PAGE_SIZE > SGE_PAGE_SIZE it also triggers "DMA-API:
      device driver frees DMA memory with different size".
      
      Fix this by making the mapping and unmapping symmetric:
       - Do not map the whole pool page at once. Instead map the
         SGE_PAGE_SIZE-sized pieces individually, so they can be unmapped in
         the same manner.
       - What's mapped using dma_map_page() must be unmapped using
         dma_unmap_page().
      
      Tested on ppc64.
      
      Fixes: 4cace675 ("bnx2x: Alloc 4k fragment for each rx ring buffer element")
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8031612d
    • Geert Uytterhoeven's avatar
      net: via: VIA_RHINE and VIA_VELOCITY should depend on HAS_DMA · 0f8b6cea
      Geert Uytterhoeven authored
      If NO_DMA=y:
      
          ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_set_mask" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/via/via-rhine.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/via/via-velocity.ko] undefined!
          ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/via/via-velocity.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/via/via-velocity.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/via/via-velocity.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/via/via-velocity.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/via/via-velocity.ko] undefined!
      
      Before, the symbols depended implicitly on HAS_DMA through PCI or
      USE_OF.  Add explicit dependencies on HAS_DMA to fix this.
      
      Fixes: b7d3282a ("net: via/Kconfig: replace USE_OF with OF_???")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f8b6cea
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · ebc03239
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2015-06-26
      
      This series contains fixes for igb, e1000e and i40evf.
      
      Todd disables IPv6 extension header processing due to a hardware errata
      and bumps the driver version.
      
      Yanir provides six fixes for e1000e.  First is a fix for a locking issue
      where we were not always taking the pci_bus_sem semaphore all the time
      when calling pci_disable_link_state_locked(), so fix the code to only call
      pci_disable_link_state_locked() when the semaphore has been acquired,
      otherwise call pci_disable_link_state().  A previous fix for i219 where
      the hardware prevented ULP entry caused EEE in Sx not the be enabled, so
      modify the code flow that allows both ULP and EEE in Sx.  Fix an issue
      when running 10/100 full duplex on i219 where CRC errors were occurring
      by increasing the IPG from 8 to 0xC as per the hardware developers.
      Fix a data corruption issue found on some platforms by increasing the
      minimum gap between the PHY FIFO read and write pointers.  Fix i219,
      which does not require the K1 workaround for LPT devices.
      
      Mitch provides a i40evf fix for a panic when changing MTU.  Down was
      requesting queue disables, but then exited immediately without waiting
      for the queues to actually be disabled.  This could allow any function
      called after i40evf_down() to run immediately, including i40evf_up(),
      and causes a memory leak.  Fixed the issue by removing the whole
      reinit_locked function which allows for the driver to handle the state
      changes by requesting reset from the periodic timer.  The second fix
      resolves an issue where RSS was being configured as though it is using
      the maximum number of queue.  This can cause the device to drop a lot
      of receive traffic, as the packets get assigned to non-functional queues.
      This is resolved by only configuring RSS with the number of active queues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebc03239
    • Shengzhou Liu's avatar
      net/phy: tune get_phy_c45_ids to support more c45 phy · da1da284
      Shengzhou Liu authored
      As some C45 10G PHYs(e.g. Cortina CS4315/CS4340 PHY) have
      zero Devices In package, current driver can't get correct
      devices_in_package value by non-zero Devices In package.
      so let's probe more with zero Devices In package to support
      more C45 PHYs.
      Signed-off-by: default avatarShengzhou Liu <Shengzhou.Liu@freescale.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da1da284
    • Eric Dumazet's avatar
      bnx2x: fix lockdep splat · d53c66a5
      Eric Dumazet authored
      Michel reported following lockdep splat
      
      [   44.718117] INFO: trying to register non-static key.
      [   44.723081] the code is fine but needs lockdep annotation.
      [   44.728559] turning off the locking correctness validator.
      [   44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0
      [   44.770289] Call Trace:
      [   44.772741]  [<ffffffff816eb1cd>] dump_stack+0x4c/0x65
      [   44.777879]  [<ffffffff8111d921>] ? console_unlock+0x1f1/0x510
      [   44.783708]  [<ffffffff811121f5>] __lock_acquire+0x1d05/0x1f10
      [   44.789538]  [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90
      [   44.795276]  [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   44.801967]  [<ffffffff8111390d>] ? trace_hardirqs_on+0xd/0x10
      [   44.807793]  [<ffffffff811330fa>] ? hrtimer_try_to_cancel+0x4a/0x250
      [   44.814142]  [<ffffffff81112ba6>] lock_acquire+0xb6/0x290
      [   44.819537]  [<ffffffff810d6675>] ? flush_work+0x5/0x280
      [   44.824844]  [<ffffffff810d66ad>] flush_work+0x3d/0x280
      [   44.830061]  [<ffffffff810d6675>] ? flush_work+0x5/0x280
      [   44.835366]  [<ffffffff816f3c43>] ? schedule_hrtimeout_range+0x13/0x20
      [   44.841889]  [<ffffffff8112ec9b>] ? usleep_range+0x4b/0x50
      [   44.847365]  [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90
      [   44.853102]  [<ffffffff810d8585>] ? __cancel_work_timer+0x105/0x1c0
      [   44.859359]  [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   44.866045]  [<ffffffff810d851f>] __cancel_work_timer+0x9f/0x1c0
      [   44.872048]  [<ffffffffa0010982>] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
      [   44.878481]  [<ffffffff810d8670>] cancel_work_sync+0x10/0x20
      [   44.884134]  [<ffffffffa00259e5>] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
      [   44.890829]  [<ffffffff8110ce02>] ? up+0x32/0x50
      [   44.895439]  [<ffffffff811306b5>] ? del_timer_sync+0x5/0xd0
      [   44.901005]  [<ffffffffa005596d>] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
      [   44.907527]  [<ffffffff811f1aef>] ? might_fault+0x5f/0xb0
      [   44.912921]  [<ffffffffa005851c>] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
      [   44.919879]  [<ffffffffa005a3c5>] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
      [   44.926664]  [<ffffffff815d498b>] dev_ethtool+0x55b/0x1c40
      [   44.932148]  [<ffffffff815dfdc7>] ? rtnl_lock+0x17/0x20
      [   44.937364]  [<ffffffff815e7f8b>] dev_ioctl+0x17b/0x630
      [   44.942582]  [<ffffffff815abf8d>] sock_do_ioctl+0x5d/0x70
      [   44.947972]  [<ffffffff815ac013>] sock_ioctl+0x73/0x280
      [   44.953192]  [<ffffffff8124c1c8>] do_vfs_ioctl+0x88/0x5b0
      [   44.958587]  [<ffffffff8110d0b3>] ? up_read+0x23/0x40
      [   44.963631]  [<ffffffff812584cc>] ? __fget_light+0x6c/0xa0
      [   44.969105]  [<ffffffff8124c781>] SyS_ioctl+0x91/0xb0
      [   44.974149]  [<ffffffff816f4dd7>] system_call_fastpath+0x12/0x6f
      
      As bnx2x_init_ptp() is only called if bp->flags contains PTP_SUPPORTED,
      we also need to guard bnx2x_stop_ptp() with same condition, otherwise
      ptp_task workqueue is not initialized and kernel barfs on
      cancel_work_sync()
      
      Fixes: eeed018c ("bnx2x: Add timestamping and PTP hardware clock support")
      Reported-by: default avatarMichel Lespinasse <walken@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Michal Kalderon <Michal.Kalderon@qlogic.com>
      Cc: Ariel Elior <Ariel.Elior@qlogic.com>
      Cc: Yuval Mintz <Yuval.Mintz@qlogic.com>
      Cc: David Decotigny <decot@google.com>
      Acked-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d53c66a5
    • Greg Ungerer's avatar
      net: fec: don't access RACC register when not available · 18803495
      Greg Ungerer authored
      Not all silicon implementations of the Freescale FEC hardware module
      have the RACC (Receive Accelerator Function) register, so we should not
      be trying to access it on those that don't. Currently none of the ColdFire
      based parts with a FEC have it.
      
      Support for RACC was introduced by commit 4c09eed9 ("net: fec: Enable imx6
      enet checksum acceleration"). A fix was introduced in commit d1391930
      ("net: fec: Fix build for MCF5272") that disables its use on the ColdFire
      M5272 part, but it doesn't fix the general case of other ColdFire parts.
      
      To fix we create a quirk flag, FEC_QUIRK_HAS_RACC, and check it before
      working with the RACC register.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18803495
  3. 28 Jun, 2015 10 commits
  4. 26 Jun, 2015 10 commits