linux-kernel - Re: [PATCH v2 0/6] ARM: STi reset controller support

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, 24 Feb 2014 14:03:54 +0000
From:	srinivas kandagatla <srinivas.kandagatla@...com>
To:	Philipp Zabel <p.zabel@...gutronix.de>,
	Maxime Coquelin <maxime.coquelin@...com>
Cc:	Mark Rutland <mark.rutland@....com>, <devicetree@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>, <kernel@...inux.com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Olof Johansson <olof@...om.net>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <stephen.gallimore@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Arnd Bergmann <arnd@...db.de>, Rob Landley <rob@...dley.net>,
	Kumar Gala <galak@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/6] ARM: STi reset controller support

Thanks Philipp for your comments,

On 24/02/14 10:33, Philipp Zabel wrote:
>> > Did Srini's explanations convinced you?
>> > 
>> > If so, could you queue the series for v3.15?
> to be honest, I'm not comfortable with this explanation. If the
> "powerdown" bits only gate the clocks to those modules, calling it a
> reset control is clearly the wrong abstraction. If that is the case,
> couldn't you handle those bits via the clock framework?
I just had a re-look at the IPs specs for more information on where
these power-down signals are actually terminating on the IP side.

For example: ST-Synopsis Ethernet GMAC IP has two pins
power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
the software to either put the IP in powerdown or bring it out of
powerdown state.

The IP itself drives power_down_ack to indicate when the power down
request is successfully finished. For power_down/power_up request the IP
will change the internal state accordingly including powering up/down
its internal blocks and/or clock gating.

> If on the other hand these powerdown bits also trigger reset machinery,
> such that asserting and deasserting that bit will change the module's
> internal state, I could be convinced to queue them like this.
This is true with ST IPs, these lines change the state of the IP as
described above. Reset framework seems to fits in very well with this
behavior rather than power-domains or clock framework.

Thanks,
srini




--
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/