Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp959664imm; Fri, 28 Sep 2018 09:30:53 -0700 (PDT) X-Google-Smtp-Source: ACcGV63/lloQdOJFsKW4fvn69fpgv+4igyY58hxxl9bGvu2zuKqwZiEcuyO4U17BdVPTBvrxenKu X-Received: by 2002:a62:2056:: with SMTP id g83-v6mr17686759pfg.165.1538152253498; Fri, 28 Sep 2018 09:30:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538152253; cv=none; d=google.com; s=arc-20160816; b=lD0hWKUI9mj24kKDyaATLbk20YCYOM6WmyP/HkNnNJ9G6TZsxS8ASoPkd0UMW/OQy+ k8cRjMckcl8yO4exU6b/8HolI8jK6n4zUWSKhT4N/lYaTaP0lJGtXFen3a5ceVEmVgaY Rucvo6nuAeB3oCdaKLfXdJYChxocMiaWMaojnkGvt2KzQOJGJC6s5HpKOJvdiy+AuZyu tqWEX6/l8Ri2TcP2B1Ffu6n9zRQ58PA8QwjX7huWV8lDkCoY8BRLnhMxa+wW0rtHjc2k jywvK9LJzW49N9CvqT2GDoX5NK2B83MoOwMQTMmyhRy/ZF6yVv20VH0BWqSOizrzXC0n 30MA== 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; bh=Tr6BDQnVfH6Usp30L04xWiJKMYgd2r2fC+up8Fsy4+k=; b=jB1Bw+cOWMFVc8A6QeROXnFrXvMWhUNGmtRLsUNf9INHphXILlieBk8uSMtXYXLUpu 6ytJW37n+a0d7Mvmc6JHOXMLFm18JnFLtfyHdEb+0nDpdPjm2l1YLnwclk8G7svD8Qkx ML2+RsshMUg+BtaD3sXie646AbmYouPT59pBVH1X25RFoMirLX56+Fe6sZYVyLXnqYks Bnbn/H2QlEhZCq9WIxBm1k4EUX/ap5OKM5BYqkZ3onMQzOhI9eAz4+2tUz/FBa6ZHQg4 cCDXilrbElJ4WtbGLzN3rXqLXQVBvJC847EcAFNB1RQTYLBsEJYKqGpCv7NXkRSZjmAD yzXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@synopsys.com header.s=mail header.b=W945o5qf; 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=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12-v6si5178494pga.81.2018.09.28.09.30.37; Fri, 28 Sep 2018 09:30:53 -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=@synopsys.com header.s=mail header.b=W945o5qf; 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=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728643AbeI1Wxe (ORCPT + 99 others); Fri, 28 Sep 2018 18:53:34 -0400 Received: from smtprelay4.synopsys.com ([198.182.47.9]:37098 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726934AbeI1Wxe (ORCPT ); Fri, 28 Sep 2018 18:53:34 -0400 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id D8BBB24E0F92; Fri, 28 Sep 2018 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1538152142; bh=/JD/Tezb0aJc21feiQLo0Y5EimHxriYofNL0REfYIeo=; h=From:To:Cc:Subject:Date:From; b=W945o5qfft6UFKptw47HnpTR+WFORpIgObxryPUfGufSSwORZmXZbmNIGlFEzDTI1 0Pe9ZXNT4Sz9Iy0vIYqiueeJkcXqbrPxVw79HrFGE2qdHTbMpfKreNePQfwJuBafHw ZoscynmNfsDnrCK5R8x6IGcZl7I8riP2jaimG08U2qndFdFWoAGsVgXgtfdW6dSLbM 1WRrjW5V+52YK1dmFs+EN1jqDduTJnmsK2uNZgBdXJbc2GUgi3GuMSCt3B4BTw+Uyj 3meGSD/xGI1n5D9uKycz0xXrw+CXp7WrMA3jG9MWOKKcIpusau/odQmFbNNdQRZ//b VuEgS85lV0OMw== Received: from paltsev-e7480.internal.synopsys.com (paltsev-e7480.internal.synopsys.com [10.121.3.38]) by mailhost.synopsys.com (Postfix) with ESMTP id 92412349D; Fri, 28 Sep 2018 09:28:59 -0700 (PDT) From: Eugeniy Paltsev To: Philipp Zabel Cc: linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org, Alexey Brodkin , Eugeniy Paltsev Subject: [PATCH v2] ARC: HSDK: improve reset driver Date: Fri, 28 Sep 2018 19:28:56 +0300 Message-Id: <20180928162856.4726-1-Eugeniy.Paltsev@synopsys.com> X-Mailer: git-send-email 2.14.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As for today HSDK reset driver implements only .reset() callback. In case of driver which implements one of standard reset controller usage pattern (call *_deassert() in probe(), call *_assert() in remove()) that leads to inoperability of this reset driver. Improve HSDK reset driver by calling .reset() callback inside of .deassert() callback to avoid each reset controller user adaptation for work with both reset methods (reset() and {.assert() & .deassert()} pair) Signed-off-by: Eugeniy Paltsev --- Changes v1->v2: * Don't call hsdk_reset_reset in .assert callback. drivers/reset/reset-hsdk.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/reset/reset-hsdk.c b/drivers/reset/reset-hsdk.c index 8bce391c6943..399440f197c5 100644 --- a/drivers/reset/reset-hsdk.c +++ b/drivers/reset/reset-hsdk.c @@ -84,8 +84,21 @@ static int hsdk_reset_reset(struct reset_controller_dev *rcdev, return ret; } +static int hsdk_reset_dummy(struct reset_controller_dev *rcd, unsigned long id) +{ + return 0; +} + +/* + * Doing real reset from .assert isn't necessary/useful here. So we pass + * 'hsdk_reset_dummy' to .assert callback to prevent -ENOTSUPP returning by + * reset_control_assert() to make happy drivers which check + * reset_control_{assert | deassert} return status. + */ static const struct reset_control_ops hsdk_reset_ops = { .reset = hsdk_reset_reset, + .assert = hsdk_reset_dummy, + .deassert = hsdk_reset_reset, }; static int hsdk_reset_probe(struct platform_device *pdev) -- 2.14.4