linux-kernel - Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151125230509.GB21715@charon>
Date:	Wed, 25 Nov 2015 23:05:09 +0000
From:	Luis Henriques <luis.henriques@...onical.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	akpm@...ux-foundation.org, Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative
 HDA controllers

On Tue, Nov 24, 2015 at 10:33:59PM +0000, Ben Hutchings wrote:
> 3.2.74-rc1 review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Takashi Iwai <tiwai@...e.de>
> 
> commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
> 
> We've had many reports that some Creative sound cards with CA0132
> don't work well.  Some reported that it starts working after reloading
> the module, while some reported it starts working when a 32bit kernel
> is used.  All these facts seem implying that the chip fails to
> communicate when the buffer is located in 64bit address.
> 
> This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
> flag to the corresponding PCI entries.  I casually had a chance to
> test an SB Recon3D board, and indeed this seems helping.
> 
> Although this hasn't been tested on all Creative devices, it's safer
> to assume that this restriction applies to the rest of them, too.  So
> the flag is applied to all Creative entries.
> 
> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA]

Is there a reason for dropping this change?  Adding the
AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does
seem to make sense.

Cheers,
--
Luís

> Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
> ---
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -3099,11 +3099,13 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids)
>  	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
>  	  .class_mask = 0xffffff,
>  	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
> +	  AZX_DCAPS_NO_64BIT |
>  	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
>  #else
>  	/* this entry seems still valid -- i.e. without emu20kx chip */
>  	{ PCI_DEVICE(0x1102, 0x0009),
>  	  .driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
> +	  AZX_DCAPS_NO_64BIT |
>  	  AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
>  #endif
>  	/* Vortex86MX */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/