Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2130936pxb; Fri, 25 Mar 2022 11:37:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFzJ/4OYXWPr6z26cj6tuV0d2zJeYqLYMIYjXBodWnabuvX/C+65Lojdq8NIk39SFSwAbB X-Received: by 2002:a05:6a02:20c:b0:381:f276:98d6 with SMTP id bh12-20020a056a02020c00b00381f27698d6mr689263pgb.39.1648233465841; Fri, 25 Mar 2022 11:37:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648233465; cv=none; d=google.com; s=arc-20160816; b=RCq5vOwGRCGRKiOZu9NhWffU/PETIrEihu+hq8F0ONvS1Hdx0iTWv3A8NSYYN8biRX G1WuupL61I5QXILJN9mqpK1QYTBFn+g4WFy64tlB3R/HAn2yKxsg80Mca2O0qgtLknLf 2CxuojlsdTeU1AaMrpwOYkVp3ptmKs1tXSq+Oc0AhoWX+h+gFV5xaK1L+J8Z2YpoJXua fZgRMNc0RAvi/LXNcwQ63YCBvXoO+ODeig2JYHYf449XTxXAyeq7HEqdC3cPZE39aA8n iF9f7wGn0ET5Wdo/2Tgy9VIPtL4GKtOxK1ISF5OM6rmsn/SWoNIdPqQuMN0HoZ4FPemg 0mrQ== 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=ZhPSU24YY9mltlRMqZUGskBkBnB8OLkvXpa728pTDGY=; b=y+VZMY1JdnIa+imMyskhL2MuSnzgP5lNQtHn21UKGZidyWMsjQO5KzCQkfEttYIbTf L+nDjVcARg2f8V3Tnk61WZTmm5aD3SsUu9Bq6yDdoBE3g2hVjgZwWPbtsUheBrfN0PLl TjKjcn8rVN+TiVepxuBvvJ38P50xRtTsCuON4CXqDaVhCsuvlA4kT3o6tWZMQDwr8ZPB XYn5AJ7aaRcGgYCtJC3w2c3c2bO1+7OFysSUqkvtfDK1qfNQIPHTWi1JdwMDe/dmIZKq t/lRFKdEkYccmnTX2odv59NRr0lPIGfkg1eRVWPboT3ClQGspZjJtSyVziOcb45J0W5u 8IMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dkUjRBS0; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q3-20020a17090311c300b00153b2d1659dsi3327582plh.421.2022.03.25.11.37.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 11:37:45 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dkUjRBS0; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2C02A18FAD2; Fri, 25 Mar 2022 10:55:30 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236838AbiCXRYt (ORCPT + 99 others); Thu, 24 Mar 2022 13:24:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352237AbiCXRYq (ORCPT ); Thu, 24 Mar 2022 13:24:46 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B84F71CB20; Thu, 24 Mar 2022 10:23:13 -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 ams.source.kernel.org (Postfix) with ESMTPS id 7406FB82335; Thu, 24 Mar 2022 17:23:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7135C340EC; Thu, 24 Mar 2022 17:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648142591; bh=Ii6N9yX0cfvtlWGYsRFUlxpmnU5DBEOXCXBEVeUK1m4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dkUjRBS0vQTUg1Sz1AEMShGyKGTmbunTXyYN4gS3PEI7v7chIhQlEh4j9L7nEnwBW EKYR8C3DHrHaONiYk/yFDenQDWCxLA6w24pOc5ybAZyPHJ3cnvNa0IYihNl7omVObg 8cNRIAidGUVpmu9Qbws+svgUr0wbTc9JhBF6cI0PdxAGBm1gk+tBjOKZ4EFAqxKHhB Yj0QTkVK4AFTmN9JueLDEmjI44hjfzbBEEJ2aMip1SWLzb6XfWlfaHVh5jQAo2UI9x Tzvhc1zpzZeJTEnKATnOiybc7/c9hI5aenkYyFKvCcuHGylL5/fJHHQFhne2tJgG/l iW+VnVEFeutLQ== Date: Thu, 24 Mar 2022 17:23:05 +0000 From: Mark Brown To: David Collins Cc: Sudeep Holla , Rob Herring , Liam Girdwood , devicetree@vger.kernel.org, Cristian Marussi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Subbaraman Narayanamurthy , Stephen Boyd , Mike Tipton Subject: Re: [PATCH v2 0/2] regulator: scmi: add support for registering SCMI regulators by name Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="81Z0hAsjzpiu2TPf" Content-Disposition: inline In-Reply-To: X-Cookie: Orders subject to approval. X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 --81Z0hAsjzpiu2TPf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 22, 2022 at 06:12:33PM -0700, David Collins wrote: > Another problem is that, as with regulators, ID numbers could > unknowingly get out of sync between the platform and the agent. Using > clock domain names for referencing fixes both issues. This can be This is just saying that the hard coded IDs that the firmware and kernel use to communicate can get out of sync which is true no matter if those IDs are strings or if they're numerical, either way it's an ABI which can be broken. > > If the IDs are correct like the names, it is guaranteed. I see this > > ID vs name is more for some maintenance convenience because somewhere > > something else needs to changes or moved away from existing way of > > maintenance. > How do you quantify an ID number to physical regulator mapping as > "correct"? What happens if the mapping must be changed on the SCMI > platform side (e.g. a PMIC was added or removed, or the order that > regulators are listed in needs to change)? If the SCMI agent is blindly The whole point with the numbers being an ABI is that things must never be renumbered, just as if names are used the names can't be changed. If the numbering is changing that just sounds like bugs on the platform side. There's an implicit assumption in what you've written above that implementation details of the firmware should affect the IDs presented through SCMI which simply shouldn't be true, and indeed if the firmware can assign fixed strings it can just as well assign fixed numbers. --81Z0hAsjzpiu2TPf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmI8qPgACgkQJNaLcl1U h9ADUgf9F+Vf4g7qBC+8QlTTVuL2G2gfodUp02z5tMeeey6bl+LR16pl2v9gT7hB p2CJjMjVg8NZYrrhb7BwEoibIRppAy02Ehy+FRZNXpLUNtrZjskye0LqYJW2nVnv r/XEam7moUDXHEhQWOGz8pY8PTTE66kMytsL4tWpK6ERwyHonh7kEuLRdY5s0JLT haW0CXliardrk2R8uh3+Zk40wyq2NW+AcGrBarTE9EaJVVjg2WcPWgAnCeBXgQxw fJ01Gyz3VeWZdk0XGD3+b8DejXOsi5ltsGRDbzZd6cusY76qGUL+XzyQMJLnYwzX J/ksIIO1L4uR2q+DYs9zCnueo1ahmQ== =u7Hy -----END PGP SIGNATURE----- --81Z0hAsjzpiu2TPf--