From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752801AbbG2LJn (ORCPT ); Wed, 29 Jul 2015 07:09:43 -0400 Received: from rtits2.realtek.com ([60.250.210.242]:47746 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751826AbbG2LJl (ORCPT ); Wed, 29 Jul 2015 07:09:41 -0400 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.54 with qID t6TB9Xpx014646, This message is accepted by code: ctloc85258 From: Hayes Wang To: Oliver Neukum CC: "netdev@vger.kernel.org" , nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" Subject: RE: [PATCH net v2 2/2] r8152: reset device when tx timeout Thread-Topic: [PATCH net v2 2/2] r8152: reset device when tx timeout Thread-Index: AQHQyS4AWs20zW5jRUuoEFJdQdKEO53wRVKAgACJJdD//4NNgIABYUqQ///S/4CAAMFfoA== Date: Wed, 29 Jul 2015 11:09:32 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB2F3CDA7@RTITMBSV03.realtek.com.tw> References: <1394712342-15778-156-Taiwan-albertk@realtek.com> <1394712342-15778-159-Taiwan-albertk@realtek.com> <1394712342-15778-161-Taiwan-albertk@realtek.com> <1438085645.1787.4.camel@suse.com> <0835B3720019904CB8F7AA43166CEEB2F3C538@RTITMBSV03.realtek.com.tw> <1438088317.1787.5.camel@suse.com> <0835B3720019904CB8F7AA43166CEEB2F3C673@RTITMBSV03.realtek.com.tw> <1438154521.9445.3.camel@suse.com> In-Reply-To: <1438154521.9445.3.camel@suse.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.71.143] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t6TB9mnH024712 Oliver Neukum [mailto:oneukum@suse.com] > Sent: Wednesday, July 29, 2015 3:22 PM [...] > Now, I think I got the reason for the confusion. > > You are using cancel_delayed_work(&tp->schedule); after you queue a reset. > Therefore the order in which the work and the reset will be executed is undefined. > Usually the scheduled work will be canceled, but not always. Actually, the order is not important for me. There are some protections to avoid the work and the reset run at the same time. Besides, the reset could be run before or after the work. I cancel the work because I want to let the reset start as early as possible. If the work runs before the reset, the reset wouldn't start until the work is finished. > That is not good. I think I had better to remove cancel_delay_work(), because it makes confusion. And, it doesn't seem to be necessary. Thanks. Best Regards, Hayes {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I