linux-kernel - Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

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: <8738lnl19p.fsf@natisbad.org>
Date:	Fri, 20 Dec 2013 21:23:46 +0100
From:	arno@...isbad.org (Arnaud Ebalard)
To:	Mark Brown <broonie@...nel.org>
Cc:	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com, Mark Rutland <mark.rutland@....com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	jason@...edaemon.net, Pawel Moll <pawel.moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	linux-arm-kernel@...ts.infradead.org,
	Rob Landley <rob@...dley.net>,
	Kumar Gala <galak@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	Peter Huewe <peter.huewe@...ineon.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thierry Reding <treding@...dia.com>,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

Hi,

Mark Brown <broonie@...nel.org> writes:

> On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote:
>
>> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
>> is used as main RTC clock but can also provide alarm. But the alarm
>> interrupt line of the chip is *not* connected to the SoC. It is
>> connected to some power component and can be used to wake up the NAS
>> when it is completely off and the alarm rings.
>
> Can the PMIC or whatever function as an interrupt controller and report
> the interrupt on to the SoC?

I do not even know to which specific component the irq line of the chip
is connected. You can take a look at [1] to see what's on the PCB; if
you have an idea about which one could be a good candidate (TPS65251?),
I can try and check with an ohmmeter which pin is connected to confirm
your guess. Then, I could look at the datasheet (if any) to see if it
can relay the interrupt to the SoC (if the component is supported by
Linux kernel).

But, except if we can do what you propose, there are two problems at
hand:

 1) I cannot currently test the IRQ handler my changes would bring
 because it is not connected to the SoC on my platforms

 2) even if I find a solution for 1), noone ever provided any directions
 on what should be required to make some program like rtc-test.c happy on
 my platforms (alarm support but no interrupt from the RTC). e.g. some 
 refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear:
 Provide flag for no support of UIE mode). I guess it should be fairly
 simple for someone w/ good knowledge of the RTC subsystem to tell what
 is needed. I do not have that knowledge and the documentation does not
 help.

Regarding 1), I am starting to wonder if the best way out would not be
for me to connect the interrupt line of the ISL12057 to one of the GPIO
line currently connected to the LCD on my RN104 (after having
disconnected the LCD) and change the function of the associated MPP on
the SoC to make it an interrupt line. Could that work w/o additional
hardware modification? What are my chances of killing the board?

But this is pointless if I do not get any clear directions about 2).

Cheers,

a+

[1]: http://natisbad.org/NAS2/index.html#hw
--
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/