linux-kernel - Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

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, 20 Jun 2016 18:57:21 +0100
From:	Sudeep Holla <sudeep.holla@....com>
To:	Kevin Hilman <khilman@...libre.com>,
	"Jon Medhurst (Tixy)" <tixy@...aro.org>
Cc:	Sudeep Holla <sudeep.holla@....com>, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v2 3/3] firmware: scpi: add device power domain support
 using genpd



On 20/06/16 18:50, Kevin Hilman wrote:
> "Jon Medhurst (Tixy)" <tixy@...aro.org> writes:
>
>> On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote:
>>>
>>> On 16/06/16 18:47, Jon Medhurst (Tixy) wrote:
>>>> On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote:
>>>> [...]
>>>>> +enum scpi_power_domain_state {
>>>>> +	SCPI_PD_STATE_ON = 0,
>>>>> +	SCPI_PD_STATE_OFF = 3,
>>>>> +};
>>>>
>>>> The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno
>>>> specifics' chapter. So does these values need to come from device-tree
>>>> to allow for other hardware or SCP implementations?
>>>>
>>>
>>> Ah unfortunately true :(. I had not noticed that. But I would like to
>>> check if this can be made as part of the standard protocol. Adding such
>>> details to DT seems overkill and defeat of the whole purpose of the
>>> standard protocol.
>>
>> Well. it seems to me the 'standard protocol' is whatever the current
>> implementation of ARM's closed source SCP firmware is. It also seems to
>> me that people are making things up as they go along, without a clue as
>> to how to make things generic, robust and future proof. Basically,
>> Status Normal ARM Fucked Up.
>
> Fully agree here.  Just because ARM calls it a "standard" does not make
> it so.  As we've already seen[1], vendors are using initial/older/whatever
> versions of SCPI, so pushing the Juno version as standard just becuase
> it's in ARM's closed firmware is not the right way forward either.
>

I am not disagreeing on that. There's an on going effort to make it as
standard as PSCI. But that's still work in progress. We need to deal
with the existing variety of SCPI until then. No argument on that.

The only argument I had on the other thread is not to make the changes
too flexible that enabled the vendors to make up their own deviation of
SCPI even for their future platforms. All I am asking is to keep is less
flexible just to support existing platforms out there and not to help
the vendors to deviate further.

-- 
Regards,
Sudeep