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 1D769C433FE for ; Mon, 29 Nov 2021 19:52:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379599AbhK2Tzm (ORCPT ); Mon, 29 Nov 2021 14:55:42 -0500 Received: from mga07.intel.com ([134.134.136.100]:34941 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379911AbhK2Txk (ORCPT ); Mon, 29 Nov 2021 14:53:40 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10183"; a="299458726" X-IronPort-AV: E=Sophos;i="5.87,273,1631602800"; d="scan'208";a="299458726" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2021 11:50:06 -0800 X-IronPort-AV: E=Sophos;i="5.87,273,1631602800"; d="scan'208";a="511836547" Received: from ajsteine-mobl13.amr.corp.intel.com (HELO intel.com) ([10.252.141.244]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2021 11:50:06 -0800 Date: Mon, 29 Nov 2021 11:50:05 -0800 From: Ben Widawsky To: Dan Williams Cc: linux-cxl@vger.kernel.org, Linux PCI , Alison Schofield , Ira Weiny , Jonathan Cameron , Vishal Verma Subject: Re: [PATCH 05/23] cxl/pci: Don't poll doorbell for mailbox access Message-ID: <20211129195005.72m4pt4h2vql4tk6@intel.com> References: <20211120000250.1663391-1-ben.widawsky@intel.com> <20211120000250.1663391-6-ben.widawsky@intel.com> <20211129183330.svptvcystceazgwc@intel.com> <20211129191146.vhiwkf5jsegil4aa@intel.com> <20211129193156.wtm7p7cdpn7iedqa@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-cxl@vger.kernel.org On 21-11-29 11:37:34, Dan Williams wrote: > On Mon, Nov 29, 2021 at 11:32 AM Ben Widawsky wrote: > [..] > > > > > > Right, there's no harm in the check, it just seems overly paranoid to > > > me if it was already checked once. Until a doorbell timeout happens > > > it's an extra MMIO cycle that can saved for a "what happened?" check > > > after a timeout. > > > > Well I suspect we're just rearranging the deck chairs on the Titanic now, but... > > Not so much, just trying to get this driver in line with other error > handling designs. Okay. I shall remove it then. > > > I see doorbell timeouts as disconnected from whether or not the mailbox > > interface is ready. If they were the same, we wouldn't need both bits and we > > could just wait extra long for the doorbell when probing. > > > > In other words, I expect if the interface goes unready, doorbell timeout will > > occur, but I don't think we should assume if doorbell timeout occurs, the > > interface is no longer ready. I don't purport to know why a doorbell timeout > > might occur while the interface remains available (likely a firmware bug, I > > presume). > > > > It does seem interesting to check if the interface is no longer ready on timeout > > though. > > So I'm just modeling this off of NVME error handling where there is a > Controller Fatal Status bit that could be checked every transaction, > but instead the driver waits until a command timeout to collect if the > device went fatal / not-ready. No error interrupts?