linux-kernel - Re: [RFC] regulator: Shared regulators (configured by bootloader)

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] [day] [month] [year] [list]

Date:   Mon, 19 Jun 2017 23:21:18 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Nayak, Rajendra" <rnayak@...eaurora.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Serge Broslavsky <serge.broslavsky@...aro.org>
Subject: Re: [RFC] regulator: Shared regulators (configured by bootloader)

On Fri, Jun 16, 2017 at 03:29:17PM +0530, Viresh Kumar wrote:

> Yes, but there can be weird dependencies between different components that want
> to interact. For example a supply shared between LCD and I2C controller (Not
> sure if such configurations are there in any of the hardware we have), where the
> same i2c controller is used to access the LCD controller's registers. Both are
> enabled at boot and the supply is configured to satisfy both. If the voltage
> requirements of the I2C controller are below that of LCD, then we can't decide
> on which one to probe first. We can't probe LCD first as its bus isn't active
> and if we probe I2C first, then it may take the supply down to a level that
> isn't acceptable for the LCD (which was on from boot).

There are good solid reasons why it's extremely rare to see variable
voltage shared supplies.

> > and
> > when people do want such behaviour they should be able to say so in
> > terms of the objective they want to achieve rather than having to figure
> > out how the hardware is wired together in order to do so.

> Right. Where do you suggest such user-specific configuration should be present?
> I hope userspace as we want different users (that want to use LCD vs doesn't
> want to use LCD) to use the same kernel image?

The command line seems to be a good first start and would ensure that we
have something that works for all firmwares, not just DT.  For DT the
chosen node is intended for things like this although it's questionable
how valuable this is with typical FDT systems.

> > Proxy regulators are just operating at the wrong abstraction level, take
> > a step back and think about the goal you're trying to achieve and design
> > an interface for doing that.  The user interfaces should be at the level
> > of the goal the user is trying to achieve rather than down in the
> > implementation details.

> Are we talking about writing a new framework here which can take care of the
> constraints (which can support any resource type) set by the bootloader until
> the time:

> - the device get probed by its driver
> - userspace overrides the constraint

> Did I misunderstood your comment ?

I don't know that it needs to be a framework particularly, seems more
like an extension of the device model to work back through the
dependencies and let things do something useful with them.

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