Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4759326iog; Wed, 22 Jun 2022 05:26:57 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vYouOMLMd3EJgTcArYjK80TAr2eE+p0GBXH2Q3DwbfrU/PyogRu0YaTEyW8eHDq16hvThm X-Received: by 2002:a17:906:6a1c:b0:70a:fd95:ee6a with SMTP id qw28-20020a1709066a1c00b0070afd95ee6amr2956154ejc.36.1655900817262; Wed, 22 Jun 2022 05:26:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655900817; cv=none; d=google.com; s=arc-20160816; b=poj/8hfCGCcywEMgXiQy5vUNqYeJHVDM5KUymdcF9JJqNQFtO5oKZVlv5NJavgZyb7 ZXpaKIZZW7CImlSaDYSRWs9qQue7ER+KYaPcFHlIAI21wgnfKx73Va119b3pohQtjY4X yw0CjWDKsLgbBnIjTeKMdqQ96zPsbuLardpT00qODumVgh790gaIkXbwMC/Nc5EDsl35 1fCze352kxdwa2cnDU66DiyyqGHDu2gmv3c+ByDC+O6MJAxIeVNvNPqptU6JjBIiKl7I w087TCEFxJbtedFYorjXPDGE9j5SPJyqUQiwwlffWE09zaUxUKwUP9DxsiTjChj5r4rs tU0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/ZLvFGn5tCyiyPGF6eSFkkWFsQEYCi/DhkEMm38J3pQ=; b=CJfnkd/cIVe6UZGY5IRSkG9E5BrmyIW/J8+pB6PkpNPZrW0ZRKRHcWuH75YPUtKrS0 vu0r/Y+HgPFaBR3S0XGh/9CPTu4m2Dz5kbZ2jwUfCW256L91EnlDXSabv2boNV00BG2j Ej7Sq3lc9juMs+W7J6GibwwdeB4J0LPQTH/GYL+QJjd0Uvv3BvREacAhCT8wwUF6p8ny t17cHPrk70jCHpLmqFvy3g2wK3B3LrwX71tFDsA8kSxJ0Axl1H4set/Neg+8ki6K04uc bDEkUxXcQS7E273r6OaZdaPvHBcKPC/G0TblpawziPVvIjyTMnowZ5j6WwjgRrf8VthT xjJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TwqvsZlM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id js5-20020a17090797c500b00702f7cc84b3si5182328ejc.47.2022.06.22.05.26.29; Wed, 22 Jun 2022 05:26:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TwqvsZlM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236836AbiFVMZ1 (ORCPT + 99 others); Wed, 22 Jun 2022 08:25:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231184AbiFVMZR (ORCPT ); Wed, 22 Jun 2022 08:25:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E9CA344CE for ; Wed, 22 Jun 2022 05:25:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C7103618EC for ; Wed, 22 Jun 2022 12:25:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91EB3C3411B; Wed, 22 Jun 2022 12:25:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655900709; bh=66Ai0jmOleHM0/MLlKM55knutcIWjWBHUpIcmAG661g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TwqvsZlMirwNizSWpNzV4Qc2aF0KxrS2tE8whw6bU1qMGpWPWVv+5/qkVXX70YqI5 YZeJ+sy8OAQ2VgmbejeCsE5I4ND5eIHwD8dlNUb4eGmkY+avUjFOKJvsQJ/Pyy6J/j sG4hn6UJbs7G9wVcvScBrVtPjAp8RzSiuf3eN28sKK1u6v1Ka2Gqzd3gvwHIXvPlhM AL69frrV7Rx48JJyHCaOYWI+jdr89GwpHqT7Iz8soqUI8vi3/T5e25fDWAPIhQw/lV cczWPnorSF4dx4VwTVZkd2gBn2VEIe8JZMJMZpECuvtAz/ocpaXHVyq56WnxX/TCbN 4qW5QYVaRcNkA== Date: Wed, 22 Jun 2022 13:25:04 +0100 From: Mark Brown To: Lucas Stach Cc: Aisheng Dong , "linux-kernel@vger.kernel.org" , "dongas86@gmail.com" , Peng Fan , "shawnguo@kernel.org" Subject: Re: [PATCH RFC 1/2] regmap: add option to disable debugfs Message-ID: References: <20220620134758.1286480-2-aisheng.dong@nxp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2exi8FfNrXBHFDBX" Content-Disposition: inline In-Reply-To: X-Cookie: Truckers welcome. X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --2exi8FfNrXBHFDBX Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 22, 2022 at 10:08:10AM +0200, Lucas Stach wrote: > Am Dienstag, dem 21.06.2022 um 18:16 +0000 schrieb Aisheng Dong: > > 1. There's a warning dump if using cache_only without cache > > void regcache_cache_only(struct regmap *map, bool enable) > > { > > =A0=A0=A0=A0=A0=A0=A0=A0map->lock(map->lock_arg); > > =A0=A0=A0=A0=A0=A0=A0=A0WARN_ON(map->cache_bypass && enable); > > =A0=A0=A0=A0=A0=A0=A0=A0... > > } > > 2. It seems _regmap_write() did not handle cache_only case well > > without cache. > > It may still writes HW even for cache_only mode? > >=20 > > I guess we may need fix those two issues first before we can safely > > use it? > Why would you write to a cache only regmap. The debugfs interface only > allows to dump the registers, no? One of the use cases is where you've got settings that can be changed while the device is idle and just map those directly onto the registers, syncing the cache to the device when it gets powered up for actual use. This can only be done when there's a cache, and won't apply to a lot of devices. There is debugfs code to do writes but you have to modify the kernel to enable it, there's no config option for it upstream. > I think it wouldn't be too hard to fix this for the blk-ctrl drivers. > I'll give it a try today. The other thing is that even with the bodge to just turn debugfs presumably any case where the driver would try to write to a powered off device is still a bug that needs fixing anyway - having a regmap in cache only mode will translate it into a warning rather than a write that goes AWOL or otherwise fails. > > > That's a different thing, that's due to us naming the directory > > > after the struct > > > device but syscons being created before we have that struct device > > > available. > > Yes, but syscon has the same issue that the system may hang if dump > > registers > > through debugfs without power on. > > How would you suggest for this case as syscon is also a common > > driver? > This is a general issue. If something uses a syscon that is inside a > power-domain where the runtime PM is controlled by some other entity, > how is it safe to use the syscon at all? Every access might end up > locking up the system. So those syscons really need to learn some kind > of runtime PM handling. Right. If you can interact with the device safely there's no need to put it into cache only mode and you don't need to worry about managing things (this should be the normal case for system controllers). If you can't interact with the device without powering it up then you still have to worry about doing that regardless of what regmap is doing, if anything I'd guess the warnings from regmap might be easier to debug than the hardware misbehaviour. Please delete unneeded context from mails when replying. Doing this makes it much easier to find your reply in the message, helping ensure it won't be missed by people scrolling through the irrelevant quoted material. --2exi8FfNrXBHFDBX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmKzCh8ACgkQJNaLcl1U h9DYzgf+PvdXgiM8kQsAwpjkZSdPzQQkLyVwJ2psQabROP7ycvk7NPs2Ds6Z21M2 tAKQL5jHOE3jvs+08LkWLS5necn05+kY8w+KDUKM2lSSdGQC9hvyPWSokLMqaCSb vEDoL084fdJahjZWmQDZMfkQc9QjzD/JAIF6qIppnUa9oXiOu7AinSHU7CjehOSv oJ6AUG3IhAWVQ39X9Tm4OkKeIYPF4f2b8WGkSWp2lCZmlclt8sok/T9VLBQVFJDH /q6AigrZ96xZdMHCFQf8dUNOammOY9wkGJNFKomLws23qPLhh7qecJxuW9KvUknr mRhNTdjgaBBDUrzJN9jfSCM/kv7Mcg== =1ahr -----END PGP SIGNATURE----- --2exi8FfNrXBHFDBX--