1. 19 Apr, 2013 2 commits
  2. 18 Apr, 2013 7 commits
  3. 17 Apr, 2013 1 commit
  4. 16 Apr, 2013 1 commit
  5. 15 Apr, 2013 2 commits
  6. 13 Apr, 2013 1 commit
    • Thomas Petazzoni's avatar
      net: mvmdio: add select PHYLIB · 2e0cbf2c
      Thomas Petazzoni authored
      
      
      The mvmdio driver uses the phylib API, so it should select the PHYLIB
      symbol, otherwise, a build with mvmdio (but without mvneta) fails to
      build with undefined symbols such as mdiobus_unregister, mdiobus_free,
      etc.
      
      The mvneta driver does not use the phylib API directly, so it does not
      need to select PHYLIB. It already selects the mvmdio driver anyway.
      
      Historically, this problem is due to the fact that the PHY handling
      was originally part of mvneta, and was later moved to a separate
      driver, without updating the Kconfig select statements
      accordingly. And since there was no functional reason to use mvmdio
      without mvneta, this case was not tested.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e0cbf2c
  7. 12 Apr, 2013 1 commit
  8. 11 Apr, 2013 1 commit
  9. 10 Apr, 2013 2 commits
    • Yuval Mintz's avatar
      bnx2x: Prevent null pointer dereference in AFEX mode · fea75645
      Yuval Mintz authored
      
      
      The cnic module is responsible for initializing various bnx2x structs
      via callbacks provided by the bnx2x module.
      One such struct is the queue object for the FCoE queue.
      
      If a device is working in AFEX mode and its configuration allows FCoE yet
      the cnic module is not loaded, it's very likely a null pointer dereference
      will occur, as the bnx2x will erroneously access the FCoE's queue object.
      
      Prevent said access until cnic properly registers itself.
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fea75645
    • Neil Horman's avatar
      e100: Add dma mapping error check · 61a0f6ef
      Neil Horman authored
      e100 uses pci_map_single, but fails to check for a dma mapping error after its
      use, resulting in a stack trace:
      
      [   46.656594] ------------[ cut here ]------------
      [   46.657004] WARNING: at lib/dma-debug.c:933 check_unmap+0x47b/0x950()
      [   46.657004] Hardware name: To Be Filled By O.E.M.
      [   46.657004] e100 0000:00:0e.0: DMA-API: device driver failed to check map
      error[device address=0x000000007a4540fa] [size=90 bytes] [mapped as single]
      [   46.657004] Modules linked in:
      [   46.657004]  w83627hf hwmon_vid snd_via82xx ppdev snd_ac97_codec ac97_bus
      snd_seq snd_pcm snd_mpu401 snd_mpu401_uart ns558 snd_rawmidi gameport parport_pc
      e100 snd_seq_device parport snd_page_alloc snd_timer snd soundcore skge shpchp
      k8temp mii edac_core i2c_viapro edac_mce_amd nfsd auth_rpcgss nfs_acl lockd
      sunrpc binfmt_misc uinput ata_generic pata_acpi radeon i2c_algo_bit
      drm_kms_helper ttm firewire_ohci drm firewire_core pata_via sata_via i2c_core
      sata_promise crc_itu_t
      [   46.657004] Pid: 792, comm: ip Not tainted 3.8.0-0.rc6.git0.1.fc19.x86_64 #1
      [   46.657004] Call Trace:
      [   46.657004]  <IRQ>  [<ffffffff81065ed0>] warn_slowpath_common+0x70/0xa0
      [   46.657004]  [<ffffffff81065f4c>] warn_slowpath_fmt+0x4c/0x50
      [   46.657004]  [<ffffffff81364cfb>] check_unmap+0x47b/0x950
      [   46.657004]  [<ffffffff8136522f>] debug_dma_unmap_page+0x5f/0x70
      [   46.657004]  [<ffffffffa030f0f0>] ? e100_tx_clean+0x30/0x210 [e100]
      [   46.657004]  [<ffffffffa030f1a8>] e100_tx_clean+0xe8/0x210 [e100]
      [   46.657004]  [<ffffffffa030fc6f>] e100_poll+0x56f/0x6c0 [e100]
      [   46.657004]  [<ffffffff8159dce1>] ? net_rx_action+0xa1/0x370
      [   46.657004]  [<ffffffff8159ddb2>] net_rx_action+0x172/0x370
      [   46.657004]  [<ffffffff810703bf>] __do_softirq+0xef/0x3d0
      [   46.657004]  [<ffffffff816e4ebc>] call_softirq+0x1c/0x30
      [   46.657004]  [<ffffffff8101c485>] do_softirq+0x85/0xc0
      [   46.657004]  [<ffffffff81070885>] irq_exit+0xd5/0xe0
      [   46.657004]  [<ffffffff816e5756>] do_IRQ+0x56/0xc0
      [   46.657004]  [<ffffffff816dacb2>] common_interrupt+0x72/0x72
      [   46.657004]  <EOI>  [<ffffffff816da1eb>] ?
      _raw_spin_unlock_irqrestore+0x3b/0x70
      [   46.657004]  [<ffffffff816d124d>] __slab_free+0x58/0x38b
      [   46.657004]  [<ffffffff81214424>] ? fsnotify_clear_marks_by_inode+0x34/0x120
      [   46.657004]  [<ffffffff811b0417>] ? kmem_cache_free+0x97/0x320
      [   46.657004]  [<ffffffff8157fc14>] ? sock_destroy_inode+0x34/0x40
      [   46.657004]  [<ffffffff8157fc14>] ? sock_destroy_inode+0x34/0x40
      [   46.657004]  [<ffffffff811b0692>] kmem_cache_free+0x312/0x320
      [   46.657004]  [<ffffffff8157fc14>] sock_destroy_inode+0x34/0x40
      [   46.657004]  [<ffffffff811e8c28>] destroy_inode+0x38/0x60
      [   46.657004]  [<ffffffff811e8d5e>] evict+0x10e/0x1a0
      [   46.657004]  [<ffffffff811e9605>] iput+0xf5/0x180
      [   46.657004]  [<ffffffff811e4338>] dput+0x248/0x310
      [   46.657004]  [<ffffffff811ce0e1>] __fput+0x171/0x240
      [   46.657004]  [<ffffffff811ce26e>] ____fput+0xe/0x10
      [   46.657004]  [<ffffffff8108d54c>] task_work_run+0xac/0xe0
      [   46.657004]  [<ffffffff8106c6ed>] do_exit+0x26d/0xc30
      [   46.657004]  [<ffffffff8109eccc>] ? finish_task_switch+0x7c/0x120
      [   46.657004]  [<ffffffff816dad58>] ? retint_swapgs+0x13/0x1b
      [   46.657004]  [<ffffffff8106d139>] do_group_exit+0x49/0xc0
      [   46.657004]  [<ffffffff8106d1c4>] sys_exit_group+0x14/0x20
      [   46.657004]  [<ffffffff816e3b19>] system_call_fastpath+0x16/0x1b
      [   46.657004] ---[ end trace 4468c44e2156e7d1 ]---
      [   46.657004] Mapped at:
      [   46.657004]  [<ffffffff813663d1>] debug_dma_map_page+0x91/0x140
      [   46.657004]  [<ffffffffa030e8eb>] e100_xmit_prepare+0x12b/0x1c0 [e100]
      [   46.657004]  [<ffffffffa030c924>] e100_exec_cb+0x84/0x140 [e100]
      [   46.657004]  [<ffffffffa030e56a>] e100_xmit_frame+0x3a/0x190 [e100]
      [   46.657004]  [<ffffffff8159ee89>] dev_hard_start_xmit+0x259/0x6c0
      
      Easy fix, modify the cb paramter to e100_exec_cb to return an error, and do the
      dma_mapping_error check in the obvious place
      
      This was reported previously here:
      http://article.gmane.org/gmane.linux.network/257893
      
      
      
      But nobody stepped up and fixed it.
      
      CC: Josh Boyer <jwboyer@redhat.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarMichal Jaegermann <michal@harddata.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61a0f6ef
  10. 08 Apr, 2013 1 commit
  11. 07 Apr, 2013 1 commit
  12. 05 Apr, 2013 2 commits
  13. 04 Apr, 2013 1 commit
  14. 02 Apr, 2013 1 commit
  15. 31 Mar, 2013 4 commits
    • Joseph CHANG's avatar
      DM9000B: driver initialization upgrade · 6741f40d
      Joseph CHANG authored
      
      
      Fix bug for DM9000 revision B which contain a DSP PHY
      
      DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY,
      So need extra change in initialization, For
      explicity PHY Reset and PHY init parameter, and
      first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe().
      
      Following DM9000_NCR reset cause by dm9000_open() clear the
      NCR_MAC_LBK bit.
      
      Without this fix, Power-up FIFO pointers error happen around 2%
      rate among Davicom's customers' boards. With this fix, All above
      cases can be solved.
      Signed-off-by: default avatarJoseph CHANG <josright123@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6741f40d
    • Sergei Shtylyov's avatar
      sh_eth: make 'link' field of 'struct sh_eth_private' *int* · 3340d2aa
      Sergei Shtylyov authored
      
      
      The 'link' field of 'struct sh_eth_private' has type 'enum phy_state' while the
      'link' field of 'struct phy_device' is merely *int* (having values 0 and 1) and
      the former field gets assigned from the latter. Make the field match, getting
      rid of incorrectly used PHY_DOWN value in assignments/comparisons.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3340d2aa
    • Sergei Shtylyov's avatar
      sh_eth: workaround for spurious ECI interrupt · 3893b273
      Sergei Shtylyov authored
      
      
      At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its
      mask in EESIPR register. I can 100% reproduce it with the following scenario:
      target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device
      but doesn't get a proper reply and then succeeds with on-board SMC chip; then
      I login and try to bring up the SoC Ether device with 'ifconfig', and I get
      an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt
      mask in EESIPR register is all 0), if that interrupt is accompanied by a pending
      EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx()
      because sh_eth_ring_init() hasn't been called yet!
      
      The solution I worked out is the following: in sh_eth_interrupt(), mask the
      interrupt status from EESR register with the interrupt mask from EESIPR register
      in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit
      in this mask set because we always need to fully handle EESR.ECI interrupt in
      sh_eth_error() in order to quench it (as it doesn't get cleared by just writing
      1 to the this bit as all the other interrupts).
      
      While at it, remove unneeded initializer for 'intr_status' variable and give it
      *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: default avatarMax Filippov <max.filippov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3893b273
    • Sergei Shtylyov's avatar
      sh_eth: fix handling of no LINK signal · 1e1b812b
      Sergei Shtylyov authored
      
      
      The code handling the absent LINK signal (or the absent PSR register -- which
      reflects the state of this signal) is quite naive and has probably never really
      worked.  It's probably enough to say that this code is executed only on the LINK
      change interrupt (sic!) but even if we actually have the signal and choose to
      ignore it (it might be connected to PHY's link/activity LED output as on the
      Renesas BOCK-W board), sh_eth_adjust_link() on which this code relies to update
      'mdp->link' gets executed later than the LINK change interrupt where it is
      checked, and so RX/TX never get enabled via ECMR register.
      
      So, ignore the LINK changed interrupt iff LINK signal is absent (or just chosen
      not to be used) or PSR register is absent, and enable/disable RX/TX directly in
      sh_eth_adjust_link() in this case.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e1b812b
  16. 29 Mar, 2013 6 commits
  17. 27 Mar, 2013 6 commits