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: <20150820225947.GB3769@piout.net>
Date:	Fri, 21 Aug 2015 00:59:47 +0200
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Joonyoung Shim <jy0922.shim@...sung.com>
Cc:	rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org,
	linux-samsung-soc@...r.kernel.org, stable@...r.kernel.org,
	a.zummo@...ertech.it, cw00.choi@...sung.com,
	k.kozlowski@...sung.com
Subject: Re: [PATCH v2] rtc: s3c: fix disabled clocks for alarm

On 12/08/2015 at 19:21:46 +0900, Joonyoung Shim wrote :
> The clock enable/disable codes for alarm have been removed from
> commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
> control") and the clocks are disabled even if alarm is set, so alarm
> interrupt can't happen.
> 
> The s3c_rtc_setaie function can be called several times with 'enabled'
> argument having same value, so it needs to check whether clocks are
> enabled or not.
> 
> Signed-off-by: Joonyoung Shim <jy0922.shim@...sung.com>
> Cc: <stable@...r.kernel.org> # v4.1
> ---
> This is v2 of prior patch "[PATCH 4/4] rtc: s3c: enable/disable clocks
> for alarm".
> 
> Changelog for v2:
> - commit messages is modified by Krzysztof suggestion
> - make to backportable patch
> - add Cc-stable
> 
>  drivers/rtc/rtc-s3c.c | 24 ++++++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 

Applied, thanks.

However, ...

> @@ -39,6 +39,7 @@ struct s3c_rtc {
>  	void __iomem *base;
>  	struct clk *rtc_clk;
>  	struct clk *rtc_src_clk;
> +	bool clk_disabled;
>  

This is quite unusual and I would say the principle of least
astonishment would require using clk_enabled and explicitly set it to
true in the probe. I don't expect a lot of changes regarding the clocks
in the probe so this is probably OK but doing so will require extra
carefulness.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ