Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp446748pxb; Wed, 3 Feb 2021 09:05:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZVaehfTglSHnLTL0yg0jWfaQ/ZcfARglIUeJ4PEZ6WHOVdUc13yfjAhQROXVWMcfOAC5W X-Received: by 2002:a17:906:c9d8:: with SMTP id hk24mr4309292ejb.468.1612371933520; Wed, 03 Feb 2021 09:05:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612371933; cv=none; d=google.com; s=arc-20160816; b=GotQXxo+ztTFFuZKDQaNUJyA0mJmD2xuwfNn5wHjiNh061MG7Q0saUh8GUej+36yLU aWdWFAoVeoByfxtGg4rwYa0WeAYp1kN73hTadcsYlgkHohXYUVgQ1EOIuqh4XCbK2NM6 UGlaL5Z5saH1pI3Ngg3ltxFmnPxyTuXfUtdyTK81NNn7b1go84z9CnBuA5dvsjOpiSHN PhXTNviLj983iwUNwIzh2o0/tYC3uoWSWtxZ7Yy5BFls4PcxZAndhKTRWUgXUmhZeom0 SIzDy9RRX7SjOkQLwOeO8yVbpd7HxWb9qFfYnVNKtbeWL0nE/5wDtDciP8VkEIVd8vxC KWjQ== 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 :message-id:date:subject:cc:to:from; bh=ZNNSH/FjF2Fo2mOmK2lZ8OHaq9TrZvJ6ZVJXScsmDtw=; b=R/65aitRgPibDIdVnRJPY02plYusSt43vE5g+6/UYKLWDxSsBj+0Xngwcyl24xF3j4 1Lu5in8gaBj5+1lCerbYCq5QIMqPUneM+J4FjxrJVxFwROiuE4ohmNdmG5Rw4R+00cjh HAhD1CNaHgfl9efu25v4rmy8VUHT5CFF32jCB5SKNff8XqPN/a0rfHggul0JwMgG5k96 wk6Z8xl/1WCb4oZoVNujDN3WPbjiOVxz2b02/TBLjDxp8ABwC4teH9ws72pTx6ry65yx VUcpdIIzuSI83ClivP2VzV/0FdjeMrmVSUs+B8KMUaHVdfBJB7xP2GH62g4skviazMOe snPg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j19si1718505edq.356.2021.02.03.09.05.02; Wed, 03 Feb 2021 09:05:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231652AbhBCREY (ORCPT + 99 others); Wed, 3 Feb 2021 12:04:24 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:44503 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231923AbhBCRDg (ORCPT ); Wed, 3 Feb 2021 12:03:36 -0500 X-Originating-IP: 86.210.203.150 Received: from localhost.localdomain (lfbn-tou-1-972-150.w86-210.abo.wanadoo.fr [86.210.203.150]) (Authenticated sender: miquel.raynal@bootlin.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5D19560004; Wed, 3 Feb 2021 17:02:46 +0000 (UTC) From: Miquel Raynal To: Mark Brown Cc: , Tudor Ambarus , linux-kernel@vger.kernel.org, zhengxunli@mxic.com.tw, juliensu@mxic.com.tw, ycllin@mxic.com.tw, Miquel Raynal Subject: [PATCH] spi: Fix the logic around the maximum speed Date: Wed, 3 Feb 2021 18:02:45 +0100 Message-Id: <20210203170245.31236-1-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max speed") rationaly introduced a new condition on which the device's maximum speed would be set to the controller's one: if the device advertizes a higher speed than the one supported by the controller. However, it seems that the SPI core does not enforce controllers to always advertize a maximum speed value. Other similar conditions in the SPI core always check that the controller->max_speed_hz was set before doing anything else. Not doing this check here breaks SPI controller drivers which do not advertize a maximum speed: - the controller maximum speed is 0 - the child device max speed is set to an apparently coeherent value - in this case the child device maximum speed is set to 0 Either (1) all controller drivers should set max_speed_hz or (2) the child device maximum speed should not be updated in this particular situation. Perhaps there is a rationale for not enforcing (1), but in any case as a fix it is safer to use solution (2). Fixes: 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max speed") Signed-off-by: Miquel Raynal --- drivers/spi/spi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 51d7c004fbab..f59bf5094adb 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -3378,8 +3378,9 @@ int spi_setup(struct spi_device *spi) if (status) return status; - if (!spi->max_speed_hz || - spi->max_speed_hz > spi->controller->max_speed_hz) + if (spi->controller->max_speed_hz && + (!spi->max_speed_hz || + spi->max_speed_hz > spi->controller->max_speed_hz)) spi->max_speed_hz = spi->controller->max_speed_hz; mutex_lock(&spi->controller->io_mutex); -- 2.20.1