From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B268C282C3 for ; Thu, 24 Jan 2019 09:12:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40DCD20855 for ; Thu, 24 Jan 2019 09:12:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726080AbfAXJMC (ORCPT ); Thu, 24 Jan 2019 04:12:02 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:50713 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725986AbfAXJMC (ORCPT ); Thu, 24 Jan 2019 04:12:02 -0500 Received: from lupine.hi.pengutronix.de ([2001:67c:670:100:3ad5:47ff:feaf:1a17] helo=lupine) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1gmb3F-00088q-5O; Thu, 24 Jan 2019 10:11:57 +0100 Message-ID: <1548321116.6014.1.camel@pengutronix.de> Subject: Re: [PATCH v4 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs From: Philipp Zabel To: Andrey Smirnov Cc: Lucas Stach , Leonard Crestez , Fabio Estevam , Chris Healy , "A.s. Dong" , Richard Zhu , dl-linux-imx , linux-arm-kernel , linux-kernel Date: Thu, 24 Jan 2019 10:11:56 +0100 In-Reply-To: References: <20181220010700.8598-1-andrew.smirnov@gmail.com> <20181220010700.8598-3-andrew.smirnov@gmail.com> <1547743553.4009.16.camel@pengutronix.de> <1548240735.3904.8.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrey, On Wed, 2019-01-23 at 21:33 -0800, Andrey Smirnov wrote: > On Wed, Jan 23, 2019 at 2:52 AM Philipp Zabel wrote: > > > > On Thu, 2019-01-17 at 14:38 -0800, Andrey Smirnov wrote: > > [...] > > > > To be honest, I don't like these two, I'm not convinced anymore that > > > > they actually qualify as reset signals. To me it looks like this is > > > > something that the PCIe glue code should handle via syscon like i.MX6. > > > > Leonard, Lucas, what do you think? > > > > > > OK, one thing to keep in mind about this is that those bits are > > > already exposed for i.MX7D and I think (correct me if I am wrong) > > > there's no going back there. > > > > That's not a reason to repeat the same mistake for i.MX8QM, but at the > > moment I'm still trying to figure out if it actually was a mistake. > > > > It absolutely is. Ok, that was a sloppy expression. I'm glad you got my meaning anyway. Of course it is a reason, but it's not a good one. > Removing those resets will not meaningfully simplify > maintenance burden for this driver (a one line change), I'm less worried about the maintenance burden on this reset driver and more about lying in the device tree description and possibly setting a bad precedent. > but it will cause additional code churn on PCI side of things. > You may not agree with me that it is a _good_ reason to not to remove > those resets, but it is a reason nonetheless. Exactly. Code churn in one driver implementation should not stop us from fixing device tree bindings (in a backwards compatible fashion). Mind you, this is all under my assumption that the bits in question do not control resets and should never have been described as resets in the device tree. regards Philipp