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 11:33:08 +0100
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Maxime Coquelin <maxime.coquelin@...com>
Cc:	srinivas kandagatla <srinivas.kandagatla@...com>,
	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

Hi Maxime,

Am Mittwoch, den 19.02.2014, 14:57 +0100 schrieb Maxime Coquelin:
> Hi Philipp,
> 
> On 02/07/2014 01:54 PM, srinivas kandagatla wrote:
> > Hi Philipp,
> > Thankyou for looking at the patches.
> >
> >
> > On 05/02/14 09:28, Philipp Zabel wrote:
> >> Hi Srinivas,
> >>
> > ...
> >>
> >> the patchset looks good to me for the soft resets. But for the powerdown
> >> bits I am wondering whether the reset controller API is the right
> >> abstraction. Depending on whether those bits really just put the IPs
> >> into reset or there is some power gating / sequencing involved,
> >> shouldn't this rather be handled as a set of pm domains?
> >
> > The hardware name of these control signals into the devices is
> > slightly unfortunate and a bit misleading. We do not generally
> > have separate power domains for peripheral devices in our
> > current STB SoCs, in the sense that the voltage cannot actually be
> > removed from individual devices. In the USB case we believe the
> > powerdown signals internally gate off two of the three
> > incoming clocks to most of the USB controller's logic blocks,
> > essentially holding the device in a disabled (enable/disable
> > might have been a better name for the signal) state.
> >
> > The primary requirement to manipulate these signals is to bring
> > the device out of its cold boot default powerdown/disabled/reset
> > (whatever you want to call it) state when the device is probed or
> > after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> >
> >
> >> I see that for example on STiH415 there are both soft resets and
> >> powerdown bits for USB[012].
> >
> > Our IPs typically have two or sometimes three signals going into
> > them, controlled from outside of the IP block itself (typically using
> > SoC global system configuration registers) that you could view
> > as "reset-a-like"; that is toggling each of the signals puts the IP
> > into a state where it is in some way unusable and then back to
> > being useable again. The reset controller API appeared to be the
> > natural abstraction for the drivers to be given access to such control
> > signals, regardless of the precise effect the signals have on the
> > device's internal state.
> >
> > With regards to sequencing between these signals; it is the case that
> > there is a likely sequencing because at least in the USB case it is
> > thought that the "powerdown" stops the clock going to the reset chain
> > logic. But we did not see that as an issue as the reset controller
> > framework allows for multiple named "reset" lines being defined for
> > a device through its DT attributes. The driver knows which signal
> > is which and what each does, because it asks for them by name;
> > therefore, it knows how to impose any required ordering when changing
> > the state of those signals.
> >
> 
> 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?
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.

regards
Philipp

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