22 Nov, 2010

2 commits


11 Nov, 2010

6 commits

  • The Atmel SSC can divide by even numbers, not only powers of two.

    Signed-off-by: Peter Rosin
    Signed-off-by: Takashi Iwai

    Peter Rosin
     
  • In each function, the value apcm is stored in the private_data field of
    runtime. At the same time the function ct_atc_pcm_free_substream is stored
    in the private_free field of the same structure. ct_atc_pcm_free_substream
    dereferences and ultimately frees the value in the private_data field. But
    each function can exit in an error case with apcm having been freed, in
    which case a subsequent call to the private_free function would perform a
    dereference after free. On the other hand, if the private_free field is
    not initialized, it is NULL, and not invoked (see snd_pcm_detach_substream
    in sound/core/pcm.c). To avoid the introduction of a dangling pointer, the
    initializations of the private_data and private_free fields are moved to
    the end of the function, past any possible free of apcm. This is safe
    because the previous calls to snd_pcm_hw_constraint_integer and
    snd_pcm_hw_constraint_minmax, which take runtime as an argument, do not
    refer to either of these fields.

    In each function, there is one error case where apcm needs to be freed, and
    a call to kfree is added.

    The sematic match that finds this problem is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @@
    expression e,e1,e2,e3;
    identifier f,free1,free2;
    expression a;
    @@

    *e->f = a
    ... when != e->f = e1
    when any
    if (...) {
    ... when != free1(...,e,...)
    when != e->f = e2
    * kfree(a)
    ... when != free2(...,e,...)
    when != e->f = e3
    }
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Takashi Iwai

    Julia Lawall
     
  • If the platform already provides a definition for these accessors
    do not redefine them. The warning was caught on MIPS.

    Signed-off-by: Florian Fainelli
    Signed-off-by: Takashi Iwai

    Florian Fainelli
     
  • BugLink: http://launchpad.net/bugs/673075

    According to the datasheet of 92HD87B, there is a digital mic
    at nid 0x11, so enable it in order to be able to use the mic.

    Cc: stable@kernel.org
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai

    David Henningsson
     
  • The [vk][cmz]alloc(_node) family of functions return void pointers which
    it's completely unnecessary/pointless to cast to other pointer types since
    that happens implicitly.

    This patch removes such casts from sound/oss/

    Signed-off-by: Jesper Juhl
    Signed-off-by: Takashi Iwai

    Jesper Juhl
     
  • Signed-off-by: Joe Perches
    Signed-off-by: Takashi Iwai

    Joe Perches
     

03 Nov, 2010

4 commits


02 Nov, 2010

5 commits

  • Mark Brown
     
  • Signed-off-by: Mark Brown

    Eric Miao
     
  • This patch adds support for Power/Status LED on Creative USB X-Fi S51.
    There is just one LED on the device. The LED can either be On or it
    can be set to Blink. There doesn't seem to be a way to switch it off.
    The control message to change LED status is similar to that of
    audigy2nx except that the index is to be set to 0 and value is 1 for
    Blink and 0 for On.

    The 'Power LED' control in alsamixer when muted will cause the LED to
    Blink continuously. When unmuted the LED will stay On. The Creative
    driver under Windows sets the LED to blink whenever audio is muted.
    This LED can be treated as the CMSS LED but I figured since there is
    just one LED, it should be treated as the Power LED. Is that alright?

    I've also changed the comment "Usb X-Fi" to "Usb X-Fi S51" as there
    are other external X-Fi devices from Creative like Usb X-Fi Go and
    Xmod. The volume knob and LED support patch doesn't apply to them.

    Signed-off-by: Mandar Joshi
    Signed-off-by: Takashi Iwai

    Mandar Joshi
     
  • I noticed that sound/pci/asihpi/hpicmn.c::hpi_alloc_control_cache() does
    not check the return value from kmalloc(), which may fail.
    If kmalloc() fails we'll dereference a null pointer and things will go bad
    fast.
    There are two memory allocations in that function and there's also the
    problem that the first may succeed and the second may fail and nothing is
    done about that either which will also go wrong down the line.

    Signed-off-by: Jesper Juhl
    Acked-by: Eliot Blennerhassett
    Signed-off-by: Takashi Iwai

    Jesper Juhl
     
  • Add missing newlines.

    Signed-off-by: Joe Perches
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown

    Joe Perches
     

01 Nov, 2010

20 commits


31 Oct, 2010

3 commits