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]
Message-ID: <20061120224832.GE26791@flint.arm.linux.org.uk>
Date:	Mon, 20 Nov 2006 22:48:33 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	David Brownell <david-b@...bell.net>
Cc:	Alessandro Zummo <alessandro.zummo@...ertech.it>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	rpurdie@...ys.net
Subject: Re: [patch 2.6.19-rc6 2/6] rtc-sa1100 tweaks

On Mon, Nov 20, 2006 at 10:19:53AM -0800, David Brownell wrote:
> Minor updates to rtc-sa1100: report whether the alarm is enabled, remove
> duplicate procfs reporting of that factoid, and stick a FIXME at a place
> where alarms should be enabled (but aren't).

I think you're rather confused about alarms, but you're going to tell
me that it's me who is no doubt, so I'm not sure why I'm bothering to
write this mail.

The pre-rtc-lib user API was as follows:

- ALM_SET - sets the time of the alarm, does not enable or disable
            current alarm settings
- AIE_ON - enables alarm interrupts
- AIE_OFF - disables alarm interrupts
- WKALM_SET - sets the wake up alarm, enables wake up alarm, indicates
              whether wake up alarm is pending

So, alrm->enabled indicates _independently_ of the alarm interrupt whether
this should cause a wakeup, as per the SA1100 driver.  Whether a wakeup
can occur with or without AIE_ON is implementation defined.

Now, if the new RTC library treats this differently, then /it's/ changing
the userspace API and is therefore buggy.

Note also that _lots_ of drivers don't support these new weird
device_set_wakeup_enable() and device_may_wakeup() calls - it seems
that there's an exercise for someone to go through and add a load of
device_set_wakeup_enable() before we go trying to use device_may_wakeup()
on those devices.  I'm not presently sure what they're supposed to do
or achieve.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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