1. 27 May, 2016 1 commit
    • Arnd Bergmann's avatar
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann authored
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  2. 25 May, 2016 1 commit
  3. 24 May, 2016 1 commit
  4. 23 May, 2016 1 commit
  5. 20 May, 2016 1 commit
  6. 18 May, 2016 3 commits
  7. 17 May, 2016 2 commits
  8. 13 May, 2016 11 commits
  9. 12 May, 2016 4 commits
  10. 11 May, 2016 9 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: drop skip argument from helper functions to queue a packet · ff38e0c7
      Takashi Sakamoto authored
      On most of audio and music units on IEEE 1394 bus which ALSA firewire stack
      supports (or plans to support), CIP with two quadlets header is used.
      Thus, there's no cases to queue packets with blank payload. If such packets
      are going to be queued, it means that they're for skips of the cycle.
      
      This commit simplifies helper functions to queue a packet.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ff38e0c7
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: add context information to tracepoints · a9c4284b
      Takashi Sakamoto authored
      In current implementation, packet processing is done in both of software
      IRQ contexts of IR/IT contexts and process contexts.
      
      This is usual interrupt handling of IR/IT context for 1394 OHCI.
      (in hardware IRQ context)
      irq_handler() (drivers/firewire/ohci.c)
      ->tasklet_schedule()
      (in software IRQ context)
      handle_it_packet() or handle_ir_packet_per_buffer() (drivers/firewire/ohci.c)
      ->flush_iso_completions()
        ->struct fw_iso_context.callback.sc()
        = out_stream_callback() or in_stream_callback()
      
      However, we have another chance for packet processing. It's done in PCM
      frame handling via ALSA PCM interfaces.
      (in process context)
      ioctl(i.e. SNDRV_PCM_IOCTL_HWSYNC)
      ->snd_pcm_hwsync() (sound/core/pcm_native.c)
        ->snd_pcm_update_hw_ptr() (sound/core/pcm_lib.c)
          ->snd_pcm_update_hw_ptr0()
            ->struct snd_pcm_ops.pointer()
            = amdtp_stream_pcm_pointer()
              ->fw_iso_context_flush_completions() (drivers/firewire/core-iso.c)
                ->struct fw_card_driver.flush_iso_completions()
                = ohci_flush_iso_completions() (drivers/firewire/ohci.c)
                  ->flush_iso_completions()
                    ->struct fw_iso_context.callback.sc()
                    = out_stream_callback() or in_stream_callback()
      
      This design is for a better granularity of PCM pointer. When ioctl(2) is
      executed with some commands for ALSA PCM interface, queued packets are
      handled at first. Then, the latest number of handled PCM frames is
      reported. The number can represent PCM frames transferred in most near
      isochronous cycle.
      
      Current tracepoints include no information to distinguish running contexts.
      When tracing the interval of software IRQ context, this is not good.
      
      This commit adds more information for current context. Additionally, the
      index of packet processed in one context is added in a case that packet
      processing is executed in continuous context of the same kind,
      
      As a result, the output includes 11 fields with additional two fields
      to commit 0c95c1d6 ("ALSA: firewire-lib: add tracepoints to dump a part
      of isochronous packet data"):
      17131.9186: out_packet: 07 7494 ffc0 ffc1 00 000700c0 9001a496 058 45 1 13
      17131.9186: out_packet: 07 7495 ffc0 ffc1 00 000700c8 9001ba00 058 46 1 14
      17131.9186: out_packet: 07 7496 ffc0 ffc1 00 000700d0 9001ffff 002 47 1 15
      17131.9189: out_packet: 07 7497 ffc0 ffc1 00 000700d0 9001d36a 058 00 0 00
      17131.9189: out_packet: 07 7498 ffc0 ffc1 00 000700d8 9001e8d4 058 01 0 01
      17131.9189: out_packet: 07 7499 ffc0 ffc1 00 000700e0 9001023e 058 02 0 00
      17131.9206: in_packet:  07 7447 ffc1 ffc0 01 3f070072 9001783d 058 32 1 00
      17131.9206: in_packet:  07 7448 ffc1 ffc0 01 3f070072 90ffffff 002 33 1 01
      17131.9206: in_packet:  07 7449 ffc1 ffc0 01 3f07007a 900191a8 058 34 1 02
      (Here, some common fields are omitted so that a line is within 80
      characters.)
      
      The legend is:
       - The second of cycle scheduled for the packet
       - The count of cycle scheduled for the packet
       - The ID of node as source (hex)
       - The ID of node as destination (hex)
       - The value of isochronous channel
       - The first quadlet of CIP header (hex)
       - The second quadlet of CIP header (hex)
       - The number of included quadlets
       - The index of packet in a buffer maintained by this module
       - 0 in process context, 1 in IRQ context
       - The index of packet processed in the context
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a9c4284b
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: permit to flush queued packets only in process context for... · 1dba9db0
      Takashi Sakamoto authored
      ALSA: firewire-lib: permit to flush queued packets only in process context for better PCM period granularity
      
      These three commits were merged to improve PCM pointer granularity.
      commit 76fb8789 ("ALSA: firewire-lib: taskletize the snd_pcm_period_elapsed() call")
      commit e9148ddd ("ALSA: firewire-lib: flush completed packets when reading PCM position")
      commit 92b862c7 ("ALSA: firewire-lib: optimize packet flushing")
      
      The point of them is to handle queued packets not only in software IRQ
      context of IR/IT contexts, but also in process context. As a result of
      handling packets, period tasklet is scheduled when acrossing PCM period
      boundary. This is to prevent recursive call of
      'struct snd_pcm_ops.pointer()' in the same context.
      
      When the pointer callback is executed in the process context, it's
      better to avoid the second callback in the software IRQ context. The
      software IRQ context runs immediately after scheduled in the process
      context because few packets are queued yet.
      
      For the aim, 'pointer_flush' is used, however it causes a race condition
      between the process context and software IRQ context of IR/IT contexts.
      
      Practically, this race is not so critical because it influences process
      context to skip flushing queued packet and to get worse granularity of
      PCM pointer. The race condition is quite rare but it should be improved
      for stable service.
      
      The similar effect can be achieved by using 'in_interrupt()' macro. This
      commit obsoletes 'pointer_flush' with it.
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1dba9db0
    • Stephen Rothwell's avatar
    • Takashi Iwai's avatar
      ALSA: usb-audio: Yet another Phoneix Audio device quirk · 84add303
      Takashi Iwai authored
      Phoenix Audio has yet another device with another id (even a different
      vendor id, 0556:0014) that requires the same quirk for the sample
      rate.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      84add303
    • Axel Lin's avatar
      af37d21a
    • Joonas Lahtinen's avatar
      ASoC: Intel: Fix printk formatting · 396cbebe
      Joonas Lahtinen authored
      Format number after 0x in hex.
      
      Cc: Jie Yang <yang.jie@linux.intel.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      396cbebe
    • Peter Ujfalusi's avatar
      ASoC: twl6040: Select LPPLL during standby · 1135ef11
      Peter Ujfalusi authored
      When the codec is in standby we do not need to keep the HPPLL active.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      1135ef11
    • Takashi Iwai's avatar
      ALSA: hda - Fix regression on ATI HDMI audio · 39669225
      Takashi Iwai authored
      The HDMI/DP audio output on ATI/AMD chips got broken due to the recent
      restructuring of chmap.  Fortunately, Daniel Exner could bisect, and
      pointed the culprit commit [739ffee9: ALSA: hda - Add hdmi chmap
      verb programming ops to chmap object].
      
      This commit moved some ops from hdmi_ops to chmap_ops, and reassigned
      the ops in the embedded chmap object in hdmi_spec instead.
      Unfortunately, the reassignment of these ops in patch_atihdmi() were
      moved into an if block that is performed only for old chips.  Thus, on
      newer chips, the generic ops is still used, which doesn't work for
      such ATI/AMD chips.
      
      This patch addresses the regression, simply by moving the assignment
      of chmap ops to the right place.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114981
      Fixes: 739ffee9 ('ALSA: hda - Add hdmi chmap verb programming ops to chmap object')
      Reported-and-tested-by: default avatarDaniel Exner <dex@dragonslave.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      39669225
  11. 10 May, 2016 6 commits