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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CD3AC3527D for ; Mon, 4 Apr 2022 21:17:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379420AbiDDVTp (ORCPT ); Mon, 4 Apr 2022 17:19:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379592AbiDDRng (ORCPT ); Mon, 4 Apr 2022 13:43:36 -0400 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29ADE31DE7; Mon, 4 Apr 2022 10:41:39 -0700 (PDT) Received: by mail-oi1-f173.google.com with SMTP id 12so10784259oix.12; Mon, 04 Apr 2022 10:41:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Gm8Q9IkyRhAeqdPU+N8JCDzIc1jnZK1MiElDRAVrowg=; b=IUBHRZUR1CP3Z09zzwDN8OLdIU3U07bDFgwfp9DzAfLqHZSjUyvTkYVKDifPWhJDEY HgqG9FLdyQi2fqiXqgbicwQbZMmFUM11LmAPO+n2SXPgHr9O0D6HSBmpoCMoVhyBIZDn 9Sk/WyQ9G4n2IGYP5rlMdVnx/1qlvpb293G/i8NtkNHMXb8KdLkxdaSJo6IUeLf3tmuX W+qOksGIRnDK41UUGBq8Y1YP+Uw1AGiHGySiPenYLMiCZr5mthIBFSUOAKJS7CO2oFe3 enx5ldHm+i9K15O0+x0RXLqcupcO+9KdXHTvYIMcm+F4ueuvTVb3F5ifLAlJJTqOvAe9 RBvQ== X-Gm-Message-State: AOAM531zyOtAi5B5SKJweFoAFCSTnnHGT4vx/JXULeGC/nShkQWZ+4Ns A8ISAZey8ULra68Ig6B0Mw== X-Google-Smtp-Source: ABdhPJzSZ9WfFV7feWqE4tE2BP8FLwzfupkBO4Pv3m1nUPLK+RrkI1IoCe9ioNTKSDmYmbnfBAqL3Q== X-Received: by 2002:a05:6808:b0f:b0:2ec:f51d:ae0b with SMTP id s15-20020a0568080b0f00b002ecf51dae0bmr131491oij.67.1649094098466; Mon, 04 Apr 2022 10:41:38 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id r37-20020a05687108a500b000e20bfd86casm901587oaq.11.2022.04.04.10.41.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:41:37 -0700 (PDT) Received: (nullmailer pid 1597042 invoked by uid 1000); Mon, 04 Apr 2022 17:41:37 -0000 Date: Mon, 4 Apr 2022 12:41:37 -0500 From: Rob Herring To: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= Cc: Philipp Zabel , Frank Rowand , Lars Povlsen , Steen Hegelund , UNGLinuxDriver@microchip.com, Thomas Petazzoni , Alexandre Belloni , Allan Nielsen , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 0/3] add fwnode support to reset subsystem Message-ID: References: <20220324141237.297207-1-clement.leger@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220324141237.297207-1-clement.leger@bootlin.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Mar 24, 2022 at 03:12:34PM +0100, Clément Léger wrote: > This series is part of a larger series which aims at adding fwnode > support in multiple subsystems [1]. The goal of this series was to > add support for software node in various subsystem but in a first > time only the fwnode support had gained consensus and will be added > to multiple subsystems. The goal is describing a solution. What is the problem? What's the scenario where you have a reset provider not described by firmware providing resets to devices (consumers) also not described by firmware. > For the moment ACPI node support is excluded from the fwnode support > to avoid creating an unspecified ACPI reset device description. With > these modifications, both driver that uses the fwnode_ API or the of_ > API to register the reset controller will be usable by consumer > whatever the type of node that is used. Good, because controlling reset lines directly isn't how the ACPI device model works AFAIK. > One question raised by this series is that I'm not sure if all reset > drivers should be modified to use the new fwnode support or keep the > existing device-tree support. Maintainer advice on that particular > question will be welcome. That would be pointless churn IMO. Why do we need to convert drivers which the vast majority will never use anything but DT? Rob