Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp235974yba; Fri, 3 May 2019 00:24:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqyrGF9JvdKZaOiEb9HszBxOSAezVhd9259+IK9Lde503CjACLe0ix529A1pCvisX/SNmOHS X-Received: by 2002:a63:9dc8:: with SMTP id i191mr8266975pgd.91.1556868251902; Fri, 03 May 2019 00:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556868251; cv=none; d=google.com; s=arc-20160816; b=u6Z4+LtJJmz+HDaJNYRRR9S5llGwFK1bIZYIJlHAA4WHlEC8scLNwocBWEJizkIJC3 WueM9JpcIHwmpPxxkEG5m96w7RrxtMyH75SBHuJ828SxTkiSYlik2kZbYWp3v3vCkOyE bn/CWKyKOB+7Gy+/m7MTQAUApA4z/qjZUb5jyI/tTWJX70wUeizDT+Y+zhMJxv7+enDI EDz2NpJnN2tPHCyIrM20ed8yCQWtdSEoUVMOWHMdf+oqq4fZeIRXGr19Qj9wDD7Z0Db1 +QX7Tr3ZamcbsqW28bP4haQwUoSt8iJyqbXN+SYX/ydt4ayoj5ToTiW4t+Y6e8nv+rYH 4Z5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:in-reply-to:subject:cc:to :from:dkim-signature; bh=ZQwUU+J/MQcrEGIy0MJ+HGRMeveOuqWSbA/IkAltfgs=; b=LkXIR+3ZDDn/Bn34UAilptIlcpBU/XVwyMWy2+L7Ihcov+CVs9b27fjWYcvKndl9Zp Jqfm4HKKAk6LWjhySlbN2Wm0VLy/JNOoijJsLirykLWqP81CUpuFNXdZUrodymplDHl+ xpFsj92Ax7KmRzfezHWjn+jZRUklPmhaMT/swhtdmv+BVNxWg6PAbD2QFjFjsdQJjX7x ZqoUKvqdoOPDVxuYJp722vF7O79TSO9i97HFLjj/1+GUjIyFsNrg2vKncaH2fOvGcRWd 5h4UdHumFXDAVHzafKCXhZto/1ebZZ1eK7JG1onGPGuc39cd83KAG9EN8K6GCK66cm7j wJmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=a1Afsbzi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w125si1341924pfw.137.2019.05.03.00.23.56; Fri, 03 May 2019 00:24:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=a1Afsbzi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727090AbfECGX4 (ORCPT + 99 others); Fri, 3 May 2019 02:23:56 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:33908 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727061AbfECGXx (ORCPT ); Fri, 3 May 2019 02:23:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=ZQwUU+J/MQcrEGIy0MJ+HGRMeveOuqWSbA/IkAltfgs=; b=a1Afsbzi0iI8 BX8SvVx+DoACqhfVuyw9iAPBy/YOudOv1gqW3PdiwOI9nIai/jlEzWh4bgWsCVbMlR1HYfqNxh91c 6z1dfTLO4jOJJhOIvCD9xeJRQzhxXfRnmtPe1dh47kfer5lo6Zaipo974btGJPDuZIUGFe5pvvduU iHHgU=; Received: from [42.29.24.106] (helo=finisterre.ee.mobilebroadband) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hMRbc-0000jW-CG; Fri, 03 May 2019 06:23:37 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id 33FB0441D3F; Fri, 3 May 2019 07:23:32 +0100 (BST) From: Mark Brown To: Ross Zwisler Cc: alsa-devel@alsa-project.org, Jaroslav Kysela , Jie Yang , Liam Girdwood , linux-kernel@vger.kernel.org, Mark Brown , Pierre-Louis Bossart , Ross Zwisler , stable@vger.kernel.org, Takashi Iwai Subject: Applied "ASoC: Intel: avoid Oops if DMA setup fails" to the asoc tree In-Reply-To: <20190429182517.210909-1-zwisler@google.com> X-Patchwork-Hint: ignore Message-Id: <20190503062332.33FB0441D3F@finisterre.ee.mobilebroadband> Date: Fri, 3 May 2019 07:23:32 +0100 (BST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The patch ASoC: Intel: avoid Oops if DMA setup fails has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From 0efa3334d65b7f421ba12382dfa58f6ff5bf83c4 Mon Sep 17 00:00:00 2001 From: Ross Zwisler Date: Mon, 29 Apr 2019 12:25:17 -0600 Subject: [PATCH] ASoC: Intel: avoid Oops if DMA setup fails Currently in sst_dsp_new() if we get an error return from sst_dma_new() we just print an error message and then still complete the function successfully. This means that we are trying to run without sst->dma properly set up, which will result in NULL pointer dereference when sst->dma is later used. This was happening for me in sst_dsp_dma_get_channel(): struct sst_dma *dma = dsp->dma; ... dma->ch = dma_request_channel(mask, dma_chan_filter, dsp); This resulted in: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware] Fix this by adding proper error handling for the case where we fail to set up DMA. This change only affects Haswell and Broadwell systems. Baytrail systems explicilty opt-out of DMA via sst->pdata->resindex_dma_base being set to -1. Signed-off-by: Ross Zwisler Cc: stable@vger.kernel.org Acked-by: Pierre-Louis Bossart Signed-off-by: Mark Brown --- sound/soc/intel/common/sst-firmware.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/common/sst-firmware.c b/sound/soc/intel/common/sst-firmware.c index 1e067504b604..f830e59f93ea 100644 --- a/sound/soc/intel/common/sst-firmware.c +++ b/sound/soc/intel/common/sst-firmware.c @@ -1251,11 +1251,15 @@ struct sst_dsp *sst_dsp_new(struct device *dev, goto irq_err; err = sst_dma_new(sst); - if (err) - dev_warn(dev, "sst_dma_new failed %d\n", err); + if (err) { + dev_err(dev, "sst_dma_new failed %d\n", err); + goto dma_err; + } return sst; +dma_err: + free_irq(sst->irq, sst); irq_err: if (sst->ops->free) sst->ops->free(sst); -- 2.20.1