Received: by 10.223.185.116 with SMTP id b49csp789219wrg; Wed, 14 Feb 2018 07:03:18 -0800 (PST) X-Google-Smtp-Source: AH8x226l+92yIPdW94IZEagu7xNFPshATU3byUb3MJs0I8CmAVjzZhCdsDPBnvsviyege4NrKMTf X-Received: by 10.99.97.68 with SMTP id v65mr4205938pgb.104.1518620598176; Wed, 14 Feb 2018 07:03:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518620598; cv=none; d=google.com; s=arc-20160816; b=IBAa3WcP/l3eS5U1C3qN5ceAM7tAzc9tx1ahHmQr0I0h9HC5xLuyfrnMAoQBXj2+11 rO8VElmkjykURwReO1tNyRjto6KrvdSb+kSLvNDJog9IWYspyqw396bXxjSmOuewfk8s lFoYZinMADar0KtHP0ab3HoVCUbKx4eDyuCfdInH6wjwaYMYf3g0NOJ4s0tvzETqqPXJ XyRugPrZ/IS63HK2VZsEudQveWqLVVODK1bDmu7qdz5F84PCtLeK+UfW7VPadx9kb+p+ 8tiHC435m4rT6laaD+9GRdfh1LNqbCPhxjsZgTns2ilFNeRLqq751lZLd3+MHrif+HXy ikdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=jD+lzx4HLXKQq+7pDXF65K01dWtIewMGNnSQGqK8Uzo=; b=ET2sWAl9Zv1DOcD0Vq9v8NH1O6QT4v6EpZi9qcom8oKe2O908gzI2awYhgNT3963OL GlTITziOYz2G+IzfuHCpMW9kkNH+fkP55M2zL5Rjf59OdnHDPYZoe0EDYFQbG4ch7VYI abBlrDge+/gZ0OJ9HFo7Qo3ypN4NrUA/nVb572tW3OPbaUvyfdBTgCjxORw7TtzjEHiy b+CPeYRS7Vjkd9ucGMFo5QfBYjJu+HiGKsYtsvpY5RXgWYLskNYrQzuniWnk6uNhSUQ2 wrBkOnCl1tsM3tPk4qYoF+2x8GFIwu8OKDAHC3dYKri1qBG47bL6pO0HhVlyEGY2Giys FDZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=IjzcEGRL; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 124si2195809pgj.673.2018.02.14.07.02.48; Wed, 14 Feb 2018 07:03:18 -0800 (PST) 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=@ti.com header.s=ti-com-17Q1 header.b=IjzcEGRL; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031007AbeBNPAw (ORCPT + 99 others); Wed, 14 Feb 2018 10:00:52 -0500 Received: from fllnx209.ext.ti.com ([198.47.19.16]:63078 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030382AbeBNPAu (ORCPT ); Wed, 14 Feb 2018 10:00:50 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id w1EExq0u008173; Wed, 14 Feb 2018 08:59:52 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1518620392; bh=hv+V11vTc3NGkgp2ish9czFpMjlnSnDYLoGy3wtcoeE=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=IjzcEGRLqgetpZHyIdevJW3sjfn4TfRZE8OEEuqKbfCSgixGPM74gtoZ7mKa++n8G L1vVgvYRkXyRLbEpQrJsj6Q1+OwsHY7MS3/dBEXYfhxjkwMnPU6tyRQFTWnstmWR44 XA2k4T0MLrb5RCYuadeGznysf5YWuH4oW3NT2pTY= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w1EExqrO022007; Wed, 14 Feb 2018 08:59:52 -0600 Received: from DLEE106.ent.ti.com (157.170.170.36) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 14 Feb 2018 08:59:51 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DLEE106.ent.ti.com (157.170.170.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Wed, 14 Feb 2018 08:59:51 -0600 Received: from [172.24.190.171] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w1EExndn013316; Wed, 14 Feb 2018 08:59:50 -0600 Subject: Re: [PATCH v2] reset: add support for non-DT systems To: Bartosz Golaszewski , Philipp Zabel CC: , Bartosz Golaszewski , Kevin Hilman , David Lechner References: <20180213183946.1662-1-brgl@bgdev.pl> From: Sekhar Nori Message-ID: <65b864b2-e8dc-cf69-5c8e-f94b7f4fd640@ti.com> Date: Wed, 14 Feb 2018 20:29:48 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180213183946.1662-1-brgl@bgdev.pl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 14 February 2018 12:09 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The reset framework only supports device-tree. There are some platforms > however, which need to use it even in legacy, board-file based mode. > > An example of such architecture is the DaVinci family of SoCs which > supports both device tree and legacy boot modes and we don't want to > introduce any regressions. > > We're currently working on converting the platform from its hand-crafted > clock API to using the common clock framework. Part of the overhaul will > be representing the chip's power sleep controller's reset lines using > the reset framework. > > This changeset extends the core reset code with a new field in the > reset controller struct which contains an array of lookup entries. Each > entry contains the device name and an additional, optional identifier > string. > > Drivers can register a set of reset lines using this lookup table and > concerned devices can access them using the regular reset_control API. > > This new function is only called as a fallback in case the of_node > field is NULL and doesn't change anything for current users. > > Tested with a dummy reset driver with several lookup entries. > > An example lookup table can look like this: > > static const struct reset_lookup foobar_reset_lookup[] = { > [FOO_RESET] = { .dev = "foo", .id = "foo_id" }, > [BAR_RESET] = { .dev = "bar", .id = NULL }, > { } > }; > > where FOO_RESET and BAR_RESET will correspond with the id parameters > of reset callbacks. > > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: David Lechner > Signed-off-by: Bartosz Golaszewski This should really help get rid of the private davinci_clk_reset_assert() API. Thanks for getting this done. I noticed that the array based API still remains DT only. Its not a concern for DaVinci so it can probably be supported when its really needed. Reviewed-by: Sekhar Nori Thanks, Sekhar