linux-kernel - Re: [PATCH] serial: 8250: omap: Provide ability to enable/disable UART as wakeup source

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: <c43b081a-a94a-fb89-d2d7-9c4947bac4a6@ti.com>
Date:   Thu, 29 Mar 2018 11:02:03 +0530
From:   Vignesh R <vigneshr@...com>
To:     Tony Lindgren <tony@...mide.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH] serial: 8250: omap: Provide ability to enable/disable
 UART as wakeup source



On Thursday 29 March 2018 04:00 AM, Tony Lindgren wrote:
> * Vignesh R <vigneshr@...com> [180327 12:03]:
>> Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
>> return value of device_may_wakeup() in .suspend(). This allows
>> userspace to use sysfs to control the ability of UART to wakeup the
>> system from deep sleep state. Register is restored back in .startup()
>> call that happens as part of resume sequence.
>> 
>> With this patch, userspace can control UART wakeup capability via sysfs:
>> To enable wakeup capability:
>> echo enabled >  /sys/class/tty/ttyXX/device/power/wakeup
>> For disabling wakeup capability:
>> echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
> 
> To avoid confusion, can you please add this to the description:
> 
> Note that the UART wakeup events configured in the 8250 hardware only
> work for idle modes that do not cut off power for the UART. For deeper
> idle states, dedicated padconf wakeirqs must be used. Or in some cases
> the UART RX pin can be remuxed to GPIO input if the GPIO block stays
> powered.
> 

That makes sense, I will add it to patch description in v2.

> I tested this briefly and the dedicated wakeirqs still work for me,
> so from that point of view:
> 
> Tested-by: Tony Lindgren <tony@...mide.com>

Thanks for testing!

-- 
Regards
Vignesh