linux-kernel - Re: [PATCH v2 3/3] scsi: allow scsi devices to use direct complete

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: <CAGAzgsrzwO_uCLeJWnqfZXGbv8Ex=i_jfQ=W9AhqEdv0-uuN-w@mail.gmail.com>
Date:	Sat, 27 Feb 2016 01:07:06 -0800
From:	"dbasehore ." <dbasehore@...omium.org>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Linux-pm mailing list <linux-pm@...r.kernel.org>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Martin K . Petersen" <martin.petersen@...cle.com>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] scsi: allow scsi devices to use direct complete

On Sat, Feb 27, 2016 at 12:38 AM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> On Sat, Feb 27, 2016 at 12:10:03AM -0800, dbasehore . wrote:
>> A device is not able to use direct complete if its children do not
>> also use direct complete. Even though the SCSI layer leaves devices
>> runtime suspended, the way it does it still prevents its parent from
>> using direct complete.
>
> Okay.
>
> Do you need to provide ->complete() hook that then resumes the device
> when system is resumed (since the device resume hook is never called
> when direct_complete is set)? Along the lines of
> pm_complete_with_resume_check().

That's an interesting question. Part of direct complete is to leave
the device runtime suspended even after the system resumes if
possible. The comments in pm_complete_with_resume_check indicate that
the firmware may resume a device. I could see this happening with some
kind of SCSI device.

If this is possible, are we able to put the device back into a
consistent state (runtime suspended) by calling suspend for the scsi
device? If not, we might need to use pm_complete_with_resume_check for
the complete callback.