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 F1F04C352A1 for ; Wed, 7 Dec 2022 07:56:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229670AbiLGH44 (ORCPT ); Wed, 7 Dec 2022 02:56:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229744AbiLGH4v (ORCPT ); Wed, 7 Dec 2022 02:56:51 -0500 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7CF3C30554; Tue, 6 Dec 2022 23:56:50 -0800 (PST) Received: from pecola.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id D92B2200E6; Wed, 7 Dec 2022 15:56:43 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1670399804; bh=uhJAeKSiEwcETVAy29NnoEcD5gNca+lhmYO7Gqq/BtY=; h=Subject:From:To:Date:In-Reply-To:References; b=dlKVQEOzmnyuL9qOvd5MCYxwIzAeVELA/XEmPXM+Z7IBbog/shMY/oITCseV4FXPM SSscjovRTYmUu8d89AQv6x4UxHKWbq7lZQYFJmEuTo3yTv8X31qzo+zE/cCpZ5tahq /zZSvIP0dXqdignAqDcjwcHkmEw63IaGz7+jLKetrIPy43UTsUo/MRKBd/7RKBA5Sn FdVV7AqKnj1F1t7+xe9QABb6L/SkpCWRyVIViNMPiOLTup5e42l99Edplx3+BjF8tH Bv0/DL/DmYA5VPZ93Aiu8viPqSXd2OfZTt7q74hoULFaFSPTJ/h4M1lAmZ3oD/twfV 3b2+VsndQCi+w== Message-ID: Subject: Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices From: Jeremy Kerr To: Arnd Bergmann , Philipp Zabel , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Lee Jones , Rob Herring , Krzysztof Kozlowski Date: Wed, 07 Dec 2022 15:56:42 +0800 In-Reply-To: References: <20221206073916.1606125-1-jk@codeconstruct.com.au> <20221206073916.1606125-3-jk@codeconstruct.com.au> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.1-1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Arnd, Thanks for taking a look a this. Just a question about the early approach; I'm not too familiar with the internals of the syscon/regmap infrastructure: > > reset_controller_register() only initializes a few fields in the > > passed rcdev structure and adds it to a static list under a static > > mutex, so there's not much of a limit. >=20 > Ok, in that case I think we should at least leave the option of > doing the reset from an early syscon as well. OK, sounds good - I'll add a direct of_reset_control_get_() in the early of_syscon_register path, which should work in a similar way to the clocks properties. However: this may conflict with the later platform_device syscon; if the late syscon tries to of_reset_control_get_exclusive() the same reset controller (because it's the same syscon node), that will (of course) fail. Hence a question about the syscon infrastructure: how are the late- and early- syscon registrations supposed to interact? Should I allow for there to be two syscons registered (one through of_syscon_register(), the other through the platform device probe), or do we expect that to never happen? In case of the former, I can just grab a shared handle to the reset controller instead, but I want to make sure that's the correct thing to do. Cheers, Jeremy