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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 375AEC6FA82 for ; Fri, 9 Sep 2022 12:22:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231774AbiIIMWV (ORCPT ); Fri, 9 Sep 2022 08:22:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231736AbiIIMWC (ORCPT ); Fri, 9 Sep 2022 08:22:02 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DC176B660 for ; Fri, 9 Sep 2022 05:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662726052; x=1694262052; h=message-id:date:mime-version:from:subject:cc:references: to:in-reply-to:content-transfer-encoding; bh=LOOofKyG6XlG77YPdUwRLfc4Vtgxg4xNzvmukZ3T7V0=; b=gfEcyAczzywKMNRppZOBJypcnZVY/c+7wo6tBmEUfYXtDgkYQ0mEVvjc kq2nYulpLADAiTD4KH7xq0A8dgpCHt2dDK+QVgDjR/kUug80sY0DtBVQj NmX7G/i1bZ6KxaVnZ63zcxmGTJ7788AAw2viojxNXjlcyp+2rXMRzoRdW W8cHQENlEZe8wvVHzhbPx4Dk0z2GZCoyRfxmAj97O3OWBit2gUQBUJQdQ 8GeLGalozOONglPWZNroDsyNMkFtJNvMYqjFm2xNiN8+6fodGkP1Q3b55 Be6Vw+L7DvcbmOpyQyh86bHeehV6EdfrgYv9e+L3JnGuiNjabIeiA01iQ A==; X-IronPort-AV: E=McAfee;i="6500,9779,10464"; a="295043979" X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="295043979" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2022 05:20:51 -0700 X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="677140126" Received: from mckumar-mobl2.gar.corp.intel.com (HELO [10.213.87.132]) ([10.213.87.132]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2022 05:20:48 -0700 Message-ID: Date: Fri, 9 Sep 2022 17:50:46 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 From: "Kumar, M Chetan" Subject: Re: [PATCH net-next 3/5] net: wwan: t7xx: PCIe reset rescan Cc: netdev@vger.kernel.org, Jakub Kicinski , David Miller , Johannes Berg , Loic Poulain , "Sudi, Krishna C" , Intel Corporation , Haijun Liu , Madhusmita Sahu , Ricardo Martinez , Devegowda Chandrashekar References: <20220816042353.2416956-1-m.chetan.kumar@intel.com> <56a42938-c746-9937-58cb-7a065815a93f@linux.intel.com> Content-Language: en-US To: Sergey Ryazanov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 9/7/2022 3:49 AM, Sergey Ryazanov wrote: > On Fri, Sep 2, 2022 at 7:50 AM Kumar, M Chetan > wrote: >> On 8/30/2022 7:32 AM, Sergey Ryazanov wrote: >>> On Tue, Aug 16, 2022 at 7:12 AM wrote: >>>> From: Haijun Liu >>>> >>>> PCI rescan module implements "rescan work queue". In firmware flashing >>>> or coredump collection procedure WWAN device is programmed to boot in >>>> fastboot mode and a work item is scheduled for removal & detection. >>>> The WWAN device is reset using APCI call as part driver removal flow. >>>> Work queue rescans pci bus at fixed interval for device detection, >>>> later when device is detect work queue exits. >>> >>> [skipped] >>> >>>> diff --git a/drivers/net/wwan/t7xx/t7xx_pci_rescan.c b/drivers/net/wwan/t7xx/t7xx_pci_rescan.c >>>> new file mode 100644 >>>> index 000000000000..045777d8a843 >>>> --- /dev/null >>>> +++ b/drivers/net/wwan/t7xx/t7xx_pci_rescan.c >>> >>> [skipped] >>> >>>> +static void t7xx_remove_rescan(struct work_struct *work) >>>> +{ >>>> + struct pci_dev *pdev; >>>> + int num_retries = RESCAN_RETRIES; >>>> + unsigned long flags; >>>> + >>>> + spin_lock_irqsave(&g_mtk_rescan_context.dev_lock, flags); >>>> + g_mtk_rescan_context.rescan_done = 0; >>>> + pdev = g_mtk_rescan_context.dev; >>>> + spin_unlock_irqrestore(&g_mtk_rescan_context.dev_lock, flags); >>>> + >>>> + if (pdev) { >>>> + pci_stop_and_remove_bus_device_locked(pdev); >>> >>> What is the purpose of removing the device then trying to find it by >>> rescanning the bus? Would not it be easier to save a PCI device >>> configuration, reset the device, and then restore the configuration? >> >> If hotplug is disabled, the device is not removed on reset. So in this >> case driver need to handle the device removal and rescan. > > I still can not understand this part and need a clue. Why should the > driver disable the hotplug? This is a platform configuration, it could be set to enable/disable. We can find this option in BIOS settings. > And is there a more gentle way to reset the firmware without the > device object removing? Device reset causes WWAN device to fall off the BUS. If device had not fallen off the bus then we could have reused. Without these changes, we need to manually execute device remove & rescan commands. Could you please suggest how can we proceed here ? -- Chetan