Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp244853rdb; Tue, 5 Dec 2023 04:29:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IEtNDbqVlIFCWuwK+nSK1TJoRrY6fYNhIr75pep0DaeS8LVmnAkLsUO6Dc93yH38+BegD2E X-Received: by 2002:a05:600c:4f94:b0:40c:67a:b3bc with SMTP id n20-20020a05600c4f9400b0040c067ab3bcmr417532wmq.71.1701779382598; Tue, 05 Dec 2023 04:29:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701779382; cv=none; d=google.com; s=arc-20160816; b=ESFReDfxoY+vsm0TI2+KezUDsHiwlglt59TJMw0HkLYXlUdtfSDuMJZdQejIIwD2f4 8ugn2APhi3mlXgSMQ82FCx6R9YOszH5c38eoEVvBDln7k9bDnLiiYiuo6D1WSA85t9fs 665Tr3jPqjpN3re/RqbCj3XjYt1f2wZaCyi4XbUWS4DVkeTlke35RkjP0hptg9Zt1zgR RvVCzsNCdggVZXVT05m/EIsRA0WWZ8s9fYRG4SdbPBQPOCqO56lShIsAU9PxDineTJTZ UMDcNUe+AGYxlrdsL4VaBCDVkoTGhrIKDeI/YpRpgvzfEPb9hah07CiiyA1l1iAQUaPn bPtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from:dkim-signature; bh=yA9Ep3IckKInwdGSdz9t5swniADUh+6+qVX+/pXd4Dc=; fh=Cl7ddUYP4sFvI5Kp04jPk/PnN3dsz9YSSE+8/gkj2R8=; b=S68bxjzMOwwzu89PcR8AGfASgrP9mYpFG++ZRV2+TeHuK3BZAOzC2GZ8BKOHiTze/s HvTlJ7f0DSTzYDaNA7pKTpNxdinlHvAOCZMI3736upR/9BE3jFONZBgxPZyHiskYk7fH aIRgSIrscj9ayye8JdTx+uJ7FUJdtw+OKcUnyluHaMdjyn90mqLVF1MDDjXYEMFQsbBj VhTnjR+IMPkVbs6XgZo1E9yZ/XY7KLbUm9s6GnczZHXRNyjZGGWIw11yK7gvfi/rs35h jJa48xJ9HlYOHdb+CJ6dQvnxfbvKzcpzxmpm/iYf9vDr9UFl4iVOVkWz/XMXZY2tXqGj 5KNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K1PNPdrg; spf=pass (google.com: domain of linux-wireless+bounces-421-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-wireless+bounces-421-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id e18-20020a17090681d200b00a0adf2903dcsi5303076ejx.731.2023.12.05.04.29.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 04:29:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless+bounces-421-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K1PNPdrg; spf=pass (google.com: domain of linux-wireless+bounces-421-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-wireless+bounces-421-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 467EB1F213A1 for ; Tue, 5 Dec 2023 12:29:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5B28C5B5B9; Tue, 5 Dec 2023 12:29:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K1PNPdrg" X-Original-To: linux-wireless@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ED913B798; Tue, 5 Dec 2023 12:29:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC69AC433C7; Tue, 5 Dec 2023 12:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701779376; bh=sQfnpXdP3ZuhtY6P7yHJiQsXf+TlE9wlb2bR43cDiMM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=K1PNPdrg+nKHRnEPaHvq1lvbaaQs0VkDae7/YEVtktDoMCG2Tr3gdxOH9//bWObym PsvVVgP13UrWiGV6TdoSBtPHPli0/bosbyB0QpnCAmQabrMlHd47JcIh52KySaYm3z pGCpKvalVR3vVO1O9/fDjnWoQCjlH7Crw9fJiCCkwymSEoaxL7hge3t/AdgtscjjFP Jm6Zs2Z4vhqF9slH2xwgIIDvNasmugdaxDMDimVwGr4xP9nqeH7jAzxwQR/ysVmbtC UI4hSONLCyr5EyX+UDz02VjQr98cvXEq3vr+dzyHz20HRhxu5VU4bH75hZ6/NxVmVJ ZI+pGsw38nKMA== From: Kalle Valo To: Manivannan Sadhasivam Cc: mhi@lists.linux.dev, ath11k@lists.infradead.org, linux-wireless@vger.kernel.org Subject: Re: [PATCH RFC v2 1/8] bus: mhi: host: add mhi_power_down_no_destroy() References: <20231127162022.518834-1-kvalo@kernel.org> <20231127162022.518834-2-kvalo@kernel.org> <20231130054250.GC3043@thinkpad> Date: Tue, 05 Dec 2023 14:29:33 +0200 In-Reply-To: <20231130054250.GC3043@thinkpad> (Manivannan Sadhasivam's message of "Thu, 30 Nov 2023 11:12:50 +0530") Message-ID: <87v89cq1ci.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Precedence: bulk X-Mailing-List: linux-wireless@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Manivannan Sadhasivam writes: > On Mon, Nov 27, 2023 at 06:20:15PM +0200, Kalle Valo wrote: > >> From: Baochen Qiang >> >> If ath11k tries to call mhi_power_up() during resume it fails: >> >> ath11k_pci 0000:06:00.0: timeout while waiting for restart complete >> >> This happens because when calling mhi_power_up() the MHI subsystem eventually >> calls device_add() from mhi_create_devices() but the device creation is >> deferred: >> >> mhi mhi0_IPCR: Driver qcom_mhi_qrtr force probe deferral >> >> The reason for deferring device creation is explained in dpm_prepare(): >> >> /* >> * It is unsafe if probing of devices will happen during suspend or >> * hibernation and system behavior will be unpredictable in this case. >> * So, let's prohibit device's probing here and defer their probes >> * instead. The normal behavior will be restored in dpm_complete(). >> */ >> >> Because the device probe is deferred, the qcom_mhi_qrtr_probe() is not called and >> qcom_mhi_qrtr_dl_callback() fails silently as qdev is zero: >> >> static void qcom_mhi_qrtr_dl_callback(struct mhi_device *mhi_dev, >> struct mhi_result *mhi_res) >> { >> struct qrtr_mhi_dev *qdev = dev_get_drvdata(&mhi_dev->dev); >> int rc; >> >> if (!qdev || mhi_res->transaction_status) >> return; >> >> So what this means that QRTR is not delivering messages and the QMI connection >> is not working between ath11k and the firmware, resulting a failure in firmware >> initialisation. >> >> To fix this add new function mhi_power_down_no_destroy() which does not destroy >> the devices during power down. This way mhi_power_up() can be called during >> resume and we can get ath11k hibernation working with the following patches. >> >> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 >> >> Signed-off-by: Baochen Qiang >> Signed-off-by: Kalle Valo > > Any reason for reposting this series without discussing the suggestion from > Mayank? Baochen quickly sent me fixes for the v1 review comments, as I have been out of office for some time I didn't want to sit on Baochen's fixes for too long. Better to get them out of the door as soon as possible. I will definitely look at Mayank's proposal but that will take longer. > As I said in the internal thread, this patch breaks the Linux device > driver model by not destroying the "struct device" when the actual > device gets removed. This patchset has been tested by several people, I'm even using this patchset on main laptop every day, and we haven't noticed any issues. Can you elaborate more about this driver model? We are not removing any ath11k devices, we just want to power down the ath11k (and in the future ath12k) devices for suspend and power up during resume. > We should try to explore alternate options instead of persisting with > this solution. What other options we have here? At least Baochen is not optimistic that using PM_POST_HIBERNATION as a workaround would work. The issue we have here is that mhi_power_up() doesn't work in the resume handler and that's what we should try to fix, not make workarounds. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches