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: <1619959760.20061219084124@gmail.com>
Date:	Tue, 19 Dec 2006 08:41:24 +0200
From:	Paul Sokolovsky <pmiscml@...il.com>
To:	David Brownell <david-b@...bell.net>
CC:	kernel-discuss@...dhelds.org, linux-kernel@...r.kernel.org,
	<linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH] RTC classdev: Add sysfs support for wakeup alarm (r/w)

Hello David,

Tuesday, December 19, 2006, 2:59:11 AM, you wrote:

> On Monday 18 December 2006 4:54 pm, David Brownell wrote:

>> > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5&r2=1.6&f=h
>> 
>> That patch you applied looks right to me -- why don't you forward it
>> to Alessandro as a bugfix for 2.6.20-rc2, and save me the effort?

> Actually, correction:  it'd be correct if you ripped out the buggy
> calls to manage the irq wake mechanism.  A later message will show
> how those need to work.  (The IRQ framework will give one helpful
> hint when it warns about mismatched enable/disable calls ...)

  Do you mean enable_irq_wake()/disable_irq_wake() calls? In what way
they are buggy? The only "bug" with them I see is that they are not
implemented for PXA, which just once again reminds that mach-pxa is
real misfit in ARM family (own DMA API instead of fitting with generic
ARM one, no cpufreq support in mainline, and few other not implemented
APIs). That's of course pretty sad, as apparently PXA was/still is
the most popular CPU for consumer market (well, at least in "something
like real computer" caregory) ;-(.

  But those calls are apparently still needed, even if you say that
wakeup stuff should be handled in generic manner, as PM feature, and
on device level. After all, what drivers will do to actually enable
wakeup for a given device? I hope we don't speak about using
CPU-specific registers in reusable device drivers for that.

  This is pretty interesting topic for us, and so far in handhelds.org
ports we don't handle dynamic wakeup configuration at all, so I would
eagerly expect your samples. In the meantime, I went and hacked
.set_wake methods for PXA's irq_chips. And that's when I got idea why
it might haven't been implemented at all - PXA27x's model of wakeup
sources is a bit weird comparing with nice and clean PXA25x's ;-).
It's still not the reason to give up on those calls at all - after
all, even "least common denominator" implementation will give good
value. I yet need to test what I've put together, though.


> - Dave


-- 
Best regards,
 Paul                            mailto:pmiscml@...il.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