From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CC52C31E5B for ; Wed, 19 Jun 2019 15:12:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F34B21880 for ; Wed, 19 Jun 2019 15:12:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729903AbfFSPMJ (ORCPT ); Wed, 19 Jun 2019 11:12:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:59656 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726009AbfFSPMJ (ORCPT ); Wed, 19 Jun 2019 11:12:09 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id B407DAF61; Wed, 19 Jun 2019 15:12:07 +0000 (UTC) Message-ID: <1560957124.4587.20.camel@suse.com> Subject: Re: [PATCH] usb: core: devio: add ioctls for suspend and resume From: Oliver Neukum To: Alan Stern Cc: Greg KH , Mayuresh Kulkarni , patches@opensource.cirrus.com, linux-usb@vger.kernel.org Date: Wed, 19 Jun 2019 17:12:04 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Am Mittwoch, den 19.06.2019, 10:40 -0400 schrieb Alan Stern: > On Wed, 19 Jun 2019, Oliver Neukum wrote: > > It would be easiest to export the usb_autopm_* API to user space. > > But ->suspend and ->resume callbacks are part of that API, and as you > say, it is not feasible to have these callbacks run in userspace. We can notify user space about resume(). There will be a delay, but there will always be a delay, even in kernel space. > The only solution I can think of is for the userspace program to first > set the device's autosuspend delay to 0. Then whenever the > WAIT_FOR_RESUME ioctl returns -- even if it returns immediately -- the > program should assume the suspend is over or is not going to happen. > Then the program can run normally for a short while (10 seconds, > perhaps) before making another attempt to suspend. That is ugly. Quite ugly actually. Why actually do we care about suspend()? Would the user space task do anything else but cease IO? We can do that in usbfs, assuming we do not care about the order of killing. User space will learn from an appropriate error code the device went to power save. And if it does not do IO, why care? I have never seen a driver that actually saves device state in suspend(). Regards Oliver