linux-kernel - Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

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: <56BACC6E.3060908@ti.com>
Date:	Wed, 10 Feb 2016 11:06:46 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Paul Walmsley <paul@...an.com>, Suman Anna <s-anna@...com>
CC:	Tony Lindgren <tony@...mide.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	<richardcochran@...il.com>, Russell King <linux@....linux.org.uk>,
	<linux-omap@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <nsekhar@...com>
Subject: Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset



On Wednesday 10 February 2016 01:06 AM, Paul Walmsley wrote:
> Hi Suman 
> 
> On Tue, 9 Feb 2016, Suman Anna wrote:
> 
>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>
>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>
>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>> work correctly.
>>>>>
>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>> possibly some of the MMUs?  
>>>>
>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>
>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>> We've stated that the main point of the custom hardreset code is to handle 
>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>> there would be an equivalent for MMUs.  Thoughts?
>>
>> The current OMAP IOMMU code already leverages the pdata ops for
>> performing the resets, so not adding the flags would also require
>> additional changes in the driver.
>>
>> Also, the reset lines controlling the MMUs actually also manage the
>> reset for all the other sub-modules other than the processor cores
>> within the sub-systems. We have currently different issues (see [1] for
>> eg. around the IPU sub-system entering RET in between), so from a PM
>> point of view, we do prefer to place the MMUs also in reset when we are
>> runtime suspended.
> 
> Should we reassert hardreset in _idle() for IP blocks that don't have 
> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
> mechanism for the uncore hardreset lines, or are there other quirks?

IIUC _idle() will be called on pm_runtime_put. That would mean we perform reset
on every suspend/resume cycle which is not desired. (suspend/resume support for
PCIe is not yet in mainline but once we have it runtime_put and runtime_get
will be invoked during suspend/resume cycle). Let me know if my understanding
is wrong.

Thanks
Kishon
> 
> Also - would that address the potential issue that you mentioned with the 
> PCIe block, or is that a different issue?
> 
> 
> - Paul
>