linux-kernel - Re: [PATCH v3 4/4] dt-bindings: arm: add support for SCMI Regulators

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]

Message-ID: <20201102090120.xb7ghg6kfh3unisr@bogus>
Date:   Mon, 2 Nov 2020 09:01:20 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Rob Herring <robh@...nel.org>,
        Cristian Marussi <cristian.marussi@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org, lukasz.luba@....com,
        james.quinlan@...adcom.com, Jonathan.Cameron@...wei.com,
        satyakim@....qualcomm.com, etienne.carriere@...aro.org,
        f.fainelli@...il.com, vincent.guittot@...aro.org,
        Sudeep Holla <sudeep.holla@....com>, souvik.chakravarty@....com
Subject: Re: [PATCH v3 4/4] dt-bindings: arm: add support for SCMI Regulators

On Fri, Oct 30, 2020 at 07:06:07PM +0000, Mark Brown wrote:
> On Fri, Oct 30, 2020 at 01:55:14PM -0500, Rob Herring wrote:
>
> > I'm a bit worried that now we're changing CPUs (at least?) from clocks
> > to 'performance domains' while at the same time here we're adding
> > low level, virtual regulators. Are we going to end up wanting something
> > more abstract here too?

Valid concern and I too am with the same opinion. However as Mark Brown
points out this was added to just satisfy some exiting consumers that
rely on regulators.

I had or still argue that we need a way to check if this is not getting
misused with devices like CPUs. I was thinking of some check with DT where
such properties are not allowed in certain device type.

>
> My understanding is that this is aimed at systems which have done the
> more abstract thing where regulators just aren't visible at all to the
> kernel but then find that they actually need to control some of the
> regulators explicitly for things like MMC so need a mechanism for the
> firmware to expose select regulators.

Thanks Mark for the explaining this, saved me time 😄.

-- 
Regards,
Sudeep