From patchwork Tue Jul 25 18:02:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 13326890 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10BDCC001DF for ; Tue, 25 Jul 2023 18:03:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231329AbjGYSDj (ORCPT ); Tue, 25 Jul 2023 14:03:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229828AbjGYSDi (ORCPT ); Tue, 25 Jul 2023 14:03:38 -0400 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 643FE1FE2 for ; Tue, 25 Jul 2023 11:03:36 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6686ef86110so3305768b3a.2 for ; Tue, 25 Jul 2023 11:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1690308216; x=1690913016; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=A3wk98CPhmXaucfW3yFy0X9veK7c7V/LOvkjR4lZXDk=; b=mdgqGoEyde5ufR0v0DwdbxwxdHa372uxZ0WCuZCPFnP2tWnW3cD+aRMsF3UhDkW2W8 JRNRLtjBkoPm/8J+2v8HL3qRmFef49+Bom+JO5Ec/knUI7wtUTiCn7WGM+yUu0pprK9T lf5uswnmIi0XpGMFOBgRcHhnhqrYFfANyRFJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690308216; x=1690913016; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A3wk98CPhmXaucfW3yFy0X9veK7c7V/LOvkjR4lZXDk=; b=BJs+LxbqsykDtH4FnCTxkthTbW/nblzDMo7bwHdvVaCRO+rsQsYF7rgpGv536wL+4l 9qNgnLL1QI3SZTf1uAzCkhkHCCCwLqZibH+amNX4qOTr8QzAhrmEXML59+eBiwNT4u1/ Fe8VACO3eDEQik8PdF5Uhjea2lLqtxS/YbRD1vzm4KxiyLIEKZhGaT3q7oq/zv9MXgBO wh5bzAJJvFJtFIQDS1mxeksKjGcPxIpollGyezpDuDepGYtZKB3FhjrZzGUpitFxZFm1 xcAYr4/ynbnqbj4E2CVDH93wEgPsLztv+LnzZzs1ADst7CUYItG1DNqbO7UdEDvSgG6n CN5w== X-Gm-Message-State: ABy/qLZ21yGuNtH4mPBDzxfWxfDUCFghl62j6vRYePdpVpu1cXMDl6o9 5nU08BslXqSfRBBkbx8ke7u1AQ== X-Google-Smtp-Source: APBJJlHM3LA5e8y9FJWQ5S6qBfzNrEBCpsSXTklOVDUtXJMwIuGCv66gAUEtztxROBRKSmqdn+oUoQ== X-Received: by 2002:a17:902:d487:b0:1b8:8069:d432 with SMTP id c7-20020a170902d48700b001b88069d432mr23474plg.16.1690308215805; Tue, 25 Jul 2023 11:03:35 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:c363:4681:f5b8:301]) by smtp.gmail.com with ESMTPSA id jl14-20020a170903134e00b001b54a88e4a6sm11305254plb.51.2023.07.25.11.03.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 11:03:35 -0700 (PDT) From: Douglas Anderson To: Mark Brown Cc: Vijaya Krishna Nivarthi , Douglas Anderson , Andy Gross , Bjorn Andersson , Konrad Dybcio , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org Subject: [PATCH 1/2] spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytes Date: Tue, 25 Jul 2023 11:02:26 -0700 Message-ID: <20230725110226.1.Ia2f980fc7cd0b831e633391f0bb1272914d8f381@changeid> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org The Qualcomm QSPI driver appears to require that any reads using DMA are a mutliple of 4 bytes. If this isn't true then the controller will clobber any extra bytes in memory following the last word. Let's detect this and falback to PIO. This fixes problems reported by slub_debug=FZPUA, which would complain about "kmalloc Redzone overwritten". One such instance said: 0xffffff80c29d541a-0xffffff80c29d541b @offset=21530. First byte 0x0 instead of 0xcc Allocated in mtd_kmalloc_up_to+0x98/0xac age=36 cpu=3 pid=6658 Tracing through what was happening I saw that, while we often did DMA tranfers of 0x1000 bytes, sometimes we'd end up doing ones of 0x41a bytes. Those 0x41a byte transfers were the problem. NOTE: a future change will enable the SPI "mem ops" to help avoid this case, but it still seems good to add the extra check in the transfer. Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Signed-off-by: Douglas Anderson Reviewed-by: Bjorn Andersson Reviewed-by: Vijaya Krishna Nivarthi --- drivers/spi/spi-qcom-qspi.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c index a0ad9802b606..39b4d8a8107a 100644 --- a/drivers/spi/spi-qcom-qspi.c +++ b/drivers/spi/spi-qcom-qspi.c @@ -355,10 +355,22 @@ static int qcom_qspi_setup_dma_desc(struct qcom_qspi *ctrl, for (i = 0; i < sgt->nents; i++) { dma_ptr_sg = sg_dma_address(sgt->sgl + i); + dma_len_sg = sg_dma_len(sgt->sgl + i); if (!IS_ALIGNED(dma_ptr_sg, QSPI_ALIGN_REQ)) { dev_warn_once(ctrl->dev, "dma_address not aligned to %d\n", QSPI_ALIGN_REQ); return -EAGAIN; } + /* + * When reading with DMA the controller writes to memory 1 word + * at a time. If the length isn't a multiple of 4 bytes then + * the controller can clobber the things later in memory. + * Fallback to PIO to be safe. + */ + if (ctrl->xfer.dir == QSPI_READ && (dma_len_sg & 0x03)) { + dev_warn_once(ctrl->dev, "fallback to PIO for read of size %#010x\n", + dma_len_sg); + return -EAGAIN; + } } for (i = 0; i < sgt->nents; i++) { From patchwork Tue Jul 25 18:02:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 13326891 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A11FC41513 for ; Tue, 25 Jul 2023 18:03:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232383AbjGYSDk (ORCPT ); Tue, 25 Jul 2023 14:03:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229828AbjGYSDj (ORCPT ); Tue, 25 Jul 2023 14:03:39 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C3A02118 for ; Tue, 25 Jul 2023 11:03:38 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1bb8e45185bso15395805ad.1 for ; Tue, 25 Jul 2023 11:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1690308217; x=1690913017; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HRQYZPtdJ90/O/wdYsOCcbEwOxH1iCaDxABLg2VMAnc=; b=O7H+ZLIoNcQEd+SafX694hZEyd6kL9iSaUGkuyFgwYR24O5btNklcnGPDRxAuZzppw qv5UqwC+rlTIxCGA2BxWpYz+A5cAw4KDBZ6eGs2c96kObajRC+mwS/ZAVnk9NEZD5z4d vrNIriah0F8xAYzNtiDgDB87bhkru80BZa6ro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690308217; x=1690913017; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HRQYZPtdJ90/O/wdYsOCcbEwOxH1iCaDxABLg2VMAnc=; b=d5wwjMNvVnTukZhkUYoo3aT994jIBkFAKDJZ/Iyz1llJ+UUR3UgbZshgiOj0WKm4+2 t3xLbO4xooVgn9jZSuJ6rxUF1rA0F8oKaGhEJAcAddPHrpXVEZkjznkq1zNQvQdhHf+1 o2ZyHWFkgEaBPT1OrL4zK/kt0nhv67x9GET/M5pByXGZQc//tzIADgBlbdAqxn7D6gfR fNqvyiIKSsURKx8bJzA8BHDxq7t9iKQj6gZSxrohkpDAIJs3eQDMh1Ar/vPyrrKZGzcD Tb1puwLQ/Rq1sBIoD47AjECPbOHL5PhuAloSo9h2lL9lQelK/HCGUmfx9AX2wndjvQJn Zk4Q== X-Gm-Message-State: ABy/qLYLd6vam2kW/QzXd14/2L6/fGXMv3Pb7887cpTc84o4mBXXTMi0 oMHxTbNuzcqeDE7YRTcQduhBhw== X-Google-Smtp-Source: APBJJlEsqf6G0ev6P/b6k5o3OywK6DpeA91QLSmSatgQZy4Y3+LKHFLS10qE4bOW2mdt0NxUKIQVfA== X-Received: by 2002:a17:902:ab8e:b0:1b8:7d0d:5ac5 with SMTP id f14-20020a170902ab8e00b001b87d0d5ac5mr13716plr.50.1690308217621; Tue, 25 Jul 2023 11:03:37 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:c363:4681:f5b8:301]) by smtp.gmail.com with ESMTPSA id jl14-20020a170903134e00b001b54a88e4a6sm11305254plb.51.2023.07.25.11.03.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 11:03:36 -0700 (PDT) From: Douglas Anderson To: Mark Brown Cc: Vijaya Krishna Nivarthi , Douglas Anderson , Andy Gross , Bjorn Andersson , Konrad Dybcio , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org Subject: [PATCH 2/2] spi: spi-qcom-qspi: Add mem_ops to avoid PIO for badly sized reads Date: Tue, 25 Jul 2023 11:02:27 -0700 Message-ID: <20230725110226.2.Id4a39804e01e4a06dae9b73fd2a5194c4c7ea453@changeid> X-Mailer: git-send-email 2.41.0.487.g6d72f3e995-goog In-Reply-To: <20230725110226.1.Ia2f980fc7cd0b831e633391f0bb1272914d8f381@changeid> References: <20230725110226.1.Ia2f980fc7cd0b831e633391f0bb1272914d8f381@changeid> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org In the patch ("spi: spi-qcom-qspi: Fallback to PIO for xfers that aren't multiples of 4 bytes") we detect reads that we can't handle properly and fallback to PIO mode. While that's correct behavior, we can do better by adding "spi_controller_mem_ops" for our controller. Once we do this then the caller will give us a transfer that's a multiple of 4-bytes so we can DMA. Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Signed-off-by: Douglas Anderson Reviewed-by: Vijaya Krishna Nivarthi --- drivers/spi/spi-qcom-qspi.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c index 39b4d8a8107a..b2bbcfd93637 100644 --- a/drivers/spi/spi-qcom-qspi.c +++ b/drivers/spi/spi-qcom-qspi.c @@ -659,6 +659,30 @@ static irqreturn_t qcom_qspi_irq(int irq, void *dev_id) return ret; } +static int qcom_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op) +{ + /* + * If qcom_qspi_can_dma() is going to return false we don't need to + * adjust anything. + */ + if (op->data.nbytes <= QSPI_MAX_BYTES_FIFO) + return 0; + + /* + * When reading, the transfer needs to be a multiple of 4 bytes so + * shrink the transfer if that's not true. The caller will then do a + * second transfer to finish things up. + */ + if (op->data.dir == SPI_MEM_DATA_IN && (op->data.nbytes & 0x3)) + op->data.nbytes &= ~0x3; + + return 0; +} + +static const struct spi_controller_mem_ops qcom_qspi_mem_ops = { + .adjust_op_size = qcom_qspi_adjust_op_size, +}; + static int qcom_qspi_probe(struct platform_device *pdev) { int ret; @@ -743,6 +767,7 @@ static int qcom_qspi_probe(struct platform_device *pdev) if (of_property_read_bool(pdev->dev.of_node, "iommus")) master->can_dma = qcom_qspi_can_dma; master->auto_runtime_pm = true; + master->mem_ops = &qcom_qspi_mem_ops; ret = devm_pm_opp_set_clkname(&pdev->dev, "core"); if (ret)