From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1429826AbdDYKdi (ORCPT ); Tue, 25 Apr 2017 06:33:38 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:42377 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1428911AbdDYKd2 (ORCPT ); Tue, 25 Apr 2017 06:33:28 -0400 Message-ID: <1493116400.2394.32.camel@pengutronix.de> Subject: Re: [PATCH V3 4/4] soc/tegra: pmc: Use the new reset APIs to manage reset controllers From: Philipp Zabel To: Jon Hunter Cc: Vivek Gautam , swarren@wwwdotorg.org, balbi@kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org, thierry.reding@gmail.com, gregkh@linuxfoundation.org, linux-arm-msm@vger.kernel.org, Thierry Reding Date: Tue, 25 Apr 2017 12:33:20 +0200 In-Reply-To: References: <1492514488-27385-1-git-send-email-vivek.gautam@codeaurora.org> <1492514488-27385-5-git-send-email-vivek.gautam@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:3ad5:47ff:feaf:1a17 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-04-25 at 11:05 +0100, Jon Hunter wrote: > On 25/04/17 05:15, Vivek Gautam wrote: > > On 04/24/2017 06:15 PM, Jon Hunter wrote: > >> On 18/04/17 12:21, Vivek Gautam wrote: > >>> Make use of reset_control_array_*() set of APIs to manage > >>> an array of reset controllers available with the device. > >> Before we apply this patch, I need to check to see if the order of the > >> resets managed by the PMC driver matter. Today the order of the resets > >> is determined by the order they appear in the DT node and although the > >> new APIs work in the same way they do not guarantee this. So let me > >> check to see if we can any concerns about ordering here. Otherwise would > >> be nice to use these APIs. > > > > Right, that will be perfect. > > So I don't see any restrictions here and so I think this change is fine. Thank you for checking. > BTW, for the DT case, is there any reason why we don't just say the > order will be determine by the order the resets are list in the DT node? I'd rather not make any promises, so I don't have to care about keeping them. This makes it easier to think about and allows for more freedom in changing the core code if needed. What if in the future there is a use case for enabling a bunch of resets by flipping a number of bits in a single register at the same time? Or if people accidentally depend on the ordering when in reality there is a small delay necessary between assertions that just happens to be hidden by the framework overhead? If there is a use case for an array of reset controls that must be (de)asserted in a fixed order and doesn't need any delay between the steps and is not suitable to be described by named resets for some reason, we can discuss this. Until then, I'm happy that tegra pmc can handle arrays without any particular ordering. regards Philipp