Message ID | 20221201134845.4055907-3-rf@opensource.cirrus.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp271264wrr; Thu, 1 Dec 2022 05:52:58 -0800 (PST) X-Google-Smtp-Source: AA0mqf6HF90pRBLLl3G7Is0RAMYi2kyRI3NKcmgPEWTQlFbkZjBzDLbCnxTEY7SrJUw3Oxw0eLvc X-Received: by 2002:a17:90a:f3d3:b0:213:241f:1939 with SMTP id ha19-20020a17090af3d300b00213241f1939mr78465660pjb.70.1669902778640; Thu, 01 Dec 2022 05:52:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669902778; cv=none; d=google.com; s=arc-20160816; b=y8iaD1HIrNgSXAPVg5a/O2IL6CDlLhI/pRHIeSOaF7WfjfpoppmWmEhip3eSM8nCR1 tThzgZtbbgMKhjvCbS5ULgGDvHC7ARQ67uq1Oi4S5PSKDqdXcJx1F3zmFn5bZsgiM0Ea gPv5TEnhUs32orjV3UmXZvs22fiWDofWia0PD2c4Am1fgY5TGoI0RpIez4o2rcG3HskT ERd5/rJmOlRi+PaEzERe6uol3eMxqvpGuRg+uY2Ghmybe9n041uY6P+gNmIZFNcAO8oi f8QfH7v++zR26cytE2F8Ghey7PBhB6/7s2w4g8ehVFR0KVzikJU7/GupWQRqodaYhazQ mpVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Sq7aVdOUXhv799GASybDC0oDppsFxEeabLuPhpHwJW0=; b=Q0mK1J4QFWhc5PDCr0bXzo4Kl5jISTuran1dCjB56XyDAaNSaS4LkXvRyb10dc7tVN 8glZfJlD6Fnxor/bNw5UGvxOLOriV+y1zbLdxTz1hzIyK1CWzyocHmRNfHUD1eyagfau ivy4ESIjXdDE8shX2FhnEGg3HLBnXaLah7iAXmxME7asXtHB2GBpsddleMocNhBSmYOC f72cj9utv5mtvBsUkRTSPVgDQpWO3ouVQIvC3zbBNiOt9pZ/4bFeIOfJmrnTPUc4Azmq q/18JicFjALsYQjDXGHUyrocu0OsCSRhgIKQ9CVupsQkhT5pjG4gPQLN5v2/Gqv7fLXJ fBVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cirrus.com header.s=PODMain02222019 header.b="e+C5tD/E"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cirrus.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k133-20020a636f8b000000b004786d59f831si2833784pgc.217.2022.12.01.05.52.45; Thu, 01 Dec 2022 05:52:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cirrus.com header.s=PODMain02222019 header.b="e+C5tD/E"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cirrus.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231637AbiLANtL (ORCPT <rfc822;heyuhang3455@gmail.com> + 99 others); Thu, 1 Dec 2022 08:49:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231183AbiLANtF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 1 Dec 2022 08:49:05 -0500 Received: from mx0b-001ae601.pphosted.com (mx0a-001ae601.pphosted.com [67.231.149.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 459D91AF01 for <linux-kernel@vger.kernel.org>; Thu, 1 Dec 2022 05:49:03 -0800 (PST) Received: from pps.filterd (m0077473.ppops.net [127.0.0.1]) by mx0a-001ae601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B15l1vC016609; Thu, 1 Dec 2022 07:48:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cirrus.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=PODMain02222019; bh=Sq7aVdOUXhv799GASybDC0oDppsFxEeabLuPhpHwJW0=; b=e+C5tD/EoW0mAzWlfnqJ6/Ne5Q24vNzUPJdGbKt7anCO7HW3HldpKtfQ++3FIxjV8J0M OwAuf25tJjinl0Td8ldA0kKN3MxFjZrFPzMTqVBncS2Qy8gMcZIn0p4ooVmqE+Eg1yQ1 6wzkJ2th/lAQk7BeDePuSlbsGfiDv/zWsTSGDijQt/wh+Ril0qny4bmQBUcchM7JP1uf M9Y06VVwdxiPNea3LIeyFqFDmgBDVOr4G9SLM3pCnqPgQt95q6cdzcq2ZZ6/1z3p/jle W7LfyQUrEu+iU5wGAaRDxmTloeDJ/rQrpS7MPIqZSZLjuv5mZsgpgcSWY0r+sOWkWuHz cA== Received: from ediex01.ad.cirrus.com ([84.19.233.68]) by mx0a-001ae601.pphosted.com (PPS) with ESMTPS id 3m6k75rhqm-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Dec 2022 07:48:50 -0600 Received: from ediex01.ad.cirrus.com (198.61.84.80) by ediex01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.20; Thu, 1 Dec 2022 07:48:46 -0600 Received: from ediswmail.ad.cirrus.com (198.61.86.93) by ediex01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server id 15.2.1118.20 via Frontend Transport; Thu, 1 Dec 2022 07:48:46 -0600 Received: from edi-sw-dsktp-006.ad.cirrus.com (edi-sw-dsktp-006.ad.cirrus.com [198.90.251.111]) by ediswmail.ad.cirrus.com (Postfix) with ESMTP id EC48DB2F; Thu, 1 Dec 2022 13:48:45 +0000 (UTC) From: Richard Fitzgerald <rf@opensource.cirrus.com> To: <vkoul@kernel.org>, <pierre-louis.bossart@linux.intel.com> CC: <yung-chuan.liao@linux.intel.com>, <sanyog.r.kale@intel.com>, <alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org>, <patches@opensource.cirrus.com>, Richard Fitzgerald <rf@opensource.cirrus.com> Subject: [PATCH 2/3] soundwire: cadence: Remove wasted space in response_buf Date: Thu, 1 Dec 2022 13:48:44 +0000 Message-ID: <20221201134845.4055907-3-rf@opensource.cirrus.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20221201134845.4055907-1-rf@opensource.cirrus.com> References: <20221201134845.4055907-1-rf@opensource.cirrus.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Proofpoint-ORIG-GUID: gNFKnIwsnYaYG1Uc5sYyKBgrGUK914N_ X-Proofpoint-GUID: gNFKnIwsnYaYG1Uc5sYyKBgrGUK914N_ X-Proofpoint-Spam-Reason: safe X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751019976190371835?= X-GMAIL-MSGID: =?utf-8?q?1751019976190371835?= |
Series |
soundwire: cadence: Fix oversized FIFO size define
|
|
Commit Message
Richard Fitzgerald
Dec. 1, 2022, 1:48 p.m. UTC
The response_buf was declared much larger (128 entries) than the number
of responses that could ever be written into it (maximum 8).
Reduce response_buf to 8 entries and add checking in cdns_read_response()
to prevent overflowing reponse_buf if CDNS_MCP_RX_FIFO_AVAIL contains
an unexpectedly large number.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
drivers/soundwire/cadence_master.c | 6 ++++++
drivers/soundwire/cadence_master.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
Comments
On 12/1/22 07:48, Richard Fitzgerald wrote: > The response_buf was declared much larger (128 entries) than the number > of responses that could ever be written into it (maximum 8). Indeed I don't know why we used 128 entries. This is a magic value that doesn't appear in any specs I've looked at. Note that there's 'sniffer' mode when each response takes two consecutive 32-words in the FIFO. we've never used this mode though so it's not really an issue. It's also possible that this is related to the automatic command retry, where a failed command can be re-issued 15 times. However in that case the worst case would be 32 commands * 15 = 480. The value of 128 makes no sense at all, unless it was an upper bound for 8 * 15. We don't use this hardware retry btw. See more below... > Reduce response_buf to 8 entries and add checking in cdns_read_response() > to prevent overflowing reponse_buf if CDNS_MCP_RX_FIFO_AVAIL contains > an unexpectedly large number. > > Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> > --- > drivers/soundwire/cadence_master.c | 6 ++++++ > drivers/soundwire/cadence_master.h | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c > index 27699f341f2c..95c84d9f0775 100644 > --- a/drivers/soundwire/cadence_master.c > +++ b/drivers/soundwire/cadence_master.c > @@ -774,8 +774,14 @@ static void cdns_read_response(struct sdw_cdns *cdns) > u32 num_resp, cmd_base; > int i; > > + BUILD_BUG_ON(ARRAY_SIZE(cdns->response_buf) < CDNS_MCP_CMD_LEN); > + > num_resp = cdns_readl(cdns, CDNS_MCP_FIFOSTAT); > num_resp &= CDNS_MCP_RX_FIFO_AVAIL; > + if (num_resp > ARRAY_SIZE(cdns->response_buf)) { > + dev_warn(cdns->dev, "RX AVAIL %d too long\n", num_resp); > + num_resp = CDNS_MCP_CMD_LEN; .... this is different from what the hardware documentation tells me. The range of values to RX_FIFO_AVAIL is 0..RX_FIFO_DEPTH + 2. I don't understand the +2, but we should maybe be more cautious and use u32 response_buf[CDNS_MCP_CMD_LEN + 2]; > + } > > cmd_base = CDNS_MCP_CMD_BASE; > > diff --git a/drivers/soundwire/cadence_master.h b/drivers/soundwire/cadence_master.h > index 0434d70d4b1f..c2d817e8e22a 100644 > --- a/drivers/soundwire/cadence_master.h > +++ b/drivers/soundwire/cadence_master.h > @@ -117,7 +117,7 @@ struct sdw_cdns { > struct sdw_bus bus; > unsigned int instance; > > - u32 response_buf[0x80]; > + u32 response_buf[8]; > struct completion tx_complete; > struct sdw_defer *defer; >
On 01/12/2022 18:12, Pierre-Louis Bossart wrote: > > > On 12/1/22 07:48, Richard Fitzgerald wrote: >> The response_buf was declared much larger (128 entries) than the number >> of responses that could ever be written into it (maximum 8). > > Indeed I don't know why we used 128 entries. This is a magic value that > doesn't appear in any specs I've looked at. > > Note that there's 'sniffer' mode when each response takes two > consecutive 32-words in the FIFO. we've never used this mode though so > it's not really an issue. > > It's also possible that this is related to the automatic command retry, > where a failed command can be re-issued 15 times. However in that case > the worst case would be 32 commands * 15 = 480. The value of 128 makes > no sense at all, unless it was an upper bound for 8 * 15. We don't use > this hardware retry btw. > > See more below... > >> Reduce response_buf to 8 entries and add checking in cdns_read_response() >> to prevent overflowing reponse_buf if CDNS_MCP_RX_FIFO_AVAIL contains >> an unexpectedly large number. >> >> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> >> --- >> drivers/soundwire/cadence_master.c | 6 ++++++ >> drivers/soundwire/cadence_master.h | 2 +- >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c >> index 27699f341f2c..95c84d9f0775 100644 >> --- a/drivers/soundwire/cadence_master.c >> +++ b/drivers/soundwire/cadence_master.c >> @@ -774,8 +774,14 @@ static void cdns_read_response(struct sdw_cdns *cdns) >> u32 num_resp, cmd_base; >> int i; >> >> + BUILD_BUG_ON(ARRAY_SIZE(cdns->response_buf) < CDNS_MCP_CMD_LEN); >> + >> num_resp = cdns_readl(cdns, CDNS_MCP_FIFOSTAT); >> num_resp &= CDNS_MCP_RX_FIFO_AVAIL; >> + if (num_resp > ARRAY_SIZE(cdns->response_buf)) { >> + dev_warn(cdns->dev, "RX AVAIL %d too long\n", num_resp); >> + num_resp = CDNS_MCP_CMD_LEN; > > .... this is different from what the hardware documentation tells me. > The range of values to RX_FIFO_AVAIL is 0..RX_FIFO_DEPTH + 2. > > I don't understand the +2, but we should maybe be more cautious and use > u32 response_buf[CDNS_MCP_CMD_LEN + 2]; > Probably we wouldn't know what to do with those extra 2 responses. _cdns_xfer_msg() tells cdns_fill_msg_resp() to extract the same number of responses as the original message length. So it would only extract 8 maximum. But anyway yes I can add the mysterious +2 into this. Thinking about it, that's probably a good idea anyay for the next patch that drains the RX FIFO after an error. >> + } >> >> cmd_base = CDNS_MCP_CMD_BASE; >> >> diff --git a/drivers/soundwire/cadence_master.h b/drivers/soundwire/cadence_master.h >> index 0434d70d4b1f..c2d817e8e22a 100644 >> --- a/drivers/soundwire/cadence_master.h >> +++ b/drivers/soundwire/cadence_master.h >> @@ -117,7 +117,7 @@ struct sdw_cdns { >> struct sdw_bus bus; >> unsigned int instance; >> >> - u32 response_buf[0x80]; >> + u32 response_buf[8]; >> struct completion tx_complete; >> struct sdw_defer *defer; >>
diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index 27699f341f2c..95c84d9f0775 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -774,8 +774,14 @@ static void cdns_read_response(struct sdw_cdns *cdns) u32 num_resp, cmd_base; int i; + BUILD_BUG_ON(ARRAY_SIZE(cdns->response_buf) < CDNS_MCP_CMD_LEN); + num_resp = cdns_readl(cdns, CDNS_MCP_FIFOSTAT); num_resp &= CDNS_MCP_RX_FIFO_AVAIL; + if (num_resp > ARRAY_SIZE(cdns->response_buf)) { + dev_warn(cdns->dev, "RX AVAIL %d too long\n", num_resp); + num_resp = CDNS_MCP_CMD_LEN; + } cmd_base = CDNS_MCP_CMD_BASE; diff --git a/drivers/soundwire/cadence_master.h b/drivers/soundwire/cadence_master.h index 0434d70d4b1f..c2d817e8e22a 100644 --- a/drivers/soundwire/cadence_master.h +++ b/drivers/soundwire/cadence_master.h @@ -117,7 +117,7 @@ struct sdw_cdns { struct sdw_bus bus; unsigned int instance; - u32 response_buf[0x80]; + u32 response_buf[8]; struct completion tx_complete; struct sdw_defer *defer;