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] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 3 Dec 2012 13:42:25 +0800
From:	Chao Xie <xiechao.mail@...il.com>
To:	Haojian Zhuang <haojian.zhuang@...il.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Chao Xie <chao.xie@...vell.com>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/4] rtc: sa1100: enable/disable rtc when probe/remove the device

On Mon, Dec 3, 2012 at 1:35 PM, Haojian Zhuang <haojian.zhuang@...il.com> wrote:
> On Mon, Dec 3, 2012 at 10:53 AM, Chao Xie <xiechao.mail@...il.com> wrote:
>> On Mon, Dec 3, 2012 at 9:39 AM, Chao Xie <xiechao.mail@...il.com> wrote:
>>> On Fri, Nov 30, 2012 at 3:04 PM, Haojian Zhuang
>>> <haojian.zhuang@...il.com> wrote:
>>>> On Thu, Nov 29, 2012 at 6:25 PM, Russell King - ARM Linux
>>>> <linux@....linux.org.uk> wrote:
>>>>> On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
>>>>>> The original sa1100_rtc_open/sa1100_rtc_release will be called
>>>>>> when the /dev/rtc0 is opened or closed.
>>>>>> In fact, these two functions will enable/disable the clock, and
>>>>>> register/unregister the irqs.
>>>>>> User application will use /dev/rtc0 to read the rtc time or set
>>>>>> the alarm. The rtc should still run indepent of open/close the
>>>>>> rtc device.
>>>>>> So only enable clock and register the irqs when probe the device,
>>>>>> and disable clock and unregister the irqs when remove the device.
>>>>>
>>>>> NAK.  I don't think you properly understand what's going on here if you
>>>>> think moving the entire open and release functions into the probe and
>>>>> remove functions is the right thing to do.
>>>>
>>>> Since PXA27x & PXA3xx supports dual rtc device at the same time,
>>>> user could choose use either of rtc at run time. Then clk & irq are setup
>>>> in open().
>>>>
>>>> Chao,
>>>> So you shouldn't remove them into probe().
>>>
>>> How can user to choose one RTC?
>>> The user API, for example "date" will open the device, get the time
>>> and then close the device.
>>> WHen set a alarm, it is the same routine. open->set->close.
>>> The open routine will enable clock and register irq, close will
>>> disable the clock and unregister irq. It means that if only open is
>>> invoked, rtc begins to work, and after close is invoked rtc stops
>>> working. It means that the user can not get correct time and can not
>>> get right alarm.
>>
>> hi
>> I want to correct what i said. For the irq register/unregister i think
>> can be done at open/release. But for clock enable/disable, i do not
>> think so. If clock is disabled, as i think RTC will not work. User API
>> still use open->get_time->close for "date" command. It means that RTC
>> will not return correct date to user.
>
> I didn't get your point. Do you mean that RTC can't work without your patch?
hi
open/release will done two things
1. enable/disable clock
2. register/unregister the irq
i checked the rtc dev code. register/unregister irq is prefered to be
done at open/release routine, and the users will keep rtc to be opened
if he want to make use of the interrupts.
the only problemis the clock. It should be on always.
If user want to get the rtc value, or set alarm. it will  follow
open->ioctrl->release. After release the clock is offed, and i do not
think rtc will has its value updated if the clock is offed.
--
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