1. 16 Jun, 2015 18 commits
    • Paul Gortmaker's avatar
      MIPS: don't use module_init in non-modular cobalt/mtd.c file · b0c6d930
      Paul Gortmaker authored
      As of commit 34b1252b ("MIPS:
      Cobalt: Do not build MTD platform device registration code as module.")
      this file became built-in instead of modular.  So we should also
      stop using module_init as an alias for __initcall as that can be
      rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      b0c6d930
    • Paul Gortmaker's avatar
      drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c · 33d69ca1
      Paul Gortmaker authored
      This file is built for a bool Kconfig variable, and hence this
      code is either present or absent.  It currently can never be
      modular, so using module_init as an alias for __initcall can be
      somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      And since it can't be modular, we remove all the __exitcall
      stuff related to module_exit() -- it is dead code that won't
      ever be executed.
      
      Cc: Bryan Wu <cooloney@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
      Acked-by: default avatarJacek Anaszewski <j.anaszewski@samsung.com>
      Cc: linux-leds@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      33d69ca1
    • Paul Gortmaker's avatar
      cris: don't use module_init for non-modular core eeprom.c code · 84c3e5bf
      Paul Gortmaker authored
      The eeprom.c code is compiled based on the Kconfig setting
      ETRAX_I2C_EEPROM, which is bool.  So the code is either built in
      or absent.  It will never be modular, so using module_init as an
      alias for __initcall is rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: linux-cris-kernel@axis.com
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      84c3e5bf
    • James Hogan's avatar
      tty/metag_da: Avoid module_init/module_exit in non-modular code · 4d38e5c4
      James Hogan authored
      The metag_da TTY driver can't get built as a module at the moment, but
      it still uses module_init() and module_exit(). Those macros are moving
      to module.h which isn't included by metag_da.c, which will result in the
      following build warnings (remarkably no build errors) and an apparent
      failure to boot as the TTY driver won't be loaded.
      
      drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
      drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
      drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
      drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
      drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
      drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
      drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
      drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
      drivers/tty/metag_da.c In function ‘dash_console_write’:
      drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
      
      Instead of just adding the module.h include, now would be a good time to
      remove the use of these macros, replacing the module_init with
      device_initcall, and removing the exit function altogether since it
      isn't needed. If module support is added later the code can always be
      resurrected.
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: linux-metag@vger.kernel.org
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4d38e5c4
    • Paul Gortmaker's avatar
      drivers/clk: don't use module_init in clk-nomadik.c which is non-modular · 791ed0bb
      Paul Gortmaker authored
      The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
      hence this code is either present or absent.  It will never be
      modular, so using module_init as an alias for __initcall can be
      somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      Cc: Mike Turquette <mturquette@linaro.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      791ed0bb
    • Paul Gortmaker's avatar
      xtensa: don't use module_init for non-modular core network.c code · 30e3c642
      Paul Gortmaker authored
      The network.c code is piggybacking off of the arch independent
      CONFIG_NET, which is bool.  So the code is either built in or
      absent.  It will never be modular, so using module_init as an
      alias for __initcall is rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Thomas Meyer <thomas@m3y3r.de>
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      30e3c642
    • Paul Gortmaker's avatar
      sh: don't use module_init in non-modular psw.c code · b205118b
      Paul Gortmaker authored
      The psw.o is built for obj-y -- and hence this code is always
      present.  It will never be modular, so using module_init as an alias
      for __initcall can be somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      b205118b
    • Paul Gortmaker's avatar
      mn10300: don't use module_init in non-modular flash.c code · 1b4d5bee
      Paul Gortmaker authored
      The flash.o is built for obj-y -- and hence this code is always
      present.  It will never be modular, so using module_init as an alias
      for __initcall can be somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Cc: David Howells <dhowells@redhat.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: linux-am33-list@redhat.com
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      1b4d5bee
    • Paul Gortmaker's avatar
      parisc64: don't use module_init for non-modular core perf code · 15becabd
      Paul Gortmaker authored
      The perf.c code depends on CONFIG_64BIT, so it is either built-in
      or absent.  It will never be modular, so using module_init as an
      alias for __initcall is rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.  Aside from it not making sense, it also
      causes a ~10% increase in CPP overhead due to module.h having a
      large list of headers itself -- for example compare line counts:
      
       device_initcall() and <linux/init.h>
      	20238 arch/parisc/kernel/perf.i
      
       module_init() and <linux/module.h>
      	22194 arch/parisc/kernel/perf.i
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      15becabd
    • Paul Gortmaker's avatar
      parisc: don't use module_init for non-modular core pdc_cons code · aed6850a
      Paul Gortmaker authored
      The pdc_cons.c code is always built in.  It will never be modular,
      so using module_init as an alias for __initcall is rather
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      aed6850a
    • Paul Gortmaker's avatar
      cris: don't use module_init for non-modular core intmem.c code · 73de14e8
      Paul Gortmaker authored
      The intmem.c code is always built in.  It will never be modular,
      so using module_init as an alias for __initcall is rather
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: linux-cris-kernel@axis.com
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      73de14e8
    • Paul Gortmaker's avatar
      ia64: don't use module_init in non-modular sim/simscsi.c code · 2a177fd1
      Paul Gortmaker authored
      The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      And since it can't be modular, we remove all the __exitcall
      stuff related to module_exit() -- it is dead code that won't
      ever be executed.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      2a177fd1
    • Paul Gortmaker's avatar
      ia64: don't use module_init for non-modular core kernel/mca.c code · 2e21fa2d
      Paul Gortmaker authored
      The mca.c code is always built in.  It will never be modular,
      so using module_init as an alias for __initcall is rather
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Direct use of __initcall is discouraged, vs prioritized ones.
      Use of device_initcall is consistent with what __initcall
      maps onto, and hence does not change the init order, making the
      impact of this change zero.   Should someone with real hardware
      for boot testing want to change it later to arch_initcall or
      something different, they can do that at a later date.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      2e21fa2d
    • Paul Gortmaker's avatar
      arm: don't use module_init in non-modular mach-vexpress/spc.c code · 4a0ece7c
      Paul Gortmaker authored
      The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4a0ece7c
    • Paul Gortmaker's avatar
      powerpc: don't use module_init in non-modular 83xx suspend code · a390a2f1
      Paul Gortmaker authored
      The suspend.o is built for SUSPEND -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      a390a2f1
    • Paul Gortmaker's avatar
      powerpc: use device_initcall for registering rtc devices · 8f6b9512
      Paul Gortmaker authored
      Currently these two RTC devices are in core platform code
      where it is not possible for them to be modular.  It will
      never be modular, so using module_init as an alias for
      __initcall can be somewhat misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- they will remain at level 6 in initcall ordering.
      
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Geoff Levand <geoff@infradead.org>
      Acked-by: default avatarGeoff Levand <geoff@infradead.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      8f6b9512
    • Paul Gortmaker's avatar
      x86: don't use module_init in non-modular devicetree.c code · d54b675a
      Paul Gortmaker authored
      The devicetree.o is built for "OF" -- which is bool, and hence
      this code is either present or absent.  It will never be modular,
      so using module_init as an alias for __initcall can be somewhat
      misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      d54b675a
    • Paul Gortmaker's avatar
      x86: don't use module_init in non-modular intel_mid_vrtc.c · 4711e2f9
      Paul Gortmaker authored
      The X86_INTEL_MID option is bool, and hence this code is either
      present or absent.  It will never be modular, so using
      module_init as an alias for __initcall is rather misleading.
      
      Fix this up now, so that we can relocate module_init from
      init.h into module.h in the future.  If we don't do this, we'd
      have to add module.h to obviously non-modular code, and that
      would be a worse thing.
      
      Note that direct use of __initcall is discouraged, vs. one
      of the priority categorized subgroups.  As __initcall gets
      mapped onto device_initcall, our use of device_initcall
      directly in this change means that the runtime impact is
      zero -- it will remain at level 6 in initcall ordering.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      4711e2f9
  2. 15 Jun, 2015 7 commits
  3. 14 Jun, 2015 1 commit
    • Linus Torvalds's avatar
      Merge tag 'sound-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 2fbbada1
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "Most of commits are regression fixes for HD-audio: a few corner case
        fixes for regmap transition, and i915 binding issues.
      
        In addition, a quirk for another USB-audio device supporting DSD"
      
      * tag 'sound-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: hda - Abort the probe without i915 binding for HSW/BDW
        ALSA: hda - Re-add the lost fake mute support
        ALSA: hda - Continue probing even if i915 binding fails
        ALSA: hda - Don't actually write registers for caps overwrites
        ALSA: hda - fix number of devices query on hotplug
        ALSA: usb-audio: add native DSD support for JLsounds I2SoverUSB
      2fbbada1
  4. 13 Jun, 2015 3 commits
    • Jaedon Shin's avatar
      MPI: MIPS: Fix compilation error with GCC 5.1 · 36f58113
      Jaedon Shin authored
      This patch fixes mips compilation error:
      
      lib/mpi/generic_mpih-mul1.c: In function 'mpihelp_mul_1':
      lib/mpi/longlong.h:651:2: error: impossible constraint in 'asm'
      Signed-off-by: default avatarJaedon Shin <jaedon.shin@gmail.com>
      Cc: Linux-MIPS <linux-mips@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/10546/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      36f58113
    • Rabin Vincent's avatar
      IRQCHIP: mips-gic: Don't nest calls to do_IRQ() · 1b3ed367
      Rabin Vincent authored
      The GIC chained handlers use do_IRQ() to call the subhandlers.  This
      means that irq_enter() calls get nested, which leads to preempt count
      looking like we're in nested interrupts, which in turn leads to all
      system time being accounted as IRQ time in account_system_time().
      
      Fix it by using generic_handle_irq().  Since these same functions are
      used in some systems (if cpu_has_veic) from a low-level vectored
      interrupt handler which does not go throught do_IRQ(), we need to do it
      conditionally.
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Reviewed-by: default avatarAndrew Bresticker <abrestic@chromium.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: tglx@linutronix.de
      Cc: jason@lakedaemon.net
      Patchwork: https://patchwork.linux-mips.org/patch/10545/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      1b3ed367
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · c8d17b45
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix uninitialized struct station_info in cfg80211_wireless_stats(),
          from Johannes Berg.
      
       2) Revert commit attempt to fix ipv6 protocol resubmission, it adds
          regressions.
      
       3) Endless loops can be created in bridge port lists, fix from Nikolay
          Aleksandrov.
      
       4) Don't WARN_ON() if sk->sk_forward_alloc is non-zero in
          sk_clear_memalloc, it is a legal situation during swap deactivation.
          Fix from Mel Gorman.
      
       5) Fix order of disabling interrupts and unlocking NAPI in enic driver
          to avoid a race.  From Govindarajulu Varadarajan.
      
       6) High and low register writes are swapped when programming the start
          of periodic output in igb driver.  From Richard Cochran.
      
       7) Fix device rename handling in mpls stack, from Robert Shearman.
      
       8) Do not trigger compaction synchronously when optimistically trying
          to allocate an order 3 page in alloc_skb_with_frags() and
          skb_page_frag_refill().  From Shaohua Li.
      
       9) Authentication with COOKIE_ECHO is not handled properly in SCTP, fix
          from Marcelo Ricardo Leitner.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        Doc: networking: Fix URL for wiki.wireshark.org in udplite.txt
        sctp: allow authenticating DATA chunks that are bundled with COOKIE_ECHO
        net: don't wait for order-3 page allocation
        mpls: handle device renames for per-device sysctls
        net: igb: fix the start time for periodic output signals
        enic: fix memory leak in rq_clean
        enic: check return value for stat dump
        enic: unlock napi busy poll before unmasking intr
        net, swap: Remove a warning and clarify why sk_mem_reclaim is required when deactivating swap
        bridge: fix multicast router rlist endless loop
        tipc: disconnect socket directly after probe failure
        Revert "ipv6: Fix protocol resubmission"
        cfg80211: wext: clear sinfo struct before calling driver
      c8d17b45
  5. 12 Jun, 2015 11 commits
    • Masanari Iida's avatar
      Doc: networking: Fix URL for wiki.wireshark.org in udplite.txt · b07d4961
      Masanari Iida authored
      This patch fix URL (http to https) for wiki.wireshark.org.
      Signed-off-by: default avatarMasanari Iida <standby24x7@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b07d4961
    • Marcelo Ricardo Leitner's avatar
      sctp: allow authenticating DATA chunks that are bundled with COOKIE_ECHO · ae36806a
      Marcelo Ricardo Leitner authored
      Currently, we can ask to authenticate DATA chunks and we can send DATA
      chunks on the same packet as COOKIE_ECHO, but if you try to combine
      both, the DATA chunk will be sent unauthenticated and peer won't accept
      it, leading to a communication failure.
      
      This happens because even though the data was queued after it was
      requested to authenticate DATA chunks, it was also queued before we
      could know that remote peer can handle authenticating, so
      sctp_auth_send_cid() returns false.
      
      The fix is whenever we set up an active key, re-check send queue for
      chunks that now should be authenticated. As a result, such packet will
      now contain COOKIE_ECHO + AUTH + DATA chunks, in that order.
      Reported-by: default avatarLiu Wei <weliu@redhat.com>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae36806a
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · b85dfd30
      Linus Torvalds authored
      Pull block layer fixes from Jens Axboe:
       "Remember about a week ago when I sent the last pull request for 4.1?
        Well, I lied.  Now, I don't want to shift the blame, but Dan, Ming,
        and Richard made a liar out of me.
      
        Here are three small patches that should go into 4.1.  More
        specifically, this pull request contains:
      
         - A Kconfig dependency for the pmem block driver, so it can't be
           selected if HAS_IOMEM isn't availble.  From Richard Weinberger.
      
         - A fix for genhd, making the ext_devt_lock softirq safe.  This makes
           lockdep happier, since we also end up grabbing this lock on release
           off the softirq path.  From Dan Williams.
      
         - A blk-mq software queue release fix from Ming Lei.
      
        Last two are headed to stable, first fixes an issue introduced in this
        cycle"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: pmem: Add dependency on HAS_IOMEM
        block: fix ext_dev_lock lockdep report
        blk-mq: free hctx->ctxs in queue's release handler
      b85dfd30
    • Linus Torvalds's avatar
      Merge tag 'md/4.1-rc7-fixes' of git://neil.brown.name/md · 7b565d9d
      Linus Torvalds authored
      Pull three more md fixes from Neil Brown:
       "Hasn't been a good cycle for md has it :-(
      
        The main issue fixed here is a rare race which can result in two
        reshape threads running at once, which doesn't end well.
      
        Also a minor issue with a write to a sysfs file returning the wrong
        value.  Backports to 4.0-stable are indicated"
      
      * tag 'md/4.1-rc7-fixes' of git://neil.brown.name/md:
        md: make sure MD_RECOVERY_DONE is clear before starting recovery/resync
        md: Close race when setting 'action' to 'idle'.
        md: don't return 0 from array_state_store
      7b565d9d
    • Linus Torvalds's avatar
      Merge git://git.infradead.org/intel-iommu · c39f3bc6
      Linus Torvalds authored
      Pull VT-d hardware workarounds from David Woodhouse:
       "This contains a workaround for hardware issues which I *thought* were
        never going to be seen on production hardware.  I'm glad I checked
        that before the 4.1 release...
      
        Firstly, PASID support is so broken on existing chips that we're just
        going to declare the old capability bit 28 as 'reserved' and change
        the VT-d spec to move PASID support to another bit.  So any existing
        hardware doesn't support SVM; it only sets that (now) meaningless bit
        28.
      
        That patch *wasn't* imperative for 4.1 because we don't have PASID
        support yet.  But *even* the extended context tables are broken — if
        you just enable the wider tables and use none of the new bits in them,
        which is precisely what 4.1 does, you find that translations don't
        work.  It's this problem which I thought was caught in time to be
        fixed before production, but wasn't.
      
        To avoid triggering this issue, we now *only* enable the extended
        context tables on hardware which also advertises "we have PASID
        support and we actually tested it this time" with the new PASID
        feature bit.
      
        In addition, I've added an 'intel_iommu=ecs_off' command line
        parameter to allow us to disable it manually if we need to"
      
      * git://git.infradead.org/intel-iommu:
        iommu/vt-d: Only enable extended context tables if PASID is supported
        iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register
      c39f3bc6
    • David Woodhouse's avatar
      iommu/vt-d: Only enable extended context tables if PASID is supported · c83b2f20
      David Woodhouse authored
      Although the extended tables are theoretically a completely orthogonal
      feature to PASID and anything else that *uses* the newly-available bits,
      some of the early hardware has problems even when all we do is enable
      them and use only the same bits that were in the old context tables.
      
      For now, there's no motivation to support extended tables unless we're
      going to use PASID support to do SVM. So just don't use them unless
      PASID support is advertised too. Also add a command-line bailout just in
      case later chips also have issues.
      
      The equivalent problem for PASID support has already been fixed with the
      upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change
      PASID support to bit 40 of Extended Capability Register"), because the
      problematic platforms use the old definition of the PASID-capable bit,
      which is now marked as reserved and meaningless.
      
      So with this change, we'll magically start using ECS again only when we
      see the new hardware advertising "hey, we have PASID support and we
      actually tested it this time" on bit 40.
      
      The VT-d hardware architect has promised that we are not going to have
      any reason to support ECS *without* PASID any time soon, and he'll make
      sure he checks with us before changing that.
      
      In the future, if hypothetical new features also use new bits in the
      context tables and can be seen on implementations *without* PASID support,
      we might need to add their feature bits to the ecs_enabled() macro.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      c83b2f20
    • NeilBrown's avatar
      md: make sure MD_RECOVERY_DONE is clear before starting recovery/resync · ea358cd0
      NeilBrown authored
      MD_RECOVERY_DONE is normally cleared by md_check_recovery after a
      resync etc finished.  However it is possible for raid5_start_reshape
      to race and start a reshape before MD_RECOVERY_DONE is cleared.  This
      can lean to multiple reshapes running at the same time, which isn't
      good.
      
      To make sure it is cleared before starting a reshape, and also clear
      it when reaping a thread, just to be safe.
      Signed-off-by: default avatarNeilBrown  <neilb@suse.de>
      ea358cd0
    • NeilBrown's avatar
      md: Close race when setting 'action' to 'idle'. · 8e8e2518
      NeilBrown authored
      Checking ->sync_thread without holding the mddev_lock()
      isn't really safe, even after flushing the workqueue which
      ensures md_start_sync() has been run.
      
      While this code is waiting for the lock, md_check_recovery could reap
      the thread itself, and then start another thread (e.g. recovery might
      finish, then reshape starts).  When this thread gets the lock
      md_start_sync() hasn't run so it doesn't get reaped, but
      MD_RECOVERY_RUNNING gets cleared.  This allows two threads to start
      which leads to confusion.
      
      So don't both if MD_RECOVERY_RUNNING isn't set, but if it is do
      the flush and the test and the reap all under the mddev_lock to
      avoid any race with md_check_recovery.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.")
      Cc: stable@vger.kernel.org (v4.0+)
      8e8e2518
    • NeilBrown's avatar
      md: don't return 0 from array_state_store · c008f1d3
      NeilBrown authored
      Returning zero from a 'store' function is bad.
      The return value should be either len length of the string
      or an error.
      
      So use 'len' if 'err' is zero.
      
      Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.")
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Cc: stable@vger.kernel (v4.0+)
      c008f1d3
    • Krzysztof Kozlowski's avatar
      dmaengine: Fix choppy sound because of unimplemented resume · 88d04643
      Krzysztof Kozlowski authored
      Some drivers implement only pause operation (no resuming). Example is
      pl330 where pause is needed for getting residuum. pl330 does not support
      resume operation, transfer must be stopped after pause.
      
      However for slaves this is exposed always as "pause and resume" which
      introduces subtle errors on Odroid U3 board (Exynos4412 with pl330).
      After adding pause function to pl330 driver the audio playback
      (utilizing DMA) gets choppy after some time (approximately 24 hours).
      
      Fix this by exposing "cmd_pause" if and only if pause and resume are
      implemented.
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reported-by: gabriel@unseen.is
      Reported-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 88987d2c ("dmaengine: pl330: add DMA_PAUSE feature")
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      88d04643
    • Takashi Iwai's avatar
      ALSA: hda - Abort the probe without i915 binding for HSW/BDW · 535115b5
      Takashi Iwai authored
      The previous patch tried to continue the probe if i915 binding fails.
      For for simplicity reason, we haven't implemented abort even for
      controller chips that are dedicated for HDMI/DP on HSW and BDW.
      However, Mengdong suggested that this can be dangerous; BIOS may
      disable gfx power well although the PCI entry for HD-audio is left,
      and this may result in the unexpected behavior, kernel errors, etc.
      
      For avoiding this situation, abort the probe at i915 binding failure
      only for HSW/BDW chips selectively.  For other chips, it still
      continues.
      
      Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails')
      Reported-by: default avatarMengdong Lin <mengdong.lin@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      535115b5