1. 18 8月, 2011 1 次提交
  2. 07 7月, 2011 1 次提交
  3. 05 7月, 2011 1 次提交
  4. 07 6月, 2011 1 次提交
  5. 10 5月, 2011 1 次提交
  6. 31 3月, 2011 1 次提交
  7. 10 3月, 2011 1 次提交
  8. 04 2月, 2011 1 次提交
  9. 02 2月, 2011 1 次提交
  10. 26 1月, 2011 1 次提交
  11. 11 1月, 2011 1 次提交
  12. 09 11月, 2010 1 次提交
    • L
      libipw: fix proc entry removal · 269e2d77
      Linus Torvalds 提交于
      This bug seems to be due to commit 27ae60f8 ("ipw2x00: replace
      "ieee80211" with "libipw" where appropriate"), where Pavel did this:
      
      -       libipw_proc = proc_mkdir(DRV_NAME, init_net.proc_net);
      +       libipw_proc = proc_mkdir("ieee80211", init_net.proc_net);
      
      but then the cleanup was kept as
      
              remove_proc_entry(DRV_NAME, init_net.proc_net);
      
      in both places (both in the failure case and in the unload case). The
      error string is also total crap, and says
      
           "Unable to create " DRV_NAME " proc directory\n");
      
      Even though it doesn't actually create a proc directory named DRV_NAME at all.
      
      So that patch looks like total and utter crap to me. The commit message says
      
        "Keep /proc/net/ieee80211 under the original name to avoid breaking user
          interface."
      
      but the thing is, it really didn't fix anything but that one create
      thing. It needs to fix all the other cases too.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      269e2d77
  13. 06 11月, 2010 1 次提交
    • L
      ipw2x00: remove the right /proc/net entry · 151f52f0
      Linus Torvalds 提交于
      Commit 27ae60f8 ("ipw2x00: replace "ieee80211" with "libipw" where
      appropriate") changed DRV_NAME to be "libipw", but didn't properly fix
      up the places where it was used to specify the name for the /proc/net/
      directory.
      
      For backwards compatibility reasons, that directory name remained
      "ieee80211", but due to the DRV_NAME change, the error case printouts
      and the cleanup functions now used "libipw" instead.  Which made it all
      fail badly.
      
      For example, on module unload as reported by Randy:
      
        WARNING: at fs/proc/generic.c:816 remove_proc_entry+0x156/0x35e()
        name 'libipw'
      
      because it's trying to unregister a /proc directory that obviously
      doesn't even exist.
      
      Clean it all up to use DRV_PROCNAME for the actual /proc directory name.
      Reported-and-tested-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Pavel Roskin <proski@gnu.org>
      Cc: John W. Linville <linville@tuxdriver.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      151f52f0
  14. 06 10月, 2010 1 次提交
  15. 18 8月, 2010 2 次提交
    • J
      drivers/net: Convert unbounded kzalloc calls to kcalloc · baeb2ffa
      Joe Perches 提交于
      These changes may be slightly safer in some instances.
      
      There are other kzalloc calls with a multiply, but those
      calls are typically "small fixed #" * sizeof(some pointer)"
      and those are not converted.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Acked-by: NLuciano Coelho <luciano.coelho@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      baeb2ffa
    • J
      ipw2100: don't sync status queue entries · c206a04f
      John W. Linville 提交于
      These are allocated with pci_alloc_consistent, so calling
      pci_dma_sync_single_for_cpu is incorrect usage of the API.  Remove this
      misuse and consequently avoid the following backtrace:
      
      WARNING: at lib/dma-debug.c:902 check_sync+0xce/0x43a()
      Hardware name: 2373HU6
      ipw2100 0000:02:02.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000034e88008] [size=8 bytes]
      Modules linked in: microcode ipw2100(+) snd_seq_device ppdev libipw nsc_ircc snd_pcm lib80211 video output irda parport_pc cfg80211 parport thinkpad_acpi e1000 iTCO_wdt crc_ccitt snd_timer iTCO_vendor_support snd i2c_i801 pcspkr rfkill soundcore joydev snd_page_alloc yenta_socket radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
      Pid: 0, comm: swapper Tainted: G        W   2.6.35-wl+ #8
      Call Trace:
       [<c043aa42>] warn_slowpath_common+0x6a/0x7f
       [<c05d252a>] ? check_sync+0xce/0x43a
       [<c043aaca>] warn_slowpath_fmt+0x2b/0x2f
       [<c05d252a>] check_sync+0xce/0x43a
       [<c046189a>] ? print_lock_contention_bug+0x11/0xb2
       [<c05d2b6f>] debug_dma_sync_single_for_cpu+0x47/0x49
       [<c06cbd3c>] ? ehci_irq+0x31/0x331
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a221d>] pci_dma_sync_single_for_cpu.clone.1+0x42/0x4b [ipw2100]
       [<f82a23a2>] ipw2100_irq_tasklet+0x17c/0x5e9 [ipw2100]
       [<c043fd87>] tasklet_action+0x78/0xcb
       [<c0440293>] __do_softirq+0xc4/0x183
       [<c044038d>] do_softirq+0x3b/0x5f
       [<c04404d0>] irq_exit+0x3a/0x6d
       [<c0404423>] do_IRQ+0x8b/0x9f
       [<c04038b5>] common_interrupt+0x35/0x3c
       [<c062ecfa>] ? acpi_idle_enter_simple+0xfe/0x13c
       [<c045007b>] ? exit_itimers+0x2d/0x73
       [<c062ecfc>] ? acpi_idle_enter_simple+0x100/0x13c
       [<c070bf10>] cpuidle_idle_call+0x78/0xdc
       [<c040251c>] cpu_idle+0x9b/0xb7
       [<c07b1dd2>] rest_init+0xa6/0xab
       [<c0a4b96d>] start_kernel+0x389/0x38e
       [<c0a4b0c9>] i386_start_kernel+0xc9/0xd0
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c206a04f
  16. 17 8月, 2010 1 次提交
  17. 12 8月, 2010 1 次提交
    • J
      ipw2100: register pm_qos request before registering pci driver · 2f81b471
      John W. Linville 提交于
      It is necessary to call pm_qos_add_request prior to calling
      pm_qos_update_request.  It was revealed that ipw2100 has been
      doing this wrong since "pm_qos: Get rid of the allocation in
      pm_qos_add_request()" (commit 82f68251)
      added a WARN that results in the following backtrace:
      
      WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
      pm_qos_update_request() called for unknown object
      Call Trace:
      [<c1024088>] ? warn_slowpath_common+0x78/0xb0
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1024153>] ? warn_slowpath_fmt+0x33/0x40
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
      [<c11961c9>] ? vsnprintf+0xc9/0x530
      [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
      [<c12f542d>] ? register_netdevice+0x7d/0x3c0
      [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
      [<c12f579f>] ? register_netdev+0x2f/0x40
      [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
      [<c11a5ebb>] ? local_pci_probe+0xb/0x10
      [<c11a6d49>] ? pci_device_probe+0x69/0x90
      [<c1224704>] ? driver_probe_device+0x74/0x180
      [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
      [<c1224889>] ? __driver_attach+0x79/0x80
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c1223fa2>] ? bus_for_each_dev+0x52/0x80
      [<c1224586>] ? driver_attach+0x16/0x20
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c122395f>] ? bus_add_driver+0x17f/0x250
      [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
      [<c11a6c80>] ? pci_device_remove+0x0/0x40
      [<c1224b13>] ? driver_register+0x63/0x120
      [<c11a6f96>] ? __pci_register_driver+0x36/0xa0
      [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
      [<c1001122>] ? do_one_initcall+0x32/0x170
      [<c1087078>] ? __vunmap+0xb8/0xf0
      [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
      [<c10510c1>] ? sys_init_module+0x161/0x1000
      [<c108f847>] ? sys_close+0x67/0xe0
      [<c13647c1>] ? syscall_call+0x7/0xb
      
      This patch moves pm_qos_add_request prior to pci_register_driver in
      ipw2100 in order to avoid this problem.
      Reported-by: NChristoph Fritz <chf.fritz@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2f81b471
  18. 05 8月, 2010 1 次提交
  19. 27 7月, 2010 1 次提交
  20. 21 7月, 2010 2 次提交
  21. 19 7月, 2010 1 次提交
  22. 17 6月, 2010 1 次提交
  23. 04 6月, 2010 1 次提交
  24. 03 6月, 2010 2 次提交
  25. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      Joe Perches 提交于
      This patch removes from drivers/net/ all the unnecessary
      return; statements that precede the last closing brace of
      void functions.
      
      It does not remove the returns that are immediately
      preceded by a label as gcc doesn't like that.
      
      It also does not remove null void functions with return.
      
      Done via:
      $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
        xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'
      
      with some cleanups by hand.
      
      Compile tested x86 allmodconfig only.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  26. 11 5月, 2010 1 次提交
    • M
      PM QOS update · ed77134b
      Mark Gross 提交于
      This patch changes the string based list management to a handle base
      implementation to help with the hot path use of pm-qos, it also renames
      much of the API to use "request" as opposed to "requirement" that was
      used in the initial implementation.  I did this because request more
      accurately represents what it actually does.
      
      Also, I added a string based ABI for users wanting to use a string
      interface.  So if the user writes 0xDDDDDDDD formatted hex it will be
      accepted by the interface.  (someone asked me for it and I don't think
      it hurts anything.)
      
      This patch updates some documentation input I got from Randy.
      Signed-off-by: Nmarkgross <mgross@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      ed77134b
  27. 01 4月, 2010 2 次提交
  28. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  29. 24 3月, 2010 1 次提交
  30. 16 3月, 2010 1 次提交
  31. 11 3月, 2010 2 次提交
  32. 08 1月, 2010 1 次提交
  33. 05 12月, 2009 1 次提交
  34. 04 12月, 2009 1 次提交
  35. 29 11月, 2009 1 次提交