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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8C236CD98E2 for ; Wed, 17 Jun 2026 15:47:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kZkkt7pTAcwVisdd5LWiHecZhGxj27GXnwp7KJTgyC4=; b=RLb5NW+diGiDcbL/SNu+fCTlgz s03PWk0Fw+5NsdqRZW9IRxYTRwyYk5ONhebZTcgrTAen4ydaMdKowRdzh4JiA+bplsxiV5hC/c1Dw cVNYicgE5PdMCK8xvt9Zsr/h3RCXIdOOxnVhdQnVciGl3dzMobkKkttEqZG/VO7l02KLMJUq6af0a QVzWpvniBjpyUx9eERwX1N6RR5YcH7bOKEc4eEdusJlFh6g6d/pNg5+X1sJdz+25Ky6EWJgb2kMYL 0byrlwhaT2l6WZ2CSp6osZYuZjRsy9m7/yyYrgJoEKg288C4gZSb0yFNeL8huVg5qm1f8fZdgftoH /MBRykzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZsU9-0000000HaDr-2CBX; Wed, 17 Jun 2026 15:47:25 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZsU6-0000000HaCv-3Oc7 for ath11k@lists.infradead.org; Wed, 17 Jun 2026 15:47:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781711242; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kZkkt7pTAcwVisdd5LWiHecZhGxj27GXnwp7KJTgyC4=; b=G6qcqYnrQg5OgMaATLiCaXkofo22Z2+2Ed5ZTsHGbTBldfESI0jsyqA8Mdft3+hftskbW3 u5WjFip3CHrXzYqoTj23MsFaiOoLYm4wZHZp2S/aNGTEs6RWwTpom70n6VJrMDhOHVV+Oc OsHStW2AcN65pRkoxV18hKgsGp2eGzw= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-661-X1sZflmnMEizcLDBGUmEqw-1; Wed, 17 Jun 2026 11:47:17 -0400 X-MC-Unique: X1sZflmnMEizcLDBGUmEqw-1 X-Mimecast-MFC-AGG-ID: X1sZflmnMEizcLDBGUmEqw_1781711236 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C724519539BC; Wed, 17 Jun 2026 15:47:15 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.32.13]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B77E11771; Wed, 17 Jun 2026 15:47:10 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: mani@kernel.org Cc: alex@shazbot.org, ath11k@lists.infradead.org, ath12k@lists.infradead.org, bhelgaas@google.com, jjohnson@kernel.org, jtornosm@redhat.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org, mhi@lists.linux.dev Subject: Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices Date: Wed, 17 Jun 2026 17:47:04 +0200 Message-ID: <20260617154709.186286-1-jtornosm@redhat.com> In-Reply-To: <6nivb5fncfd5dwqkzlxwhtgbsiqvifazcbgpsgukp44iib45ke@65qpwgrvtkgn> References: <6nivb5fncfd5dwqkzlxwhtgbsiqvifazcbgpsgukp44iib45ke@65qpwgrvtkgn> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 X-Mimecast-MFC-PROC-ID: 3_DYvwDD22T5fnjYLsJyHzWjNu8p1RIGXx_BA4nr5nM_1781711236 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260617_084722_934867_DA6F5ADE X-CRM114-Status: GOOD ( 10.52 ) X-BeenThere: ath11k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath11k" Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org Hi Mani, Thank you for the internal clarification and sharing this information. I understand the behavior is firmware error recovery, not a proper reset. However, these devices are widely used, and the inability to use them in VMs is a significant problem. Could we explore options to achieve safe VFIO operation? 1. Are there ANY alternative reset mechanisms besides D3cold? For example: - Device-specific registers or commands? - MHI bus-level operations? - Firmware commands that could trigger proper reset? If such mechanisms exist, I'm willing to implement whatever is needed. 2. If firmware error recovery is the only option available on platforms without _PR3, could we add software steps to make it VFIO-safe? For example, before/after the D3hot transition: - Explicit MHI state teardown? - Firmware commands to clear sensitive device state? - Additional verification or cleanup steps? 3. The practical challenge is that _PR3 support is not available on most platforms where these devices need to be deployed (desktops, servers). Additionally, the general d3cold reset method has limitations and remains unimplemented due to the concerns raised earlier (ACPI portability, bridge issues, runtime PM complications). If D3cold is the only proper reset but requires _PR3, and no alternative mechanisms exist, could we consider accepting the firmware error recovery behavior as a last resort - clearly documented as a platform-specific workaround? Currently these devices have no reset capability on most platforms, making them completely unusable for VFIO. Even an imperfect reset is significantly better than no reset at all. My goal is ensuring these devices can be safely reassigned between VMs. I'm open to implementing any of the above approaches - or others you might suggest. Thank you Best regards José Ignacio