Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp815260pxb; Fri, 22 Apr 2022 11:45:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8FFBUiEQztvytj5rTY07ibAJlmdv/I8NNX9EozBj6oWobYPPJYwRTIs6AutERZlhTj3q+ X-Received: by 2002:a63:df44:0:b0:3aa:45e2:ed2c with SMTP id h4-20020a63df44000000b003aa45e2ed2cmr5022116pgj.507.1650653148587; Fri, 22 Apr 2022 11:45:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650653148; cv=none; d=google.com; s=arc-20160816; b=zq0MHLWbfoc7KFGPAekT93SmBsWsG4wqDV2QtRCHbrjuO28Gmta6Z+D5H0PhhV2AMV tlk5zJGtxG/EkVhwrm+S8dWX9mJNYbTa5t/5svy+ETvE6dcGyI4WRPbEcbdc1DdM5M9D qlfffZKG/dtkxwW6lisDsbJH51BfK0ieIvEMG5JBN8GAsaqKBqrSbXaxUuU95oopHr0v zEky9skZI9qoS92oenx0bda2vgM9za2ma7bMyU9p5fhrOm4D2E9Tao76gMN3wD2o4iR2 aVaxXzbDiTf26zVxteZB5UcaK+bAaj2UY7rgr4C7ugf3pcwsgnk/wk3rcEPTpJXNfi6i 8G+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=1oRwe0TIDuzQvqI5swQOjfPaii6i0ZZa4uI+Q2pkulM=; b=VPQCVnJWYQGnvwzI+G9nrkcRk5VU+cQZXkjlxKto9d7/L82bN2BNvjJgDsq0lhwOvI y9w8I0qeR81iLtrUQ6BlMY7bVUPCgneqvcVbH6FUig3O/rc4rAIVLF5sEMk7a+gGhGbR Be0thY9kfs+MKE62h9C+pViV2NUzHEbHV7trzaPV5OcHUeRWk3jBMUBSek6/m4HBOJkf uqY0KGpvvWdVY7pE2IpB7yL0A2B60Iva7T2UjKKf2zfUHvejqDTebgiBB1wmhnrm47Ku DdWpcivsbTnou6JZv/V9Kyca6/NrneyBiIP8wZdXYcS4ltbVw5uSddORiRLK9AXDDmve /VSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kRseLUuW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l20-20020a17090a409400b001d297b4e18fsi8264139pjg.144.2022.04.22.11.45.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 11:45:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kRseLUuW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AC529163D1F; Fri, 22 Apr 2022 11:13:35 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447224AbiDVMAA (ORCPT + 99 others); Fri, 22 Apr 2022 08:00:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1447214AbiDVL77 (ORCPT ); Fri, 22 Apr 2022 07:59:59 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 753863ED01; Fri, 22 Apr 2022 04:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650628626; x=1682164626; h=to:cc:references:from:subject:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=una0KHCh52R2HL+UriGbWNcELDP4ksfAOACMj6FtIPs=; b=kRseLUuWngxFvBJCbWGiM35dNTXkOKhkUrVXVTgVBZ/QQPoGv0jqgqp6 hmi9dZ2KS83qD8uwC1Y6Z91ZbgqICtj9dfcxFh5pfj/oBzm6CmmhJCbbM Kr+RLADYQeDAeC9cftg3pwWNEmfPb9MiP9uTiiEhr6O6TAKfvMrfk9PCs H986E/mkaD/YlpHoHUAIkleJE7rj3UmF0hunziFAW3hEUPvRJyxZpYaK4 vsBMQIyCvDwwLbn2VvuKsDUyCtWvpdUNp1f7B3bsAbEPzZWNMYfAp4TvQ qwkkJg6o32XmUwBkACT6AYfvYs0mNKKvrAO2dSNLXJuB50ypJk46aDzD2 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10324"; a="264132747" X-IronPort-AV: E=Sophos;i="5.90,281,1643702400"; d="scan'208";a="264132747" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2022 04:57:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,281,1643702400"; d="scan'208";a="867560850" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by fmsmga005.fm.intel.com with ESMTP; 22 Apr 2022 04:57:04 -0700 To: surong pang Cc: mathias.nyman@intel.com, Greg KH , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Orson.Zhai@unisoc.com, yunguo.wu@unisoc.com References: <20220412122524.26966-1-surong.pang@gmail.com> <610871b2-1707-dfba-868f-4ddecc4d554d@linux.intel.com> From: Mathias Nyman Subject: Re: [PATCH V1 1/1] usb/host: Let usb phy shutdown later Message-ID: Date: Fri, 22 Apr 2022 14:59:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22.4.2022 13.43, surong pang wrote: >>>> @@ -398,6 +397,7 @@ static int xhci_plat_remove(struct platform_device *dev) >>>> clk_disable_unprepare(clk); >>>> clk_disable_unprepare(reg_clk); >>>> + usb_phy_shutdown(hcd->usb_phy); >>>> usb_put_hcd(hcd); > > Is it ok to put usb_phy_shutdown before usb_put_hcd(hcd)? hcd is > released at usb_put_hcd. yes, above looks good. > > UNISOC DWC3 phy is not divided USB 2.0/3.0 phy clearly. Yes, it's > UNISOC's issue. > It UNISOC's dtsi: phys = <&ssphy>, <&ssphy>; > If to shutdown phy too earlier, it will cost 10s timeout to do xhci_reset. > usb_remmove_hcd --> usb_stop_hcd --> xhci_stop --> xhci_reset --> > xhci_handshake(&xhci->op_regs->command, CMD_RESET, 0, 10 * 1000 *1000) > > I want to know this change is acceptable or not? > > hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0); > Why in xhci_plat_remove, just to shutdown "usb-phy"[0], not to > shutdown "usb-phy"[1] ? xhci-plat.c only takes one phy at index 0, so we only shutdowns that one. Looks like usb core hcd code has better phy handling when adding and removing hcds. It supports multiple phys. If possible use that instead. See drivers/usb/core/hcd.c usb_add_hcd() Thanks -Mathias