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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 3B8B5C46466 for ; Tue, 6 Oct 2020 07:04:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EEFD920760 for ; Tue, 6 Oct 2020 07:04:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727117AbgJFHEB (ORCPT ); Tue, 6 Oct 2020 03:04:01 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:49463 "EHLO relay8-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726761AbgJFHEA (ORCPT ); Tue, 6 Oct 2020 03:04:00 -0400 X-Originating-IP: 90.65.88.165 Received: from localhost (lfbn-lyo-1-1908-165.w90-65.abo.wanadoo.fr [90.65.88.165]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id BAF111BF203; Tue, 6 Oct 2020 07:03:57 +0000 (UTC) Date: Tue, 6 Oct 2020 09:03:57 +0200 From: Alexandre Belloni To: Peter Geis Cc: a.zummo@towertech.it, "Rafael J. Wysocki" , len.brown@intel.com, pavel@ucw.cz, Greg KH , linux-rtc@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org Subject: Re: [Question] rtc wake behavior and sysfs Message-ID: <20201006070357.GF2804081@piout.net> References: <20201005222953.GD2804081@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/10/2020 21:47:01-0400, Peter Geis wrote: > On Mon, Oct 5, 2020 at 6:29 PM Alexandre Belloni > wrote: > > > > On 05/10/2020 09:13:08-0400, Peter Geis wrote: > > > Good Morning, > > > > > > While testing suspend to ram on the Ouya, I encountered an interesting > > > issue with the rtc-tps65910 driver. > > > Attempting to use rtc-wake on the default configuration returned: > > > rtcwake: /dev/rtc0 not enabled for wakeup events > > > This is due to: > > > eb5eba4ef722 drivers/rtc/rtc-tps65910.c: enable/disable wake in suspend/resume > > > This commit changed this driver's behavior to not enable wakeup by > > > default, but enables it when entering sleep mode. > > > This seems to be odd behavior to me. > > > Looking at a few other rtc drivers show they simply enable themselves > > > as wakeup sources by default. > > > > > > I also found the sysfs entries are at /sys/devices/ .. > > > /tps65910-rtc/power but are missing at /sys/class/rtc/rtc0/power/ > > > > > > I have two questions. > > > - Should the sysfs wakeup entries be missing at /sys/class/rtc/rtc0/power/ ? > > > > I would be in /sys/class/rtc/rtc0/device/power > > > > > - Shouldn't a rtc be enabled as a wakeup source by default? > > > > > > > The short answer is no, the reason being that not all RTCs are connected > > to an IRQ or a pin that can wakeup or start the platform. What should be > > done is enabling wakeup only when interrupts are available or the > > wakeup-source property is in the rtc device tree node. > > Thank you for your explanation. > > So it would seem we have two issues. > - The sysfs wakeup entries are not populating in > /sys/class/rtc/rtc0/power when they are populating in > /sys/devices/<..>/tps65910-rtc/power. I think the rationale here is that the rtc device is not the wakeup device but the underlying one is hence why it is in /sys/class/rtc/rtc0/device/power and not in /sys/class/rtc/rtc0/power/. > - The wakeup-source property is not being applied to the tps65910-rtc > sub-device when it is applied in the tps65910 devicetree node. > > Should wakeup-source handling be the tps65910-rtc driver's > responsibility, or is that a limitation of the driver core that needs > to be fixed? For now, parsing this property is left to the individual drivers. You'll have to implement it for the tps65910 and so you can get it from the parent node if necessary. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com