From patchwork Mon Jul 10 15:24:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 107305 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp3567228qge; Mon, 10 Jul 2017 08:25:19 -0700 (PDT) X-Received: by 10.99.113.11 with SMTP id m11mr275948pgc.96.1499700319587; Mon, 10 Jul 2017 08:25:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499700319; cv=none; d=google.com; s=arc-20160816; b=PCczrvydOcV276j35MgPP8+tS4UKbCRK2+qC9hyl5NXQtYLCygCTBSa8mqPkEWeaEZ fC4yCSpc8DLQsGM+Q9jsVhJXBhSytnc86kRZZk/RBWkl6Vf3Q3jXcdfwNOuIWu9/UGIg kpiu1RHTIsBp46KtjKLtGaPsSLLMY9cGVLok0rNYJV21nXc6+m6qQhjO8dKqTUYgmtF8 Tw27TYGEqM3/9PCOoFjxRZncOyi30Ibwpe/smP/qj8sz1RbGubtr3d2/510lrzsJHaFW yAlEYTrBm/4dV34XjrxaD2qNeLWnZpLz/jgo8ji+gHGLz3f6ljIlRRulDzIJgCywAIYe TTDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=IpU7Ji1sKL5vugQKxXSx1HZfKXzI7odJerT2KGuI/ek=; b=1HZoRd9oLWy6QoqJiFgvPY6q1IuSfx4Ln5FTwGBm6DXX8OByWblwnLof/IeLQDVzIL alIvy6BPC05qcWpTxK74rPm7lCxy5pFKfRsbBeCcHaXILUPmJ13rRp8zHCNg1gHPEZcf iE54dCcnW7KWsgQ0LDrCWE51AI9lmG+WYNVKFZO7zRLQWBxezLY4cRKKm4OdpQL0Xzpn kRglEflnOe+0GNSHaJceOR9n1yVaOKfTHrDYKe0PMmHAO2vcBaa66IpDlvRv4L+MlUt1 DsHAst390kYyERGroKVPZ226+LZwnO91O9hMy49W23EFrnsU/vMmUwDSw/b8FJffAaN8 9IzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=EBmiv6ut; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k30si7958456pgf.531.2017.07.10.08.25.19; Mon, 10 Jul 2017 08:25:19 -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=pass header.i=@linaro.org header.b=EBmiv6ut; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754332AbdGJPZN (ORCPT + 25 others); Mon, 10 Jul 2017 11:25:13 -0400 Received: from mail-lf0-f46.google.com ([209.85.215.46]:32969 "EHLO mail-lf0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754256AbdGJPZL (ORCPT ); Mon, 10 Jul 2017 11:25:11 -0400 Received: by mail-lf0-f46.google.com with SMTP id z78so64899197lff.0 for ; Mon, 10 Jul 2017 08:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=IpU7Ji1sKL5vugQKxXSx1HZfKXzI7odJerT2KGuI/ek=; b=EBmiv6utI5CpY6WtGhuKUwbU8mznWJMg2uz4NkGvneNfgk/OUTGMEpXwk7IMXxw+Yb tb1DQ2gY3AcAfhk78S8RC0Rh1IQsMsC38UgQDo4b18Ha/6O8susgMzI7whATMOa5CjJW tTTE5V5NB+STV6kVCnmq+ib9Fc2bNHif90bv0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=IpU7Ji1sKL5vugQKxXSx1HZfKXzI7odJerT2KGuI/ek=; b=DmRSpScnMyeHFkjzFW6e4PjLwilQ2AAJhyryFMaTMVxHwL7kBIzP3xHa/5f6X9KSLZ YAwOIgpnPhh0GgOWD6C0FaPyn4Qg3O9D3EitTfaq2PHG6bEzEkFx+eQIWMZPAr/s8kva 7KFhiGj9Yw1W13w87DYRFm8KGOLbKtHxLEotMH2UgjbfjjjmKKJSMUPUVlHiz2WcGR4f CDLH+LhmCe+Y6sboRKsLP8sA3m5l077wsn+83OtCyUvgOm8gymmJqPz+ggY1YxTDX3m1 oiyY5phPm3Gq4XU3Hpb0FiR+uIwZf+87ELGqCz1AyGqw1jHtv7CJH6eyaeEtApsqEbx+ hSUQ== X-Gm-Message-State: AIVw1127XgExPbWRRS45hTQ1TutdIPg/7HDpk+1cRTu3s/6UPEiQk7cw jAPqTvFYoFuhHh2r X-Received: by 10.46.69.137 with SMTP id s131mr4927860lja.31.1499700304599; Mon, 10 Jul 2017 08:25:04 -0700 (PDT) Received: from fabina.bredbandsbolaget.se (c-8d7271d5.014-348-6c756e10.cust.bredbandsbolaget.se. [213.113.114.141]) by smtp.gmail.com with ESMTPSA id d62sm2745025lfd.55.2017.07.10.08.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 08:25:03 -0700 (PDT) From: Linus Walleij To: Philipp Zabel , Greg Kroah-Hartman Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Walleij , Joel Stanley Subject: [PATCH] serial: 8250_of: Fix regression in reset support Date: Mon, 10 Jul 2017 17:24:51 +0200 Message-Id: <20170710152451.5773-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.9.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org commit e2860e1f62f2 ("serial: 8250_of: Add reset support") introduced reset support for the 8250_of driver. However it unconditionally uses the assert/deassert pair to deassert reset on the device at probe and assert it at remove. This does not work with systems that have a self-deasserting reset controller, such as Gemini, that recently added a reset controller. As a result, the console will not probe on the Gemini with this message: Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled of_serial: probe of 42000000.serial failed with error -524 This (-ENOTSUPP) is the error code returned by the deassert() operation on self-deasserting reset controllers. Add some code and comments that will: - In probe() avoid to bail out if -ENOTSUPP is returned from the reset_deassert() call. - If reset_assert() bails out with -ENOTSUPP on remove(), try the self-deasserting method as a fallback. Cc: Joel Stanley Cc: Philipp Zabel Cc: Greg Kroah-Hartman Fixes: e2860e1f62f2 ("serial: 8250_of: Add reset support") Signed-off-by: Linus Walleij --- Philipp: please comment on this or ACK if it is the right approach. It sort of sets a precedent for handling different reset controllers from the consumer side. Another possibility is to modify the reset core such that .deassert() bails out silently if the controller only has .reset(), and .assert() just calls .reset() if the controller does not have .assert(). Actually I think the latter is more intuitive but it is also more intrusive. --- drivers/tty/serial/8250/8250_of.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) -- 2.9.4 diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c index 0cf95fddccfc..927ee8561c8d 100644 --- a/drivers/tty/serial/8250/8250_of.c +++ b/drivers/tty/serial/8250/8250_of.c @@ -138,7 +138,12 @@ static int of_platform_serial_setup(struct platform_device *ofdev, if (IS_ERR(info->rst)) goto out; ret = reset_control_deassert(info->rst); - if (ret) + /* + * If the deassert operation is not supported, this could be because + * the reset controller is self-deasserting and onlt supports the + * .reset() operation, so this is not a probe error. + */ + if (ret && (ret != -ENOTSUPP)) goto out; port->type = type; @@ -235,10 +240,14 @@ static int of_platform_serial_probe(struct platform_device *ofdev) static int of_platform_serial_remove(struct platform_device *ofdev) { struct of_serial_info *info = platform_get_drvdata(ofdev); + int ret; serial8250_unregister_port(info->line); - reset_control_assert(info->rst); + ret = reset_control_assert(info->rst); + /* If the assert operation is not supported, use pure reset() */ + if (ret == -ENOTSUPP) + reset_control_reset(info->rst); if (info->clk) clk_disable_unprepare(info->clk); kfree(info);