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]
Date:	Thu, 26 Nov 2015 00:34:33 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Luis Henriques <luis.henriques@...onical.com>
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 Wed, 2015-11-25 at 23:05 +0000, Luis Henriques wrote:
> 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.
[...]

The AZX_DCAPS_PRESET_CTHDA macro was introduced in 3.5.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)

Powered by blists - more mailing lists