1. 25 2月, 2015 1 次提交
  2. 20 1月, 2015 1 次提交
  3. 14 1月, 2015 1 次提交
  4. 20 10月, 2014 1 次提交
  5. 01 9月, 2014 1 次提交
  6. 13 8月, 2014 1 次提交
  7. 13 6月, 2014 1 次提交
  8. 06 5月, 2014 1 次提交
    • A
      net: via-rhine: Convert #ifdef USE_MMIO to a runtime flag · 5b579e21
      Alexey Charkov 提交于
      This introduces another flag in 'quirks' to replace the preprocessor
      define (USE_MMIO) used to indicate whether the device needs a
      separate enable routine to operate in MMIO mode.
      
      All of the currently known platform Rhine cores operate in MMIO
      mode by default, and on PCI it is preferred over PIO for performance
      reasons. However, a comment in code suggests that some (?) early
      Rhine cores only work in PIO mode, so they should not be switched
      to MMIO.
      
      Enabling MMIO on PCI is still triggered by the same Kconfig option
      to avoid breaking user configs needlessly, but this can be changed
      going forward towards automatic runtime detection in case a list of
      PIO-only Rhine revisions can be compiled.
      
      This also fixes a couple of compiler warnings detected by Fengguang
      Wu's test bot (!USE_MMIO case):
      
         drivers/net/ethernet/via/via-rhine.c: In function 'rhine_init_one_pci':
         drivers/net/ethernet/via/via-rhine.c:1108:1: warning: label 'err_out_unmap' defined but not used [-Wunused-label]
          err_out_unmap:
          ^
         drivers/net/ethernet/via/via-rhine.c:1022:6: warning: unused variable 'i' [-Wunused-variable]
           int i, rc;
               ^
         drivers/net/ethernet/via/via-rhine.c:916:22: warning: 'quirks' may be used uninitialized in this function [-Wmaybe-uninitialized]
           phy_id = rp->quirks & rqIntPHY ? 1 : 0;
                               ^
         drivers/net/ethernet/via/via-rhine.c:1026:6: note: 'quirks' was declared here
           u32 quirks;
               ^
      Signed-off-by: NAlexey Charkov <alchark@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b579e21
  9. 03 5月, 2014 1 次提交
  10. 24 4月, 2014 3 次提交
  11. 25 3月, 2014 2 次提交
  12. 20 3月, 2014 1 次提交
  13. 19 3月, 2014 1 次提交
  14. 15 3月, 2014 1 次提交
  15. 16 1月, 2014 1 次提交
  16. 29 11月, 2013 1 次提交
  17. 06 11月, 2013 1 次提交
    • J
      net: Explicitly initialize u64_stats_sync structures for lockdep · 827da44c
      John Stultz 提交于
      In order to enable lockdep on seqcount/seqlock structures, we
      must explicitly initialize any locks.
      
      The u64_stats_sync structure, uses a seqcount, and thus we need
      to introduce a u64_stats_init() function and use it to initialize
      the structure.
      
      This unfortunately adds a lot of fairly trivial initialization code
      to a number of drivers. But the benefit of ensuring correctness makes
      this worth while.
      
      Because these changes are required for lockdep to be enabled, and the
      changes are quite trivial, I've not yet split this patch out into 30-some
      separate patches, as I figured it would be better to get the various
      maintainers thoughts on how to best merge this change along with
      the seqcount lockdep enablement.
      
      Feedback would be appreciated!
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Acked-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Roger Luethi <rl@hellgate.ch>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Wensong Zhang <wensong@linux-vs.org>
      Cc: netdev@vger.kernel.org
      Link: http://lkml.kernel.org/r/1381186321-4906-2-git-send-email-john.stultz@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      827da44c
  18. 24 10月, 2013 1 次提交
  19. 27 9月, 2013 1 次提交
  20. 15 8月, 2013 1 次提交
  21. 10 8月, 2013 1 次提交
  22. 20 7月, 2013 1 次提交
  23. 13 7月, 2013 1 次提交
    • N
      via-rhine: fix dma mapping errors · 9b4fe5fb
      Neil Horman 提交于
      this bug:
      https://bugzilla.redhat.com/show_bug.cgi?id=951695
      
      Reported a dma debug backtrace:
      
      WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
      Hardware name: To Be Filled By O.E.M.
      via-rhine 0000:00:12.0: DMA-API: device driver failed to check map error[device
      address=0x0000000075a837b2] [size=90 bytes] [mapped as single]
      Modules linked in: ip6_tables gspca_spca561 gspca_main videodev media
      snd_hda_codec_realtek snd_hda_intel i2c_viapro snd_hda_codec snd_hwdep snd_seq
      ppdev mperf via_rhine coretemp snd_pcm mii microcode snd_page_alloc snd_timer
      snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc
      parport shpchp ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm
      pata_via sata_via i2c_core uinput
      Pid: 295, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.1.fc20.x86_64 #1
      Call Trace:
       <IRQ>  [<ffffffff81068dd0>] warn_slowpath_common+0x70/0xa0
       [<ffffffff81068e4c>] warn_slowpath_fmt+0x4c/0x50
       [<ffffffff8137ec6d>] check_unmap+0x47d/0x930
       [<ffffffff810ace9f>] ? local_clock+0x5f/0x70
       [<ffffffff8137f17f>] debug_dma_unmap_page+0x5f/0x70
       [<ffffffffa0225edc>] ? rhine_ack_events.isra.14+0x3c/0x50 [via_rhine]
       [<ffffffffa02275f8>] rhine_napipoll+0x1d8/0xd80 [via_rhine]
       [<ffffffff815d3d51>] ? net_rx_action+0xa1/0x380
       [<ffffffff815d3e22>] net_rx_action+0x172/0x380
       [<ffffffff8107345f>] __do_softirq+0xff/0x400
       [<ffffffff81073925>] irq_exit+0xb5/0xc0
       [<ffffffff81724cd6>] do_IRQ+0x56/0xc0
       [<ffffffff81719ff2>] common_interrupt+0x72/0x72
       <EOI>  [<ffffffff8170ff57>] ? __slab_alloc+0x4c2/0x526
       [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
       [<ffffffff810d5807>] ? __lock_is_held+0x57/0x80
       [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
       [<ffffffff811bf1bf>] kmem_cache_alloc+0x2df/0x360
       [<ffffffff811992e0>] mmap_region+0x2b0/0x5a0
       [<ffffffff811998e6>] do_mmap_pgoff+0x316/0x3d0
       [<ffffffff81183ca0>] vm_mmap_pgoff+0x90/0xc0
       [<ffffffff81197d6c>] sys_mmap_pgoff+0x4c/0x190
       [<ffffffff81367d7e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8101eb42>] sys_mmap+0x22/0x30
       [<ffffffff81722fd9>] system_call_fastpath+0x16/0x1b
      
      Usual problem with the usual fix, add the appropriate calls to dma_mapping_error
      where appropriate
      
      Untested, as I don't have hardware, but its pretty straightforward
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Roger Luethi <rl@hellgate.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b4fe5fb
  24. 29 6月, 2013 1 次提交
  25. 20 6月, 2013 1 次提交
  26. 21 5月, 2013 3 次提交
  27. 20 4月, 2013 3 次提交
  28. 03 2月, 2013 1 次提交
  29. 29 1月, 2013 1 次提交
  30. 09 1月, 2013 1 次提交
  31. 08 12月, 2012 1 次提交
  32. 04 12月, 2012 2 次提交