linux-kernel - Re: [PATCH] rtc: omap: let device wakeup capability be configured from chip init logic

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <AANLkTil3CqFL6ncfxOquYZOCDbU1iKtWmdw5p7xD-Iek@mail.gmail.com>
Date:	Thu, 13 May 2010 06:57:25 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Alessandro Zummo <a.zummo@...ertech.it>
Cc:	Sekhar Nori <nsekhar@...com>,
	Paul Gortmaker <p_gortmaker@...oo.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Tony Lindgren <tony@...mide.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
	rtc-linux@...glegroups.com
Subject: Re: [PATCH] rtc: omap: let device wakeup capability be configured 
	from chip init logic

On Tue, Mar 16, 2010 at 1:20 PM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
> From: Sekhar Nori <nsekhar@...com>
>
> The rtc-omap driver currently hardcodes the RTC wakeup capability
> to be "not capable". While this seems to be true for existing OMAP1
> boards which are not wired for this, the DA850/OMAP-L138 SoC, the
> RTC can always be wake up source from its "deep sleep" mode.
>
> This patch lets the wakeup capability to be set from platform data and
> does not override the setting from the driver. For DA850/OMAP-L138, this
> is done from arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc()
>
> Note that this patch does not change the behavior on any existing OMAP1
> board since the platform device registration sets the wakeup capability
> to 0 by default.
>
> Signed-off-by: Sekhar Nori <nsekhar@...com>
> Signed-off-by: Kevin Hilman <khilman@...prootsystems.com>
> ---
>
> Alessandro, with your ack, I can merge this one as well via the davinci
> tree.

Alessandro, do I have your ack for this one?

We agreed[1] that the main driver would go upstream via my davinci
tree so I may as well merge this one as well.  It's been in linux-next
for a while now, but I just realized I didn't have your ack.

Kevin

[1] http://marc.info/?l=linux-kernel&m=126844362130704&w=2

>  drivers/rtc/rtc-omap.c |   12 +++++++-----
>  1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 64d9727..73377b0 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -34,7 +34,8 @@
>  * Board-specific wiring options include using split power mode with
>  * RTC_OFF_NOFF used as the reset signal (so the RTC won't be reset),
>  * and wiring RTC_WAKE_INT (so the RTC alarm can wake the system from
> - * low power modes).  See the BOARD-SPECIFIC CUSTOMIZATION comment.
> + * low power modes) for OMAP1 boards (OMAP-L138 has this built into
> + * the SoC). See the BOARD-SPECIFIC CUSTOMIZATION comment.
>  */
>
>  #define OMAP_RTC_BASE                  0xfffb4800
> @@ -401,16 +402,17 @@ static int __init omap_rtc_probe(struct platform_device *pdev)
>
>        /* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE:
>         *
> -        *  - Boards wired so that RTC_WAKE_INT does something, and muxed
> -        *    right (W13_1610_RTC_WAKE_INT is the default after chip reset),
> -        *    should initialize the device wakeup flag appropriately.
> +        *  - Device wake-up capability setting should come through chip
> +        *    init logic. OMAP1 boards should initialize the "wakeup capable"
> +        *    flag in the platform device if the board is wired right for
> +        *    being woken up by RTC alarm. For OMAP-L138, this capability
> +        *    is built into the SoC by the "Deep Sleep" capability.
>         *
>         *  - Boards wired so RTC_ON_nOFF is used as the reset signal,
>         *    rather than nPWRON_RESET, should forcibly enable split
>         *    power mode.  (Some chip errata report that RTC_CTRL_SPLIT
>         *    is write-only, and always reads as zero...)
>         */
> -       device_init_wakeup(&pdev->dev, 0);
>
>        if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
>                pr_info("%s: split power mode\n", pdev->name);
> --
> 1.7.0.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/