linux-kernel - Re: [Question] rtc wake behavior and sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201006070357.GF2804081@piout.net>
Date:   Tue, 6 Oct 2020 09:03:57 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Peter Geis <pgwipeout@...il.com>
Cc:     a.zummo@...ertech.it, "Rafael J. Wysocki" <rjw@...ysocki.net>,
        len.brown@...el.com, pavel@....cz,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-rtc@...r.kernel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [Question] rtc wake behavior and sysfs

On 05/10/2020 21:47:01-0400, Peter Geis wrote:
> On Mon, Oct 5, 2020 at 6:29 PM Alexandre Belloni
> <alexandre.belloni@...tlin.com> 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