linux-kernel - Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

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: <CADRPPNRaDaUBD1JG_QHrEQ5pKP9Ap1hV+bBdUnC-V32Nzr2qQw@mail.gmail.com>
Date:	Mon, 17 Aug 2015 14:10:46 -0500
From:	Li Yang <leoli@...escale.com>
To:	Yao Yuan <yao.yuan@...escale.com>
Cc:	Nigel Cunningham <nigel@...elcunningham.com.au>,
	Vinod Koul <vinod.koul@...el.com>,
	"stefan@...er.ch" <stefan@...er.ch>, Arnd Bergmann <arnd@...db.de>,
	Dan Williams <dan.j.williams@...el.com>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support

On Mon, Aug 17, 2015 at 2:22 AM, Yao Yuan <yao.yuan@...escale.com> wrote:
> Hi Nigel,
>
> On Mon, Aug 17, 2015 at 2:49 PM, Nigel Cunningham < nigel@...elcunningham.com.au > wrote:
>> On 17/08/15 13:59, Yao Yuan wrote:
>> > On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku.leo@...il.com > wrote:
>> >> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan <yao.yuan@...escale.com> wrote:
>> >>> Hi Leo,
>> >>>
>> >>> Thanks for your review.
>> >>> About those two methods for DMA suspend that you have mentioned.
>> We
>> >> have a lot of the discussions in other DMA driver like DMA for
>> >> Freescale PowerPC.
>> >>> Finally, we think the device which used the DMA transmission service
>> >>> should
>> >> cancel the transmission service in its suspend.
>> >>> So DMA in suspend should be idle.
>> >> If that's the case you should clearly state this in the commit
>> >> message and in code, although I don't know if it is safe to make such
>> >> assumption.  There could be user of the DMA that doesn't track the
>> completion of transfers.
>> > I think it should be safe. In my opinion, even some client(the user of
>> > the DMA) forget to cancel its DMA transmission, It will just lead to PM failed
>> but no other system and data risk.
>> > Although we should first fix the behavior of the client.
>> > Once you are no need the DMA transmission, why not stop it?
>> >
>> > Is it right?
>> Think of it from the end user perspective. Would you like your laptop (or
>> whatever) to refuse to suspend because of this condition? The user may well
>> expect that closing the lid on their laptop will reliably lead to it suspending to
>> ram. Returning a failure here could result in a loss of data if the condition is not
>> detected and the machine subsequently runs out of power.
>>
>
> Yes, the user may well expect that closing the lid on their laptop will reliably lead to it suspending to ram.
> So the client(the user of the DMA) must  to PAUSE or terminate the DMA transmission.
>
> We need to rely on client doing the right thing here.
> The DMA should not make a decision instead of client.
> If the DMA is not idle in DMA suspend, it should be the client's issue.
> We don't know what the client really want to do, so just return the non-success value.

The problem here is that neither the client nor the DMA controller
driver should easily decide to stop the suspend entrance and rollback.
I don't think the non-idle situation is serious enough to cause a
rollback.  You should do whatever can be done with the DMA
controller(such as stop the controller and leave whatever to be done
to the wake up) and continue with the suspend.

Regards,
Leo
--
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/