From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CD294F93C9 for ; Fri, 9 Oct 2026 18:16:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791569784; cv=none; b=jyTX2z4cjviyYYwme7gBOcxLW0lcLZ8wbnmJVmO0Mq8gSWZdJH5b/SU06FQe3O339A+ISH/mtpIsbtWQWTZg6E/922mL3dYe5GMO7QiyIk9VeXgQqL1ba0d8E9kOgBX49ygBJTB1CdIR3hsz0FI+fl/taGhiIr1LHhcGMDorN4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791569784; c=relaxed/simple; bh=mvTDjrt5Dv25R3e84Btc+sW0GIDNqjbWHM1WFt4kyIM=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=PTpdch9qWMKiQyNZLXT4gcptuW6e1usTgfIDNZUv8QkHGh+6yny6/3QTUEGvK4aY8l5L6ZOD4ySsw8de66m9rOrO6EeLl07AbY3EvPtAloqjfur5fFOqapmvu4tZNpWWF4Jl/rR4rItTmju5eO5OKWc93ZAvi+eliNjdLiyBIxo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--brianvv.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=uHfmligZ; arc=none smtp.client-ip=209.85.214.198 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--brianvv.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uHfmligZ" Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2e818ca61bfso17240885ad.2 for ; Fri, 09 Oct 2026 11:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1791569782; x=1792174582; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:mime-version:date:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/kiALaK1i6cuDxf/sysDWLUxJOWIbgnuKC2Zu4gvHcM=; b=uHfmligZJUMf9NEIjK8+rexxzGECBkA4KuJITj7YpfsIwnrvRnEe/Pj5MF2fVeaDNg p3DDiSX/XfsCi6yK9ynvix0jzTKlRMWE5WwB9B1pHPssiqMLyODkl0LlFvokaC9Kisxg 8bm2cPs3+CAeKd5BEJWC8jZ9I6HpH1Q0YQLz6wtCubcZe/f74jipZ79nx198AH3UFlZt R+0OPyOZBBlvGhZP0F9zbm86/kPCptYCUo/rz/CUonPA5Qj7/bv+HNVtdvU5yDiZ19+w 57ASKnoFW46pfux9MBbJ7NRpl4flWEK4tWN6RqWNionBoMXTnvm6tA2ys02z1cwbVD5t jXwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791569782; x=1792174582; h=content-type:cc:to:from:subject:message-id:mime-version:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=/kiALaK1i6cuDxf/sysDWLUxJOWIbgnuKC2Zu4gvHcM=; b=gn1GHWOJldozRWBOTnizk5BurNkLhLN5ABEy0ZGSNsY5BkedPPqgqO0f1hL5dJxwSZ uCl4sPhao+iPcFigEGWBZltRGmRDnY/aegFrfbPU+i85jJdeLU3jhUKDHNKSzmNRvoy6 0Ked51336zadM2Y3nQb4APJlaOEF1v7pUedTFZKbJJ3Q3yZTulSGsCj7EhFU5fE8YvTN /7fed9d5V4pSzOjeI6h9svc88IZ/mvrp6x1BKhISKfIP8TWuV5grw2pxeTYPeQ7llkRw kU52nThc9qT4Q3+jibrXOMVj1qK0gdSt1gf7thWoPxRhrOS48hwc6Iz0qkXX69Cfo2Td zHIg== X-Forwarded-Encrypted: i=1; AKwUvBxkKvK+qxn3CU9j1C1nn3IFRF8EPE+3ZHX5tujPQJ4cwFZFtlgX5h6ajUc1sASa62CcUdHWZGzxbZHZqoA=@vger.kernel.org X-Gm-Message-State: AFq9FYL5S2lLJXhNSSI7Vq4u9v/z3pPDMDV8kOnEnB9drA5tNpmKJK/G ucWkUNaHb4GxVF5cygxhRJb3BKDUHjyrZpWExRQgqPQSQ3XhwQWLZMW+5lFQMj/cfgmjHUyTpSe k76X6Lg4hgw== X-Received: from plcf10.prod.google.com ([2002:a17:903:104a:b0:2e5:6b23:1f55]) (user=brianvv job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ce0d:b0:2e5:6af9:a745 with SMTP id d9443c01a7336-2e842ac678amr21256985ad.23.1791569782074; Fri, 09 Oct 2026 11:16:22 -0700 (PDT) Date: Fri, 9 Oct 2026 18:15:53 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.56.0.385.gd3acb90ef8-goog Message-ID: <20261009181553.582029-1-brianvv@google.com> Subject: [PATCH iwl-net v2] idpf: wait for the reset completed state in idpf_check_reset_complete() From: Brian Vazquez To: Brian Vazquez , Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Cc: Madhu Chittim , Joshua Hay , Sridhar Samudrala , linux-kernel@vger.kernel.org, David Decotigny , Li Li , Emil Tantilov , Brian Vazquez , Paul Menzel Content-Type: text/plain; charset="UTF-8" PFGEN_RSTAT[1:0] / VFGEN_RSTAT[1:0] (PFR_STATE / VFR_STATE) encode the function reset progress as a 2-bit state, not a flag. From the IDPF specification [1], "PF Reset Status - PFGEN_RSTAT": 00b - reset in progress 01b - reset completed, written by the control plane 10b - function active, written by the control plane once the function has completed VIRTCHNL2_OP_VERSION 11b - reserved The "Function Level Reset" chapter of the same document has the driver poll the register until it reads 01b before re-initializing. idpf_check_reset_complete() tests (reg_val & rstat_m) as a boolean, with rstat_m = GENMASK(1, 0), so any non-zero state is taken as "completed", although only 01b carries that meaning. That only works if hardware moves the field to 00b as soon as the reset is triggered. On the Intel IPU E2100 (8086:1452) it does not: PFSWR transitions PFR_STATE to 00b only when the field currently reads 01b. When the function is active (10b) the field keeps its value until the control plane finishes the reset and writes 01b, which takes a few hundred milliseconds. Consequently, on a hard reset of an active function (IDPF_HR_FUNC_RESET) the first poll sees 10b, returns immediately, the driver re-creates the mailbox and sends VIRTCHNL2_OP_VERSION while the reset is still being processed. The control plane tears the mailbox down underneath it, VERSION is never answered, and the driver sits in a 60 second virtchnl timeout (-ETIME) before going through a second hard reset which then succeeds. An FLR on an active PF is enough to reproduce it: # echo 1 > /sys/bus/pci/devices/0000:01:00.0/reset [ 299.685030] idpf 0000:01:00.0: HW reset detected [ 299.715710] idpf 0000:01:00.0: Device HW Reset initiated [ 362.916087] idpf 0000:01:00.0: Device HW Reset initiated [ 364.318246] eth0: (slave eth1): link status definitely up, ... Nothing is logged during the 63 seconds; the timeout is silent on this path. Make idpf_check_reset_complete() wait for the state to be exactly 01b. This is the stricter reading of the register definition and it does not depend on how the field got to its current value: functions that are still in progress (00b) or active (10b) keep polling until the control plane reports completion. With the change the same FLR results in a single reset and the link is back after 1.5 seconds: [ 206.856635] idpf 0000:01:00.0: HW reset detected [ 206.887106] idpf 0000:01:00.0: Device HW Reset initiated [ 208.368721] eth0: (slave eth1): link status definitely up, ... [1] https://github.com/oasis-tcs/idpf-specification/blob/main/idpf_specification.md Fixes: 8077c727561a ("idpf: add controlq init and reset checks") Reviewed-by: Emil Tantilov Reviewed-by: Paul Menzel Reviewed-by: Li Li Signed-off-by: Brian Vazquez --- v2: reference the IDPF spec, name the device and add an FLR reproducer with before/after (Paul); collect Reviewed-by tags. No code change. drivers/net/ethernet/intel/idpf/idpf.h | 2 ++ drivers/net/ethernet/intel/idpf/idpf_lib.c | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf.h b/drivers/net/ethernet/intel/idpf/idpf.h index 470bc23c844c..ce8a1bd0ec8b 100644 --- a/drivers/net/ethernet/intel/idpf/idpf.h +++ b/drivers/net/ethernet/intel/idpf/idpf.h @@ -166,6 +166,8 @@ struct idpf_netdev_priv { spinlock_t stats_lock; }; +#define IDPF_RSTAT_COMPLETE 0x01 + /** * struct idpf_reset_reg - Reset register offsets/masks * @rstat: Reset status register diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c index 827c795afcb6..92eb3e9de77c 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c @@ -1874,7 +1874,8 @@ static int idpf_check_reset_complete(struct idpf_adapter *adapter, * register for us yet and 0xFFFFFFFF is not a valid value for * the register, so treat that as invalid. */ - if (reg_val != 0xFFFFFFFF && (reg_val & reset_reg->rstat_m)) + if (reg_val != 0xFFFFFFFF && + (reg_val & reset_reg->rstat_m) == IDPF_RSTAT_COMPLETE) return 0; usleep_range(5000, 10000); -- 2.56.0.385.gd3acb90ef8-goog