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 X-Spam-Level: X-Spam-Status: No, score=-10.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C28BC47089 for ; Thu, 27 May 2021 04:11:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27CB06139A for ; Thu, 27 May 2021 04:11:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27CB06139A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sholland.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:Subject:From:References:Cc:To:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=nd6XNtofUmgNTRmfQzQTI1B4xeIjN0iSq3EMsaabB3Y=; b=H2+ktg3mLykr45DKsoPmpVE14Y EkGF/xhzaXtD98wyEeXfyL3QgR7+n1ecu28fXXr7OOTM70rp09sVmLT2kYwQRJO5vTNP6RzJSRa87 xMV2T9pKogbM9jal7GEc9NVkXHQU5m1JUeUUDe7WifQ2r7URvHRAVADxdKn315Mw5SBZtiiu3jWtj HFEjplEyvlAYhzWAN+yGRhXhOpDgpKjbZYSYE8H+zNe0QrWIQs3IGb7SRRgpQh7wcq3BwAcyfiJTF u3PiaeMBcaGviX1Ir22Iq11o9YUT8RQe1t4HL4Aw88sErcFAIaZMAq3XLqoM1EnIVnSnCE5EvrBSL EvkWXLuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lm7Kk-002Hyp-L7; Thu, 27 May 2021 04:09:22 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lm7Kg-002Hw3-BK for linux-arm-kernel@lists.infradead.org; Thu, 27 May 2021 04:09:20 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 724BD5C008C; Thu, 27 May 2021 00:09:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 27 May 2021 00:09:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= to:cc:references:from:subject:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=F le4QsL0suhBg+31Rp9XpR54QEn82lcPFK4WnOHC9y4=; b=E5n39DFlE9DPPrm5d fqb+MXTvx1ky93KmhWbOEApEnlCLpN4gjsjD0vh1LUKsWv6xVyrFC+F8pF0miVqf lPRKF0dP3DiACFVBM/IBGcy5/9sejRb5dPmTxArjtdqVGqa2pMrhBGdbp4Gkq16H FsJ6UvHK7DPuARTaRmdHPiUjgGyTvQB2XRgHBnLfsDTDW/+gS8s+6hoQs3SxVd3l 3CXfIkPcQNqMBXTbPTJfR1ZLs4fD/fRaA3zN1Wrumpn7RxhYwyvcTe6+/oZhRqqq HP5eHCYb51ixHERmADlIkXiqKc47E1lJUlTwl/8plajyzLZjXJhmpChhCcrUpkwd OEyRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Fle4QsL0suhBg+31Rp9XpR54QEn82lcPFK4WnOHC9 y4=; b=K0MzeTldCxqdNn5dAZz/PBmcUldQmPxWg7FasuY4W0WbbHZlNT9BjQesj veO3jYgU0BzgPP8ubyJ+6hdjXINOZ9tZBhAE5U1NDZSxBORNDH4BoBw6baJM61wA lyKifXqYlBhq8nh5HpxDDitCYGHSkBhmVRHlkesGWcItr8g6f+mYO4UqtRiFQ5rL K0QTZDiXh3gwRruhwWCQ2Ghj7kLfIv6GsghBYIb6VQFVQxDAR/e7Gg8ZKpDBPMHP 1SSr1CBqYaFa7LYgqu356QYSahGcnQcApeRA4RJBQCR5iKIKhfGjGrrQ0p6EsXEF m24UJWGXeKs7gzVHj5rKuMq8LtsKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekgedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepvfhfhffukffffgggjggtgfesthekredttdefheenucfhrhhomhepufgrmhhu vghlucfjohhllhgrnhguuceoshgrmhhuvghlsehshhholhhlrghnugdrohhrgheqnecugg ftrfgrthhtvghrnhepheejgefhudeffeetleeigefgheetveeiteeuffehhfffkeeuvdff veffveetudefnecukfhppeejtddrudefhedrudegkedrudehudenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmuhgvlhesshhhohhllhgr nhgurdhorhhg X-ME-Proxy: Received: from [70.135.148.151] (70-135-148-151.lightspeed.stlsmo.sbcglobal.net [70.135.148.151]) by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 May 2021 00:09:10 -0400 (EDT) To: Maxime Ripard Cc: Alessandro Zummo , Alexandre Belloni , Chen-Yu Tsai , Jernej Skrabec , linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org References: <20210419014549.26900-1-samuel@sholland.org> <20210430090206.lybmygrt636nysoc@gilmour> <20210525082416.jkqmlkbdx6nhrens@gilmour> From: Samuel Holland Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider Message-ID: <70366b7a-f8e2-abaf-682b-998094095f59@sholland.org> Date: Wed, 26 May 2021 23:09:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210525082416.jkqmlkbdx6nhrens@gilmour> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210526_210918_486205_B177842F X-CRM114-Status: GOOD ( 28.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 5/25/21 3:24 AM, Maxime Ripard wrote: > On Sun, May 09, 2021 at 10:39:30PM -0500, Samuel Holland wrote: >> On 4/30/21 4:02 AM, Maxime Ripard wrote: >>> Hi, >>> >>> On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote: >>>> The sun6i RTC provides 32 bytes of general-purpose data registers. >>>> They can be used to save data in the always-on RTC power domain. >>>> The registers are writable via 32-bit MMIO accesses only. >>>> >>>> Expose the region as a NVMEM provider so it can be used by userspace and >>>> other drivers. >>>> >>>> Signed-off-by: Samuel Holland >>> >>> As far as I understood, you want to use those registers to implement >>> super-standby? If so, while it makes sense for the kernel to be able to >>> be able to write to those registers, I guess it would be a bit unwise to >>> allow the userspace to access it? >> >> I want the user to be able to pass information to the bootloader (to >> select a boot device, e.g. reboot to FEL). I also want the user to be >> able to read data stored to these registers by system firmware (e.g. >> crust writes exception information there). It's not really related to >> standby. > > What information do you want to provide? This looks like punching > through the abstraction layer provided by the kernel. I don't see how registering an NVMEM provider is punching through any abstraction layer. NVMEM _is_ the relevant abstraction layer provided by the kernel. What else would you suggest I use? > This is also an issue since it ties an ABI to the use of crust: if > there's another user for those RTC registers at some point, the > userspace would have no way to tell whether or not crust is being > used and might get complete garbage (compared to what crust usually > provides) instead. If the user chooses to interact with the NVMEM via sysfs, then the user has to deal with the consequences. This is equivalent to the user's responsibility when using, for example, /dev/mem or libusb. For the purpose of providing the abstraction, the actual data stored there is irrelevant. And if you want to partition up the registers to reserve for different users, that is what NVMEM cells accomplish. >> I would want to stack a nvmem-reboot-mode on top to give friendlier >> names to some of the numbers, but I don't see a problem with root having >> direct access to the registers. It's no different from /dev/nvram >> providing access to the PC CMOS RAM. > > And those solutions have issues too. efivarfs for example can totally > brick the system it runs on if the user has an unfortunate rm -rf. The sun6i RTC, like PC CMOS, is battery-backed RAM. efivarfs writes to flash. The magnitude of any such "danger" is vastly different between the two. (And I think we can do better than vendors who release those brickable EFI implementations.) Regards, Samuel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel