From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E922231A21; Wed, 29 Oct 2025 19:44:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.153 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761767051; cv=none; b=JTXSNOYywEXqd8GhjYzhLWUa8mBIqz5Rt+fMmUojmlGGt189BJaU8ioQquba3FmwXPBXGaoQWWJOeCIu/68suz2N75Ac7z9tGmfHAF0FOA+g+UIod1zYXnCI4gaDnEnUETatlNuoEiFxieTje9AIRK7IidZqLBmQfRKHuh9CgDw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761767051; c=relaxed/simple; bh=aNDdmYw2elfYdy4M78GQ5YNtZ3s9q3s66tvcmf1yMiw=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=dOB+NG5gUnCEpYlGlKL3YQTjV5EhdAw8JzBor+x+FzH76DnhtasMRVjU2Cvh1LePVxPwGqxvYu+95IcKGdxPld8TFCZ1qw4nmCf8XCOuuzfn0G8o5Knr1JGEJVP9oMhUS2gDFinRlKlAmJWmbadmIyaW68MfaYsfJA/U2YK1tgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=JDX03KMC; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=tJNT36Q5; arc=none smtp.client-ip=103.168.172.153 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="JDX03KMC"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="tJNT36Q5" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3B2BF1400126; Wed, 29 Oct 2025 15:44:05 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-04.internal (MEProxy); Wed, 29 Oct 2025 15:44:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1761767045; x=1761853445; bh=QRy1TWnz9b3IslGsVJisdAEmqAzlqSPRloIKecHxR6g=; b= JDX03KMCRYwJu1Rejr/b3osU8xRpbi7kp9U2QH/al3iTS+e0AK/Den1RS3iDcTJx Xb0klpvE5XXLi3RG7tKJulu9TJ4HsDFDuv5d4lAItmBkTcy/VPP1by327JD0qAcH YPBcn1RwtbEiTo6jK8qDeu1fKjZ+z2eNCtlBANNJvP5iNIoP0lZ7GPNqY4O47qoV D92Z6f8hu0rM49pemFP81zRTTTg0vWFOyyh8+Sdx9u4UmWz2jMpyqYbRsKbdmL+0 bt8qY4CgQqMdcT96ehgyQNtEWYrpa806WlxYKANJsmvj03VnDdCntx3pUfds0FHW cPQ0pMPS+Ig+2OX1xqZFPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1761767045; x= 1761853445; bh=QRy1TWnz9b3IslGsVJisdAEmqAzlqSPRloIKecHxR6g=; b=t JNT36Q59TJDqXUdwjZ5o8FY9VMNU+SSWU4so7g6kB5eEsJ84+TPrtN5rytDtaiw9 iN+JSEuKsbn4beZ8qNdQwwdUpghRM6MpDG019qwatAxP5/l94l3NdYjwL4gBgRDK NIqbUduX7ulKfiW+LVvtMLz2QE6QK+adTSMBwcjm3j7Ms4uxX0ame6NZlMO2gdJV 11XvZh7h+XlJM3/6a53Mk+5+1dmrgLtB5bBGvCUYiy4SHTEAKLXxisSLELuLYdx3 bXaOxzA9KX8E6JrpKuvgMGa/A8biyQWhE3f1ipGs1DRFtcbOUDVgl6+C8sZsBkXq fGqzibP1TxQZ+xGgmnVlg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduieegiedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrnhgu uceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrthhtvg hrnhephfdthfdvtdefhedukeetgefggffhjeeggeetfefggfevudegudevledvkefhvdei necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnh gusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohepledpmhhouggvpehsmhhtphhouhht pdhrtghpthhtoheptghonhhorhdoughtsehkvghrnhgvlhdrohhrghdprhgtphhtthhope hkrhiikhdoughtsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlvggvsehkvghrnhgv lhdrohhrghdprhgtphhtthhopehrohgshheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoh eprghnughrvgdrughrrghsiihikheslhhinhgrrhhordhorhhgpdhrtghpthhtohepuggr nhdrtggrrhhpvghnthgvrheslhhinhgrrhhordhorhhgpdhrtghpthhtohepphgvthgvrh drghhrihhffhhinheslhhinhgrrhhordhorhhgpdhrtghpthhtohepuggvvhhitggvthhr vggvsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrh hnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id C9E1B700054; Wed, 29 Oct 2025 15:44:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AK9Cqudmt2dw Date: Wed, 29 Oct 2025 20:43:33 +0100 From: "Arnd Bergmann" To: "Dan Carpenter" , "Lee Jones" Cc: "Conor Dooley" , devicetree@vger.kernel.org, "Krzysztof Kozlowski" , linux-kernel@vger.kernel.org, "Rob Herring" , =?UTF-8?Q?Andr=C3=A9_Draszik?= , "Peter Griffin" Message-Id: <3fd4beba-0d0b-4a20-b6ed-4e00df109b66@app.fastmail.com> In-Reply-To: References: Subject: Re: [PATCH 0/2] mfd: syscon: introduce no-auto-mmio DT property Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Oct 29, 2025, at 18:27, Dan Carpenter wrote: > Most syscons are accessed via MMMIO and created automatically. But one > example of a syscon that isn't is in drivers/soc/samsung/exynos-pmu.c > where the syscon can only be accessed via the secure partition. We are > looking at upstreaming a different driver where the syscon will be > accessed via SCMI. > > Normally, syscons are accessed by doing something like > syscon_regmap_lookup_by_phandle_args() but that function will > automatically create an MMIO syscon if one hasn't been registered. So > the ordering becomes a problem. The exynos-pmu.c driver solves this > but it's a bit awkward and it would be even trickier if there were > several drivers accessing the same syscon. What would happen on the current exynos platform if we just take away the 'regs' property? I would hope that we can avoid encoding what is essentially operating system policy in that driver and instead just describe it as a device that expects to be implemented by firmware and doesn't need registers? In new syscon devices that need both cases, we can then start doing it that way at the beginning. Arnd