linux-kernel - Re: [PATCH V4 16/16] ARM64: tegra: select PM_GENERIC

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]

Message-ID: <CAPDyKFq=AWtranL2uifgO5TuTW5ykt+X8NkGpg7UDBpEivDxjA@mail.gmail.com>
Date:	Wed, 16 Dec 2015 13:51:46 +0100
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Jon Hunter <jonathanh@...dia.com>
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Rafael Wysocki <rjw@...ysocki.net>,
	Kevin Hilman <khilman@...nel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Vince Hsu <vinceh@...dia.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH V4 16/16] ARM64: tegra: select PM_GENERIC_DOMAINS

On 16 December 2015 at 12:40, Jon Hunter <jonathanh@...dia.com> wrote:
>
> On 16/12/15 09:47, Ulf Hansson wrote:
>> On 16 December 2015 at 10:40, Jon Hunter <jonathanh@...dia.com> wrote:
>>> Hi Ulf,
>>>
>>> On 15/12/15 19:54, Ulf Hansson wrote:
>>>> On 4 December 2015 at 15:57, Jon Hunter <jonathanh@...dia.com> wrote:
>>>>> Enable PM_GENERIC_DOMAINS for tegra 64-bit devices. To ensure that devices
>>>>> dependent upon a particular power-domain are only probed when that power
>>>>> domain has been powered up, requires that PM is made mandatory for tegra
>>>>> 64-bit devices and so select this option for tegra as well.
>>>>>
>>>>> Signed-off-by: Jon Hunter <jonathanh@...dia.com>
>>>>> ---
>>>>>  arch/arm64/Kconfig.platforms | 2 ++
>>>>>  1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>>>> index 9806324fa215..e0b5bd0aff0f 100644
>>>>> --- a/arch/arm64/Kconfig.platforms
>>>>> +++ b/arch/arm64/Kconfig.platforms
>>>>> @@ -93,6 +93,8 @@ config ARCH_TEGRA
>>>>>         select GENERIC_CLOCKEVENTS
>>>>>         select HAVE_CLK
>>>>>         select PINCTRL
>>>>> +       select PM
>>>>> +       select PM_GENERIC_DOMAINS
>>>>
>>>> If you still want to allow ARCH_TEGRA to run without PM, you should
>>>> probably change to:
>>>>
>>>> select PM_GENERIC_DOMAINS if PM
>>>
>>> Per the changelog this is deliberate. If we allow !PM, then there is a
>>> potential that you could probe a device when the power domain is not
>>> powered on. I understand that some SoCs turn on all the power-domains
>>> when !PM but this will not work for tegra because we don't register the
>>> power domain until later in the boot and so we are relying upon probe
>>> deferral to defer the probe of devices that use power-domains.
>>
>> So what you are saying is that adding the PM domain support, will fix
>> some devices to become successfully probed as they were broken before?
>
> Not exactly. There is a legacy tegra_powergate_sequence_power_up() that
> has been used to date to get around this. However, by migrating to GENPD
> we really need to make PM mandatory, otherwise you could attempt to
> probe a device in a power domain that is not powered. In other words,
> you are probing blindly. I know some SoCs do this, but that does not
> seem very robust.

Thank for the clarification. I agree.

You may add my:

Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>

Kind regards
Uffe
--
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/