From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= Subject: Re: [PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep Date: Tue, 05 Mar 2013 17:08:07 +0100 Message-ID: <87wqtlommw.fsf@nemi.mork.no> References: <1362456103-24956-1-git-send-email-ming.lei@canonical.com> <1362456103-24956-5-git-send-email-ming.lei@canonical.com> <87boayqq5c.fsf@nemi.mork.no> <87d2veot6t.fsf@nemi.mork.no> <871ubtq47a.fsf@nemi.mork.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: (Ming Lei's message of "Tue, 5 Mar 2013 23:29:15 +0800") Sender: netdev-owner@vger.kernel.org To: Ming Lei Cc: "David S. Miller" , Greg Kroah-Hartman , Jiri Kosina , Alan Stern , Oliver Neukum , netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-input@vger.kernel.org List-Id: linux-input@vger.kernel.org Ming Lei writes: > Yes, USB core will flush any outstanding URBs, but the driver still n= eed > to deal with suspend failure carefully, for example, suppose usb_resu= me() > is called in suspend failure path, and the submitted URBs are killed > by USB core later. But after the device is wakeup, and the resume() w= ill > do nothing since the suspend count is leaked. So it is what the patch= es > are fixing, and it is better to not depend on the default flushing UR= Bs of > USB core. I am starting to wonder why the USB core has combined system suspend an= d runtime suspend if we are going to end up with every driver testing PMSG_IS_AUTO(message) and selecting a completely different code path. You are right that we will end up with problems if usbnet_resume is called for a device usbnet hasn't suspended. But I'd still claim that is a bug in the USB core, which is the one that decided to ignore the suspend error and still call resume. I guess proper error handling here require the USB core to see the interface driver as dead if it fails to suspend on system suspend, and do forced rebinding on resume. I am not going to fight this any longer. The per-driver PMSG_IS_AUTO(message) testing is an ugly workround for a core problem, but they are already all over the place... Still, please make sure the drivers all return 0 if they are pretending to suspend. No error code return if the driver ignores the error. Bj=C3=B8rn