linux-kernel - Re: [PATCH 4/4] regulator: qcom: Rework to single platform device

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Mar 2015 00:56:14 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>,
	Andy Gross <agross@...eaurora.org>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH 4/4] regulator: qcom: Rework to single platform device

On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote:

> I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
> but as it's a mixture of internal and external dependencies (e.g.
> <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started
> looking at using the dt dependencies sort and iterate over the entries
> in a way that adheres to their dependencies, but that's also a lot of
> code.

This is why I don't like trying to open code in subsystems, it's too
much work.

> So I think you're right, we should be able to alter the supply lookup
> code to defer the EPROBE_DEFER until we actually need the supply to be
> there; e.g. attempt to map supplies when an external consumer request
> the regulator.
> Some care needs to be taken with regards to e.g. always-on regulators.

I'm not sure why always on regulators would need special casing here?
Enabling is orthogonal to supply mapping.

Like I said in reply to Stephen's mail I'm more worried about
discoverability of problems with this approach and with interactions
with dependencies on other subsystems (mainly GPIOs).  Thinking about it
some more the other subsystems will probably sort themselves out but the
diagnosics are an issue.

I do like the idea of a general mechanism for registering dependency
resources and deferring completion until they're ready more - I'm not
sure it's even that much more work, especially if the first cut only
handles regulators as a dependency...  that feels like attacking the
right problem, there's other things people are raising with deferred
probe like your complaint about logging.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)