Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3725908pxy; Tue, 4 May 2021 08:35:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwu2ltWrwWVlzmL1TWSudAB6R+4BEGU06itEfWSlhEdyjrVWtZYjnDbLR46lXcrA6YwM5h4 X-Received: by 2002:a17:90a:644b:: with SMTP id y11mr28000194pjm.229.1620142514578; Tue, 04 May 2021 08:35:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620142514; cv=none; d=google.com; s=arc-20160816; b=xFSO8CZkYtNb2N+x+2Rx7LGj8VfBCVjPrdBPBGXesQdrVhOK07JXUvzhfTXqOTKdEs YngYJAAC6UM1QJsAguLTox6qesHa4o7DzkVUXO7xtFGDb77L1Rj7XNA4KxXmVrhyYESW fm5Z9G68GWWOLytvZB3k/2a/uSu8wRSWwAYgESeHXTW3NtqDoMgkuyaQcHmp2Xiw4yiK B5BgoSwX7j43MMOLD8o5fVgBD5i0PUoCh2/v3qaeTrJ0CibD6GKM1uNjw/iFeBm2Wg+f Pj21uXwaIkXaem/SJlbfgQZac7Zck6nW03rLj9t/9Fe6wEVVtHMrgSRqo1qtYB0vq5RX el6A== 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; bh=PmQ6iSDPsmJLrRtJn8jtvSnIqJ6BQRJRfbyT2S7mugo=; b=gVDI/ulzU+swHhEi0pnSFeaCtGO1wq5PHdQx0Wi5Jun1n8OgtlTV5is4og0rDICd9n 5I95anoj5mlMiQeJaMhkwLfQ3yJXk0xlxnVutzWKdWp5ES6prGTGTaWsrDrrJzT53Vpe cQrwZydXpEElkzpCWlqU0wpPMZOmMlPXQXyvnhZox79SnOmC84Vyidpbnv3RC12DNv60 0L07MvCbR2Y2ZTpqYo174uGn0v5+uJp94xYFMje3u4NMCG4Q9dSNhkRQ6UhKcag34KwO P6y6ivZ55QMzieshLS9LA0tVxOhUI5EnUs0KAx4iZBabXmCjTjP5mtvKMHd54jsgUTSg D2qQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v32si3886604pga.107.2021.05.04.08.35.01; Tue, 04 May 2021 08:35:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230385AbhEDPe6 (ORCPT + 99 others); Tue, 4 May 2021 11:34:58 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:54805 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230112AbhEDPe5 (ORCPT ); Tue, 4 May 2021 11:34:57 -0400 X-Originating-IP: 90.65.108.55 Received: from localhost (lfbn-lyo-1-1676-55.w90-65.abo.wanadoo.fr [90.65.108.55]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2AB0A1C0007; Tue, 4 May 2021 15:33:59 +0000 (UTC) Date: Tue, 4 May 2021 17:33:59 +0200 From: Alexandre Belloni To: Maxime Ripard Cc: Samuel Holland , Alessandro Zummo , 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 Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider Message-ID: References: <20210419014549.26900-1-samuel@sholland.org> <20210430090206.lybmygrt636nysoc@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210430090206.lybmygrt636nysoc@gilmour> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/04/2021 11:02:06+0200, 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 would think nvmem is still the proper subsystem. I guess maybe we should have a version of __nvmem_device_get that would ensure exclusive access to a cell, thus preventing userspace accessing it as long a the kernel is using it. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com