From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S939754AbdEZDc3 (ORCPT ); Thu, 25 May 2017 23:32:29 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:33313 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S939040AbdEZDc1 (ORCPT ); Thu, 25 May 2017 23:32:27 -0400 From: Joel Stanley To: Philipp Zabel , Rob Herring , Mark Rutland Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Benjamin Herrenschmidt , Andrew Jeffery Subject: [PATCH 0/2] reset: Basic reset controller Date: Fri, 26 May 2017 13:32:12 +1000 Message-Id: <20170526033214.8081-1-joel@jms.id.au> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, In the Aspeed SoCs we have some reset registers spread out in various parts of the soc: in the system controller IP, as well as other peripherals. I need to be able to deassert those resets before other drivers work. In writing a driver to do this I realised it was very generic. So instead I've sent a generic driver that can be used by the device tree to clear reset lines described by single bits in a register. Let me know what you think of the idea. I've tested this driver on our SoC to release the UART reset. Joel Stanley (2): dt-bindings: reset: Add bindings for basic reset controller reset: Add basic single-register reset driver .../devicetree/bindings/reset/reset-basic.txt | 31 ++++++ drivers/reset/Kconfig | 6 ++ drivers/reset/Makefile | 1 + drivers/reset/reset-basic.c | 109 +++++++++++++++++++++ 4 files changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt create mode 100644 drivers/reset/reset-basic.c -- 2.11.0