Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp562851pxb; Wed, 18 Nov 2020 11:15:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJwL+aHYizS8XO48o/Aex55toXQKTAKfKhW4ocWgD2PRh57CYUN/gTMnTmJMdfcbgQwxwtUv X-Received: by 2002:aa7:dbca:: with SMTP id v10mr27681592edt.219.1605726949955; Wed, 18 Nov 2020 11:15:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605726949; cv=none; d=google.com; s=arc-20160816; b=ufIIUd5GfR82N9kEjRDYv4JnmfAmMtWdJjCnYKVyoIIXTkAwSSQf0Y8PjQOmBvEJgg Hc0AystWc7Kt+6GAjF/Z+OWC1n6N0WeDId+RVjtvnvSybDVoQ8qZOFoTwrjBvzW6ghi5 RuYq9uXjRlhyaSP6uPxxnA1ME/G5MIDuRKMH8ejtO+pmALbLNotHdrl/LFN7N82NvQtW rXGv6QP+XtXr3WBLqTR3/KshBdscuFDzGLv3JxiIFcVt8BBDh16xZuc/xc0p/sEkgcHT gEYUA1IRNLpQSAiE97CRMx1KN4mMmyAI0yJFxaG/R5+znE8AurZAxkhIvdupuvgWycVd ysdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :mail-reply-to:reply-to:organization:subject:cc:to:from:date :content-transfer-encoding:mime-version:sender:dkim-signature; bh=8898U5caluN8Fm4wyA6ljvWBwAbzAR4kyIfffD9KtsU=; b=juLQKELz+6cosS/y18hlo8BdLdCrHE0mvQ+61X9dFAEWEscxeS4hYF3v9WO/P9IAse AsjzdrbXumKoRKJ8o+oTdLQminSKGzsPmkMK3K10HeRI1LMpP/45HqX3QkugoF2k12/L +hh5iBb5M7XZbm5VRdc/4Ny38qnSP1ckhE/cexFIy69QTnxqx7xdzeikHjGU/rI82beR 05YmMLXZ+z2NCcmUeqSPJN242WlvFIyF1pVgWZ9zWjLEyjYvopsSN62diJW2YwdI7v57 e/SXeqtsfxC+1BfX1Dy1Vw4+ZLk61ot5I67vFgpDlxtQjv1WtUMxL3PUxVufL9MPgGUb 5vVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=KNwTZtYD; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga10si15776580ejc.686.2020.11.18.11.15.13; Wed, 18 Nov 2020 11:15:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=KNwTZtYD; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725822AbgKRTNl (ORCPT + 99 others); Wed, 18 Nov 2020 14:13:41 -0500 Received: from z5.mailgun.us ([104.130.96.5]:49067 "EHLO z5.mailgun.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726020AbgKRTNk (ORCPT ); Wed, 18 Nov 2020 14:13:40 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1605726820; h=Message-ID: References: In-Reply-To: Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=8898U5caluN8Fm4wyA6ljvWBwAbzAR4kyIfffD9KtsU=; b=KNwTZtYDXAxSD1cgG+AHC4WIwZM7Kg5+3KmkN9/SuzvztyWi3U/1SKjR4Xq3vMnS4O9gwycg mrJ9yUuoWjjDLvodN2OR3nubVnC4aFPKt9YOuHv5kLf6QE4hyDasw1no3ou1MqxamWzHflkD Ia02yLBvE2z+8WNZyLwziiG3GY0= X-Mailgun-Sending-Ip: 104.130.96.5 X-Mailgun-Sid: WyI3YTAwOSIsICJsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n01.prod.us-west-2.postgun.com with SMTP id 5fb5726322377520ee7525f2 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Wed, 18 Nov 2020 19:13:39 GMT Sender: bbhatt=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id A6469C43462; Wed, 18 Nov 2020 19:13:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bbhatt) by smtp.codeaurora.org (Postfix) with ESMTPSA id D6E4CC433ED; Wed, 18 Nov 2020 19:13:38 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2020 11:13:38 -0800 From: Bhaumik Bhatt To: Jeffrey Hugo Cc: manivannan.sadhasivam@linaro.org, kvalo@codeaurora.org, linux-wireless@vger.kernel.org, cjhuang@codeaurora.org, linux-arm-msm@vger.kernel.org, hemantk@codeaurora.org, linux-kernel@vger.kernel.org, ath11k@lists.infradead.org, clew@codeaurora.org, loic.poulain@linaro.org, netdev@vger.kernel.org, jhugo=codeaurora.org@codeaurora.org Subject: Re: [PATCH] net: qrtr: Unprepare MHI channels during remove Organization: Qualcomm Innovation Center, Inc. Reply-To: bbhatt@codeaurora.org Mail-Reply-To: bbhatt@codeaurora.org In-Reply-To: <5e94c0be-9402-7309-5d65-857a27d1f491@codeaurora.org> References: <1605723625-11206-1-git-send-email-bbhatt@codeaurora.org> <5e94c0be-9402-7309-5d65-857a27d1f491@codeaurora.org> Message-ID: <4369f0e36886db303f5543b8a380b9d0@codeaurora.org> X-Sender: bbhatt@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi Jeff, On 2020-11-18 10:34 AM, Jeffrey Hugo wrote: > On 11/18/2020 11:20 AM, Bhaumik Bhatt wrote: >> Reset MHI device channels when driver remove is called due to >> module unload or any crash scenario. This will make sure that >> MHI channels no longer remain enabled for transfers since the >> MHI stack does not take care of this anymore after the auto-start >> channels feature was removed. >> >> Signed-off-by: Bhaumik Bhatt >> --- >> net/qrtr/mhi.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c >> index 7100f0b..2bf2b19 100644 >> --- a/net/qrtr/mhi.c >> +++ b/net/qrtr/mhi.c >> @@ -104,6 +104,7 @@ static void qcom_mhi_qrtr_remove(struct mhi_device >> *mhi_dev) >> struct qrtr_mhi_dev *qdev = dev_get_drvdata(&mhi_dev->dev); >> qrtr_endpoint_unregister(&qdev->ep); >> + mhi_unprepare_from_transfer(mhi_dev); >> dev_set_drvdata(&mhi_dev->dev, NULL); >> } >> > > I admit, I didn't pay much attention to the auto-start being removed, > but this seems odd to me. It allows fair and common treatment for all client drivers. > > As a client, the MHI device is being removed, likely because of some > factor outside of my control, but I still need to clean it up? This > really feels like something MHI should be handling. It isn't really outside of a client's control every time. If a client driver module is unloaded for example, it should be in their responsibility to clean up and send commands to close those channels which allows the device to clean up the context. In the event of a kernel panic or some device crash outside of a client's control, this function will just free some memory and return right away as MHI knows not to pursue it over the link anyway. Some client drivers depend on USB or other drivers, which allows flexibility on their end as to when to call these MHI prepare/unprepare for transfer APIs. Thanks, Bhaumik --- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project