Skip to content
  1. Nov 08, 2016
    • Takashi Iwai's avatar
      ALSA: info: Return error for invalid read/write · 6809cd68
      Takashi Iwai authored
      
      
      Currently the ALSA proc handler allows read or write even if the proc
      file were write-only or read-only.  It's mostly harmless, does thing
      but allocating memory and ignores the input/output.  But it doesn't
      tell user about the invalid use, and it's confusing and inconsistent
      in comparison with other proc files.
      
      This patch adds some sanity checks and let the proc handler returning
      an -EIO error when the invalid read/write is performed.
      
      Cc: <stable@vger.kernel.org> # v4.2+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6809cd68
    • Takashi Iwai's avatar
      ALSA: info: Limit the proc text input size · 027a9fe6
      Takashi Iwai authored
      
      
      The ALSA proc handler allows currently the write in the unlimited size
      until kmalloc() fails.  But basically the write is supposed to be only
      for small inputs, mostly for one line inputs, and we don't have to
      handle too large sizes at all.  Since the kmalloc error results in the
      kernel warning, it's better to limit the size beforehand.
      
      This patch adds the limit of 16kB, which must be large enough for the
      currently existing code.
      
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      027a9fe6
  2. Nov 02, 2016
  3. Nov 01, 2016
    • Chen-Yu Tsai's avatar
      ASoC: sun4i-codec: Enable bus clock after getting GPIO · 3716a891
      Chen-Yu Tsai authored
      
      
      In the current probe function the GPIO is acquired after the codec's
      bus clock is enabled. However if it fails to acquire the GPIO due to
      a deferred probe, it does not disable the bus clock before bailing out.
      This would result in the clock being enabled multiple times.
      
      Move the code that enables the bus clock after the part that gets the
      GPIO, maintaining a separation between resource acquisition and device
      enablement in the probe function.
      
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      3716a891
  4. Oct 31, 2016
  5. Oct 28, 2016
  6. Oct 27, 2016
  7. Oct 26, 2016
  8. Oct 25, 2016
  9. Oct 24, 2016
  10. Oct 20, 2016
  11. Oct 18, 2016
  12. Oct 13, 2016
  13. Oct 12, 2016
  14. Oct 11, 2016
    • Masahiro Yamada's avatar
      treewide: remove redundant #include <linux/kconfig.h> · 97139d4a
      Masahiro Yamada authored
      Kernel source files need not include <linux/kconfig.h> explicitly
      because the top Makefile forces to include it with:
      
        -include $(srctree)/include/linux/kconfig.h
      
      This commit removes explicit includes except the following:
      
        * arch/s390/include/asm/facilities_src.h
        * tools/testing/radix-tree/linux/kernel.h
      
      These two are used for host programs.
      
      Link: http://lkml.kernel.org/r/1473656164-11929-1-git-send-email-yamada.masahiro@socionext.com
      
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      97139d4a
    • Petr Mladek's avatar
      kthread: kthread worker API cleanup · 3989144f
      Petr Mladek authored
      A good practice is to prefix the names of functions by the name
      of the subsystem.
      
      The kthread worker API is a mix of classic kthreads and workqueues.  Each
      worker has a dedicated kthread.  It runs a generic function that process
      queued works.  It is implemented as part of the kthread subsystem.
      
      This patch renames the existing kthread worker API to use
      the corresponding name from the workqueues API prefixed by
      kthread_:
      
      __init_kthread_worker()		-> __kthread_init_worker()
      init_kthread_worker()		-> kthread_init_worker()
      init_kthread_work()		-> kthread_init_work()
      insert_kthread_work()		-> kthread_insert_work()
      queue_kthread_work()		-> kthread_queue_work()
      flush_kthread_work()		-> kthread_flush_work()
      flush_kthread_worker()		-> kthread_flush_worker()
      
      Note that the names of DEFINE_KTHREAD_WORK*() macros stay
      as they are. It is common that the "DEFINE_" prefix has
      precedence over the subsystem names.
      
      Note that INIT() macros and init() functions use different
      naming scheme. There is no good solution. There are several
      reasons for this solution:
      
        + "init" in the function names stands for the verb "initialize"
          aka "initialize worker". While "INIT" in the macro names
          stands for the noun "INITIALIZER" aka "worker initializer".
      
        + INIT() macros are used only in DEFINE() macros
      
        + init() functions are used close to the other kthread()
          functions. It looks much better if all the functions
          use the same scheme.
      
        + There will be also kthread_destroy_worker() that will
          be used close to kthread_cancel_work(). It is related
          to the init() function. Again it looks better if all
          functions use the same naming scheme.
      
        + there are several precedents for such init() function
          names, e.g. amd_iommu_init_device(), free_area_init_node(),
          jump_label_init_type(),  regmap_init_mmio_clk(),
      
        + It is not an argument but it was inconsistent even before.
      
      [arnd@arndb.de: fix linux-next merge conflict]
       Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.com
      
      
      Suggested-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3989144f
    • murray foster's avatar
      ASoC: cs4270: fix DAPM stream name mismatch · aa5f9209
      murray foster authored
      
      
      Mismatching stream names in DAPM route and widget definitions are
      causing compilation errors. Fixing these names allows the cs4270
      driver to compile and function.
      
      [Errors must be at probe time not compile time -- broonie]
      
      Signed-off-by: default avatarMurray Foster <mrafoster@gmail.com>
      Acked-by: default avatarPaul Handrigan <Paul.Handrigan@cirrus.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      aa5f9209
    • Arnd Bergmann's avatar
      ASoC: Intel: haswell depends on sst-firmware · c3474e21
      Arnd Bergmann authored
      
      
      The Intel Haswell audio support fails to link if
      CONFIG_SND_SOC_INTEL_SST_FIRMWARE is disabled:
      
      sst-haswell-dsp.c: undefined reference to `sst_mem_block_register'
      sst-haswell-dsp.c: undefined reference to `sst_mem_block_unregister_all'
      sst-haswell-dsp.c: undefined reference to `sst_module_alloc_blocks'
      sst-haswell-dsp.c: undefined reference to `sst_module_free'
      sst-haswell-dsp.c: undefined reference to `sst_module_new'
      sst-haswell-pcm.c: undefined reference to `sst_module_get_from_id'
      sst-haswell-pcm.c: undefined reference to `sst_module_runtime_restore'
      sst-haswell-pcm.c: undefined reference to `sst_module_runtime_save'
      ERROR: "sst_block_alloc_scratch" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_block_free_scratch" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_dma_copyfrom" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_dma_copyto" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_dma_get_channel" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_dma_put_channel" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_free" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_get_offset" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_dsp_new" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_fw_free_all" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_fw_new" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_fw_reload" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_fw_unload" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_module_runtime_alloc_blocks" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_module_runtime_get_from_id" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      ERROR: "sst_module_runtime_new" [sound/soc/intel/haswell/snd-soc-sst-haswell-pcm.ko] undefined!
      
      This moves the 'select' statement from two of the three haswell based users
      into the line that is used by all of them, so make it harder to get wrong
      and to fix the existing randconfig regressions.
      
      Fixes: 2d995e5d ("ASoC: Intel: boards: Add bdw-rt5677 machine driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c3474e21
  15. Oct 10, 2016
  16. Oct 06, 2016
  17. Oct 04, 2016
  18. Sep 29, 2016
Loading