Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2245747imj; Sun, 10 Feb 2019 22:36:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IYBRHs/WVxGbO8tK9MHvGQvPKuvHrJFmpXtEHL4yJ2STjc/S9IJLs9tHjcJfGa6EYeBfiG+ X-Received: by 2002:a17:902:449:: with SMTP id 67mr27399572ple.310.1549867004186; Sun, 10 Feb 2019 22:36:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549867004; cv=none; d=google.com; s=arc-20160816; b=M9UN+ACkyOs0DsB6ul9gZn1K4hCR9wWuTTTVjLf0x79PDwk0zaQFwZEot+Ch9nKbhx 4Zeu2G5X9vU1VgZ+fV1zjIAu7lnx0DtabNRZ1kX/wfcGuG4k+O4b74bzkjRh53SDaaEl ToY9PF3LkzwnKY1M3k6FqeXTcb1nJpw7dY8HGnVESnDVqjWeexumliWeV19mDMNcZPA6 OtKt2CyYAodFf6jCGil6Fw0uBqEMa/clrnEfgyGuVMNYsZ5cmzczjXvwBMHQSO2E2noX bvfn1HlaxmUgvZqwwL+ERsLCSQCzL5x+EaL1sDRTuUAqju6BoSdMx+W+isnu/akxAHpn vOig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pYhQxAlN3J7IWCPKgtu0ThRZ02YGp3ieh807DzI6ZUE=; b=UPFvFwbamvxj8qcSHfPu7vJRrOcVHln1Ikc42RUL+0BPwctdsDIPQCtfkusWJ9RbzG 5PPynuHUA/uJ7NMO0T0NH45xACrz61nAUIo5fbMiXBCVTjRTqr658CpAJXDsTP5VWIlY gokXkmNVFP22uJlZkneldrIiW9XlKn64CKBjmxvfC4vdynnjmurjrIO0VuQmwShHOEtG 6/fSSFJ53pbKCl+qYOOryVm72OPtinwnqOpRv3CBllkbgdMtpbpo7lbj7Z2TWqY542cm lZ7gW7vExStwZaLQJDNQb/sCMXVTCa8DB/KCG61llZ2E7DnInqaoHy6qCtu0u0cXo/Bd uB9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y26si9570323pfd.25.2019.02.10.22.36.28; Sun, 10 Feb 2019 22:36:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726366AbfBKGf5 (ORCPT + 99 others); Mon, 11 Feb 2019 01:35:57 -0500 Received: from bmailout2.hostsharing.net ([83.223.90.240]:40537 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725931AbfBKGf5 (ORCPT ); Mon, 11 Feb 2019 01:35:57 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 6E7152800B1DF; Mon, 11 Feb 2019 07:35:55 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 1E343115A6F; Mon, 11 Feb 2019 07:35:55 +0100 (CET) Date: Mon, 11 Feb 2019 07:35:55 +0100 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Michael Jamet , Yehezkel Bernat , Andreas Noever , Andy Shevchenko Subject: Re: [PATCH v2 15/28] thunderbolt: Deactivate all paths before restarting them Message-ID: <20190211063555.2bozvqen2jmskox4@wunner.de> References: <20190206131738.43696-1-mika.westerberg@linux.intel.com> <20190206131738.43696-16-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190206131738.43696-16-mika.westerberg@linux.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 06, 2019 at 04:17:25PM +0300, Mika Westerberg wrote: > We can't be sure the paths are actually properly deactivated when a > tunnel is restarted after resume. Why can't we be sure? Please provide proper reasoning. > So instead of marking all paths as > inactive we go ahead and deactivate them explicitly. This seems like a bad idea if the root partition is on a Thunderbolt- attached drive, the system is waking from hibernate and the EFI NHI driver has already established a tunnel to that drive. It would seem more appropriate to discover tunnels already existing on resume from system sleep and then attempt to establish any others that might be missing. > @@ -183,8 +183,15 @@ int tb_tunnel_restart(struct tb_tunnel *tunnel) > > tb_tunnel_info(tunnel, "activating\n"); > > + /* Make sure all paths are properly disabled before enable them again */ This isn't proper English, s/enable/enabling/. Thanks, Lukas